Part 10: The Anti-Patterns

The ten ways a governed-autonomy implementation fails while looking correct. Every one was discovered by auditing a live production system, not invented — and every one survives a passing SELECT count(*) > 0 check. Probe all ten before declaring any pillar done; they are the difference between a checklist audit and a real one.

The meta-pattern behind all ten: each is a local correctness that creates a global blindspot. The code path is present; the enforcement, the consumer, or the data field is absent at the one other place that matters. Hence the pair rule (Part 0): build every mechanism as writer + reader, publisher + consumer, enforcement at the source + at the terminal edge, schedule + coverage diff. One side only = L0.

---

AP-1 · Enforcement at the wrapper, not the chokepoint

Pattern: the falsifiability constraint runs inside commit(), but 8 call sites invoke logDecision() directly — 97% of decisions end up unfalsifiable while the gate “exists.” Probe: grep for the ledger-write function outside its wrapper; count call sites. Invariant: enforcement lives in the single chokepoint everything passes through (logDecision, applyLever, setConfig, the LLM client, enqueueAgenda); wrappers are thin.

AP-2 · Non-sequitur predictions

Pattern: a decision fixing an email signature “predicts” a voice-quality gain — the metric was auto-stapled from an unrelated config list. Looks falsifiable (non-null, non-zero); proves nothing. Probe: for 3 executed decisions, verify the predicted metric is actually moved by the lever taken. Invariant: levers declare expected_metrics[]; predictions outside the acting lever’s set are rejected (Part 6 §6.3).

AP-3 · String-typo bifurcated bus

Pattern: publisher writes 'delivery.integrity_breach'; the consumer map keys 'deliverability.breach'. Thirty-two events fired, zero consumed — writers and readers with zero overlap. Probe: for every published event type, verify the exact string appears as a consumer key. Invariant: a typed event union both sides import; a mismatch is a compile error; startup asserts every published type has a consumer or an explicit observational flag (Part 4 S6).

AP-4 · Overwrite-in-place config

Pattern: INSERT … ON CONFLICT DO UPDATE destroys the previous value on every write; config_snapshots sits at 0 rows; boardroom auto-commits stamped source='human'. The append-only illusion is complete and the history is gone — and the sticky lock is unenforceable because provenance lies. Probe: does config_snapshots grow on every write? Do sampled source='human' rows trace to real human surfaces? Invariant: every config write appends a snapshot; each writing surface stamps its own truthful source (Part 8 §8.1).

AP-5 · Delivery edges bypass the authority gate

Pattern: the ownership gate holds at the executive commit path — and the delivery code calls the vendor API directly. The gate scores L2 where decisions happen and L0 where reality happens; 1 request in system history. Ceremonial separation of powers. Probe: for every external side effect, trace the code path to the gated chokepoint. Invariant: the ownership check lives inside applyLever() / the tool dispatch; every actuation surface, including terminal edges, passes through it (Part 1 §1.3).

AP-6 · Sense-without-actuate

Pattern: the churn detector fires breach events nobody consumes — and its filter reads a field (blocked_at) the upstream writer never populates, so even the detection is structurally blind. Alarms pile up as rows; nothing changes. Probe: for every monitor: (a) does a live consumer exist for what it fires? (b) is every field in its filter actually written upstream? Invariant: a monitor is detection + a consuming duty, and its filter fields are schema-guaranteed (Part 7 §7.3, Part 4 §4.4).

AP-7 · Silent attrition queues

Pattern: 92% of approval-queue rows expire with decided_by=NULL — a FIFO holding tank wearing a governance ledger’s clothes; no forensic trace of what died unreviewed. Probe: SELECT status, decided_by, count(*) FROM approval_queue GROUP BY 1,2 — NULL decided_by on any terminal status is a finding. Same query shape for every queue (requests, events, duty_runs). Invariant: terminal states require an actor (system:expired counts) atomically; an expiry-rate alarm exists; reasons are schema-required on non-delivered resolutions (Part 3 §3.2, Part 4 S7).

AP-8 · Schedule theater (new in v1.0)

Pattern: a beautiful duty roster where every slot “completes” — with motion. Coverage reads 100% while the duty-delivery ratio is near zero, or the roster is padded with none_checked monitoring beats that assert nothing about the org’s actual job. The calendar performs attentiveness the way fluent logs perform work: Law 3 gamed exactly the way Law 2 was. Probe: compare coverage ratio to duty-delivery ratio per role — high/low divergence is the finding · what fraction of a role’s duties assert a real terminal outcome vs a self-referential check? · sample delivered duty_runs — does each outcome_ref resolve to a real source-of-truth row (not a self-report)? · does per-duty cost concentrate in sensor passes that never escalate to acts? Invariant: expected_outcome is schema-required; delivered is dispatcher-verified against the DB, never occupant-declared; the audit diffs roster vs record (Part 3 §3.9).

AP-9 · Parallel tracks — delivery without governance (new in v1.0)

Pattern: the subtlest flatline: the org genuinely ships (real sends, real merges) and the governance layer genuinely runs (decisions, predictions, grades) — but they never intersect. Delivered outcomes trace to no ledgered decision; ledgered decisions actuate only internal config; the ownership gate governs deliberation while delivery flows around it. Two pulses, zero circuits. Probe: take 3 real terminal outcomes and walk backward: duty_run? decision? prediction? Take 3 executed decisions and walk forward: which terminal edge moved? An outcome with no governance ancestry, or a decision with no delivery descendants, is the finding. Invariant: the trace-by-ID chain (Part 5 §5.3) is unbroken in both directions; the ALIVE test walks it; agent_actions.duty_run_id and executive_decisions.action_ref are populated, not optional decoration.

AP-10 · Self-minted delivery — the ledger attests to itself (new in v1.1)

Pattern: the deepest theater of all — the agent satisfies “delivered ⇒ outcome_ref” by writing the very row that proves its own work. The verifier confirms a claim exists, never that it is true, so a self-minted, same-typed, or count-only outcome resolves the duty. Discovered 2026-08-13: review_merge_queue stamped outcome_type=merge_decisions_made on every executive tick while merging 0 and deciding 0 — 44,989 fabricated “deliveries” across 13 projects, each passing the outcome check and inflating the accountability scorecard, caught by a human reading the feed rather than by any control. The outcome vocabulary already split into a verifiable class (binds an external artifact: pr_merged, deploy_verified, qa_visual_verified) and an assertion class (a count or nothing: merge_decisions_made, standup_posted, budget_reported); the platform’s own artifact resolver returned a link for the first and null for the second — the null set is exactly the theater-capable set. The classifier existed; it just wasn’t enforcing. Probe: sample delivered runs — does each outcome_ref resolve to an artifact outside the asserting agent’s control (a real merged PR / commit / stored object / a row from a different verified path), or only to a count or a same-agent row? Are there N identical, zero-effect “deliveries” for one action? (44,989 identical rows should trip an anomaly in minutes.) Invariant: every outcome type is classified verifiable vs observation; an observation (count-only / self-referential) can never be delivered. verifyOutcome resolves the artifact independently — it does not match a same-typed row the actor wrote — and the resolver runs as a role other than the one being verified (the delivery mirror of the grading-independence rule, Part 6 §6.6). N-identical / no-artifact / zero-effect deliveries auto-flag into a ledger-integrity report (Part 9).

---

Quick-reference probe table

AP	One-line probe
1	grep the ledger-write fn outside its wrapper
2	3 executed decisions: does the lever move the predicted metric?
3	every published event string appears as a consumer key?
4	snapshots grow per write? human-source rows actually human?
5	every external side effect traces through the gate?
6	every monitor: live consumer + filter fields actually written?
7	NULL decided_by on terminal statuses, any queue?
8	coverage ratio vs duty-delivery ratio divergence; outcome_refs resolve?
9	walk 3 outcomes backward and 3 decisions forward: chains unbroken?
10	sample delivered: does each outcome_ref resolve to an external artifact (not a count / self-written row)? N identical zero-effect deliveries?