Part 5: The Life of a Governed Action
Every action any occupant takes runs the same nine-step gauntlet, enforced in the substrate, not requested in the prompt. If any step is skippable by any code path, the gauntlet does not exist (the pair rule: enforcement at the source and at the terminal edge).
5.1 The gauntlet
0 · Duty context the action exists because a duty fired (cron / event / dependency) — or a human/boardroom directive; ad-hoc actions still get a duty_run row1 · Wake the dispatcher claims the item (compare-and-set, deduped)2 · Deliberate the occupant (LLM / code / human) reasons over blackboard + fabric, scoped by its context grants3 · Ownership check does this role OWN the lever? ── not owned → becomes a REQUEST4 · Validation gate deterministic hard-blocks, then judged lenses; never fails open5 · Guarded execution a GRANTED tool is the only delivery path; the tool re-guards ownership inside its handler6 · Verify delivery does the outcome_ref RESOLVE to an artifact OUTSIDE the acting role's control (a merged PR, a commit, a stored object, a row from a different verified path), confirmed by an INDEPENDENT verifier? ── no → FAILED and escalated, never silently retried (Law 2). Row-exists ≠ delivered; a count-only or self-written outcome is an observation, not a delivery (AP-10)7 · Record + predict append-only ledger row + a falsifiable prediction bound to the lever's metric domain (Law 1 meets Part 6)8 · Grade on horizon measured later against reality; the grade calibrates future trust5.2 The validation gate in detail (step 4)
Two layers, strictly ordered:
- Deterministic hard-blocks. Regex/schema/policy rules that no model can override and that run even when every LLM dependency is down: missing required elements (a CTA, a license header), forbidden content (secrets, naked booking links, competing CTAs), structural validity. Failing open is not a degraded mode; it is an unvalidated release.
- Judged lenses. An LLM judge scores the artifact per lens — retarget per domain: GTM → brand-truth / funnel / economic-risk / compliance; engineering → correctness / security / performance / maintainability; legal → accuracy / privilege / jurisdiction / tone. Lens failures trigger a bounded auto-revise loop; repeated failure escalates and can seed a ledger rule (Part 6 §6.7).
Boundary-enforced norms work where persona deliberation doesn’t: the reference implementation’s gate enforced ~500 validations/week that prompt instructions had failed to achieve — and it also correctly hard-blocked a fabricated claim in a press release the drafting agent was fully confident about.
Every outbound artifact passes the gate: emails, posts, chat replies, PR descriptions, filings — and agent-authored configuration (a proposed prompt, roster, or rule change is an outbound artifact aimed at the org itself).
5.3 Trace-by-ID (the auditability contract)
Every step writes a row that carries the IDs of its neighbors, so one query chain reconstructs any action end-to-end:
duty_runs.id → agent_actions.duty_run_id → agent_actions.outcome_value (terminal row ref) → executive_decisions.action_ref → executive_decisions.measured_effectThis chain is precisely what the audit’s ALIVE test walks (Part 9 §9.4). A system where delivery exists but cannot be traced back to a duty, a decision, and a prediction is doing real work outside its own governance — the “delivery pulse without a governance pulse” failure (AP-9), which is the subtlest flatline of all.
5.4 Chat is an actuation surface, not an exception
Conversational surfaces (boardroom @mentions, operator chat, working chats) run the same gauntlet: the chat runtime’s toolset is the role’s granted tools (step 5), proposals from chat run the ownership check (step 3), outbound replies pass the gate (step 4), and every tool call lands in the record (step 7). The transcript is backed by an auditable action log — chat that acts is governed action with a conversational trigger, nothing more.
The default conversational surface SHOULD be a single accountable entry-point role — the Chief of Staff. Exposing every role for direct @mention pushes the routing decision onto the human (they must know which role owns which lever) and diffuses accountability across the thread: no one role owns whether the human’s request was delivered. Instead, a human talks by default to one coordinating role that holds broad read across the record, resolves intent, routes the work to the owning role — or files a request when the lever is unowned (§1.2) — and is accountable for the request being delivered (Law 2) and covered (Law 3). Direct @mention of a specific role stays available as an escalation/override, not the front door.
The Chief of Staff is a coordinator, not a god-agent: it owns the conversation and the routing, and owns no execution levers of its own. “Knows everything” means broad read; “gets it done” means the authority to delegate, open duties, and hold owners accountable — never the authority to pull every lever itself. A single role that owned all the levers would collapse separation of powers, hand one occupant unbounded blast radius (§1.2), and reduce delivery to its own self-report — the very failure Law 2 and AP-10 exist to prevent.
Customer-facing chat tiers share the plumbing but never the permissions: hard tenant isolation, minimal toolsets, gate on every outbound reply.