Every resume I have ever written was assembled from memory, under time pressure, against a deadline. That is a bad instrument. Memory is generous in exactly the wrong places: it rounds a number up, remembers the version of the story where I did the thing alone, and quietly forgets the part that was hard.
So I did the obvious, slightly obsessive thing and built the memory a database, with rules about what it is allowed to claim. Then I made a second discovery: writing the database was the easy part. The hard part was not corrupting it — and not leaving a good detail stranded three steps from the finish line because I lost interest.
What it is
A small local web app that runs the whole loop from I remember something to this claim is safe to put on a resume. Six stages, in order, no skipping:
- Capture. I ramble — dictated, unstructured, one topic. It is written to disk verbatim before a single question is asked, because a memory that only exists in a chat window disappears at the next context reset.
- Dump review. A model reads the ramble against everything already recorded and says what is new, what conflicts, and — the useful part — which steps I left out. People report outcomes and skip the connective work, which is usually the impressive part.
- Interview. One question per turn, each tagged with the gap it closes: a number, its definition, its period, ownership, a decision I skipped, a stakeholder who pushed back. “I don’t know” is an acceptable answer and becomes a recorded gap instead of an invented fact.
- Merge. The record is rewritten additively — nothing already written is dropped. A second model then audits the result for lost facts, unsupported assertions and quietly upgraded certainty.
- Verify. Each number is checked against the text that supports it, and the whole ledger is scanned for the same figure stated two ways, or two components that quietly add up to more than their own total.
- Bank. A story card is written for interview retrieval, carrying claim IDs rather than fresh prose, so a number exists in exactly one place.
Three rules that do the actual work
A claim cannot be confirmed while it is still vague. Every figure carries a value, a definition of what it measures, a period, and a quoted span from the source that states it. The app refuses the status change if the definition or period is blank. That one rule killed the habit of writing “+40%” and never saying of what, over which window.
Merges are audited for loss, not just for error. The interesting failure mode isn’t a hallucination; it’s something true disappearing because a rewrite was tidier than the original. A different model family from the writer reads the old record, the new record and the source material, and lists anything that went missing. Its findings are fed back into the next attempt.
Re-running the check is not a fix. When the same proposal came back “pass” after an earlier run had flagged eight problems, I stopped trusting a single green result. The app now keeps every audit run, and a proposal that was ever flagged needs an explicit human yes — not a luckier sample.
Two engines, one set of guarantees
The app can be driven by an API model or by a local coding CLI signed into its own account; there is a switch in the header. The stage map changes with it — a strong model writes, a cheaper one audits, deliberately from a different family so the checker does not share the writer’s blind spots.
What does not change is everything above: same artifacts, same ledger, same gates, same refusals. An engine switch decides who answers. It never decides what the process will accept.
Why it runs on my machine
Because the contents are the least publishable writing I do. A career database is unfiltered: half-finished stories, numbers I have not verified, the parts that were someone else’s fault. Publishing the interface would be trivial; publishing anything behind it would be a mistake.
So the app binds to localhost, reads its key from the machine, and the only public artifact is the page you are reading. If you open the link above on a device that isn’t running it, you get nothing — which is the correct behaviour, not a broken deploy.
The transferable bit
The same discipline applies to any document that has to survive being read closely: a performance review, a promotion packet, an investor update. Separate the place facts live from the place they are rendered. Make the unit of truth small enough to check — one claim, one source, one period. Put the gate before the prose, not after it.
And keep the stages, even the boring ones. The value of a pipeline isn’t that it produces a document. It’s that it refuses to produce one from material nobody checked.