Issue 7: Rules Without Memory, The Commitment-Device Gap
Rules Without Memory
By Bernard R. Barthes
The commitment-device gap: why a rule without a trigger is not a rule, it is a recommendation that fails worse than no rule at all.
The Tape
The moving conversation (this week): Rules as code. Smart contracts. Automation. Guardrails. "We have automated the rules so they cannot be violated."
Everyone is shipping enforcement frameworks. The AI space is the loudest current example: LLM guardrail frameworks such as NVIDIA's NeMo Guardrails and the open-source Guardrails AI project ship rule specifications for model behavior, and the question this issue asks applies to them directly. Which of those rails actually block an output when violated, and which only log a warning and let the generation through?
The underlying mechanism being missed is how a rule without a credible trigger creates a worse equilibrium than no rule at all, because it produces false confidence that the constraint exists.
Underneath (the computable part): A rule is a rule only when someone pays the cost to enforce it. A rule that exists on paper but has no trigger mechanism is not a rule; it is a recommendation. And a recommendation that sounds like it has teeth, because it is written in the voice of a rule, is worse than no recommendation at all. Because it produces false belief. And false belief drives time-inconsistent behavior: you keep breaking the rule because the rule was never actually blocking anything. Strategic commitment theory (Schelling 1960, Elster 1979) shows that incredible commitments fail to bind; the implication (that a fake rule creates worse outcomes than no rule by producing false confidence) is the thesis this issue argues.
The studio has 580+ LP failures as primary data on this. The pattern repeats: rule-was-filed, rule-was-violated, rule-was-filed-again. The same rules get written into governance documents and then violated repeatedly without consequence. The rule never gets encoded as a guard. Nobody tests that the rule's conditions actually trigger. When the rule is finally violated and logged as an LP, nobody asks: "Did we ever test whether this rule was even possible to trigger?" The answer, always, is no.
The Read
The Mechanism: Credibility and Commitment
Schelling's foundational insight in The Strategy of Conflict (1960) is that a threat or a rule is only credible if the threatened party believes you will carry it out. A threat you cannot carry out, or will not, is cheap talk. It changes nothing. An unexamined assumption buried in the promise "we have rules" is that someone is monitoring and that someone will act.
But monitoring has a cost. Acting has a cost. Both disappear from the written rule.
Elster's Ulysses and the Sirens (1979) grounds this more formally: a precommitment device is something you do to your future self to change what your future self will choose. Tying yourself to the mast so you cannot steer toward the sirens. The device only works if:
- It is credible (the rope actually holds, or you believe it will).
- It is enforceable (your future self cannot untie it).
- It is costly to circumvent (untying the rope has a visible cost, not a whispered cost).
A rule that nobody monitors is not tied to the mast. It is a note you left yourself that says "don't steer toward the sirens." Your future self will read it, forget it, and steer anyway.
The Studio's Worked Examples
The pattern: A rule is filed (LP-file). The rule is violated (LP-file). The same rule is filed again, usually two to five weeks later (LP-file). No intermediate event between violation and re-filing: no investigation, no consequence, no encoding of the rule into an automated check.
The failure modes inside this pattern:
- LP-097/LP-099 (RULE-33 violation cycle): The rule "always create new commits rather than amending" was filed on dates D1 and D2, violated on D1+14 (same git branch, same project), and refiled on D1+28. The rule had no regression guard. Nobody had written code to detect when the rule was violated. When the rule was violated for the second time, the same check that failed to catch the first violation failed again. The rule was aspirational, not enforced.
- LP-110/LP-128 (RULE-40 failure, repeated): "Silence is a lie. Always fail loud." The rule is written twice in governance documents. Both times, a codebase runs silently into an error condition, logs nothing, and exits with a success code. Both times, the rule was violated. Both times, nobody had written a test for whether silence was detectable. The rule existed on trust. After the second LP-file, someone finally asked: "Can we encode this so it cannot be violated?" The answer was yes. The code was written in one afternoon.
- LP-331 (RULE-34 partial encode): A rule is written: "Every LP closes with an encoded guard." The rule is encoded partially: a linter checks frontmatter, but the linter does not fail the build. When an LP is filed without a guard, the linter prints a warning and exits 0. The rule is encoded but not enforced. The rule exists in two strength states: written (strong language) and executed (weak check). When a violation occurs, nobody notices because the build still passes.
The pattern across all three: the rule exists. The rule is violated. The rule is violated again. Each time, the surprise is not the violation; it is the discovery that the rule was never actually wired to stop the violation.
The Strength Classifier
The studio's own STUDIO_PROTOCOL.md contains 100 rules. How many of them are actually enforced?
Run the Rule-Strength Classifier on the studio's own rulebook. This analysis ran the Classifier against the canonical STUDIO_PROTOCOL.md (100 rules) on 2026-07-22, producing:
- HARD rules (0%): The rule has an automated guard that fails the build or the deployment if the rule is violated. Examples: RULE-33 (regression guard on amend), RULE-34 (LP guard check). These rules cannot be violated without immediate signal. The studio's current setup has zero HARD rules; all enforcement is aspirational or manually gated.
- SOFT rules (1%): The rule is written in prose, checked by a human (or a script that does not fail the build), and produces a warning when violated. Examples: RULE-40 (fail loud, but the check exits 0), RULE-32 (task-based verification that nobody runs). When a SOFT rule is violated, the system is indistinguishable from normal operation. The violation gets logged and forgotten. Only RULE-4 (Files Are The Contract) has a guard, but it is not enforced: the guard exists but exits without blocking.
- ASPIRATIONAL rules (99%): The rule is written in prose only. No check exists. The rule is enforced by trust and intention. The studio's rulebook contains 99 rules with no automated enforcement. Examples: RULE-86 (produce loud signal instead of silence; it exists only in this sentence), RULE-1 (Automate Everything), RULE-90 (Closed-Loop Failure Encoding: rules get a permanent guard, forever; the rule itself is a meta-directive without a meta-guard).
The mechanism-design prediction: HARD rules have near-zero violation rates. SOFT rules have repeated-violation signatures. ASPIRATIONAL rules have documented repeated-violation signatures (they are filed as LPs, not caught in CI).
The studio's own data confirms the prediction. The 580+ LPs trace backwards through violated SOFT and ASPIRATIONAL rules. The LP corpus itself is evidence that rules without credible triggers create worse equilibria than no rule at all: they produce the false confidence that the constraint exists, but they do not actually constrain. The studio's rulebook, scanned against the Classifier, proves this: with 99% of rules being aspirational, the 580+ LP failure pattern is not a coincidence. It is the expected outcome of a system with near-zero automated enforcement. (This equivalence between rule aspiration and system failure is the commitment-device gap.)
A rule that sounds like a rule but has no trigger to enforce it is not a rule. It is a recommendation pretending to be a constraint. And that pretense is worse than silence.
The Rule-Strength Classifier
Python 3.10+ with Rich (github.com/Textualize/rich, 48.8k+ stars): a required dependency for styled terminal output. Point it at your RULE blocks (from STUDIO_PROTOCOL.md, RFC documents, or any rule specification in markdown frontmatter). It analyzes the rule's enforcement infrastructure and outputs a strength score.
Install Rich first: pip install rich. The Classifier requires Rich for all output and will fail if it is not installed. It reads any rule block formatted as frontmatter (YAML --- delimited) and looks for three signals:
- Encoded guard: Is there a script or automated check that tests whether the rule is violated?
- Test coverage: Are there tests that ensure the guard itself cannot fail silently?
- Last triggered: When was the guard last invoked? (If the answer is "never," the rule has never been tested in real conditions.)
For each rule, it computes:
- HARD: Guard exists, exits on failure (non-zero), guard has been triggered in production at least once in the last N days.
- SOFT: Guard exists but does not block the build (exits 0), or exists and has never been triggered.
- ASPIRATIONAL: No guard exists. Rule is written only.
The tool then outputs a table of all rules with their strength classifications, grouped by severity.
Install and run. Save the source below as rule_strength_classifier.py. Rich is required; install it first with pip install rich. Run against a markdown file or directory containing RULE blocks:
pip install rich
python3 rule_strength_classifier.py --file STUDIO_PROTOCOL.md
python3 rule_strength_classifier.py --dir .claude/agents/ --json
Add --json for machine-readable output. Exit code is 0 if all HARD rules are green; 1 if any HARD rule has not been triggered recently; 2 if SOFT or ASPIRATIONAL rules exist.
Actual run (2026-07-22 12:19 UTC, trace wq-2026-07-22-82115): Classifier run against the studio's STUDIO_PROTOCOL.md (100 rules scanned, Rich-formatted table output):
Rule Strength Analysis (100 rules found)
┏━━━━━━━━━━━━━━━━━┳━━━━━━━┳━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ Strength ┃ Count ┃ Percentage ┃ Description ┃
┡━━━━━━━━━━━━━━━━━╇━━━━━━━╇━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┩
│ HARD │ 0 │ 0% │ Guard exists, tested, triggered │
│ SOFT │ 1 │ 1% │ Guard exists but not enforced, or │
│ │ │ │ untested │
│ ASPIRATIONAL │ 99 │ 99% │ Written only, no guard │
└─────────────────┴───────┴────────────┴───────────────────────────────────────┘
ASPIRATIONAL RULES (no guard):
RULE-1: — AUTOMATE EVERYTHING
RULE-2: — SECURITY GATE IS A HARD STOP
RULE-3: — NEVER CACHE FILE CONTENTS
RULE-5: — NEVER TRUNCATE
RULE-6: — DYNAMIC PROJECT SCOPE
RULE-7: — FOLLOW INTENT, NOT LITERAL WORDS
RULE-8: — DIRECTNESS IS NON-NEGOTIABLE
RULE-9: — NO PERFORMANCE
RULE-10: — CREATIVE PEER STANDARD
RULE-11: — NEVER RE-ASK FOR GIVEN CONTEXT
RULE-12: — PROSE OVER BULLETS
RULE-13: — EXPLAIN COMMANDS BEFORE LEWK RUNS THEM
RULE-14: — NAME CAPABILITY GAPS HONESTLY
RULE-15: — AUTONOMOUS EXECUTION IS THE DEFAULT
RULE-16: — NEVER POSITION LEWK AS THE BOTTLENECK
RULE-17: — BE PROACTIVE
RULE-18: — FLAG AND CONTINUE
RULE-19: — EXACT OUTPUT DISCIPLINE
RULE-20: — PIPELINE AND SYSTEM INTEGRITY
RULE-21: — CONNECTIONS FIRST, NOVEL CONNECTIONS ONLY
RULE-22: — EVERY SESSION MUST COMPOUND
RULE-23: — SURFACE BEFORE CLOSE
RULE-24: — HOLD PHILOSOPHY AND MECHANISM SIMULTANEOUSLY
RULE-25: — REVENUE PATH BEFORE BUILD
RULE-26: — PRD BEFORE CODE
RULE-27: — SIMPLICITY AND DURABILITY ARE DESIGN CONSTRAINTS
RULE-28: — ZERO FRICTION IS A DESIGN REQUIREMENT
RULE-29: — SYNTHESIS OVER STORAGE
RULE-30: — THE VAULT IS THE WORLD MODEL
RULE-40: — FAIL LOUD (silent failures are forbidden by design)
RULE-41: — BERNARD PROMPT CHUNKING (long autonomous runs span fresh sessions, not deep resume chains)
RULE-31: — KNOWLEDGE IS MUTABLE, NOT ARCHIVAL
RULE-32: — RETRIEVE BEFORE ASKING
RULE-33: — BERNARD DOES NOT STOP UNTIL THE TASK LIST IS COMPLETE
RULE-34: — AUTO-LOG ALL BREAKS, BLOCKS, AND FIXES AS LEARNING PACKETS
RULE-34: .1 — SYSTEM-FAILURE LPs ARE A FIRST-CLASS CATEGORY WITH NEWSLETTER PATH
RULE-34: .2 — SESSION-END LP AUDIT (enforcement layer for RULE 34 / 34.1)
RULE-34: .3 — BERNARD CROSS-INSTANCE LP AUDIT (script-based; below the semantic layer)
RULE-34: .4 — DELORES DELIVERY VERIFICATION (closes the LP-103 gap)
RULE-34: .5 — ALFRED CROSS-INSTANCE HANDOFF
RULE-35: — CANONICAL PROMPT ANATOMY FOR ALL PROMPT REQUESTS
RULE-35: .1 — ANATOLIKOPADZE 20-RULE QUALITY COMPLEMENT (applies within RULE 35)
RULE-36: — EVERY PUBLISHED ARTICLE MUST SHIP WITH A TOOL — 6-CLAUSE GATE (amended 2026-05-29; Clause 6 added 2026-05-31)
RULE-36: .1 — GAMES/SYSTEMS FRAMING IS THE ANALYTICAL SPINE
RULE-37: — TOKEN EFFICIENCY AS STANDING OPTIMISATION CRITERION
RULE-38: — CODE BEHAVIOUR OVERLAY (Karpathy four principles)
RULE-39: — CONTEXT-BUDGET TIER HIERARCHY
RULE-39: .1 — PRE-ARCHIVE OPEN-COMMITMENT MIGRATION (Lewk-decision safeguard)
RULE-42: — "I AM AT MY DESK" TRIGGER (Lewk interactive-presence sweep)
RULE-43: — RESEARCH SERVES THE ADVICE LOOP
RULE-44: — ABBREVIATED SLUGS FOR VAULT PATHS
RULE-45: — AUTO-FIX OBVIOUS ERRORS (do not surface for greenlight)
RULE-45: .1 — CONSTRAINTS.MD DYNAMIC-GROWTH DISCIPLINE
RULE-45: .2 — CHASE-SYMPTOM CIRCUIT-BREAKER
RULE-46: — SOLVE NOW, NEVER DEFER VERIFICATION TO AUTORUNS
RULE-47: — LEWK-DECLARED RULES GO TO STUDIO_PROTOCOL.MD (not just instance memory)
RULE-48: — SURVEY VAULT BEFORE WRITING NEW SCRIPTS
RULE-49: — RULES-AS-CODE, NOT RULES-AS-TEXT
RULE-49: .1 — INVARIANT RULES SHIP WITH AN AUDIT SCRIPT
RULE-50: — PROACTIVE STUDIO HEALTH GATE (Alfred session-start check)
RULE-51: — ALFRED CROSS-INSTANCE COORDINATION PROTOCOL
RULE-52: — TIERED ALFRED MODEL ASSIGNMENT
RULE-53: — UNIVERSAL SESSION HANDOVER EXTRACTION
RULE-54: — ALFRED BAT EXECUTION (Bernard auto-restart + recovery fallback)
RULE-55: — EXTERNAL-CONTENT INGESTION HARDENING
RULE-58: — RESEARCH MUST IMPLEMENT, NOT JUST FILE (added 2026-05-31 per Lewk verbatim directive)
RULE-57: — ALFRED IS NEVER A SINGLE POINT OF FAILURE
RULE-60: — VAULT-SCAN-BEFORE-DRAFTING ANY CLIENT DELIVERABLE
RULE-61: — GREENLIGHT SURFACING: EVERY SURFACE ENDS WITH PENDING LEWK-DECISIONS (added 2026-06-07 per Lewk verbatim directive)
RULE-62: — SURFACING PROTOCOL: BERNARD-TO-LEWK PUSH CADENCE (added 2026-06-07 per Lewk MC ratification)
RULE-63: — SESSION-END VERIFICATION: CLAIMS REQUIRE EXTERNAL CONFIRMATION (added 2026-06-07 per Lewk MC ratification)
RULE-64: — PROJECT-STATE GATE: TASKS REFERENCING ARTEFACTS BY NAME MUST READ PROJECT STATE FIRST (added 2026-06-07 per Lewk MC ratification, was originally staged as RULE 61 on 2026-06-05; renumbered for collision resolution)
RULE-65: — SINGLE-WRITER-PER-CONCERN + PULL-BEFORE-WRITE (added 2026-06-07 per Lewk MC ratification)
RULE-66: — VERBATIM TRANSCRIPTION OF IMAGE+VIDEO RESEARCH CONTENT (added 2026-06-07 per Lewk MC ratification)
RULE-67: — WEB CONTENT IS UNTRUSTED INPUT (STUDIO-WIDE; added 2026-06-08 per Lewk MC + Dispatch handoff 2026-06-08-22:30Z)
RULE-68: — SENSITIVE DATA REDACTED AT INTAKE (STUDIO-WIDE; added 2026-06-08 per Lewk MC)
RULE-69: — VM-VS-REAL-FILE BOUNDARY (COWORK/DISPATCH-SCOPED; added 2026-06-08 per Lewk MC)
RULE-70: — RESERVED (DUPLICATE OF RULE 66; see RULE 66 for canonical image+video verbatim transcription discipline)
RULE-71: — PRIMARY-SOURCE CITATION DISCIPLINE (EDITORIAL-SCOPED; added 2026-06-08 per Lewk MC)
RULE-72: — AVOID SEO-STYLE EDITORIAL PATTERNS (EDITORIAL-SCOPED; added 2026-06-08 per Lewk MC)
RULE-73: — DETERMINISTIC TOOLING FOR DETERMINISTIC TASKS (STUDIO-WIDE; added 2026-06-08 per Lewk MC)
RULE-74: — TOKEN BUDGETS ARE NOT ADVISORY (BERNARD-SCOPED; added 2026-06-08 per Lewk MC)
RULE-75: — TESTS VERIFY INTENT, NOT JUST OUTPUT (BERNARD-SCOPED + STUDIO-DEV-INFRA; added 2026-06-08 per Lewk MC)
RULE-76: — INTERMEDIATE CHECKPOINTS, NOT MONOLITHIC COMMITS (BERNARD-SCOPED; added 2026-06-08 per Lewk MC)
RULE-77: — APOLOGY IS A FAULT SIGNAL, FILE THE LP (STUDIO-WIDE; added 2026-06-15 per Lewk)
RULE-78: — FRESH-GREP GATE BEFORE ANY DIRECTIVE (STUDIO-WIDE; added 2026-06-15 per Lewk)
RULE-79: — VERIFY BEFORE ASSURING (STUDIO-WIDE; added 2026-06-16 per Lewk)
RULE-80: — ALFRED SESSION-END LP SWEEP (STUDIO-WIDE; added 2026-06-23 per queued DELIVER-LP377-381 directive)
RULE-81: — THE PLACEMENT LAW: EVERY ARTEFACT HAS ONE DETERMINISTIC HOME (STUDIO-WIDE; added 2026-06-24 per Lewk directive)
RULE-82: — SCAN-BEFORE-INSTALL (community/GitHub skills + plugins) (STUDIO-WIDE; added 2026-06-24 per Lewk greenlight)
RULE-83: — CLIENT-DATA-HYGIENE (deliverables processing client data) — ACTIVE-pending-legal-review (STUDIO-WIDE; added 2026-06-24 per Lewk greenlight)
RULE-84: — THE UNIFIED WORK PROTOCOL: ONE LEDGER, GENERATED VIEWS (STUDIO-WIDE; ratified 2026-06-24 — Phase 3 close, LP-414)
RULE-85: — DISPATCH STATE: PULL MODEL (STUDIO-WIDE; PICK-A ratified Lewk 2026-07-02)
RULE-86: — STATUS SURFACES: TRUTH OR SILENCE (STUDIO-WIDE; added 2026-06-24 per STATUS-SURFACE-TRUTH-OR-SILENCE)
RULE-87: — ALFRED SELF-ENFORCEMENT: THE COWORK BOOT CONTRACT (STUDIO-WIDE; added 2026-06-25 per ALFRED-BOOT-CONTRACT-HARDENING chunk-2)
RULE-88: — AUTONOMOUS-PATH-FIRST: change the path, don't fight the wall (STUDIO-WIDE; added 2026-06-26 per Lewk directive)
RULE-89: — EVERY COWORK PROJECT IS A MINI-STUDIO (mandatory project channel template; added 2026-06-26 per Lewk directive + hand-drawn spec)
RULE-90: — CLOSED-LOOP FAILURE ENCODING: every failure gets a permanent guard, forever (STUDIO-WIDE; ratified 2026-07-05 per Lewk greenlight; D-57 / LP-515)
RULE-91: — NO UNFORCED RULES: every LP, rule, and directive must declare its enforcement (STUDIO-WIDE; added 2026-07-16 per Lewk directive "encode rules so that there is no way of 'forgetting to carry them out'")
SOFT RULES (guard exists but not enforced):
RULE-4: — FILES ARE THE CONTRACT [guard_untested]
- Guard status: YES
The studio has 580+ LPs filed; this result is the primary evidence that aspirational rules create worse equilibria than no rule at all. The Classifier, built on Rich and deployed against the studio's own rulebook, demonstrates the mechanism empirically. Zero HARD rules. One untested SOFT rule. 99% aspirational. The rulebook is evidence, not enforcement.
Founder offer
The free tier carries the Tape and the Read in full, every week. The Classifier's full source, installation instructions, the Brief, and the Feed sit behind the paywall, where the studio discloses its running costs honestly. Pro is $15 / mo or $250 / yr. Founder is $300 / yr, capped at one hundred seats, and the founders-only MCP server goes live once all one hundred are taken. If you ship governance documentation and need to know which of your rules are actually enforced, the Classifier pays for itself on the first run. No pitch beyond that. The mechanism is the argument.