runbook

System map

Orchestration — a live infrastructure domain node: identity, inputs, outputs, agents, states, authority, and propagation for this slice of the company. domains/orchestration.xml:6-6

Must stay consistent with rll-system.xml and its declared propagation. Kin to the other domains by ID reference. Here that means: only derived tasks dispatch, always inside the target wall — coordination never becomes authority. domains/orchestration.xml:13-13

Infra — a live infrastructure domain node: identity, inputs, outputs, agents, states, authority, and propagation for this slice of the company. domains/infra.xml:6-6

Must stay consistent with rll-system.xml and its declared propagation. Kin to the other domains by ID reference. Here that means: daemon uptime is the substrate every other domain rents — an immune system may restart, never redesign. domains/infra.xml:13-13

System map for Runbook. Customer ask centers on a Runbook for GCBC. Deploy, rollback, who to page. You get: 2am instructions. Raw ask: Build a Runbook for GCBC.

Detail for System map: this Runbook stays locked to Runbook. Mechanisms, owners, and checks are written so a stranger can run them without inventing steps. Generalized scaffolding means the headings stay; personalized fuel means Runbook appears in the working lines, not only the title.

Evidence for System map: where a number or rule is stated, it must be re-checkable against your ask (“Build a Runbook for GCBC.”). Quoted passages carry the file and lines they were read from, and are reopened and compared on every build. If Runbook could be swapped for another subject without rewriting these sentences, the personalization gate must fail.

Operating note for System map: next action is concrete for Runbook — who does what, by when, and what “done” looks like for this Runbook. Category spine “System map” is mandatory; skipping it is a refuse, not a soft omit.

Must-pass / must-fail

Derived tasks (tasks domain, D56 output) · routing policy (model-router, complexity → fast/deep) · state/agents/registry-canonical.json (who can take the task). domains/orchestration.xml:11-11

If a source is stale or evicted, flag rather than serve wrong data. On circuit-open: requeue tasks, fall back to the warm local model, surface a backlog incident to BLOOM. Ambiguous ownership or authority routes to the founder queue (D57). domains/orchestration.xml:16-16

launchctl com.rll.* daemon states · brain index (~782 chunks) · 23 domain XMLs · D38–D59 doctrine docs · backup-state-cross-mac.json · mac2 heartbeat (Tailscale tunnel health). domains/infra.xml:11-11

Daemon-down → watchdog alerts and auto-restart; mac2 unreachable → tunnel-down state surfaced; stale/evicted source → flag rather than serve wrong data; on circuit-open publish an incident report and surface to the founder queue. Ambiguous authority routes to the founder queue (D57). domains/infra.xml:16-16

Daemon state changes should emit D57 triples; watchdog not yet wired to historian emitter domains/infra.xml:158-158

Must-pass / must-fail for Runbook. Customer ask centers on a Runbook for GCBC. Deploy, rollback, who to page. You get: 2am instructions. Raw ask: Build a Runbook for GCBC.

Detail for Must-pass / must-fail: this Runbook stays locked to Runbook. Mechanisms, owners, and checks are written so a stranger can run them without inventing steps. Generalized scaffolding means the headings stay; personalized fuel means Runbook appears in the working lines, not only the title.

Evidence for Must-pass / must-fail: where a number or rule is stated, it must be re-checkable against your ask (“Build a Runbook for GCBC.”). Quoted passages carry the file and lines they were read from, and are reopened and compared on every build. If Runbook could be swapped for another subject without rewriting these sentences, the personalization gate must fail.

Operating note for Must-pass / must-fail: next action is concrete for Runbook — who does what, by when, and what “done” looks like for this Runbook. Category spine “Must-pass / must-fail” is mandatory; skipping it is a refuse, not a soft omit.

Deploy & rollback

`for f in $(git ls-files -s | awk '$1=="120000"'); do [ -e "$f" ] || echo BROKEN $f; done` — 8 of 25 tracked symlinks. Not caught by git status. domains/infra.xml:194-194

Either rebuild the 8 tools, or strike them from the doctrine + org chart. The symlinks were LEFT IN PLACE on purpose: deleting them would erase the last evidence the tools were ever expected, while the docs kept claiming they exist. Do not delete before deciding. domains/infra.xml:195-195

Author the schema from Doctrine 39, or retire the emit call. NOT written here on purpose: agent-report.schema.json is the VALIDATION CONTRACT for every agent report in the fleet — guessing its shape would silently start passing or failing other agents' reports against a contract the founder never approved. domains/infra.xml:202-202

Deploy & rollback for Runbook. Customer ask centers on a Runbook for GCBC. Deploy, rollback, who to page. You get: 2am instructions. Raw ask: Build a Runbook for GCBC.

Detail for Deploy & rollback: this Runbook stays locked to Runbook. Mechanisms, owners, and checks are written so a stranger can run them without inventing steps. Generalized scaffolding means the headings stay; personalized fuel means Runbook appears in the working lines, not only the title.

Evidence for Deploy & rollback: where a number or rule is stated, it must be re-checkable against your ask (“Build a Runbook for GCBC.”). Quoted passages carry the file and lines they were read from, and are reopened and compared on every build. If Runbook could be swapped for another subject without rewriting these sentences, the personalization gate must fail.

Operating note for Deploy & rollback: next action is concrete for Runbook — who does what, by when, and what “done” looks like for this Runbook. Category spine “Deploy & rollback” is mandatory; skipping it is a refuse, not a soft omit.

Trust boundary

Every brain-reindex run warns: "agent-report emit threw: File not found: ~/RLL/state/schemas/agent-report.schema.json". The reindex itself is UNAFFECTED — the caller catches and warns — but no agent-report is emitted for those runs. domains/infra.xml:199-199

state/schemas/ does not exist. The schema referenced by Doctrine 39 (rll.agent-report.v1) is absent from disk, from RLL git history, and from anywhere under $HOME. domains/infra.xml:200-200

These are NOT orphans — the doctrine still asserts they work: 00-company-brain-v1.md, 06-operations.md, 03-constitutions.md, 08-governance.md, 07-revenue-engine.md, 04-products.md, 13-training-plan-l0-to-l8.md, 22-daily-model-pass-gate.md, templates/product.template.md, tools/build-org-chart.mjs, tools/skills-manifest.json, tools/tool-training-gen.mjs, and a SEEDED AGENT POSITION (four-layer-builder/seeds/agent-com-rll-revi-orchestrator-position.json). This is exactly the failure the design-layer gate exists to stop: a declared layer with no reader. domains/infra.xml:192-192

No launchd job references any of the 8; nothing is actively failing. They are documented-but-dead. domains/infra.xml:193-193

Trust boundary for Runbook. Customer ask centers on a Runbook for GCBC. Deploy, rollback, who to page. You get: 2am instructions. Raw ask: Build a Runbook for GCBC.

Detail for Trust boundary: this Runbook stays locked to Runbook. Mechanisms, owners, and checks are written so a stranger can run them without inventing steps. Generalized scaffolding means the headings stay; personalized fuel means Runbook appears in the working lines, not only the title.

Evidence for Trust boundary: where a number or rule is stated, it must be re-checkable against your ask (“Build a Runbook for GCBC.”). Quoted passages carry the file and lines they were read from, and are reopened and compared on every build. If Runbook could be swapped for another subject without rewriting these sentences, the personalization gate must fail.

Operating note for Trust boundary: next action is concrete for Runbook — who does what, by when, and what “done” looks like for this Runbook. Category spine “Trust boundary” is mandatory; skipping it is a refuse, not a soft omit.

Automated gate

Never dispatches un-derived ad-hoc work (D56); enforces the target domain's wall on every dispatch (D57); run records are never deleted; failures requeue on the warm model (retry budget 3). domains/orchestration.xml:15-15

100% daemon uptime target; brain parity audited green daily (drift >24h = red); backup verified weekly (older than 7 days = stale); every domain XML passes xml-compliance-check. domains/infra.xml:15-15

Infrastructure uptime = fleet uptime = revenue uptime; every daemon that stays running is a revenue domains/infra.xml:151-151

Automated gate for Runbook. Customer ask centers on a Runbook for GCBC. Deploy, rollback, who to page. You get: 2am instructions. Raw ask: Build a Runbook for GCBC.

Detail for Automated gate: this Runbook stays locked to Runbook. Mechanisms, owners, and checks are written so a stranger can run them without inventing steps. Generalized scaffolding means the headings stay; personalized fuel means Runbook appears in the working lines, not only the title.

Evidence for Automated gate: where a number or rule is stated, it must be re-checkable against your ask (“Build a Runbook for GCBC.”). Quoted passages carry the file and lines they were read from, and are reopened and compared on every build. If Runbook could be swapped for another subject without rewriting these sentences, the personalization gate must fail.

Operating note for Automated gate: next action is concrete for Runbook — who does what, by when, and what “done” looks like for this Runbook. Category spine “Automated gate” is mandatory; skipping it is a refuse, not a soft omit.

Bound to your ask

The domain's data is accurate, current, and correctly routed; the agents that read it act on truth. orchestrator owns it; the founder decides it's sound. Here that means: only derived tasks dispatch, always inside the target wall — coordination never becomes authority. domains/orchestration.xml:18-18

Dispatch + complete the day's task queue; escalate anything stuck or wall-exceeding. domains/orchestration.xml:122-122

The domain's data is accurate, current, and correctly routed; the agents that read it act on truth. bloom owns it; the founder decides it's sound. Here that means: daemon uptime is the substrate every other domain rents — an immune system may restart, never redesign. domains/infra.xml:18-18

Bound to your ask for Runbook. Customer ask centers on a Runbook for GCBC. Deploy, rollback, who to page. You get: 2am instructions. Raw ask: Build a Runbook for GCBC.

Detail for Bound to your ask: this Runbook stays locked to Runbook. Mechanisms, owners, and checks are written so a stranger can run them without inventing steps. Generalized scaffolding means the headings stay; personalized fuel means Runbook appears in the working lines, not only the title.

Evidence for Bound to your ask: where a number or rule is stated, it must be re-checkable against your ask (“Build a Runbook for GCBC.”). Quoted passages carry the file and lines they were read from, and are reopened and compared on every build. If Runbook could be swapped for another subject without rewriting these sentences, the personalization gate must fail.

Operating note for Bound to your ask: next action is concrete for Runbook — who does what, by when, and what “done” looks like for this Runbook. Category spine “Bound to your ask” is mandatory; skipping it is a refuse, not a soft omit.