V·ouch
The mechanism

How it works

A review gate stands between an agent's writing and the repo's memory. Walk a real decision through it, then read the three rules that keep the memory trustworthy.

Plate IIIAnatomy of the review gate

The agent's writings do not become memory directly. They are first proposals, held in a vestibule called .vouch/proposed/, which never enters the project's history. From there a human passes them through the review gate — the synapse of the system. Only the approved cross over.

The discipline is the same one that keeps a peer-reviewed journal honest: nothing is durable until somebody else has read it. The trade is small and forgiving. A pull request already feels like this.

i · propose ii · review iii · durable claim iv · recall A .yaml .vouch/proposed/ vouch approve <id> cites: src/auth.py .vouch/claims/<id>.yaml A kb_search · kb_context — synapse — a different actor must sign the approval fig. 3·i
The review gate, in four chambers: propose → review → durable claim → recall. The synapse refuses self-approval; an agent may not certify its own remembrance.
Try the gate · a live SN74 decision
i
propose
✎
ii
review
⊙
iii
claim
▣
iv
recall
↺

Plate VIThe three rules of provenance

Three small rules carry most of the discipline. They are the reason the memory can be trusted at all.

I.

No claim without a citation.

Every assertion names a registered source — a file, a PR, a transcript, a page. The model rejects a claim without one. Provenance is built into the schema, not bolted on.

II.

No self-approval.

The agent that wrote the proposal may not sign it. A different actor — usually you — must pass the proposal across the synapse. The review gate is the whole point.

III.

The files are the truth.

Claims, pages, and the audit log live in plain markdown and YAML in your repository. They diff, they grep, they review like code. The SQLite index is a derivable cache and can be rebuilt at will.

“Files are the source of truth. state.db is a derived cache.
Losing it is never fatal.”

❦
Plate IVSymptomatology, untreated vs. treated

The clinical picture is the easiest way to recognise the condition. Before the prescription, an agent presents with the following constellation of complaints; after, the picture inverts.

· Before · cold-context, no provenance ·

  1. re-derives the architecture every session
  2. repeats fixes already shipped in march
  3. hallucinates a plausible decision because none is on record
  4. cites nothing; rationale evaporates after the chat closes
  5. contradicts last week's agent with quiet confidence
  6. the maintainer answers the same question in slack on tuesdays

· After · cited, reviewed, retrievable ·

  1. opens with kb_context and finds prior art
  2. before answering, names the claim and its source
  3. proposes the new claim cited to the file, the issue, the spec
  4. cannot rubber-stamp itself — a human signs the approval
  5. supersedes the old decision when revising; the diff is on disk
  6. the maintainer answers the question once, in a claim