An AI harness that can't lie quietly

I keep a handful of documents about myself that must stay accurate: bios, speaker profiles, the text on this site’s about page. They get rewritten for different audiences, and I wanted an AI editor to help. The one thing it could not be allowed to do was improve the facts.

You cannot prompt that risk away. A model asked to make a profile “stronger” will sometimes make it stronger by adding a number. So instead of trusting the model, I built a harness where an invented fact has nowhere to hide. It runs in a private studio on this site, behind two separate locks, which deserve a post of their own.

Figure 1. Three inputs go to the model. It can only answer with one structured proposal. The server checks the shape, and a person previews, applies or discards.

Rule 1: the model only sees approved facts

The model gets three inputs and nothing else:

• The document as it stands now.
• A facts vault: a short list of facts I have written and approved, such as dates, numbers and outcomes I can stand behind.
• The instruction, plus an optional target text to tailor towards.

There is no web search and no memory of other conversations. If a fact is not in the document or the vault, the model has no legitimate source for it.

Rule 2: one answer shape, enforced

The model is given exactly one tool and is forced to call it. It cannot reply in chat. It must return a complete proposal in a fixed schema: the whole document, a list of changes with a reason for each, the keywords it matched, and a list called gaps.

Gaps are the key idea. When the instruction asks for something the facts do not support, the rules tell the model not to add it and to list it under gaps instead. That gives the model a correct place to put the pressure to embellish. In practice the gaps list is often the most useful part of the answer: it tells me what I would need to add to the vault, if it is true.

Rule 3: the server checks before I see anything

The proposal goes through code, not straight to the screen:

Check	Why
Shape	A malformed answer is rejected with an error, not half applied
Ids	Every item keeps its id, so the preview can line changes up exactly
Metadata	Storage fields come from the current version, never from the model
Limits	Change, gap and keyword lists are capped

Rule 4: propose, then apply

Nothing is saved when the answer arrives. I see the proposal next to the current version, with the change list and the gaps. Then I choose: apply or discard.

Apply takes a snapshot first. Every version is kept for 120 days, with automatic snapshots at most every five minutes while I edit by hand. Any change, by me or by the model, can be rolled back.

Rule 5: prefer hiding to deleting

When a document is too long, the rules tell the model to mark weaker items as hidden rather than remove them. A hidden item is one click away. A deleted one is gone, and with it the evidence of what was there.

What “can’t lie quietly” means

The model can still produce a wrong sentence. What it cannot do is get one saved without me seeing it next to the original, with a stated reason, after a snapshot. The harness turns a trust problem into a review problem, and review is something people are good at.

The next check I would add is deterministic: flag any number in a proposal that does not appear in the document or the vault. It is cheap, and it catches the most common kind of embellishment before I even read the preview.

The pattern beyond one studio

Strip away the use case and the pattern is general:

1. Bound the sources. Approved facts in, nothing else.
2. Force a structured answer with a place for what the model could not support.
3. Check the shape in code.
4. Propose, preview, apply, with a snapshot before every apply.

It is the same pattern the Sylang book argues for in engineering models. The model drafts. Deterministic code checks. A person decides.