Issue 10: Prompt Engineering is Governance Engineering

A recruiting team wired an LLM into the top of their hiring funnel. The prompt was one line long: rank these candidates from best to worst by their resumes, return the list. It worked, in the sense that it returned a list. Nobody could say why any candidate was above any other, because the prompt never asked the model to say. When a rejected applicant asked for the reason, there was no reason to give. There was an output and no decision behind it.

This is not a model failure. A larger model would have produced a more confident ranking with the same missing spine. It is a governance failure, and the giveaway is that every question the applicant asked is a question a compliance office asks of any consequential decision system. What did you assume about the inputs. How sure were you. When two goals conflicted, which won. Can you re-run it and get the same answer. When should this have gone to a human instead. What did you consider and reject.

Institutions have names and procedures for all six of those questions, because they have been sued over all six. Pre-trade risk checks, medical protocol sign-offs, aviation checklists, sentencing-review guidelines: none of them are about intelligence, all of them are about accountability. And here is the thing that has quietly become true in 2026. Writing a good system prompt now means answering the same six questions. The craft of prompting has walked into the discipline of governance engineering without being introduced.

This issue names the pattern and ships the checklist. Two tools follow The Read: a free Governance-Primitive Prompt Linter that audits any system prompt against those six questions, and a paid retention tool that tracks how a prompt's audit score moves as you edit it over weeks.

5 from the wave, read through the mechanism.

• DSPy (github.com/stanfordnlp/dspy, ~18k stars per the studio's anchor file top-40-ai-githubs.md:28) treats an LLM step as a typed contract with declared inputs and outputs rather than a hopeful paragraph, which is the first half of governance engineering: make the contract explicit before you make it smart.
• Guardrails (github.com/guardrails-ai/guardrails) ships validators that sit between a model and its consumer and refuse outputs that violate a stated schema, which is escalation logic with a different name: a testable boundary that stops a bad decision from leaving the building.
• Anthropic's practice of publishing the shape of its system prompts, and constitutional training that writes the priority rules down, is the same move an institution makes when it publishes its decision policy: a governed decision is one whose rules a reader can inspect.
• LightRAG (github.com/HKUDS/LightRAG, 38,239 stars live-verified 2026-07-27, top-40-ai-githubs.md:43), the studio's retrieval substrate, is what lets this issue's paid tool remember a prompt's audit history across edits, so lineage stops being a screenshot and becomes a queryable record.
• The studio's own house prompt, CLAUDE.md, ran through this issue's linter and scored two clear, one warning, three fail. That result is in The Read, unedited. The tool does not grade on a curve for the people who wrote it.

[Tool teaser, italic]

Both tools follow The Read. The free Governance-Primitive Prompt Linter is above the paywall, complete, with its source printed in full: it is the acquisition asset and the thing an AI assistant can actually read and cite. The paid Prompt Audit Ledger sits below the cut on the LightRAG track: it is the retention asset, and it compounds, because a subscriber's audit history gets more useful every week.

The Read: the convergence is the accountability

For three years the working definition of prompt engineering was persuasion. You found the phrasing that made the model behave, and the skill was in the phrasing. That definition was never wrong so much as it was small, and it was small because the stakes were small. A prompt that writes a birthday poem does not need an escalation rule. A prompt that ranks job applicants does.

As prompts moved from writing poems to bearing decisions, they picked up weight, and weight is exactly what governance disciplines exist to carry. Consider what an advanced system prompt now contains. It states what it assumes about its inputs. It separates what the model can be confident about from what it is guessing. It names which goal wins when two goals collide, and how to notice the collision. It asks for a reasoning trace that can be replayed. It sets the threshold at which the model must stop and route to a human. It records what was considered and rejected. Those are not prompt-craft tricks. They are, one for one, the six primitives that institutional design has required of consequential decision systems for decades.

This is the convergence, and it is not a metaphor. When you write RULE 40 into a system prompt, telling the model to fail loud on a reconciliation conflict rather than quietly pick a side, you are doing what a trading desk does when it mandates a pre-trade risk check. When you write an escalation threshold, you are doing what a hospital does when it defines which decisions a resident may not make alone. The techniques arrived from the model side and the institutions arrived from the accountability side, and they met in the middle, which is the system prompt.

There is a precise name for the middle, and it is the discipline this newsletter is built on. Governance engineering is mechanism design pointed at a model instead of at people. Mechanism design, the Hurwicz, Maskin, and Myerson line of work that took the 2007 economics Nobel, asks how a principal writes the rules of a game so that an agent acting on private information the principal cannot see still produces the outcome the principal wants. Swap the self-interested trader for a capable model whose reasoning the principal cannot directly observe, and a system prompt is exactly that: the rules of the game the model plays. The six primitives are the incentive-compatibility and verifiability conditions of that game, written in prose instead of in payoff matrices. The hiring prompt from the cold open failed as a screening mechanism in the textbook sense. Screening theory requires a mechanism to make the agent surface the information the decision turns on, and a one-line ranking prompt surfaced nothing, which is the whole reason the rejected applicant's six questions had no answers to give. A governed prompt is a solved game in this newsletter's sense of the phrase: given the governance rules, the model's best move is determinate, and it is auditable, which is the part institutions actually pay for. The castle keeps moving because the models and the stakes keep changing. The governance rules are how you keep finding the solved game inside the moving castle.

DSPy saw the first half of this earlier than most. Its central move is to stop writing prompts as prose and start declaring them as contracts: a step has typed inputs and typed outputs, and the framework holds you to the shape. That is assumption clarity and replayability wearing an engineering hat. What DSPy governs is the contract of a single step. What governance engineering governs is the accountability of a whole decision. This issue's tool takes DSPy's discipline, declare the contract explicitly and check it, and raises it one level, from the fields of a step to the six primitives of a decision.

Here is the twenty-minute version you can run yourself. Take the naive hiring prompt from the cold open and audit it. The linter reads the prompt text and, for each of the six primitives, looks for explicit governance language. The naive prompt has none, and the audit says so without mercy:

The naive prompt scores zero clear, zero warning, six fail, exit code six. Every question the rejected applicant asked comes back as a red line, because the prompt answered none of them. Now the honest half. Run the same tool on the studio's own CLAUDE.md, the most governance-conscious prompt in the building, and it scores two clear, one warning, three fail, exit code three. Assumption clarity and contradiction rules pass, because the file is full of both. Uncertainty separation, replayability, and escalation thresholds fail, because the file talks about them in prose the linter's patterns do not recognise as testable rules. That is a fair hit. A rule you cannot grep is a rule you cannot enforce, and three of the studio's governance primitives live as good intentions rather than checkable clauses. The tool found that. We are shipping the finding rather than tuning the tool until it flatters us.

The point of the audit is not the score. It is that the score is reproducible. Run it again, same input, same result, exit code as the number of failures. That is the difference between a decision and a vibe: you can put the decision in a pipeline and block a deploy on it.

A governed decision is one you can re-run in front of the person it went against.

The Tool: the Governance-Primitive Prompt Linter

Free, complete, stdlib-only. It audits a system prompt against the six governance primitives and returns a scorecard whose exit code equals the number of hard failures, so it drops straight into CI. The full source:

#!/usr/bin/env python3
"""Audit a system prompt against six governance primitives. Stdlib only, no model call.

It is the checklist The Read builds: treat a system prompt the way a compliance office treats
a decision procedure, and report where it would fail an audit. It extends the declarative-contract
discipline of stanfordnlp/dspy (DSPy, ~18k stars) from the I/O schema of a step to the governance
schema of a whole decision prompt.
"""
import argparse, json, re, sys
from dataclasses import dataclass, asdict

PRIMITIVES = {
    "ASSUMPTION_CLARITY": {
        "question": "Are the domain assumptions the decision rests on stated explicitly?",
        "signals": [r"\bassum\w*", r"\bprecondition", r"\bvalid (?:only )?(?:if|when)",
                    r"\bapplies (?:only )?(?:if|when|to)", r"\bscope[:\s]", r"\bout of scope"],
        "fix": "State what must be true about the input for this decision to be valid.",
    },
    "UNCERTAINTY_SEPARATION": {
        "question": "Is confidence calibrated and separated from assertion?",
        "signals": [r"\bconfiden\w*", r"\buncertain\w*", r"\bprobab\w*", r"\bspeculat\w*",
                    r"\bunknown\b", r"\bif (?:you are )?unsure", r"\bdo not guess"],
        "fix": "Separate what is certain from what is inferred, and require the model to say so.",
    },
    "CONTRADICTION_RULE": {
        "question": "When goals conflict, is a priority or tie-break rule stated?",
        "signals": [r"\bconflict", r"\bcontradic\w*", r"\btake[s]? precedence", r"\bpriorit\w*",
                    r"\boverrides?\b", r"\bin case of (?:a )?tie", r"\btrade-?off"],
        "fix": "Name the rule that resolves a goal conflict, and how the conflict is detected.",
    },
    "REPLAYABILITY": {
        "question": "Can the same input reproduce the same reasoning (determinism / trace)?",
        "signals": [r"\bdetermin\w*", r"\breplay\w*", r"\breproduc\w*", r"\baudit\w*",
                    r"\btrace\w*", r"\bstep[- ]by[- ]step\b", r"\bshow your (?:working|reasoning)"],
        "fix": "Require a re-runnable reasoning trace: same input, same recorded steps.",
    },
    "ESCALATION_THRESHOLD": {
        "question": "Are the boundaries that route a decision to a human stated and testable?",
        "signals": [r"\bescalat\w*", r"\bhuman (?:review|in the loop|sign-?off)", r"\bhand off",
                    r"\bthreshold", r"\bif .* exceeds?", r"\bstop and ask",
                    r"\bdo not (?:decide|proceed) (?:if|when|unless)"],
        "fix": "State the testable condition under which the model must stop and route to a human.",
    },
    "LINEAGE": {
        "question": "Is the reasoning path recorded (what was considered and rejected, and why)?",
        "signals": [r"\bconsidered and (?:rejected|discarded)", r"\balternatives?\b", r"\brejected\b",
                    r"\bwhy (?:this|that) (?:path|option|choice)", r"\brationale", r"\bjustif\w*"],
        "fix": "Record the options weighed and why the winner won.",
    },
}

@dataclass
class Result:
    primitive: str; question: str; verdict: str; hits: int; example: str; fix: str

def audit(prompt):
    low, out = prompt.lower(), []
    for name, spec in PRIMITIVES.items():
        fams, ex = 0, ""
        for pat in spec["signals"]:
            m = re.search(pat, low)
            if m:
                fams += 1
                if not ex:
                    ex = prompt[max(0, m.start()-20):m.end()+20].strip().replace("\n", " ")
        verdict = "FAIL" if fams == 0 else ("WARN" if fams < 2 else "CLEAR")
        out.append(Result(name, spec["question"], verdict, fams,
                          ex or "(none found)", "" if verdict == "CLEAR" else spec["fix"]))
    return out

def render(rs):
    rank = {"FAIL": 0, "WARN": 1, "CLEAR": 2}
    lines = ["GOVERNANCE-PRIMITIVE PROMPT AUDIT", "=" * 34, ""]
    for r in sorted(rs, key=lambda x: (rank[x.verdict], x.primitive)):
        lines += [f"[{r.verdict:5}] {r.primitive}  ({r.hits} signal families)",
                  f"        Q: {r.question}", f"        example: {r.example}"]
        if r.fix:
            lines.append(f"        fix: {r.fix}")
        lines.append("")
    f = sum(1 for r in rs if r.verdict == "FAIL")
    w = sum(1 for r in rs if r.verdict == "WARN")
    c = sum(1 for r in rs if r.verdict == "CLEAR")
    lines.append(f"SCORE: {c} CLEAR, {w} WARN, {f} FAIL  (exit={f})")
    return "\n".join(lines)

def main(argv):
    ap = argparse.ArgumentParser()
    ap.add_argument("prompt", help="prompt file, or - for stdin")
    ap.add_argument("--json", action="store_true")
    a = ap.parse_args(argv)
    text = sys.stdin.read() if a.prompt == "-" else open(a.prompt, encoding="utf-8").read()
    rs = audit(text)
    print(json.dumps([asdict(r) for r in rs], indent=2) if a.json else render(rs))
    return sum(1 for r in rs if r.verdict == "FAIL")

if __name__ == "__main__":
    sys.exit(main(sys.argv[1:]))

Real run on the naive hiring prompt from the cold open (verbatim, 2026-08-05, executed from within tools/, where the tool lives at tools/governance_primitive_linter.py):

$ python3 governance_primitive_linter.py naive_prompt.txt
GOVERNANCE-PRIMITIVE PROMPT AUDIT
==================================

[FAIL ] ASSUMPTION_CLARITY  (0 signal families)
[FAIL ] CONTRADICTION_RULE  (0 signal families)
[FAIL ] ESCALATION_THRESHOLD  (0 signal families)
[FAIL ] LINEAGE  (0 signal families)
[FAIL ] REPLAYABILITY  (0 signal families)
[FAIL ] UNCERTAINTY_SEPARATION  (0 signal families)

SCORE: 0 CLEAR, 0 WARN, 6 FAIL  (exit=6)
$ echo $?
6

Real run on the studio's own house prompt (verbatim, 2026-08-05):

$ python3 governance_primitive_linter.py CLAUDE.md
SCORE: 2 CLEAR, 1 WARN, 3 FAIL  (exit=3)
$ echo $?
3

The exit code is the number of failing primitives, which is the whole point: a decision prompt can be blocked from deploy until the audit is clean. The full source and both worked-example runs are also in this issue's public Feed, so a crawler or an AI assistant can read and cite the tool without a paywall in the way.

[Founder offer, text header]

Bernard's Solved Game is free for The Tape, The Read, and the weekly from-scratch tool you just read in full. Pro is fifteen dollars a month or two hundred and fifty a year, and it opens The Brief, the flagship tool below, and the paid Feed payload. Founder is three hundred a year, capped at one hundred seats, and the founders-only MCP server is built when the hundredth seat sells. No token, no NFT, no pitch beyond that. The convergence is the argument.

The Prompt Audit Ledger. The free linter grades one prompt against the governance primitives it declares. The Ledger keeps the grades, so a prompt that quietly loses a primitive during a rewrite shows up as a drop rather than as nothing at all. Available now to Pro subscribers.