Skip to content
The GOVENANT Standard

The GOVENANT Standard — 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 row
1 · 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 grants
3 · Ownership check     does this role OWN the lever?          ── not owned → becomes a REQUEST
4 · Validation gate     deterministic hard-blocks, then judged lenses; never fails open
5 · Guarded execution   a GRANTED tool is the only delivery path; the tool re-guards ownership
                        inside its handler
6 · Verify delivery     does the outcome row EXIST in the DB?  ── no → FAILED and escalated,
                        never silently retried (Law 2)
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 trust
sequenceDiagram autonumber participant D as Duty/Event (roster) participant DP as Dispatcher participant R as Role (occupant) participant OG as Ownership gate participant VG as Validation gate participant T as Granted tool participant DB as Record (append-only) participant W as Watchdogs D->>DP: duty fires (due_at) DP->>DP: claim (CAS) + sensor pass alt nothing actionable DP->>DB: duty_run: skipped + reason else work found DP->>R: run occupant (context-scoped) R->>OG: pull lever(params) alt lever not owned OG->>DB: executive_request filed (never executes) else owned OG->>VG: artifact alt hard-block or lens fail VG->>DB: validation_log fail (+ revision loop, bounded) else pass VG->>T: execute (tool re-guards ownership) T-->>DB: terminal side effect + agent_actions row (cost, model) DP->>DB: verify outcome row exists (SLA) alt outcome missing DP->>W: FAILED + escalate (never silent retry) else verified DP->>DB: duty_run: delivered (outcome_ref) R->>DB: falsifiable prediction (metric ∈ lever domain) end end end end Note over DB,W: horizon elapses → measureDueDecisions grades the prediction (Part 6)

5.2 The validation gate in detail (step 4)

Two layers, strictly ordered:

  1. 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.
  2. 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_effect

This 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.

Customer-facing chat tiers share the plumbing but never the permissions: hard tenant isolation, minimal toolsets, gate on every outbound reply.