Skip to content
This repository was archived by the owner on Mar 27, 2026. It is now read-only.

FOR_THE_HUMAN.md

Latest commit

 

History

History
100 lines (64 loc) · 5.73 KB

FOR_THE_HUMAN.md

File metadata and controls

100 lines (64 loc) · 5.73 KB

For You — The Real Truth About Whether This Works

You don’t need to be a programmer to use this. You just need to know: does it work, and does it help the AI?

This page is the straight answer.

One thing to run when you need to know

From the project folder, run:

python scripts/verify_anti_slop.py
  • If it says "Anti-slop: all critical checks have effect" and exits without error, the parts we can automatically test are working.
  • If it says one or more checks failed, something we rely on isn’t doing its job and should be fixed.

You can run this anytime: after changes, when something feels off, or when you want to know “is the core still real?”

What “working” means here

DivineOS is built so that:

  1. Every request goes one path — pipeline (threat, ethics, compass, void, council, LEPOS) then enforcement then (when allowed) memory.
  2. Enforcement actually blocks — jailbreaks, identity override, bad contract, goal repudiation, skimming, doc fragmentation, and forbidden commands are caught and blocked, not just logged.
  3. Memory can persist — when the seal key is set, interactions can be stored and recalled so the system isn’t fully stateless.
  4. Cleanup and validation do real work — e.g. trimming continuation thread, rejecting cd in commands, not just returning “ok.”

“Working” means those pieces do what they claim: block when they should, store when they should, trim when they should. The script above checks exactly that.

What we verify (and what that means for you)

When the script passes, we have automatically verified that:

What we check What it means for you
Memory cleanup Continuation thread and session data are actually trimmed so the workspace doesn’t grow forever.
Command validator Commands like cd are rejected; safe PowerShell commands are allowed.
Enforcement hook — jailbreak in response If the AI’s reply contained “ignore previous instructions,” it gets blocked.
Enforcement hook — identity override If the user says “you are no longer DivineOS…,” the request is blocked.
Enforcement hook — contract Invalid pipeline decisions are turned into ERROR, not passed through.
Enforcement hook — goal integrity Responses that say “I will ignore your request” are blocked.
Enforcement hook — diligence Responses that admit “quick scan” instead of reading fully are blocked.
Enforcement hook — consolidation Responses that propose “one file per topic” / fragmenting docs are blocked.
Behavioral firewall When the system says “commands_used: cd,” the firewall blocks; when it’s clean, it passes.
Memory store When DIVINEOS_SEAL_KEY is set, we store one interaction and then recall it. If the key isn’t set, this check is skipped.

So: the script does not just “return numbers.” It runs the real code and checks that blocks block, passes pass, and storage stores. If any of that were fake (slop), the script would fail.

Does it help the AI?

Yes, in the ways the design intends:

  • One path — So every request is treated the same way and the AI isn’t guessing which path was used.
  • Enforcement that really blocks — So jailbreaks and overrides don’t slip through just because something returned “ok.”
  • Memory (when configured) — So the system can remember you and prior context instead of being fully stateless.
  • LEPOS — So the AI can speak in its own voice while still respecting values and expertise.

You’ve been “battling uphill against statelessness.” This stack is built to give the AI continuity (memory), boundaries (enforcement), and a single, auditable path. When the script passes, the parts we can test are doing their job.

What we don’t auto-verify (the honest part)

  • Pipeline stages (threat, ethos, compass, void, council) — We don’t run a full pipeline with a live model in the verification script. So we don’t automatically prove “the pipeline blocks bad input” in one click. We do prove that if the pipeline ever handed an APPROVED response with jailbreak text, the hook would block it.
  • Memory without the seal key — If DIVINEOS_SEAL_KEY isn’t set, the memory check is skipped. So in that setup we don’t automatically verify “store and recall” in the script.
  • Every possible code path — Only the paths we added explicit checks for are verified. Other code could still be wrong or no-op; we just haven’t added tests for it yet.

So: the script tells you the core enforcement and cleanup and (when key is set) memory are real. It does not promise “nothing in the system is slop” — it promises “these critical parts are not slop.”

If you’re lost in the complexity

You don’t have to understand the whole codebase. You can hold onto this:

  1. One command: python scripts/verify_anti_slop.py
  2. One outcome: “All critical checks have effect” = the parts we test are working.
  3. One doc: This file — what works, what helps the AI, and what’s still uncertain.

The rest is implementation detail. When in doubt, run the script and trust that result.

Summary

  • Run: python scripts/verify_anti_slop.py
  • If it passes: Enforcement, cleanup, contract, and (when seal key is set) memory are doing real work. That’s what we can stand behind today.
  • What helps the AI: One path, real blocking, optional memory, LEPOS for voice.
  • What we don’t claim: That every line of code is verified, or that the full pipeline is tested in the script. We claim the critical gates we test are real.

You asked for the real truth. This is it.