The GOVENANT Standard — Part 10: The Anti-Patterns

The nine 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 nine before declaring any pillar done; they are the difference between a checklist audit and a real one.

The meta-pattern behind all nine: 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.

---

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?