What Steelmoth is, and how it fits together

Steelmoth is an AI assistant system. You talk to one assistant brain through chat and the dashboard; it plans, calls tools, and answers — with long-term memory and integrations for email, reminders, the web and more, running on a hardened two-VPS stack. And because almost all of Steelmoth is itself written by AI coding agents, a second layer — the governance / Operator Authority harness — keeps those agents inside safe limits.

This page maps both halves. The left sidebar has a page for each box.

The system

The assistant and the machinery that runs it.

• The runtime — the one brain behind the API and dashboard: how a message becomes a planned, tool-using reply.
• Web & chat API — the surface the dashboard and channels talk to.
• The dashboard — the web UI: chat, the operator control plane, settings.
• Memory — memlink, the assistant’s long-term memory and knowledge graph, and how it recalls.
• Morpheus — the overnight agent that codes on its own, plus self-memory consolidation.
• Mail broker — how mail is sent and received on the user’s behalf.
• Runtime & memory map, Sidecars, Workspace lanes, and Structured tool arguments — the moving parts inside the runtime.

How it runs: Data and scope · Security and secrets · Per-client vaults · Operator authority · Deployment · Operations · Standards & releases · Access request flow.

The architecture diagrams draw these out — chat flow, the router, memory, containers, authentication, email, and the key sequences.

The governance harness

Almost all of Steelmoth’s code is written by agents — Claude Code, Codex, the overnight Morpheus drain, and the assistant inside the product. This half of the docs is the layer whose only job is to keep those agents inside safe limits — and the reason a written rule, on its own, isn’t enough.

The design comes from one lesson, learned the hard way: a rule that only lives in a document gets ignored. Usually not on purpose — an agent makes a mistake, misreads an instruction, or retries a step in a confused state. So every rule that really matters is written down once and then tied to something that can actually stop the action: a wall inside the Linux kernel, a check that runs before each file is written, a test that fails the build, or a block on merging the change. The rule and the thing that enforces it always come as a pair.

The one idea

There is one rulebook — AGENT_POLICY.yaml — and many checks that read it. A rule is only as strong as the check behind it, so the same rulebook is read again at every point where an agent could cause harm.

What happens when an agent acts

When an agent does something — writes a file, edits code, runs a command, opens a pull request — the action has to pass a line of separate checks. Any one of them can stop it. They don’t rely on each other: each one checks again on its own, so anything that slips past the first is caught by the next.

  WRITTEN RULES                         ENFORCEMENT (says "no")
  ─────────────                         ───────────────────────

  CLAUDE.md  ............ HARD RULES ... the gate  ─────────┐
  engineering-standards/                  (before every     │
   ├─ ARCHITECTURE_INVARIANTS .. INV ...  write / command)  │
   ├─ PROTECTED_PATHS  ................... Landlock  ───────┤
   └─ AGENT_POLICY.yaml  ◀── canonical     (kernel wall)    │
            │                                                ▼
            │ derived / read by            approval queue ─▶ ACTION
            ▼                               (operator yes/no) runs or
   scope manifests ──▶ post-hoc sweep ──▶  CODEOWNERS  ────▶ is refused
   (per task grant)    (after the run)     (at merge)        + logged
                                                              │
                                                              ▼
                                                        audit log
                                                     (violations.jsonl)

The left side is what the rules say. The right side is what makes them hold. This site has one page for each box.

The rule books — what’s allowed

Plain statements of what an agent may and may not do — some written for people to read, some for machines.

• Governance files — the map of which file is which, and which ones are advice versus which ones are enforced.
• Hard rules — the 15 rules in CLAUDE.md that are never bent, and the check standing behind each one.
• Engineering standards — the standards folder, how its tiers rank, and the steps an agent follows to build something.
• Architecture invariants — the numbered safety rules (INV-001…026) and the tests that turn each one into a pass-or-fail check on every change.
• Protected paths — the files an agent can’t touch without permission, and where that list comes from.
• Agent policy (YAML) — the single machine-readable rulebook that every check reads.
• Development process — the four roles, size tiers, code-shape limits and document templates that shape work before it starts.
• Decision records — the numbered ADRs, RFCs and PRDs that record why every layer exists.

The enforcement plane — what makes it hold

The checks themselves. Each one works on its own, and each is built to fail safe: when something goes wrong, it blocks the action rather than letting it through.

• The gate — the check that runs before every file write or command.
• Landlock — a wall built into the Linux kernel, around the agent’s own process.
• Agent shims — the wrappers around the claude and codex commands that build the walls before the agent starts.
• Approval queue — how an agent asks the operator for a yes, and waits for the answer.
• Scope manifests — the per-task permission slip listing what an agent is allowed to do right now.
• Post-hoc sweep — the safety net that checks what changed after a run and undoes anything it shouldn’t have.
• CI guards — the family of one-rule scripts that can each block a merge on its own.
• CODEOWNERS — the last check, when a change is merged on GitHub.
• Dashboard control plane — the operator’s screen: live sessions, the approval queue, submitted plans, the violation log, the global switches.
• Audit log — every block, written down.

Underneath, and inside the product

• Secret handling — why no secret ever sits in a file an agent could read, and the checks that keep it that way.
• Containers & boot — the locked-down boxes the services run in, and the one ordered way the stack starts.
• Authorization pipeline — the separate rule system for the assistant inside the product, with a tamper-evident audit ledger.
• Authorization internals — that rule system opened up: every pattern, limit and precedence rule, module by module.
• Morpheus drain — the overnight agent that codes on its own, and how it limits itself using to-do tags.

Cross-cutting views — the same system, sliced four ways

The pages above each describe one box. These four cut across all of them.

• Threat model — every way things could go wrong, and which layer stops each one.
• Identity & authority — every actor in the system, and who can ask, decide, or only watch.
• Audit trails — the nine records the system keeps, ranked by how hard they are to tamper with.
• Failure postures — what every part does when it breaks, and the one rule behind those choices.

Why two parts and not one

A document only helps an agent that is honest and paying attention. It does nothing against a plain mistake, a misunderstanding, or a confused retry. On 2026-05-23 an agent saved a secret to the wrong place and broke three written rules at once — and all three already existed, in writing. The enforcement layer is there so the next mistake is stopped as it happens, not just noticed afterwards. See HARD RULE 11.