The architecture
in six diagrams.

Spelling out the adversary is the spine of every other section

The invariants below aren't decorative — each one is the answer to a specific row in the table above. Without the threat model, a reader has to reverse-engineer the design from inference. With it, every later diagram becomes "oh, this is how we catch row N."

The list isn't exhaustive (no list of attacks ever is). It's the set of attack classes that fell out of nine cycles of red-team → fix → regression-test. New rows get added when a critique cycle finds something not on the list.

This isn't a proof of safety

Listing what we catch is not the same as listing what we'd miss. Two known classes the substrate does not defend against in Phase 0: closure-cell mutation by privileged code in the same Python process (H2), and POSIX unlink-during-lock by another OS user (H11). Both are deferred to Phase 1 (process-level isolation).

Honesty about the perimeter matters more than the size of the perimeter. Anything on the deferred list is in CYCLES.md with its rationale.

Vertical growth, not horizontal

Most agent frameworks grow horizontally — more tools, more skills, more prompts. CSIS grows vertically: every safety property becomes a substrate guarantee that higher layers depend on without re-implementing.

A subclass attack on _BackendTracker isn't fought at L4 ("agent prompt should not bypass metering"). It's fought at L0/L1 ("Coordinator refuses any backend that isn't exactly _BackendTracker"). The layers above never have to think about it.

If two layers enforce the same thing, the layer is wrong

Each layer owns exactly one structural commitment. L2 owns reversibility. L4 owns cross-checkpoint verification. L7 owns capability ceilings. Two layers enforcing the same property means the property is at the wrong abstraction level.

Cycle 9 found three places enforcing the wrapped-backend invariant. The fix was to put it in exactly one place (Coordinator.__init__) and let everything above benefit. That's pattern 2 from the cycle log.

Different durability, different retrieval shape

Working memory is per-iteration scratch. Episodic is per-iteration narrative. Semantic is durable facts. Procedural is reusable skills (this is where self-improvement actually accumulates). Causal is why-this-fixed-that hypotheses the auditor leans on.

Each tier has its own retrieval pattern. Conflating them into one store would force the auditor to discriminate at read time on every lookup — a hot-path cost the substrate avoids by partitioning at write time.

Reversibility as a structural property

Every memory mutation passes through candidate → CAS → live. If anything moves between Verifier sign and Auditor promote (concurrent iteration, racing siblings), the promotion fails atomically and the candidate is discarded. Nothing partial reaches live.

This is what makes cycle 9's writer-id tagging work cleanly. The cleanup discards stamp-matched candidates without touching anything live or anything stamped by a sibling iteration.

The Verifier can't rubber-stamp the Builder

If the same model that wrote the artifact is also the one checking it, you have one model with two hats — and a structural class of failure where the model's blind spots in build are exactly its blind spots in verify.

Different model_id means different training, different blind spots, different priors. Imperfect but structurally distinct. The substrate enforces this at the cert build site, not as an agent-prompt request.

Programmatic checks AND adversarial attempts

V1 graders are pinned (source-hashed at task start; rejected if they drift mid-task) and run programmatically — tests pass, lint clean, Dice ≥ 0.85 with CI lower bound clearing the bar. Reproducible.

V2 is the Critic — explicitly trying to falsify. For distributional outcomes, the Critic attacks the worst slice (lowest-Dice organ, highest-error landmark) rather than the artifact globally. Targeted falsification budget.

Optimistic concurrency beats single-writer

An exclusive lock on the live store would serialize every promote — including ones that don't conflict. CAS lets parallel iterations race; only the loser of a real conflict pays. For mostly-non-conflicting workloads (the common case), CAS is dramatically more throughput-friendly.

And when conflicts do happen, the loser's rollback is clean: the candidate is discarded, the why-doc is invalidated, no partial live state to clean up.

Content-addressed precondition resists rebase

A monotonic version counter can be fooled (revert + reapply = same counter, different content). Hashing the live store's actual content means the precondition encodes what was there, not how many writes have happened.

Canonical JSON serialization (sorted keys, fixed delimiters) means the hash is stable across processes. Two daemons reading the same live state get the same hash with no coordination.

Isolation from agent prompts and tool access

Consolidation that happens during a waking iteration would inherit the iteration's tools, network, and the agent's prompt-driven attention. Dreams runs as a separate process with none of these — it sees only the structured event log and the live memory snapshots. No way to call out, no way to execute, no way to be steered by a poisoned prompt.

Partial-output redaction handles the cancel case: if a dream is interrupted, partial outputs are discarded rather than persisted as untrusted candidates.

The verification stack stays the only path to live

Dreams could be wrong. Pattern-extraction over episodic memory is a heuristic — it can over-generalize from coincidence. Sending dream output straight to live would create a second mutation primitive bypassing the cycle-1 F2 atomicity guarantee.

Instead, dreams produce candidate entries. They flow into the same V1+V2 stack. They're verified against the same graders, critic, and cross-checkpoint cert. Then the Auditor signs a why-doc with hash precondition. Dreams get no special promotion path.

An invariant without a counter is a promise without a thermometer

Every row in the threat-model table maps to at least one row in this table. If we add a defense, we add the signal that proves it's still active. The reverse is also true: a signal that's been zero for months either means the defense works, or that it's no longer hooked up — the dashboard surfaces the difference.

Open the dashboard against a stopped or running daemon

The dashboard reads from on-disk artifacts only — event log, budget JSONs, memory store snapshots, daemon heartbeat. No coupling to the running process, so you can boot it against a stopped state and still inspect the full trail of what happened. Simulated demo here; live one at python -m csis.ui.

Identity beats timing

Cycle 8 detected "which iteration wrote this candidate?" via a pre-consolidate snapshot diff — infer ownership from timing. Cycle 9 found the race window.

The fix wasn't a tighter snapshot. It was a writer_iteration_id field on the candidate itself, stamped atomically at write_candidate time. Ownership belongs on the data, not in the timing.

The same lesson applies to the distributional graders: cert evidence (CI bounds, sample size, slice breakdown) belongs on the cert, not inferred at read time from a passed: bool. Bind the truth to the artifact.

Chokepoints beat perimeters

Cycles 4-8 added increasingly clever guards to _BackendTracker.__init_subclass__ against _wrapped-exposure attacks. Each cycle the attacker found a different escape (literal name → mangled name → setattr → metaclass).

Cycle 9 stopped guarding the subclass surface (infinite escapes) and started guarding the wrap site — Coordinator.__init__. Every LLM call routes through there; there's exactly one entry point to constrain.

Constrain the finite chokepoint; don't try to perimeter-fence an infinite attack surface.