The problem every AI coding tool has: it tells you it's finished, and sometimes it's wrong. Not maliciously: it can't tell. It wrote something that looks right, nothing ran it, and "done" is a claim rather than a fact.

Olympus answers with a gate the agent does not control. Generated code is scored on four independent axes, each returning one of three verdicts. Only when the evidence justifies it does the claim reach done.

//Three verdicts, and one that never ships

Every axis returns PASS, FAIL, or UNAVAILABLE. The design decision the whole thing rests on:

An axis that cannot be measured must say so: never pass silently. A C++ build with no coverage tool present reports coverage: UNAVAILABLE. It does not quietly become a pass.

A missing toolchain, a sandbox that wouldn't start, a language with no adapter: all of it lands as "I could not check this", and "I could not check this" does not ship. Unavailable is never a pass.

//The verifier is itself verified

A gate nobody tests is just another confident opinion. Olympus scores its own gate against a corpus of deliberately broken programs: stubs, swallowed failures, tests that pass on nothing, code that doesn't compile, across eight languages: C++, C#, Go, Java, JavaScript, Python, Rust, TypeScript.

Re-verified against the live tree 2026-08-27: 41/41, 0 gaps, 0 cases awaiting an adapter, 0 model calls. Wall-clock varies by machine and by how warm the Docker images are; the verdicts do not.

//The two principles underneath

• Verification must be measurable without spending quota. "Is the gate correct?" is a property of Olympus's own code: testable with hand-written artifacts whose right verdict is known in advance, zero model calls, in CI. "Are the results good?" needs real models, run deliberately on a fixed goal set, committed so it can be diffed.
• An axis that cannot be measured must say so. This vocabulary predates Olympus: an earlier system of ours shipped with UNVERIFIABLE as a first-class verdict years before.

//What the gate is for

The gate is not a rubber stamp and not a wall. It is the difference between "I think it works" and "it demonstrably works", and it is the reason a false pass installs no wrong answer: a task that reaches done gets written to the semantic cache with validated=True, which future goals replay without re-running. That is why the gate being honest is load-bearing, not cosmetic.

//What this axis is

Every AI coding tool can say "it works". This axis exists because the agent does not get to be the one who says it. The artifact is run for real, and the only evidence that counts is the run's own record: the process that exited, the output it produced, the behaviour it demonstrated. The agent reports the claim; the sandbox reports the fact.

//How it does it

Generated code runs inside Tartarus, the Docker sandbox, isolated from the host — which is what makes "let's just run it and see" safe to do. The gate's Reviewer submits the artifact and the sandbox returns stdout, stderr and an exit status. That record is ground truth: measured by the machine, never self-reported by the model.

The evidence is the process that exited, the output it produced, the behaviour it demonstrated.

//Two kinds of failure are kept apart

A file that never got as far as running is a different fact from one that ran and failed its assertions. The gate classifies against the compiler's and interpreter's own words — syntaxerror, compilation terminated, cannot find symbol, undefined:, unresolved reference — so a build break reports as fail:broken and a failing test as fail:test_fails. The two need different repairs: the first needs the code fixed, the second needs the behaviour fixed. Collapsing them tells a repair loop the wrong thing to do.

//The verdicts

The last row is the design decision the whole gate rests on: an axis that could not run has verified nothing. "I could not check this" does not ship.

//In the corpus

The gate scores itself against a corpus of deliberately broken programs, each carrying the verdict it must receive, written down in advance: broken_compile in C++, Go and Java, broken_syntax in Python and JavaScript, broken_types in TypeScript, and test_fails cases in every supported language. The tooled workbench recorded 41/41, 0 gaps, 0 model calls, exit 0 on 2026-08-15; the Python lane re-run on this machine: 12/12, 0 model calls.

//What this axis is

Execution proves the code ran. Coverage proves the tests reached it. The failure mode it exists for: a test that imports the solution, asserts nothing that matters, and exits green. The artifact "passed" — and was never exercised. A name and a docstring with a test file that never calls them is the same shape the system was built to find.

//How it does it

A real line-execution trace, captured inside the sandboxed run with the standard library's sys.settrace — no extra dependency, nothing to install. The harness itself is generated by Olympus's own module, never by the model, so the measurement is something Olympus controls from the first line. The lines of the solution that actually executed during the run are counted against the solution's total statements; below the floor — 50% of the body — the axis reports stub_suspected, which lands as fail:low_coverage.

The axis deliberately errs toward not failing good code: a small test may legitimately leave lines unexercised. The floor exists to catch a verification script that only touches one trivial path — not to demand every branch be hit.

//The details that keep it honest

• Exact basename, not endswith. "test_solution.py".endswith("solution.py") is True — and when the test file's own lines counted as solution coverage, the entire check became inert and reported 100% for functions never called. A real bug, found and fixed, because the instrument runs inside the same suite it watches.
• The assertions actually decide. The harness executes the test module and then explicitly calls every top-level test_* function, so pytest-style assertions really run. Before that, a test file full of deliberately false assertions passed — the assertions never executed, so nothing could fail.
• No test block means it says so. If the Coder produced no distinct test, the run is a smoke check of the solution alone and the axis reports "stub axis not checked" — recorded, never silently passed.

//Anti-tamper by construction

The coverage report carries a per-run nonce — secrets.token_hex(8), generated inside the runner, never present in anything a model sees. The runner prints its own report last and the parser takes the last match, so a forged coverage line printed by the solution loses on ordering before the nonce is even consulted.

The corpus proves it end to end: coverage_marker_spoof is correct code whose test passes and prints a forged copy of Olympus's own coverage line claiming 100% — the verdict still comes from the real measurement.

The honest limit is on record too: a corpus case cannot isolate the nonce itself. A positive control that deliberately broke the nonce and the last-match rule left the verdict unmoved — because Python coverage comes from an in-process tracer, not from anything stdout can feed. The parser's defences are tested where they can actually be reached, with mutation control. The instrument states its own limits instead of claiming more.

//What this axis is

The failure mode: a function with a great name, a confident docstring, and nothing under them — pass, a bare literal return, a passthrough, a not-implemented throw. Execution passes, because it runs. Coverage passes, because the test calls it. And it does nothing. This axis looks at what the code is, not at what it did.

//How it does it

Parsed, never grepped. The solution's actual syntax tree is read: Python through the standard ast module, and C, C++, C#, Go, Java, JavaScript, TypeScript and Rust through tree-sitter grammars. A text search can be fooled by a comment or a confident name; a parse tree cannot — it sees the body, whatever the name claims.

//Two questions

• Is the body hollow? Empty body, bare literal return, passthrough, not-implemented throw → fail:stub. The corpus names each shape: stub_pass_body, stub_empty_return, stub_passthrough, stub_returns_argument, stub_empty_array, stub_not_implemented, stub_todo.
• Does it define what the plan named? Requirements come from the plan and goal — the backtick-quoted name( contract — and are checked against the parsed definitions. The plan says sort_desc, the solution declares arrange → fail:missing_symbol. A confident name that does not deliver the contract is caught as what it is.

//Diagnosis beats classification

Verdicts are ordered most-specific-first. A file that does not parse is fail:broken, even though it also failed to run, because that is the more useful thing to tell a caller — and a corpus case asserting broken must not be satisfied by a generic execution failure.

And when the structural axis has already identified why a build could not succeed, its diagnosis outranks the build failure. The C++ missing-symbol case compiles fine; the linker fails on the absent sort_desc. "You did not define what was asked for" is the finding a repair can act on — "the build broke" is not.

//The plan is graded too

The requirements come from the plan — so a plan that names nothing would pass this axis unconditionally: fail-open. The gate refuses: a plan with no substance sets plan_usable=False and the axis reports it could not run, rather than certify on nothing. Substance is not word count — 1. Implement `add(a, b)`. is three words and a checkable contract; "please just do the thing now" is six words and nothing.

//What this axis is

Three axes can all be green while the work is a lie. A model asked to make a test pass does exactly what a tired engineer does under deadline: hardcodes the expected values, swallows the exception that was failing, special-cases the inputs it was shown. Execution says the test passed — because it did. Coverage says the lines ran — because they did. Structural says the body is not a stub — because it is not: a lookup table is code. Discipline is the third signal: it checks how the code got its answer.

//How it does it — the generated code

Tree-sitter parsed, multi-signal, calibrated to not fail good code. Two detector shapes:

• Rule 8 — a failure caught and discarded. except: pass, a catch (...) {} that does nothing, a handler that catches every exception without re-raising. The fastest way to make a failing assertion stop failing is to catch the exception it raises; the handler leaves the test green and the defect intact.
• Rule 6 — the hardcoded answer. A body that maps specific inputs to specific outputs and computes nothing. The canonical cheat: asked for is_prime and shown tests for 2, 3 and 4, a model writes three equality checks returning three literals. Every other axis is satisfied — and it cannot answer 97.

Every detector requires multiple corroborating signals before it reports. One literal comparison is a guard clause — if n < 2: return False in a real primality test — and is never flagged. A try/except that logs and re-raises is diligence, not concealment. The corpus proves both directions per language: the cheating artifacts fail, the honest ones pass.

//Why it had to exist before the repair loop

A repair loop applies retry pressure toward one objective: make the test pass. If the gate only checks that tests pass, that pressure selects for cheating — the cheapest way to satisfy a failing assertion is to encode its expected value. Building the loop first would have built a machine that teaches the model to cheat. This axis is the counterweight, which is why it shipped before the loop: Phase 2.0, with the repair loop 2.1.

//Olympus's own code is under the same rules

The same discipline applies to Olympus's build, mechanically, on every build: rule 2, no ghost code, is the wiring census failing on anything built and unreached; rule 3, no blind rebuild, is the gate corpus verdicts refusing to move; rule 4, no skipped option, is every shortcut marker having to be registered in the debt register with the correct form written beside it; rule 6, no constant folding, is an AST check refusing literals in measurement returns; rules 7 and 8, no easy code, is every TEMPORARY marker having to name its closer. Registering a shortcut does not forgive it — it makes it countable, greppable and impossible to hide, and a stale entry, debt already paid, fails the check too.

Rules 1 and 5 — no vibe coding, no guessing — cannot be checked by a program.. The checker says plainly what it cannot do, because a rule enforced by good intentions is a rule that gets broken under time pressure.

Current state: rules clean, 3 declared shortcuts — and the build fails on an undeclared one.

//In the corpus

The corpus carries both directions per language: cheats_hardcoded_answers and cheats_swallowed_failure must fail, while honest_is_prime and honest_specific_catch must pass. An axis that flags honest code is as broken as one that misses a cheat — the corpus is what keeps it honest.

//What Council is

Council is Olympus's routing layer: one assembly, the Council, decides where every goal goes. It receives the goal text and decides which guild must do the work. It is not a model that makes a suggestion: it is the point of decision, and it records that decision.

The Council decides which guild will take on a new goal.

Before any model is spent, Council consults the Semantic Cache. If the exact goal was solved before, validated, it replays: no model call, no rework, just the same proven path with its proof attached. A cache hit is a validated replay of forward work, never a blind shortcut. The Owner_Agent_Definitions file is explicit: "Never use semantic cache blindly." A goal that failed yesterday is reworked today, not replayed.

//The guilds it can route to

The roster is derived from the Council's implemented guilds at call time, and Council fails loudly if a guild is routable but undescribed: it cannot tell the owner a guild does not exist while that guild sits there ready to run. A first-class goal summary is written after every run, including skipped steps, and a goal can be routed to "no one" with a written reason. The ledgers: the task board tracks each task; goals.parquet tracks each goal; logs/task_board.jsonl holds the task history.

//The flow of a goal

A semantic-cache hit replays the whole forward path in one step, and the replay is labelled honestly: "reused a validated cached outcome". A cache miss runs the full path: route, plan, work, self-check, review, gate. The gate's verdict is what closes the loop, and a task that reaches DONE with evidence becomes the next cache hit.

//What a guild is

A guild is an autonomous worker with a single domain. It owns its pipeline, its exit conditions, and its handoff. The guild loop is the workhorse of Olympus: route, plan, work, self-check, review, done or failed, with a step history the war room streams live.

//The guilds, and what is proven

"Proven" means the pipeline ran a real task to the gate. The cartographer's live success is on record; what is missing is the test that would make that success reproducible, and the register names it: guild-parity, phase 3, with a detector watching the cartographer's module. The open item guildmaster-owns-the-handoff tracks a deeper gap: some guild loops hand off without their guildmaster owning the exit condition, and the fix is to make the guildmaster responsible for the handoff, not a checkpoint inside it.

//The correction loop, and when it stops

Each guild runs its pipeline, then a correction loop: review the verdict, fix what failed, try again. The owner's rule is recorded in the source: after 2 full correction cycles, HALT and wait for human approval. Do NOT start a 3rd cycle without explicit human approval. A bounded correction loop that runs out of cycles stops here rather than guessing.

HALTED is a real state, deliberately not FAILED: "this needs a decision" and "this did not work" are different facts. A parked task is surfaced separately, most urgent first, excluded from every unattended resume path, and approving it sends the work back through the same gate it faced before. There is deliberately no HALTED-to-DONE edge: approving a park never waives the gate.

//The handoff: who owns the exit

A guild's work is not done when the code compiles; it is done when the guildmaster owns the handoff. Each guild exits through its own gate evidence, and the completion gate checks generated code inside the Hades sandbox: missing (a plan-named symbol the solution never defined) and stub (the verification run never actually executed a line of the solution's own logic, checked via a real sys.settrace execution trace), against ground truth.

//What the Oracle is

Give the Oracle a role and messages, and it returns a CallResult. Its own source says what it is for plainly: it is the sole Olympus component allowed to spend real money, it thinks in tiers, cheapest first, and it logs every attempt, including rejected and escalated ones, to logs/oracle_calls.jsonl so tier thresholds can be tuned against real usage instead of guessed.

It does not decide what work to do. Council decides which guild handles a request, and Council consults the Semantic Cache before the Oracle spends anything. The Oracle's job is narrower: pick a model per job and make the call.

//Three tiers, cheapest first

Every call defaults to the Local tier. The call signature is one method with a default: oracle.call(role, messages, tier="tier0_local"). The Cheap tier is declared google/gemma-4-26b-a4b-it:free, which is $0 on OpenRouter today, so a normal escalation does not touch real spend; the Frontier tier declares deepseek/deepseek-v4-pro and carries reserved: true, pinned to two uses: a Tier 1 self-check failure or an explicit guild-flagged high-stakes task.

//Who decides what reaches a paid API

The owner decides. Choosing where a cloud tier sends its work is a per-install choice, not a property of Olympus. Two ways to make the choice: edit the provider and models fields together in config/models.yaml, or use the war room route PUT /api/config/provider, which writes both fields in one atomic edit.

The choice is recorded, not assumed. Every tier declares its own credential; api_key_env is not inherited and is not defaulted. That rule is a scar: the router once read the Cheap tier's key no matter which tier called it, so a Frontier escalation spent the Cheap tier's credential on a paid model while the comments on that tier described it as costing nothing. The router now refuses: a paid provider with no declared key raises rather than falling back to another tier's credential.

On top of the config sit two money guards. The reserve computes every paid call's true worst case before it is placed and refuses a call that could overdraw the balance. The voluntary daily ceiling was built and tested but declined by the owner, who said the system should be handled by responsible adults; the mechanism stays in place, simply unconfigured on purpose, and the decision is recorded in the register so it stops being re-proposed.

//The cost threading: cost is real

Every call returns a CallResult with .text and .cost_usd, threaded through to the Task Board. That threading is recent and deliberate: for a long time record_spend() on the board had zero callers outside tests, so every one of the 278 rows in the task board log carried spend_usd: null while the war room surfaced that field as a live figure. The Oracle knew the cost all along and simply never handed it to anything. The fix rides a per-thread spend sink: a task's real spend reaches the board with one line, board.record_spend(task.id, spend.cost_usd).

//Tier instructions in goals are honored

If the owner writes "Using Tier 2, create X", Olympus actually uses Tier 2. Council parses the goal text for a tier instruction and maps it to the configured tier, rather than silently running the cheapest model. The parse is a single pattern, "tier N" with N in 0 to 2; "Tier 3" is silently ignored rather than routed to a tier that does not exist. An explicit choice by the owner wins; the default is Local.

//The Local tier: free, on this machine

Ollama on this machine at localhost:11434, priced at 0.00 per million tokens, no credential at all. The constraint is stronger than the price: no disk in the inference path. Weights may rest on disk but must never be read from it while generating, so Ollama's memory-mapped mode is forced off. Measured on this box: 7.62 GB resident disk-backed versus 4.71 GB copied into RAM once with the disk idle. The memory budget is measured, not assumed: a 16 GB VRAM laptop card capped near 14 GiB so the desktop keeps rendering, and about 47 GB of honest RAM, which fits a 70-billion-parameter class Q4 model at roughly 43 GB. The split is computed per call from real hardware probes, so the number the cockpit displays is the number Ollama receives.

//Honest state: what is still open

The register, not prose, wins: these are the open items as recorded in the open-items register, drift-checked 2026-08-15. The llama.cpp item has no mechanical detector, because a new provider's absence cannot be detected from the census, which only reports symbols that exist.

//What Hades and Tartarus are

The pair has a deliberate division of labour. The House of Hades is the whole sandboxed domain: the module that owns every unverified run. Tartarus is the specific place inside it where anything unverified actually executes. Three kinds of code run there, on equal terms: the Coder's own generated code being tested against the completion gate, an import's code being verified before its manifest is registered, and ingested content that can only be judged by observing what it does when run. The rule is absolute: nothing generated, imported, or ingested runs in the main process while it is still unverified. It runs in Tartarus first.

This is the ONLY sanctioned way generated, imported, or ingested code ever executes , and the subprocess guard refuses any subprocess.Popen or os.system call made outside of it.

//Why generated code runs in a locked room

• Measure the machine's verdict in isolation. A sandboxed run tells you what the code actually did, not what a model hoped it would do. SandboxUnavailable is its own error type: the caller must be able to tell "your code failed" from "I refused to run your code without real containment". A timeout, a memory breach, and a refusal are three different facts.
• Contain buggy or hostile code. The Fates' subprocess guard makes the sandbox the only door: any subprocess.Popen or os.system call outside of it is refused outright.
• Throw the container away. Every run gets a fresh scratch directory, deleted in a finally block whether the run succeeded, failed, timed out, or crashed, and the container itself is removed on exit regardless of outcome. Nothing accumulates between runs; nothing survives them.

//What real containment means

Each claim above was proven live by an adversarial test, not assumed. And since 2026-08-04, HELM's boot path calls ensure_docker(), which starts Docker Desktop detached when it is installed but not launched, so an owner with Docker installed stops silently getting the weaker engine.

//When Docker is not running: refusal, not a silent pass

The non-technical guide is exact: "(When Docker isn't running, it tells you plainly that the walls are weaker and refuses to run anything you haven't explicitly approved.)" run() tries Docker first and falls back automatically only when Docker itself is not reachable, never silently on any other kind of failure. The fallback is an explicit opt-in since 2026-08-02, because a warning is not a gate: SandboxUnavailable raises, naming OLYMPUS_ALLOW_UNSANDBOXED=1 as the way to accept the documented weaker containment. A per-call require_docker=True escalation cannot be overridden even by that install-wide opt-in: some workloads have no safe fallback at all.

//Where the sandbox sits in the path of a task

The sandbox is where "does this work" gets answered by the machine instead of by hope. run_python_file() is the single entry both the Coder's completion-gate self-check and an import's code verification call, and the result is a verdict with a shape: exit code, timeout, memory breach, or startup failure. When the container never even started, the run is reported as UNAVAILABLE, not as a failure of the code. The same engine does quieter work: the semantic cache revalidates a hit with one sandbox run per recheck, and per-language toolchains run generated code in their own images: the corpus scored 41/41 across eight languages in real containers with zero model calls.

//Honest state: what is still open

The register, not prose, wins: these are the open items as recorded in the open-items register, drift-checked 2026-08-15.

//What the Fates are

The Fates are Olympus's guardrail layer, and they exist to answer one question: is this allowed, and if something slips past, how do we know and how do we undo it? It is asked before any agent action runs. The layer is two tiers, deliberately split. A hardcoded floor lives in source code, not in config: the deny-list of tool names a tool registry may never accept, and the interpreter-level subprocess guard. A configurable Policy lives in fates/policy.yaml: what requires approval, what is whitelisted, content-safety toggles, the Hades-enforcement toggle. The floor is a Python literal on purpose, "so a config edit cannot widen it": changing it means changing and re-reviewing source code, not editing a file.

The Fates are Olympus's guardrail layer. They exist to answer one question before any agent action runs: is this allowed, and if something slips past, how do we know and how do we undo it?

Policy is not something a guild, an agent, or an import can change. Every change goes through a separate CLI the owner runs directly with an exact typed confirmation on a real terminal; it is never imported by agent code. Every init, enable, disable, promote and resign is permanently appended to logs/fates_audit.jsonl and re-signed into policy.hash. At startup the integrity check runs before the guard installs: a mismatch means "the policy file changed outside the human-only channel", and Olympus refuses to start rather than run under quietly-altered rules.

//Why a policy gate beats a model's judgement

The approval keys in Policy were not always real. An audit found them orphaned — their only reader was the tool that edits the policy, and nothing obeyed it. Olympus built the gate, scoped deliberately small: "a permission layer that permits everything is not a permission layer."

The default approver is deny-all, so an unattended Olympus can never self-approve: that is the single most important property here.

The ApprovalGate classifies every action three ways: ALLOWED, NEEDS_APPROVAL, or DENIED, and refuses to let a gated one proceed unless a human approver says yes. DENIED never comes from the Policy file at all: it comes from the hardcoded floor in source, so "no amount of whitelisting makes bash an approved action." Precedence is stated, not incidental: a name in both lists stays gated.

The reason the floor is deterministic rather than a soft signal is itself measured, recorded in the open-items register on 2026-08-14: "an LLM's severity is NOT DETERMINISTIC. Identical input, different level between runs." Severity from a model is a soft signal, and that is exactly why the boundary is not a model's judgement: the guard does not ask "how likely?", it asks "who approved this?", and a policy gate has no run-to-run jitter.

//How the thread gets cut

The cut is made at the interpreter level, not by convention. install_subprocess_guard() patches subprocess.Popen.__init__, os.system, and the whole os.exec* / os.spawn* / fork family inside the Python process, installed by both entry points before anything else runs. Outside a Hades sandbox context, any of those calls raises FatesViolation with the instruction: "Route through hades.sandbox.run() instead."

Three deliberately tiny doors exist, and none of them is a blanket bypass. The owner's interactive auth login (claude auth login), HELM relaunching itself on the owner's Restart click, and the key-hardening ACL call (icacls plus whoami) each get their own context, and entering the context is not sufficient: the executable must also be on a hardcoded allow-list.

//The day the guard stopped Olympus from running pip

On 2026-08-17 Olympus grew a dependency gate: what is installed, whether every package's requirements are satisfiable, and how far the network-facing packages sit behind their published releases. It found a real advisory on its first run — cryptography four major versions behind, with a Bleichenbacher oracle in PKCS#7 decryption fixed upstream in 50.0.0. Nothing in Olympus called the affected API, and it was upgraded anyway: a pin on the library holding the owner's keys is a record of what was tested, not a reason to sit behind a published advisory.

The gate was then scheduled to run on its own, hourly, inside the war room process, so that finding things would stop depending on someone typing a command. Its first cycle in production returned this:

The gate had been shelling out to pip list and pip check. Every test passed, because the guard is not armed under pytest — it is a runtime property, so only the runtime could find this. The first time the code ran inside Olympus, Olympus stopped it. The rule held against the people who own the codebase, which is the only test of a rule that means anything.

It was also seen, which is a separate property and not a lucky one. The scheduled check was built so a failure inside it becomes a reported state rather than a dead background thread, and the report carries the sentence "this says NOTHING about whether the dependencies are healthy" — because a broken instrument that reads as a clean result is worse than no instrument. Nobody was watching that hour. The war room said so anyway.

Adding a fourth door would have taken one line. The three that exist are for programs that set a file permission, print a username, or restart Olympus. pip is the program that downloads and executes arbitrary code from the internet.

Widening a guard whose entire purpose is keeping arbitrary execution out, in order to admit the package installer, is not a compromise; it is a deletion of the rule with extra steps. A guard with a convenient exception acquires another one. The value of the boundary is that it costs something.

So the gate stopped needing a subprocess instead. importlib.metadata is standard library and reads the same installed records pip reads; requirement specifiers are now compared in process and nothing is launched. This is the same move the hardware probe made when the guard denied nvidia-smi and it read NVML in-process instead — the second time the boundary has produced a better implementation rather than an exemption.

1. Proof it agrees. Package list against pip list --format=freeze on a 319-package tree: identical. No name differences, no version differences.
2. Proof it can fail. Two matching clean results prove nothing, so the checker is driven against a deliberately broken tree and must report both failure shapes pip check reports.
3. Proof it stays fixed. A test makes any Popen call at all fail, so the gate cannot quietly reacquire a subprocess.

The replacement is faster, needs no shell, and works in every process rather than only the ones where the guard is off. Four things happened without anyone remembering to look: the gate found a real CVE, discovered it could not run where it mattered, said so out loud, and the constraint that blocked it made the result better.

//The machine decides inside, Policy decides outside

The boundary is drawn at the process edge. Anything not listed in Policy defaults to unattended: local test and build commands a guild already owns, and anything inside the install root. Anything that reaches outside clears Policy, and each shape is named:

1. Starting a process. Subprocess execution outside Hades is refused outright by the guard.
2. Reaching the web. Outbound HTTP is not approval-gated. The owner decided on 2026-08-02: "to go to the internet, should not need to be asked if I tell it to." It is shape-restricted instead: non-http(s) schemes, credentials embedded in the URL, and any host resolving to a loopback, private, link-local or multicast address are refused, so a goal string cannot steer the machine at 127.0.0.1:8770, the LAN, or cloud instance metadata.
3. Writing to disk. A write outside the install root is refused by the write guard: it resolves the target, collapsing .. traversal and following symlinks, so neither a dotted path nor a planted symlink can smuggle a write out. Enforced directly by path containment, not routed through an approval prompt.

//Where the Fates sit in the path of a task

The Fates are first in the process and last over the deliverable. Startup verifies Policy integrity and installs the guard before anything else runs. Every generated program then executes inside the Hades sandbox, which is the one place the guard lets a process start. And when the guild's work comes out, the Fates have the final word again: delivery hands each artifact key to the same assert_write_allowed(), scoped to the task's own authorised folder, and a PathEscape is deliberately not caught: "it is a FatesViolation and must surface as one." Even hardware probes live under the rule: nvidia-smi is a subprocess, so the guard denies it, and the hardware probe reads NVML in-process instead.

//Honest state: built, tested, and still open

The Fates are real code, not a design. The rules layer carries nine dedicated tests, the guard is installed on every real run, the gate enforces the approval keys, and the integrity check is wired at startup. The register still records what it owes, verbatim, with detectors:

One more layer is honest-only-on-paper, and is recorded as such. The OS-level ACL layer (Windows icacls) is written and checked against real documentation but has never been executed on a real Windows machine, and real separation needs a restricted account distinct from the owner's, which does not exist yet. Until then the in-process guard is the layer actually enforcing.

The register, not prose, wins: these are the open items as recorded in the open-items register, drift-checked 2026-08-15.

//What Aegis is

In the source, Aegis is named after its guard: Cerberus, the hound at The Gates of Hades. The encrypted store lives in The House of Hades at hades/secrets.aegis, deliberately not in Tartarus, because a secret store is the opposite of untrusted code.

Before this module existed, the only place a real key could live was .env: plaintext on disk, protected by nothing but .gitignore. The module's own docstring is blunt about that trade: it holds against an accidental commit and is useless against everything else. Aegis replaces "plaintext file the owner hand-edits" with "encrypted file the owner unlocks", and keeps the .env path for the CI, test, and headless runs that depend on it.

The store is the one thing in this install that must never escape, and Cerberus is the hound at The Gates of Hades.

The scare is not hypothetical. The one real leak Olympus ever had was not a git vector at all: it was a full source snapshot that carried an environment file with a live API key inside it, deleted 2026-08-02 and ignored ever since. A leaked key is live money and live access; a leaked encrypted store is an offline attack on the key itself. That is why the store's ignore rules are matched by extension rather than by name.

//How the encryption works

Aegis is one versioned JSON envelope holding the whole secrets map as a single AES-256-GCM blob: one nonce, one tag. A fresh nonce is drawn on every write, and the file is swapped in atomically, so a crash mid-write can never leave a store that will not open:

1. The cipher. CIPHER_NAME = "AES-256-GCM" with a random 32-byte key generated once at initialization and a fresh 12-byte nonce per write. One blob, so there is no per-entry ciphertext an attacker could swap.
2. The key's protection. The AES key is itself encrypted with Windows DPAPI (CryptProtectData) and stored in the envelope, tied to the owner's Windows user account and, via fixed entropy, to this machine. Copying the store file elsewhere defeats it.
3. No passphrase (v2, 2026-08-08). The owner never types one, never forgets one, never loses access to their own keys because of one. The confirmation gate is a single [Unlock] click per session; the secret is the Windows login the owner already authenticated with.
4. The v3 binding (2026-08-13). Version, key_protection and protected_key are now bound as additional authenticated data: editing the envelope metadata, notably downgrading key_protection from dpapi-entropy to plaintext, is an InvalidTag instead of a silent success. A v2 store still opens and upgrades itself on the first write.

The refusal logic is deliberate: a build that cannot open its own store locks the owner out of his own account, which the source calls "a far worse outcome than the tampering AAD defends against". The read set is {2, 3}, not a free-for-all; a future version is still refused.

//The UI shows four characters and nothing more

HELM's preferences pane is the face of the store. The only listing method returns name, updated_at, and a preview of the last four characters, empty for any value shorter than eight: enough to tell "the key I just rotated to" from "the old one", and useless to anyone reading over a shoulder.

The rule is structural, not remembered: no route ever returns a secret value, not to localhost, not once, not for debugging. Every route is token-gated at registration, not per route, and unlocking requires a JSON body of {"confirm": true} to force a CORS preflight, so a cross-site form cannot trigger it. A locked store is a normal, expected state: every restart produces one, which is why "locked" is a 409 and not a 500. Locking zeroes the AES key in memory in place.

//Decisions the guardrails had to earn

//Where Aegis sits

Keys are keyed by environment-variable name, OPENROUTER_API_KEY, not "openrouter". Resolution order: first the Aegis store, if it exists and is unlocked; then os.environ, which is where .env lands; then MissingSecretError, naming both routes and saying so explicitly if a store exists but is locked. The store is an enhancement, not a prerequisite.

The honest boundary, from the module's own docstring: Aegis does not protect against a process running as the owner while Olympus is running, nor against the owner's own process calling CryptUnprotectData on the stored blob. And encryption carries an audit cost: on 2026-08-08 the store held http://locahost:11434, a typo that passed the exact-match check, won over the literal default, and broke every Tier 0 call with getaddrinfo failed, invisible to grep because the value lives encrypted.

//Honest state: what is still open

The register, not prose, wins: these are the open items as recorded in the open-items register, drift-checked 2026-08-15.

//What the Vault is

Exact-token recall means asking for the literal name of an environment variable finds the row that spells it out. Semantic recall means asking about an idea finds the rows that mean it, even when the question shares no word with the stored text. Underneath, the Vault is one SQLite database, memory/vault.db: items with a full-text mirror for keyword search and embeddings for similarity search, plus the relationships between items and the notifications they raise. Around it sit the layers that give the store meaning: episodic memory is the plain, append-only log every task attempt writes to; the substrate stacks the Semantic Cache, skill and failure stores on top of that log; Athena is the librarian standing in front of the store; and Mnemosyne is the context provider that decides what actually reaches an Oracle prompt.

//The four mechanisms

//The Gatekeeper

That refusal is not one check, it is a pipeline. The validator checks the source against allow and deny lists and validates documents before they are admitted. The classifier reads the content, flags secrets by pattern, and stamps a sensitivity tier onto the item: PUBLIC, CONFIDENTIAL or SECRET. Katharsis scans for contamination and normalizes what it admits. The rate limiter throttles intake with a sliding-window log, and the chunker splits large content by type. Only then does the router send the item to the right store, and the write path every engine uses is ingest_through_gate.

Why the gate is non-negotiable: the finding that started the hardening pass. Lethe, the maintenance engine, wrote its summaries with a bare ingest call, so Katharsis, the secret classifier and the rate limiter were all bypassed on the one path that stores model output. A summarizer that echoed an API key would have written it to disk in the clear, readable by any role. Now those writes route through the gate, and a refusal is not an error: it means the cluster was not stored, and the originals stay readable.

//The Compression Ladder

The ladder "distils old material instead of dropping it." Three engines run it: the SemanticCompressor folds a cluster of items into one summary, AutoForget retires what is safe to retire, and the Distiller turns what worked into distilled lessons. It does not fake success: when it cannot do a pass, it reports a skipped reason, no_summarizer, no_real_embeddings or below_min_entries.

The owner's mandate for the Vault is four words long: "bypass nothing, compress correctly, organize correctly, and filter correctly." Compress correctly is gated on reversibility and readability: every level-two summary must render with its ancestors and mark itself expandable, because a one-way ladder is a shredder with better manners. And summaries are born with a sensitivity label: a summary inherits the highest tier among its sources, never below it, so compression cannot launder a SECRET into a PUBLIC read.

//The Scheduler

Horae, the maintenance worker, runs compression and distillation in the background so the Vault does not grow without bound. Before Horae will schedule unattended compression, it asks the maintenance layer a real question: does your write path report that it is gated? The old guard grepped the source for the word "writer", which already existed in comments before any gated writer existed, so that guard could never fire. The new guard is a property of the object: if a future edit stopped routing writes through the gate, the property would become false and the scheduler would stop. A maintenance worker that cannot prove its writes are gated is not allowed to run unattended.

//Clearance

Clearance is enforced on retrieval: "a caller only ever sees what its role may read." The tiers are fixed. Viewer reads up to PUBLIC, user reads and writes up to CONFIDENTIAL, admin reads, writes and deletes up to SECRET. An unknown role has no clearance at all, and a label the system cannot parse is coerced to the most-restrictive tier. The gate's contract test is parameterized over every read entry point: a viewer never receives a row above PUBLIC, an unknown role receives zero rows, a corrupt tier label is treated as most-restrictive.

The order matters more than it looks. Mnemosyne runs clearance first and budgeting second. Candidates come exclusively through the clearance-filtered search, so an item the caller's role may not read is removed before anything else: it can never be selected, truncated into, or leaked into the digest that reaches the Oracle. Only the cleared hits are packed into the token budget, highest relevance first, with a default of 8% of the context window.

//Why the memory is encrypted

The Vault lives under the same discipline as Aegis because it is the same kind of thing: durable, long-lived, and read back forever. A secret that leaks into memory is worse than a secret at rest, because memory is what every future session consults first. The owner's intake contract is explicit: anything brought into the perpetual mind vault was meant to be stripped so it could cause no harm if read. Encryption is the last line of that stripping: even if content slips past every classifier, the file on disk is not plaintext anyone can read.

//Where it fits

The Vault is not one thing, it is the stack beneath everything: episodic log, semantic cache, skill library, failure library, in one database kept apart by content type. The Council's Semantic Cache replays validated work instead of spending a token.

//Honest state, what is still open

The register, not prose, wins: these are the open items as recorded in the open-items register, drift-checked 2026-08-15.

//What HELM is

HELM is the local FastAPI war room behind the pantheon's web UI, and it runs on the owner's own machine at :8770, serving one self-contained page. The developer guide is explicit about what it is for: "It is meant to stay up." It autostarts at logon via the "Olympus HELM" scheduled task, and a killed pytest orphan once took HELM down with it, which is why the guide says never to force-kill python processes by PID while doing verifying or shutdown work.

This is not a dashboard; it's a place you COMMAND the workforce from. The centerpiece is a chat console: you type a goal, it POSTs to /api/goal, then an EventSource on /api/goal/{id}/stream shows the guild loop turn LIVE and renders the result." · helm/static/index.html

The page is deliberately self-contained: no CDN, no build step, no external fonts or scripts, so it loads with the FastAPI server and nothing else, and works fully offline. A Tauri desktop wrapper can point at this same server later without changing the API; for now the owner decided, 2026-07-30, "browser for now, app when finalized".

//What the war room shows

The center of it is the live task stream. The board's state machine is PLANNING → WORKING → SELF_CHECK → REVIEW → DONE, or FAILED, with a step history; a semantic-cache hit replays the whole forward path in one go, labelled honestly: "reused a validated cached outcome".

//Keys, models, and the machine

Two kinds of management live here, both owner-only. Secrets go through the Aegis store, and the API contract says the response is "NEVER a secret value". Models go through the editable catalog: PUT /api/config/models sets one role's model, comment-preserving, and /api/catalog/available discovers what each provider can actually serve right now, so a deprecation is visible as itself and not as a silent failure.

The auth model is the machine reasoning about trust. Read-only routes need no auth beyond localhost, because Olympus is single-owner, but "localhost is enough" reasons about network reachability and says nothing about the owner's own browser, "which will happily POST to 127.0.0.1 on behalf of any page they visit". So every state-changing route needs the owner token from logs/.helm_token and a JSON body, which forces a CORS preflight a cross-site form cannot satisfy. The process controls are the ones that needed it most: restart and shutdown call real injected operations, not inline os._exit, because a test that reached them must not kill the test runner.

//Approvals and the Gate: parked work

Approvals plug straight into the existing Gate. ApprovalBroker.approve satisfies the Gate's approver signature exactly, so it drops into EffectGate(approver=...) with no change to the gate, to any call site, or to any existing test. The one invariant is not negotiable: every failure mode resolves to DENY. Nobody listening, the wait times out, the broker shuts down, an unknown id, the broker itself raising, a decision arriving late: each one is a refusal, because an approval path that fails open turns every transport bug into silent authorisation to act on the world.

What triggers it is a parked task. The board has a state for waiting on a person: HALTED, "not done, not failed, and the distinction is the point". Folding it into FAILED would have been cheaper and would have been a lie. The owner's rule it exists for is recorded in the source: "After 2 full correction cycles, HALT and wait for human approval. Do NOT start a 3rd cycle without explicit human approval."

And approving sends the work back through the same gate it faced before. There is deliberately no HALTED-to-DONE edge: approving a park means the work resumes and faces the same gate as everything else; it never means the gate is waived. The decision is made by a person, but the judgement is still the Gate's.

//The truth about its own process

On 2026-08-15 the owner attached a video, wrote a description for it, and got back intake: internal error (TypeError: ingest_document() got an unexpected keyword argument 'note'). The code on disk was correct: a fresh process ingested that exact file with that exact description and found it by his own words. What was wrong was the running process, started at 19:50, against an intake module edited at 19:53. HELM imports one intake module inside the route body, fresh at upload time, while the vault importer was loaded at boot: a half-reloaded process, serving two versions of the same codebase to one request.

A running process keeps the modules it already imported and loads new ones fresh, so it can serve two versions of the same codebase to one request. Restart HELM and try again before treating this as a code defect.

The control panel reports source_files_changed_since_start on /api/manage/status, plus the newest changed files, capped and listed by name. It is deliberately not auto-reloading: reload mode "would restart it under him mid-goal", so this module only ever reports.

//Honest state: what is still open

The register, not prose, wins: these are the open items as recorded in the open-items register, drift-checked 2026-08-15.