Model-written YAML
- Source the function, restated
- Store down not an input
Topic · Intent
A human still signs the shall. Proof then fails the merge when the files have no witness. A spec written from the code is a restatement, not a check.
proof audit --fail-level warn
The model can write the YAML. It cannot sign it. Jama still authors the programme.
01 · Spec from code
A requirement that describes what the code already does will pass realizability, consistency, and vacuity. Zero bugs found is the expected result. The shall never asked a question the code could fail.
Verifying one patch is the developer loop. The buyer question when the code is model-written is who audits AI-generated code. This page is the next turn: the model also wrote the spec. There is no independent bar left unless a person signs one.
We ran this in public on a 400-line policy merge. Phase 1 wrote 38 requirements from the code. Every analysis was green. Zero bugs. Phase 3 rewrote the shalls from what the merge is supposed to do, declared an extra input, and gap analysis flagged unconstrained outputs. The test for that case crashed. The bug was always there. The restatement never asked.
proof audit --fail-level warn
proof audit --check acceptance_criteria_witnessed
A green unit test the model also wrote does not clear acceptance_criteria_witnessed. A // Verifies: marker that arrived in the same commit as the test is co_authored: the trace restates the code. That classification is in git history, not a prompt.
02 · The exhibit
Shall from the code: when apply is requested, tags are merged. Shall from intent: tags are merged only when the store is available. Click the tabs.
Model-written YAML
The missing case
store_available = false is not in the spec. Gap analysis has nothing to flag.
UnaskedThe restatement
Still green. It never mentioned the store.
Zero bugsProof
Same merge. Two bars. Click the tabs.
| What ran | Green? | What it looked at |
|---|---|---|
| YAML generated from the code | Yes | A restatement. Realizability of a mirror is not a finding. |
| Tests from the same window | Yes | Agreement. co_authored traces do not count as an oracle. |
| LLM eval of the spec | Often | Whether the YAML reads well. Not whether a case is missing. |
proof audit on an owner-signed shall |
No, here | Gap analysis on the extra input. The crash was the unconstrained case. |
If the job is “make the YAML look like a spec,” keep the model. If the job is “did we ask the question the code can fail,” a person still has to sign that question. Proof does not invent it. It fails the merge when the signed shall has no witness, or when gap analysis says an input was never constrained.
03 · The honest loss
A green audit means the checks we selected passed on the approved shalls. It does not mean those shalls are the promises a customer heard.
We have not run Proof and an LLM-eval, or Proof and a requirements bot, on the same frozen corpus. FRETish is 288 templates, not arbitrary English. Jama still wins at programme authoring. The model can draft. The owner still approves every clause before any line is judged.
The developer loop stays on verify AI agent code. The buyer question that does not also blame the spec stays on who audits AI-generated code. Machine-checkable authoring stays on FRETish. The commercial shape of the install is on the audit page.
04 · Nearby questions
The AI wrote the function and the test that agrees with it. How do I know either is right? Same circular proof, code side. Verify AI agent code.
Who audits AI-generated code for correctness? The buyer URL when the code is model-written and the shall is already signed. Who audits.
How do I write machine-checkable requirements? That is authoring, not the circular-spec problem. FRETish.
How do I catch when an agent silently breaks an existing requirement? Reverse suspect, after a shall already exists. Silent break.