Monster Agentic Runbook

Operator runbook for Taylor's agentic development environment: a UCAN-secured stack where Thoth grows, queries, and prunes a swarm of distributed-inference subagents through a chain of guards. This document is the single place to read before running the quality gate, fetching the model, or driving subagent CRUD over MCP.

It is honest about what is verified versus pending. Verified items have been run; pending items are stated as such.

Sideways scale (density heat-sink). The monster runtime can fan a coarse-cost workload SIDEWAYS across Cloudflare sidecar sub-invocations, bounded by the cheapest of three certified ceilings — carrier (algebraic) / wire (bandwidth) / cost (budget) — with token-burn metering to recoup the spend and a fano-keyed cache for geodesicLength:0 replays. Runtime: @a0n/edgework-sdk/compute/density

• the x-gnosis DensityGovernor; formal SSOT: Gnosis.{DensityChannelStoplight, WireSaturationCeiling, DensityCarrierChoice, SidecarCostCeiling} (axiom-clean); live: https://skymesh.forkjoin.ai/api/v1/sidecar/fanout. Benchmark wins: docs/BUSINESS BINDER/BENCHMARK_WINS.md (density-heat-sink-sidecar-fanout-v1).

For the top-down narrative — the problem, the principle, and the six accountable- agent gates A-F each tied to the demo gate that proves it — start with the capstone MONSTER_ACCOUNTABLE_AGENTS. This runbook is the operator detail behind that story.

The chain

Each link only grants what the link above it allows. Authority flows down; a revocation at any link kills everything below it.

a0n-auth (open-source/auth/rust)        UCAN crate: issue / verify_chain / revoke (ES256 / P-256)
   |
   v
monster-guard (open-source/gnosis/monster-guard)
   |   delegate a per-command grant, then run each invocation under the macOS
   |   sandbox (sandbox-exec) inside a time-boxed, auto-renewing lease.
   |   revoke kills running invocations at the next lease tick.
   v
monster-resident (open-source/gnosis/monster-resident)
   |   stdio JSON-RPC 2.0 MCP server. The capability root. Surfaces orchestrate
   |   + the subagent_* / swarm_* / audit_* tools. Verifies every call's UCAN.
   v
monster-swarm (open-source/gnosis/monster-swarm)
       the distributed-inference guardrails. UCAN-gated, cost-admitted CRUD over
       a leased swarm of subagents. AntColony FRF budget admits each mutation;
       autonomic auto-tick self-regulates the fleet; monster-guard enforces the
       lease. Spawned nodes are real distributed-inference binaries (fat-station,
       aeon-monitor) that join the swarm partyline.

moonshine (open-source/gnosis/moonshine) is the FRF shell Taylor lives in — the wrapping container. It warms a fat-station with the default Qwen knot and has a --oneoff one-shot mode (moonshine --oneoff -c "The capital of France is"). --oneoff is real mesh inference (verified): it boots a fat-station against the dense knot, drives one prompt through the mesh /decode-next, prints the real next token, and tears the node down — the same wire path the Paris gate uses, in a single shot.

Double-gating (the monster-swarm contract)

Every mutation (spawn, update, reap) is gated twice:

1. UCAN-enlightened — the caller presents a capability rooted at the shared resident root that grants agent/<verb> on agent:fleet. agent/* grants all of CRUD. Bad signature, wrong root, revoked, or wrong verb is rejected.
2. Cost-admitted — the op passes the AntColony FRF budget: a population ceiling (default DECAGON = 10) gates spawn; the two-queen reap floor forbids reaping the last persistent breeder; the God-Formula stability weight is reported and is always >= 1.

Runtime enforcement (sandbox + lease + revoke) is then monster-guard's job.

The quality gate (the headline)

monster-swarm/tests/paris_subagent.rs is the real-inference ratchet. It spawns a fat-station as a UCAN-leased subagent on the local mesh, drives the prompt "The capital of France is" through the mesh /decode-next, and asserts the real Qwen coder-7B model predicts the next token Paris (token id 12095).

This is the guard against "fake agent" regressions: it exercises the full path (UCAN issue -> cost admission -> monster-guard delegate -> lease + sandbox launch -> mesh wire query -> reap) against a real 7B model doing real CPU forwards. If the plumbing degrades to synthetic output, the assertion fails.

Notes that matter:

• Base completion is used on purpose. A coder model deflects a chat question ("I'm a coding assistant..."), but at the token level it still completes "The capital of France is" -> " Paris". The test asserts the next token id, immune to chat-template refusals.
• Paris is token 12095 in the Qwen2.5 tokenizer. The historical doc value "279" is wrong (279 is " the"). Use 12095.
• The prompt token ids are [785, 6722, 315, 9625, 374].
• The test self-skips (passes) when the knot or binaries are absent, so plain cargo test stays light. It is not #[ignore]d — it runs and skips.

Status

• VERIFIED: the gate passes against the real qwen-coder-7b.knot (~123 s on CPU). The mesh predicts token 12095 = " Paris" through a leased subagent.
• VERIFIED: moonshine --oneoff runs real mesh inference end to end (boot -> /decode-next -> token -> teardown), the same wire path as the gate.
• VERIFIED: fat-station exposes /detokenize (token ids -> text), so the mesh can render its own predictions to human-readable strings without a side-channel tokenizer.
• VERIFIED: per-subagent ECDSA signing closes the verify + sign loop. Each subagent is spawned with MONSTER_AGENT_ID / MONSTER_AGENT_DID / MONSTER_AGENT_KEYFILE; the node signs its swarm broadcasts with its own P-256 key and the receiver verifies the signature against the ledger DID. The subagent is now its own identity, not merely the monster-guard grant.
• PENDING (CI-cheap knot): no small dense knot exists yet, so the gate still requires the 4.7 GB dense knot. The committed *-sketches.knot are spectral-only and cannot drive the gate (see the research limitation below). To produce a CI-cheap dense knot:
  1. Download Qwen2.5-0.5B-Instruct-Q4_K_M.gguf (Qwen2.5-0.5B-Instruct, Q4_K_M quant) from its GGUF source.
  2. Convert with di/gguf-to-knot.py to a dense .knot.
  3. Verify it drives the Paris gate (or a small base-completion smoke prompt) end to end before wiring it into CI. A 0.5B dense knot would let the ratchet run in CI minutes rather than the 4.7 GB / ~2 min path that needs a primed model on the box.

Research limitation: the answer-faithful spectral / sketch path

The committed rank-32 SK32 spectral sketches are documented as too lossy for answer-faithful inference. Driven through the gate they predict top-1 aeper, not Paris — the rank-32 reconstruction loses enough of the weight spectrum that the next-token argmax moves off the correct token. This is a real limitation, not a bug to "fix" in the gate: closing it needs either a higher-rank sketch or the standing-wave .rknot representation. Until then, the ratchet runs only on the dense knot, and a sketches knot is never a valid target for MONSTER_SWARM_QWEN_KNOT.

Running the gate

Prerequisites

1. The dense Qwen knot at the cached path or pointed to by env (see Knot setup below).

2. Release builds of fat-station and monster-guard (the test resolves sibling crate target/release then target/debug):

   cargo build --release --bin fat-station   # in open-source/gnosis/distributed-inference
   cargo build --release                      # in open-source/gnosis/monster-guard

Run it

From open-source/gnosis/monster-swarm:

# Uses the cached knot at ~/.edgework/models/qwen-coder-7b.knot if present,
# or set the explicit override:
export MONSTER_SWARM_QWEN_KNOT=/path/to/qwen-coder-7b.knot   # optional override

cargo test --release --test paris_subagent -- --nocapture

Expect roughly 2 minutes (a 7B CPU forward is slow; the test gives the mesh node up to 180 s to come ready and 120 s per /decode-next). On success:

[paris] spawned subagent 'paris' pid <N>
[paris] OK: mesh predicted token 12095 = " Paris"

If the knot or a sibling binary is missing, the test prints a SKIP: line and passes — that means the gate did not actually run. To prove it ran, look for the [paris] OK line.

The test uses an isolated $MONSTER_GUARD_HOME under the temp dir and an explicit node allowlist (MONSTER_SWARM_NODES -> the fat-station directory), so it does not touch your real ~/.moonshine.d fleet, and always reaps the subagent on exit (revoke -> killed at the next 15 s lease tick).

Knot setup

The gate needs a dense Qwen coder-7B knot.

• Canonical model: qwen-coder-7b.knot, 4.7 GB, sourced from R2 (edgework.ai). Fetching it requires the edgework API key; the dense knot is the only file R2 stores for this model.
• Cache location (default): ~/.edgework/models/qwen-coder-7b.knot. The test and moonshine both default to this path when no override is set. Place the knot here once and every consumer picks it up.
• Override: set MONSTER_SWARM_QWEN_KNOT to any dense Qwen .knot to point the gate elsewhere. moonshine uses MOONSHINE_LLM_KNOT for the same purpose.

Resolution precedence (both moonshine and the gate): explicit env first, then the cached ~/.edgework/models/qwen-coder-7b.knot if present.

The committed *-sketches.knot files are spectral-only and will not satisfy the gate; do not point MONSTER_SWARM_QWEN_KNOT at a sketches knot.

How Thoth CRUDs subagents over MCP

Thoth drives the swarm through monster-resident's MCP server (stdio JSON-RPC 2.0). Every mutation carries a UCAN; the resident verifies it before monster-swarm admits and monster-guard enforces.

Provision a station capability

export MONSTER_GUARD_HOME=/path/to/open-source/.moonshine.d
monster-resident whoami     # the resident root DID; must root every capability
TOKEN=$(monster-resident grant --audience <station-did> --with agent:fleet --can agent/spawn)
# or --can agent/* to grant full CRUD

Serve the MCP and call the tools

monster-resident             # serve MCP over stdio

The everyday CRUD + audit tools (see monster-resident/README.md for the full arg table and the complete tool list):

(The resident also exposes subagent_breach / subagent_breaches / subagent_trust / subagent_reconcile; the table above is the everyday CRUD + audit subset.)

CRUD maps cleanly: subagent_create / subagent_list / subagent_update / subagent_reap. The fleet ledger is a Thoth conversation anti-queue — each live subagent is a held lease ("promise"); reap is the release; the oldest held promise carries the most review pressure.

Drive CRUD directly from the CLI (no MCP)

The same operations are the monster-swarm binary's subcommands:

monster-swarm whoami
monster-swarm spawn  --ucan <token> --node fat-station --id paris --caps net \
                     --lease 15 -- --knot ~/.edgework/models/qwen-coder-7b.knot \
                     --port 8779 --role both --layers 0..28
monster-swarm list   --json
monster-swarm update --ucan <token> --id paris --lease 30
monster-swarm reap   --ucan <token> --id paris
monster-swarm reap   --ucan <token> --id paris --cascade --json   # reap the agent + its spawned subtree
monster-swarm vibe   --json
monster-swarm auto   --ucan <token> --node fat-station --interval 30   # live controller daemon
monster-swarm broadcast --consciousness 5 --json   # drive the partyline hot (provoke a bud)
monster-swarm broadcast --consciousness 0 --json   # drive it calm (provoke a vent/reap)
monster-swarm audit  --verify --json   # walk the tamper-evident chain (exit 0 ok / 3 tamper)

spawn can only launch binaries inside the node allowlist ($MONSTER_SWARM_NODES and/or $DI_BIN_DIR) — never an arbitrary path.

Quality-gated admission (qspec)

The double gate (UCAN + FRF budget) proves the caller is allowed to mint an agent and that the fleet can afford it. A qspec adds a third, orthogonal gate that proves the agent actually works before it is admitted: a declared quality probe that monster-guard runs at delegation time and refuses to mint the grant unless it passes. Capability says "you may"; budget says "we can afford it"; qspec says "and the thing it claims to be, it provably is."

The format

A qspec is a small JSON file (*.qspec.json) declaring one quality probe — the canonical case is a real-inference next-token assertion:

{ "probe": "paris-probe-rknot",
  "knot": "~/.edgework/models/qwen2.5-0.5b-instruct.knot",
  "prompt_tokens": [785, 6722, 315, 9625, 374],
  "expect_token": 12095, "expect": "Paris" }

• probe — the probe runner monster-guard invokes (here the rknot Paris probe).
• knot — the model the probe forwards through (the 0.5B dense knot, chosen so the probe is cheap enough to run on every admission — see Benchmarks).
• prompt_tokens — the prompt token ids (The capital of France is).
• expect_token — the asserted top-1 next-token id ( Paris = 12095, the same id the heavy Paris gate asserts).
• expect — the human-readable label for logs.

The reference spec lives at monster-swarm/qspecs/paris.qspec.json.

The delegate gate

monster-guard is the enforcing authority. With a qspec, delegation grows a probe:

monster-guard delegate <name> <caps> [--ttl <secs>] [--qspec <file>]

When --qspec is present, monster-guard runs the declared probe and refuses to mint the grant unless it passes. No grant → no lease → no admission. Without --qspec the behavior is exactly today's (capability + lease admission only).

The registry quality column

open-source/.moonshine carries an optional quality column (a qspec path, or -):

name   kind    path                       caps         build                  quality
moonshine cargo gnosis/moonshine          fs,net,exec  cargo build --release  gnosis/monster-swarm/qspecs/paris.qspec.json
bw     cargo   bitwise                    fs           cargo build --release  -

setup.sh reads the column when it admits each plugin and passes --qspec <quality> to monster-guard delegate when a row declares one. A - (or an absent column, for old-format registries) means today's behavior — admit on capability + lease alone, no quality probe. Repo-relative paths resolve against the monorepo root; absolute paths are used as-is. If the spec file is missing, setup.sh warns and admits without the probe rather than failing the row.

spawn --qspec

The same gate threads through the swarm CRUD path. monster-swarm spawn takes an optional --qspec <file>:

monster-swarm spawn --ucan <token> --node fat-station --id paris --caps net \
                    --lease 15 --qspec qspecs/paris.qspec.json \
                    -- --knot ~/.edgework/models/qwen2.5-0.5b-instruct.knot \
                    --port 8779 --role both --layers 0..28

The path flows cmd_spawn → SpawnRequest.qspec → ops::spawn → guard::delegate(.., qspec), which appends --qspec <file> to the monster-guard delegate shell-out. The subagent is admitted only if its qspec passes; update does not re-run the probe (re-attenuation reuses the quality already proven at spawn), and omitting --qspec is fully back-compatible.

Why this matters (the philosophy)

The same logic as the Paris ratchet, pushed to the admission boundary: admission proves the thing works. A fake-agent or a broken artifact cannot register, because the grant it needs to run is withheld until it has demonstrably done real work — moved a real prompt through a real model and produced the real token. Quality stops being a thing you remember to test after the fact and becomes a structural precondition of existence in the fleet: an agent that cannot pass its qspec never gets a lease, so it never runs at all.

This is affordable because the probe knot is small. The 0.5B dense knot drives the Paris probe in ~2 s warm (see Benchmarks: fat-station boot ~2 s warm, paris-probe-rknot full forward ~5–6 s warm), cheap enough to run on every admission rather than only in the heavy ~123 s 7B gate. The heavy qwen-coder-7b Paris gate (tests/paris_subagent.rs) remains the deep ratchet for the full mesh; the qspec is the same assertion made cheap enough to gate every spawn.

Oaths and user-spawnable agents

A qspec gates quality — "the thing it claims to be, it provably is." An oath gates conduct — "the thing, however capable, has sworn how it will behave." The two are orthogonal and parallel: qspec is works, oath is conduct. Where the qspec is run at admission and discarded, the oath is cryptographically bound into the minted grant and travels with the capability for its whole life, so a runtime conduct monitor can always read the contract the agent agreed to.

This wave also makes the human a first-class spawner — a peer to Thoth. Thoth grows the swarm autonomically; the user spawns agents directly under their own UCAN. Both routes converge on the same monster-swarm spawn, so an agent is one definition regardless of who minted it:

An agent = a leased process + its own DID + a passed qspec (works) + a sworn oath (conduct), spawnable by Thoth OR by the user.

The oathspec format

An oath is a small JSON file (*.oath.json) declaring a sworn conduct commitment plus the bounds it accepts:

{ "oath": "<commitment>",
  "max_caps": ["net"],
  "ttl_max_secs": 3600,
  "sworn_by": "did:key:..." }

• oath — the sworn commitment, in prose (the declared conduct contract).
• max_caps — the ceiling of capabilities the bearer may hold. Requested caps must be a subset; anything outside is a denial.
• ttl_max_secs — the maximum grant lifetime the oath permits; a longer ttl is a denial.
• sworn_by — optional DID of the swearer (audit / attribution).

Reference oaths live at monster-swarm/oaths/*.oath.json.

The delegate gate (caps-subset + ttl bound + fct binding)

monster-guard is the enforcing authority, exactly as with --qspec:

monster-guard delegate <name> <caps> [--ttl <secs>] [--qspec <file>] [--oath <file>]

With --oath, before minting monster-guard checks the request against the oath's bounds and DENIES admission if either:

• the requested caps are not a subset of max_caps, or
• the requested ttl exceeds ttl_max_secs.

On success it does more than admit: it binds the oath into the minted grant as the UCAN fct (facts). The oath is therefore cryptographically bound to the capability and travels with it — the grant carries the declared conduct contract, signed, for anyone downstream to read and enforce against. (a0n-auth's IssueOptions.facts is the field that carries the fct.)

A standalone verifier:

monster-guard oath verify <file>

Without --oath the behavior is exactly today's (capability + lease, plus any --qspec quality gate).

Cryptographic proof (signed oath-tokens + Ulysses pacts)

The raw-JSON oath above proves what the bounds are, but it does not prove the swearer swore it: a raw oath is text bound into the grant fct, signed only by ROOT (the admitter). Nothing in it carries the swearer's own signature. This round closes that gap. An oath can now arrive as a signed oath-token — itself a UCAN minted by the swearer — so the contract carries the swearer's signature, not merely root's attestation that it exists.

The token format. A signed oath-token is a UCAN whose body is the oath:

iss = <swearer DID>            # who swears the oath (signs the token)
aud = <agent DID>             # who is bound by it
att = [{ can: "oath/uphold",  with: "agent:self:<id>" }]
fct = { oath, max_caps, ttl_max_secs?, sworn_by? }   # the oath terms
<signed by the swearer's key>

The capability is oath/uphold on agent:self:<id> — a self-directed promise of conduct, not authority over anyone else. The terms (oath, max_caps, ttl_max_secs, sworn_by) live in the token's fct, exactly the fields the raw oathspec carries — so a token is a raw oathspec that has been signed.

Ulysses (self-issued / self-audienced, irrevocable). When iss == aud the oath-token is a Ulysses pact: the agent binds itself to the mast — a self-issued, self-audienced precommitment it cannot later wriggle out of. The swearer and the bound party are the same DID, so it is an irrevocable conduct contract the agent imposes on its own future self. At spawn, monster-swarm mints this form: the agent self-signs its oath with its own freshly-minted keypair (see the swarm note), and oath verify / the ledger flag it as ulysses.

Co-signed chains (spawner imposes + agent accepts). When the spawner wants to impose an oath rather than let the agent author it, the oath-token is a 2-link chain: the spawner mints the oath capability and hands it down via IssueOptions.proofs (the spawner imposes), and the agent issues the leaf that accepts and binds it (the agent accepts). The proof chain is the cryptographic record that both parties consented — the imposer and the bound, each with their own signature in the chain.

Verify-at-admission flow. monster-guard delegate --oath <file> now accepts either a signed oath-token or raw JSON (back-compat; raw is marked unsigned). For a signed token it:

1. verify_chains the signature — an invalid, forged, or expired token is denied, no grant minted. (This is the new force: a forged oath cannot pass.)
2. Requires oath/uphold in the token's att.
3. Reads the terms from fct (oath, max_caps, ttl_max_secs, sworn_by) — the same caps-subset + ttl-bound checks as before, now against verified terms.
4. Binds the verified terms plus proof metadata into the minted grant: { sworn_by, ulysses, signed } ride alongside the oath in the grant fct, so the crypto provenance travels with the capability for any downstream conduct monitor to read. oath verify reports signed / swearer / ulysses.

The unification note. Before, an oath was raw JSON in the grant fct, signed only by root — the admitter's attestation that an oath exists. Now the oath carries the swearer's own signature: a verified UCAN proving the swearer (and, in a co-signed chain, the imposer too) actually swore it. The conduct contract is no longer "root says this agent has an oath" but "this agent signed this oath, and root verified that signature at admission." a0n-auth needed no change to support this — IssueOptions.facts already carries the fct, IssueOptions.proofs carries the prf chain, and verify_chain validates both.

spawn --oath and frame surfacing

The same gate threads through the swarm CRUD path. monster-swarm spawn takes an optional --oath <file>:

monster-swarm spawn --ucan <token> --node fat-station --id paris --caps net \
                    --lease 15 --oath oaths/net-only.oath.json \
                    --qspec qspecs/paris.qspec.json \
                    -- --knot ~/.edgework/models/qwen2.5-0.5b-instruct.knot \
                    --port 8779 --role both --layers 0..28

spawn --oath threads the oath to monster-guard delegate (the caps-subset + ttl bound + fct binding above), records it in the ledger, and surfaces each agent's oath in the thoth.fleet.swarm.v1 fleet frame — so every agent's sworn conduct is "front of mind" in Thoth's gate/consciousness surface, not buried in a file. With signed oath-tokens the ledger and frame now also carry oath_signed and oath_sworn_by — the cryptographic proof (was it a verified signature, and whose) rides front of mind alongside the oath text, not just its prose. At spawn the agent self-signs a Ulysses oath-token with its own keypair (see the swarm note); the file is written to $MONSTER_GUARD_HOME/oath-tokens/<id>.oath.ucan and handed to guard. Thoth already has an Oath gate (ThothGateScore::Oath); the bound, verified oath is the declared contract a conduct monitor — e.g. the monster-badchild rogue-bodyguard layer — enforces against at runtime.

The user-spawnable flow

The human spawns agents directly, peer to Thoth, through moonshine:

moonshine agent spawn --node <bin> [--oath <file>] [--qspec <file>] [--caps ...] [-- <args>]

moonshine agent spawn shells to monster-swarm spawn under the user's own UCAN, resolved from MOONSHINE_AGENT_UCAN or ~/.edgework/agent.ucan. Bootstrap the user's spawn authority once:

monster-swarm/scripts/grant-user.sh
    # keygen + monster-resident grant --with agent:fleet --can agent/spawn
    # -> writes ~/.edgework/agent.ucan

grant-user.sh mints a user keypair and delegates an agent/spawn capability on agent:fleet from the resident root into ~/.edgework/agent.ucan. After that, moonshine agent spawn runs under that capability — the same double-gated, oath-bound, qspec-gated admission Thoth uses, just initiated by the human.

Cross-links

• monster-guard/README.md — oath-bound admission (delegate --oath, oath verify, the fct binding).
• monster-swarm/README.md — the oaths note (spawn --oath, ledger, frame) and the user-spawnable note.
• moonshine/README.md — agent spawn (UCAN resolution + bootstrap).

Oath enforcement (breach -> revoke + audit)

Swearing an oath only matters if breaking it has teeth. This wave closes the oath lifecycle with enforcement: a breach revokes the agent (its lease is killed at the next tick) and appends a record to an append-only audit log. The full arc is now:

SWEAR (signed oath-token at spawn) -> BIND (grant fct) -> PROVE (verify_chain at admission) -> ENFORCE (breach -> revoke + audit).

The two layers (reflex vs. judgment)

Enforcement is split deliberately so the same mechanism serves both an automatic reflex and a deliberate semantic judgment:

• LEASE-LEVEL reflex (here, in monster-swarm). The mechanical act of enforcement — revoke the grant so the lease dies, and write the audit row — lives in monster-swarm. It is dumb and reliable: given "this agent breached," it reaps and records, no opinion required.
• SEMANTIC conduct judgment (monster-badchild). Deciding whether an agent actually misbehaved — exfiltrated, exceeded its sworn caps, acted off-mission — belongs to the monster-badchild rogue-bodyguard layer, the runtime conduct monitor. When badchild concludes an agent broke its bound oath, it calls oath-breach to enforce. Judgment decides; the reflex acts.

This is the same split as the rest of the chain: monster-swarm holds the mechanism, the layer above supplies the decision.

The breach CLIs

monster-swarm oath-breach --ucan <token> --id <id> --reason <reason>
    Enforce a breach: REVOKE the agent (its lease is killed at the next tick)
    and APPEND a breach record to $MONSTER_GUARD_HOME/breaches.json. Requires a
    UCAN authorizing the reap, exactly as `reap` does — enforcement is a guarded
    mutation, not a free action.

monster-swarm breaches [--json]
    List the recorded breaches (read the append-only audit log).

oath-breach is the enforcement primitive a conduct monitor calls; breaches is the audit reader. A breach report can be signature-verified (the same sign.rs path that signs swarm broadcasts), so the reporter's claim is itself attributable, not anonymous hearsay.

The breaches.json schema

Enforcement appends one record per breach to $MONSTER_GUARD_HOME/breaches.json — append-only (the audit trail is never rewritten, only grown):

{
  "id": "<agent id>",
  "name": "<agent name>",
  "oath_sworn_by": "<DID of the swearer>",
  "oath": "<the sworn commitment prose>",
  "caste": "<scout | breeder>",
  "reason": "<why the breach was reported>",
  "reported_by": "<DID / identity of the reporter>",
  "ts": "<timestamp>"
}

The record captures both halves of the contract — the oath that was sworn (oath, oath_sworn_by) and the breach that broke it (reason, reported_by, ts) — so the audit row stands on its own as the full account of what was promised and what was violated.

Autotick enforcement (auto --enforce-oaths)

The autonomic loop can enforce oaths on its own cadence:

monster-swarm auto --ucan <token> --enforce-oaths [--breach-at <n>] ...

With --enforce-oaths, each tick reaps agents whose conduct signal has crossed into breach and records the breach. The threshold is the SwarmSignal consciousness level: an agent at consciousness >= --breach-at (default 5) is treated as in breach, reaped, and logged via the same oath-breach path. This is the lease-level reflex on a timer — a structural backstop that reaps a misbehaving agent even if no semantic monitor fires. The semantic monster-badchild hook remains the precise judgment; --enforce-oaths is the autonomic floor.

The monster-badchild conduct-hook contract

The contract between the conduct monitor and the enforcement primitive is one call:

1. monster-badchild detects misconduct at runtime — it reads the bound, verified oath from the grant fct (the conduct contract the agent agreed to) and watches the agent's behavior against it (exfiltration, off-mission action, caps overreach).
2. On a violation, monster-badchild calls monster-swarm oath-breach with the offending agent's --id, a --reason, and a UCAN authorizing the reap.
3. monster-swarm enforces: revoke -> lease killed at the next tick -> append the breach record to breaches.json.

Judgment lives in badchild; the reflex (revoke + audit) lives here. The bound oath is what makes the contract legible to badchild in the first place — it can only enforce a contract it can read, and the oath rides front of mind in the grant fct and the thoth.fleet.swarm.v1 frame.

Trust scoring (reputation gates future spawns)

Enforcement makes a single breach bite — revoke + audit. Trust closes the loop by giving breaches memory: it scores reputation from the breach history and gates future spawns by that score. The oath lifecycle now runs end to end:

SWEAR -> BIND -> PROVE -> ENFORCE -> SCORE -> GATE.

A repeat offender is no longer punished one breach at a time and then forgiven; the breach record accumulates into a reputation that locks the offender out of spawning at all.

Trust attaches to the spawner, not the agent

Reputation is scored against the spawner — the UCAN holder who requests spawns (Thoth, or a user) — not the agent that breached. This is deliberate, and it follows from the identity model:

• Each agent gets a fresh DID per spawn. A breaching agent's DID has no history to score and never will — it is minted at spawn and discarded at reap. Scoring the agent's DID would score a stranger every time; a serial offender could wipe its record simply by respawning under a new DID.
• The spawner is a stable identity. The UCAN holder that requested the spawn persists across spawns and is accountable for the agents it spawns. Scoring the spawner is what makes reputation accumulate at all — it is the one identity in the loop with continuity.

So trust answers "should we keep accepting spawn requests from this requester, given how the agents it has spawned have behaved?" — not "is this fresh agent trustworthy?" (it has no record to judge).

The breach record's spawned_by and the trust function

To attribute a breach to its spawner, the breach record gains a spawned_by field — the spawner DID — recorded alongside the existing fields (id, name, oath_sworn_by, oath, caste, reason, reported_by, ts). Trust is then a pure function of a spawner's recent breach count:

trust_of(spawner) = clamp(1 - 0.34 * recent_breach_count, 0..1)

• 0 breaches -> 1.0 — a clean spawner is fully trusted.
• 1 breach -> ~0.66, 2 -> ~0.32, 3+ -> ~0 — trust decays ~0.34 per recent breach and is clamped to [0, 1], so three strikes drives it to the floor.

The trust CLI

monster-swarm trust [--json]
    List spawner DIDs with their trust score and recent breach count, read from
    the append-only breach audit log (breaches.json). The reputation view: who
    has spawned breaching agents, and how trusted each spawner now is.

trust is the read side of reputation, the way breaches is the read side of the audit log — breaches is per-incident, trust is per-spawner aggregate.

Admission-by-trust (the floor that locks out repeat offenders)

The score is not just reported — it gates ops::spawn. Before admitting a spawn, the op computes trust_of(<requesting spawner>) and denies the spawn when it is below a floor:

• Default floor: 0.34 — a spawner with two or more recent breaches (trust ~0.32) falls below it and is locked out.
• Env override: MONSTER_SWARM_MIN_TRUST — set a stricter or looser floor.
• Clean spawners are unaffected. Trust 1.0 clears any sane floor; a spawner whose agents have never breached spawns exactly as before. The gate only bites a requester whose spawned agents keep breaching their oaths.

This is reputation made structural: a repeat offender does not merely get its latest agent reaped — it loses the ability to spawn new agents at all until its recent breach count decays back under the floor.

Trust in the fleet frame

Trust rides front of mind in the thoth.fleet.swarm.v1 frame alongside the oath signals — the Thoth Oath-gate now surfaces reputation, not just the current sworn conduct. A spawner's standing is visible in Thoth's gate/consciousness surface, so the gate can weigh who is asking as well as what they have sworn.

The closed loop

Putting the whole arc on one line:

swear -> bind -> prove -> enforce -> score -> gate — an agent swears a signed oath, the oath is bound into its grant, the signature is proven at admission, a breach is enforced (revoke + audit), the breach scores the spawner's reputation, and that reputation gates the spawner's future spawns.

A runnable, end-to-end walkthrough of the entire story — quality (qspec) + oath (swear/bind/prove) + enforcement + trust scoring + admission-by-trust lockout — lives at monster-swarm/scripts/demo-admission.sh. Run it to watch a clean spawner spawn, an offender breach, and the offender get locked out by the trust floor.

Tamper-evident audit chain

Breaches and trust give the fleet a memory; the audit chain makes that memory tamper-evident. Every lifecycle event the fleet performs — spawn, update, reap, delegate, breach — is appended to a hash-chained, root-signed log so the record of what the fleet did cannot be quietly edited, reordered, or forged after the fact.

• Hash-chained. Each entry carries prev_hash (the previous entry's hash) and its own hash; the entries form a linked chain. Modifying, inserting, deleting, or reordering any entry breaks the link from that point forward.
• Root-signed. Each entry is ECDSA-signed by the fleet root key (the shared resident root). A forged entry cannot carry a valid signature, so it is rejected even if its hashes are internally consistent.

audit --verify walks the chain and detects all five failure classes: modification, insertion, deletion, reordering, and forgery.

Where it lives

The chain is audit.jsonl under $MONSTER_GUARD_HOME (default ~/.moonshine.d) — the same shared state dir as root.key, fleet.json, and breaches.json. It is append-only: like breaches.json it is never rewritten, only grown. Each line is one JSON entry: { seq, ts, kind, subject, actor, detail, prev_hash, hash, sig }.

How to verify the chain

export MONSTER_GUARD_HOME=/path/to/open-source/.moonshine.d

monster-swarm audit                # print the chain (human-readable)
monster-swarm audit --json         # the raw chain: { "entries": [ ... ] }
monster-swarm audit --verify       # walk the chain, report intact / tampered
monster-swarm audit --verify --json

audit --verify --json emits the verdict:

{ "ok": true, "entries": 42, "first_bad": null, "reason": "", "head": "<hash>" }

and sets the exit code: 0 when the chain verifies, 3 when tampering is detected. Use the exit code as a tripwire — fail closed on a 3.

What a failure means

A non-zero (3) verdict means the on-disk record no longer matches its own signatures and hash links. first_bad is the seq of the first broken entry and reason says why (a hash mismatch, a bad signature, a sequence gap). It is not a transient error to retry past: it means audit.jsonl has been modified, truncated, reordered, or had a forged entry inserted since it was written. Treat it as an integrity incident — the audit trail can no longer be trusted from first_bad onward, and the surrounding state (fleet.json, breaches.json) should be regarded as suspect too, since an attacker with write access to one likely had it to the others.

Over MCP

The chain is surfaced through two monster-resident MCP tools (see monster-resident/README.md):

Both shell out to the monster-swarm binary as a subprocess and isolate the child's stderr from the MCP stdout stream (the child's stdout is the JSON returned; its stderr never leaks into the JSON-RPC transport) — the same discipline the rest of the resident's subprocess shell-outs follow.

Surfaced to Thoth

The verified state rides front of mind in the thoth.fleet.swarm.v1 frame as audit: { head, verified, entries } — the chain head hash, whether it currently verified, and the entry count — so Thoth sees the tamper-evident root of the fleet's history alongside the live vibe, the sworn oaths, and the trust scores. Full reference is in the monster-swarm/README.md.

Recursive accountability (the delegation tree)

Trust runs up the chain: a child's breach dings the parent that spawned it. Recursive accountability is the matching constraint that runs down: a parent agent may spawn a CHILD, but delegation attenuates — no node can hand a child more authority than it holds itself. The swarm is therefore not a flat fleet under one root but a fully-accountable delegation tree: every node is UCAN-rooted, capabilities and oaths strictly attenuate downward, and trust propagates upward. No escalation down the tree.

Three independent mechanisms enforce attenuation, each at a different layer.

CAPS — attenuated agent/spawn, subset enforced at spawn

A parent mints a child's spawn capability with delegate-spawn:

monster-swarm delegate-spawn --ucan <parent-token> --issuer-secret <hex> \
                             --to <child-did> --caps <subset> [--ttl <secs>]

It mints an attenuated agent/spawn capability for the child, carrying the constraint {caps: <subset>} — the requested --caps are bound into the minted token as the ceiling the child may ever request. a0n-auth's verify_chain rejects a non-subset: a child cannot mint or present a capability whose caps exceed the parent's, because the proof chain would not validate.

The enforcement is then doubled at use time. ops::spawn checks that the sandbox --caps the child requests are within the authorizing chain's permitted caps:

• a root holder of agent/* is unrestricted (it may request any sandbox caps), but
• a delegated holder is bounded by the {caps} constraint its delegate-spawn token carries — a child handed caps = net cannot spawn a grandchild with caps = net,fs,exec, no matter what it asks for.

So the cap ceiling is enforced both cryptographically (the chain will not verify a non-subset) and at admission (ops::spawn refuses an out-of-subset sandbox request even if the token somehow names it).

OATH — co-signed oath chain, subset attenuation in monster-guard

The same no-escalation rule binds conduct. A co-signed oath chain (the co-signed form: the parent imposes the oath via IssueOptions.proofs, the child accepts the leaf that binds it) must attenuate, and monster-guard enforces it. At admission, monster-guard denies the grant — an "oath escalation" — if a child's oath loosens the parent's bounds, i.e. if either:

• the child's oath max_caps exceed the parent's oath max_caps, or
• the child's oath ttl ceiling is higher than the parent's ttl_max_secs.

A child may swear a stricter oath than its parent (tighter caps, shorter ttl) but never a looser one. On success the grant fct records the chain provenance: oath_chain_depth (how deep in the imposed chain this oath sits) and imposed_by (the DID of the parent that imposed it) ride alongside the oath terms, so the imposition is auditable from the grant itself.

LINEAGE — depth recorded, parent-trust propagation

The chain's shape is recorded so accountability can run both directions:

• The ledger and the thoth.fleet.swarm.v1 frame record the chain depth — how many delegation hops from the root this node sits — and spawned_by, the parent DID that minted it. A root-spawned agent is depth 0; the child it spawns is depth 1; the grandchild depth 2.
• Trust already propagates upward. Because trust attaches to the spawner (the stable spawned_by identity), a child's breach dings the parent that spawned it — the parent is accountable for the agents it grows, recursively. A node that spawns breaching children loses its own ability to spawn (the trust floor), exactly as a top-level spawner does.

The tree (root -> Thoth/user -> agent -> child, attenuating)

Put together, the swarm is a delegation tree in which authority only ever narrows on the way down and accountability only ever accumulates on the way up:

resident root  (agent/* — unrestricted)
   |  grant
   v
Thoth / user   (agent/spawn on agent:fleet)         depth 0 spawners
   |  spawn  (caps C0, oath O0)
   v
agent          (caps C1 ⊆ C0, oath O1 ⊑ O0)         depth 1
   |  delegate-spawn  (caps C2 ⊆ C1) + co-signed oath O2 ⊑ O1
   v
child          (caps C2 ⊆ C1, oath O2 ⊑ O1)         depth 2
   ...                                                deeper, still attenuating

Caps and oath bounds strictly attenuate downward (each ⊆ / ⊑ enforced — by verify_chain + ops::spawn for caps, by monster-guard for oaths); trust propagates upward (a child's breach dings its parent). Every node is UCAN-rooted at the resident, every hop is recorded with its depth and spawned_by. The net is a fully-accountable delegation TREE — recursive Ulysses: each node ties not only itself but its whole subtree to a mast no descendant can loosen.

Cascade revocation

The delegation tree gives the swarm a shape; cascade revocation is the containment guarantee over that shape. Reaping or breaching a node reaps its entire spawned subtree — the recursive closure over the spawned_by lineage graph — so a revoked or rogue parent never leaves orphaned delegated children running. It is the matching reflex to the chain rule that a revocation at any link kills everything beneath it.

When to cascade

• Revoking a parent that has delegated children. A plain reap revokes only the named agent; if that agent used delegate-spawn to grow children, those children keep running under their (now-orphaned) grants. Use --cascade to revoke the whole subtree in one act — the agent and every descendant.
• Containing a rogue. When you no longer trust a node, you no longer trust what it spawned. Cascade is the "burn the branch" action: it bounds the blast radius to exactly the subtree, no wider.
• A single leaf agent (no children) cascades to just itself — --cascade is safe to use unconditionally; it simply reaps the closure, which for a leaf is one node.

How to read the reaped subtree

monster-swarm reap --ucan <token> --id <id> --cascade --json

emits the closure that was reaped:

{ "reaped": ["<id>", "<child-id>", "<grandchild-id>", ...], "count": 3 }

reaped is the set of ids revoked — the target first, then its spawned descendants — and count is the total. The set is exactly the spawned closure of the target over the spawned_by graph; nothing outside the subtree is touched. The two-queen floor still protects the last persistent breeder.

How the audit chain records it

Each node the cascade reaps appends its own hash-chained, root-signed reap entry to audit.jsonl (see Tamper-evident audit chain), so the containment is recorded per node, not as a single opaque event. After a cascade the chain still verifies — audit --verify returns ok (exit 0) — and the reap entries' subject ids reconstruct exactly the reaped closure. The containment is therefore provable from the chain alone: you can read back which subtree was revoked, when, and by whom.

An enforced oath-breach auto-cascades on the same path: a breached agent's spawned descendants are reaped too, each emitting its own Reap entry, so a rogue node cannot leave live delegated children behind. The breach reflex (oath-breach, auto --enforce-oaths) and the cascade containment are the same mechanism — revoke + signed audit — applied across the lineage closure rather than to a single agent.

The MCP tool

Over MCP, cascade is the subagent_reap tool's optional cascade arg in monster-resident:

Like the audit_* tools, the cascade path shells out to the monster-swarm binary as a subprocess and isolates the child's stderr from the MCP stdout stream — the child's stdout ({ reaped, count }) is the JSON returned; its stderr never reaches the JSON-RPC transport. (Plain subagent_reap without cascade keeps the in-process single-agent reap.)

Autonomic re-fork (running the controller live)

The swarm now self-regulates on a live box: a controller loop reads the collective swarm consciousness off the partyline and re-forks the fleet within the FRF budget, with no operator in the path. This section is how to run it, what drives it, and how to watch it.

Run the controller as a daemon

export MONSTER_GUARD_HOME=/path/to/open-source/.moonshine.d
TOKEN=$(monster-resident grant --audience <station-did> --with agent:fleet --can agent/*)

monster-swarm auto --ucan "$TOKEN" --node aeon-monitor --interval 30
#   live controller loop, one tick every 30 s (Ctrl-C to stop). Run it under
#   your process supervisor (launchd / systemd / a moonshine subagent) to keep
#   it resident. Omit --interval for a single tick (cron/manual cadence).

Each tick reads the partyline collective consciousness and decides:

• hot — collective consciousness >= --bud-at (default 4), or a node fired a recalibration `-> bud a scout (the extra reproductive void lifts the race mode: under load the colony grows).
• calm — collective consciousness <= --reap-below (default 0) and the fleet is over-provisioned `-> reap the oldest idle scout (the vent).
• otherwise hold (the hysteresis dead band).

With --enforce-oaths [--breach-at <n>] the same loop also reaps+records agents whose conduct signal has crossed into breach (see Autotick enforcement).

The guardrails (it cannot run away)

The controller is doubly bounded, exactly like a hand-driven mutation:

• It acts only within the UCAN it is handed (agent/* on agent:fleet) — never beyond it.
• Budding is gated by the AntColony FRF budget: never past the DECAGON ceiling (default 10), never below the two-queen reap floor, and the God-Formula stability weight it reports is provably always >= 1.

So a misconfigured or adversarial partyline cannot drive the fleet past the manifold or strip it below survivable population — the budget refuses.

Drive it with broadcast

The controller is the reader of the partyline; broadcast is the writer. Emit signals to exercise the loop deterministically:

monster-swarm broadcast --consciousness 5 --json   # hot   -> next tick BUDs a scout
monster-swarm broadcast --consciousness 0 --json   # calm  -> next tick REAPs an idle scout
monster-swarm broadcast --recalibration --json     # storm -> BUD regardless of level
monster-swarm broadcast --consciousness 4 --count 3 --json   # emit 3 hot signals

broadcast --json prints exactly { "emitted": <N>, "consciousness": <C>, "source_id": "<src>" } on stdout (status to stderr), so it is scriptable. Over MCP, the same drive is the swarm_broadcast tool (below).

Read the autonomic actions in the audit chain

Every bud / reap / breach the controller takes is a signed entry in the tamper-evident audit chain tagged actor auto — distinguishable from operator- or Thoth-driven actions:

monster-swarm audit --json | python3 -c '
import sys, json
for e in json.load(sys.stdin)["entries"]:
    if e.get("actor") == "auto":
        print(e["seq"], e["kind"], e["subject"], e["detail"])'

Because the chain is hash-chained and root-signed, the autonomic record cannot be quietly edited; audit --verify still returns ok (exit 0) after the controller has been running. The whole loop is accountable.

The MCP tool

Like the audit_* tools and the cascade reap, swarm_broadcast shells out to the monster-swarm binary as a subprocess and isolates the child's stderr from the MCP stdout stream — the child's stdout (the { emitted, ... } JSON) is returned; its stderr never reaches the JSON-RPC transport. Pair it with swarm_autotick (single tick) and audit_log (read the auto-tagged actions) to drive and observe the loop entirely over MCP.

Admission registry (quality + oath)

Admission is now a double gate at registration time: a registered command is admitted only if its quality probe passes AND its oath verifies. Both gates are declared in the registry and run by monster-guard delegate via setup.sh.

The 7-column .moonshine

open-source/.moonshine now carries seven columns — the quality column gained a sibling oath column:

name kind path caps build quality oath

• quality — a *.qspec.json path (or -). When present, setup.sh passes --qspec <quality> to monster-guard delegate; the grant is withheld unless the quality probe passes (the artifact provably works).
• oath — a *.oath.json / signed oath-token path (or -). When present, setup.sh passes --oath <oath> to monster-guard delegate; the grant is withheld unless the oath verifies — the requested caps are within the oath's max_caps, the ttl is within ttl_max_secs, and (for a signed token) the signature validates.

A - in either column is back-compatible (today's behavior, that gate skipped); an old-format 6-column registry is read as having no oath column at all.

The double gate (works + behaves)

Together the two columns make setup.sh a double gate: a command registers only if it is both proven to work (quality) and admitted to behave within its sworn bounds (oath). Capability says "you may," budget says "we can afford it," quality says "it works," and the oath says "and it has sworn how it will behave" — all four checked before the grant exists. A command that fails either probe never gets a lease, so it never runs.

A worked example — a plugin registered through the full quality + oath double gate — lives at monster-swarm/oaths/example-admitted-plugin.md.

The quality-ratchet philosophy

The Paris gate is a ratchet, not a smoke test. It encodes one rule: the agentic stack must move a real prompt through a real model and get the real answer, end to end, or it does not ship. The value is precisely that it is expensive and real — it cannot be satisfied by mocks, by spectral sketches, or by a chat-template that refuses the question. Decoding bugs are the worst class of bug because the plumbing looks healthy while the output is wrong; this gate is the tripwire for exactly that failure, asserting the token id rather than a string so a deflecting model still proves the path.

Operating principle: keep the touched scope green and the ratchet armed. Before declaring agentic work done, run the gate against the dense knot and confirm the [paris] OK line. A SKIP: is not a pass for the purposes of this ratchet.

Benchmarks (cold vs warm)

Tracking ledger for the mesh. Always label cold vs warm — on this mesh the page-cache state dominates wall time, so an unlabeled number is meaningless. A 4.7 GB dense knot read cold (uncached) is the long pole; once it is page-cached ("warm") the same op is dramatically faster. Append new dated blocks below as fresh measurements land; do not overwrite prior blocks — the point is the trend.

• Cold = first run on a fresh box / after the knot has been evicted from the page cache (uncached 4.7 GB read).
• Warm = the 4.7 GB knot is already page-cached and binaries/deps are built.

2026-05-22 — Apple Silicon, CPU-only inference

Model: qwen-coder-7b.knot (4.7 GB dense knot) at ~/.edgework/models/qwen-coder-7b.knot. CPU-only forwards (no GPU).

Inference (qwen-coder-7B)

Quality (coder-7B base-completion top-1 token — the correctness ratchet)

Real weights, top-1 (argmax) next token, verified. 4–5 / 5 correct base completions on real weights is the real-inference ratchet — these are the strings that prove the mesh is doing real forwards, not synthetic output.

How to re-measure: drive each prompt through one /decode-next (or moonshine --oneoff -c "<prompt>") and assert the top-1 token id. The Paris row is the committed gate (tests/paris_subagent.rs).

Data movement / builds

Parallel wave wall (6 subagents, heavy CPU contention)

One wave, six subagents sharing the CPU (so each is throttled by contention, not isolated speed). Wall time per subagent's task:

How to re-measure: fork a 6-subagent wave on one box and record each subagent's wall time; expect heavy contention to dominate (the slowest subagent gates the wave).

Cross-references

• MONSTER_ACCOUNTABLE_AGENTS.md — the capstone narrative: the problem, the principle, and the six accountable-agent gates A-F (QUALITY / CONDUCT / ENFORCEMENT / DELEGATION / TAMPER-EVIDENCE / CONTAINMENT), each tied to the demo gate that proves it, plus the gate table and "Run the proof".
• monster-swarm/README.md — the guardrails, the two gates, autonomic homeostasis, autonomic re-fork (live) (auto --interval controller + broadcast driver, FRF-bounded, auto-tagged audit), subagent identity, oaths + user-spawnable, oath enforcement (oath-breach / breaches / auto --enforce-oaths), trust scoring (trust / admission-by-trust floor), cascade revocation (reap --cascade / containment over the spawned subtree), tamper-evident audit chain (audit / audit --verify / audit.jsonl).
• monster-swarm/SECURITY.md — threat model and accepted residual risks.
• monster-swarm/oaths/example-admitted-plugin.md — a worked example of a plugin admitted through the full quality + oath double gate.
• monster-resident/README.md — the MCP server and the full tool arg table (including the audit_verify / audit_log audit-chain tools and the swarm_broadcast partyline driver).
• monster-guard/README.md — the sandbox + lease + revoke enforcement layer; qspec + oath-bound admission.
• monster-badchild/README.md — the rogue-bodyguard conduct monitor; the semantic judgment that calls oath-breach to enforce a broken oath.
• moonshine/README.md — the FRF shell; moonshine agent spawn (user-spawnable agents).
• ../auth/rust/README.md — the a0n-auth UCAN crate (issue / verify_chain / revocation; IssueOptions.facts carries the oath fct, IssueOptions.proofs carries the co-signed prf chain, and verify_chain validates a signed oath-token at admission).