The GOVENANT Standard — Part 6: The Accountability Loop

Predict → measure → grade → calibrate. Every decision carries a falsifiable prediction; predictions are graded after their horizon; grades feed back into how much evidence the role needs to act next time. The organization grades itself — including the graders.

This is the loop most likely to be theater. The reference implementation ran it for weeks with 321/321 “measured” decisions never once graded, 620/673 predictions unfalsifiable, and a flagship prediction that was a non-sequitur. Every rule below exists because its absence was observed in production.

6.1 The decision ledger

CREATE TABLE executive_decisions (
  id TEXT PRIMARY KEY,
  scope_id TEXT NOT NULL, role_key TEXT NOT NULL,
  input_metrics TEXT,                        -- what the role saw (JSON snapshot)
  decision TEXT NOT NULL, rationale TEXT NOT NULL,
  lever TEXT, params TEXT,
  action_ref TEXT,                           -- agent_actions.id — ties decision to actuation
  expected_effect TEXT NOT NULL,             -- {metric, baseline, predicted, horizon_days}
  tier INTEGER NOT NULL,                     -- Part 7 autonomy tier at commit time
  status TEXT NOT NULL,                      -- proposed | committed | executed | unfalsifiable | skipped
  measured_effect TEXT,                      -- {actual, hit, measured_at} — written by the grader
  created_at TEXT NOT NULL
);

6.2 Falsifiability — enforced at the chokepoint

The rule: a decision that cannot be wrong cannot be committed.

Enforcement lives inside logDecision() — the single ledger-write entry point — not in a commit() wrapper call sites can bypass (AP-1: 8 bypassing call sites produced 97% unfalsifiable decisions).
The baseline is captured synchronously from the live metric at commit time. If the baseline cannot resolve, the decision is written status='unfalsifiable' and never counts as measured — visible debt, not silent debt.
Placeholder predictions (baseline=null, predicted=0, predicted==baseline) are structurally rejected. Probe it: try to commit one.

6.3 Domain binding — no non-sequitur predictions

A prediction that names a metric the action cannot move is as unfalsifiable as predicted: 0 — it just looks scientific (AP-2: an email-signature fix “predicting” a voice-quality gain).

The rule: every lever declares expected_metrics[] in the lever registry. makeFalsifiable() rejects a prediction whose metric is not in the acting lever’s set. A fix to the outreach agent predicts reply/bounce rates; a budget change predicts spend; nothing else is accepted.

6.4 Measurement and grading

A scheduled grader (measureDueDecisions) finds past-horizon decisions, fetches the actual metric, computes hit, and writes measured_effect. “Measured” means graded — a measured status with a null hit is the definition of theater.
Cron ordering is a correctness property: the grader MUST run after the metric writer (roster dependency triggers make this structural — the grading duty is trigger_kind='dependency' on the metrics duty; see Part 3 C3).
Coverage of the grader itself is audited: % of past-horizon decisions actually graded is a standing metric, not a hope.

6.5 Calibration — the feedback that makes autonomy “earned”

Per-role ledger accuracy (getLedgerAccuracy pattern) computes hit-rates over a rolling window.
Chronically miscalibrated roles get a raised evidence bar (e.g. confidence floor 95% → 99%) and shrunken predictions (regress toward historical realization).
Calibration is an input to tier promotion/demotion (Part 7): a role that doesn’t know its own hit-rate cannot earn autonomy, by construction.

6.6 Grade the graders

The grading chain MUST terminate in an assertion independent of every role being graded:

No role grades its own output without an external check (a COO that grades the agents and owns the lever that “fixes” them and auto-applies it is judge, jury, and executioner).
The terminal independent assertion is the measured metric itself — reality — which is why 6.4’s grader liveness is load-bearing: when hit is never written, the whole chain dangles from nothing.
Watchdog independence applies: the grader must not share scheduling, flags, or data sources with what it grades in a way that lets one failure silence both.

6.7 Ledger rules — self-improvement that binds

When a role learns something — from a gate failure, a human correction, or a retrospective — the lesson becomes a ledger rule: a durable operating rule injected verbatim into the role’s prompt (HARD-WON LESSONS — do NOT repeat these), capped and de-duplicated per (scope, role).

Two properties make self-modification safe:

Rule changes are themselves ledger entries, approvable at the same tiers as any decision.
Rules are config — visible in the UI, human-editable, human-lockable (Part 8).

This is the honest “self-improvement” story: human/gate-seeded, ledgered, binding — not autonomous weight-tuning. Say exactly that (Part 13 §13.7).

6.8 The significance gate

No role may declare a winner/loser on noise:

Two-proportion z-test (or domain-appropriate test) + minimum detectable effect before any A/B conclusion.
A data-readiness gate holds the system in instrument mode below a sample floor — the scorecard shows “insufficient”, never a confident red, off n=2.
Thin-data tuning is blocked structurally: the tuning lever checks the significance gate before applying.

6.9 The loop, drawn

flowchart LR D[Decision + falsifiable prediction\nmetric ∈ lever domain, live baseline] --> A[Actuation\nthrough the gauntlet] A --> O[Outcome row verified\nLaw 2] O --> M[Grader on horizon\nmeasured_effect.hit] M --> C[Per-role calibration\nhit-rate, evidence bar] C --> T[Autonomy tiers\npromote / demote — Part 7] T --> D M --> L[Ledger rules\nlessons that bind] --> D

Audit hooks: commit a placeholder prediction (must reject) · % past-horizon graded (must be

0 and trending to 100) · find a role grading itself without an independent assertion · verify the predicted metric of 3 random executed decisions is actually moved by the lever taken.