Write It Down

A promise, turned into a check

This studio makes a promise on its front page: traceable results — you can follow the chain from source to conclusion. This piece takes one corner of that promise — the traceability of a decision — and turns it from a claim into something you can check yourself.

The usual question people ask about AI is “is the model right?” It's the wrong question to build accountability on, because you often can't answer it in the moment. A more answerable question — and, when something slips, a more useful one — is: if it wasn't right, can you recover what it decided, and the reason it recorded at the time?

Here, the answer is yes, and the demonstration is deliberately humble: an ordinary grocery workflow, an ordinary miss, and a record that was already sitting in a database waiting to be queried. The interesting part isn't the mistake. It's that the reason was recoverable — and that being honest about a record like this means being just as clear about what it doesn't establish.

What happened

The workflow is the tail end of a chain of free, USDA-grounded nutrition tools: a gram-based home cookbook, and a weekly grocery-list engine that turns a meal plan into a single, store-sectioned shopping list. The last step is the one that matters here — an AI agent assembles that list into a cart in a real, logged-in grocery account, and a human reviews and completes every purchase. A person, not the agent, does the buying.

One week, a recipe called for sesame seeds. They never made it into the cart. Not a dramatic failure — a small, ordinary one. Which is exactly why it's a safe place to look closely: the method is what generalizes, and you want to learn it on a case where nothing is at stake.

The reason was already on record

Here's the part that matters. At the time it built the list, the agent had recorded an assumption it was working from: that small pantry staples like sesame were already on hand. That note wasn't reconstructed after the fact or inferred later — it was written as the work happened and stored as a single row in the orchestrator's database. Weeks afterward, I pulled it back out with an ordinary read-only query.

On that hash. The screenshot above is content-hashed, and it's worth being exact about what that does and doesn't buy you. The hash shows the image file hasn't been altered since it was captured. It does not prove the underlying record is genuine, or that its timestamp is true. So don't take the screenshot on faith — the next-but-one section lets you reproduce the whole mechanism yourself, which is the honest way to earn that trust.

The record is a database, not a log file

A natural assumption — one I've caught myself repeating — is that a system like this “writes a log file when the session ends.” It doesn't. No log file is written at close. The record is the database the whole time: sessions, phases, and events. A reasoning note is just one row in the events table — a type, a timestamp, and a JSON payload. The readable “session log” is reconstructed from those tables on demand. It's a view, not a file.

One detail on this table is load-bearing for the honesty of the whole piece: the events table has no hash column. These rows are a genuine contemporaneous record, but they are not, by themselves, tamper-evident. (Integrity of that kind lives in a separate layer, whose mechanism isn't published here.) I'd rather you see the gap than have me paper over it.

Where the miss entered

Laid out end to end, the pipeline makes the honest point visible: the failure isn't at the model. It's at the human-approval node, where a recorded assumption was approved without a check.

Recover it yourself

A case study about verifiability shouldn't ask you to trust its screenshots. So here's the actual mechanism, on a small, fully synthetic, zero-PHI database with the same shape as the real one. Download it, run one command, and recover a contemporaneous decision record yourself — a reader-runnable demonstration of the one thing this piece claims: that the record exists and is recoverable, read-only.

# recover.py — recover a contemporaneous decision record, READ-ONLY
import sqlite3, json

# mode=ro : strictly read-only — the query cannot create or modify the database
con = sqlite3.connect("file:record.db?mode=ro", uri=True)
row = con.execute(
    "SELECT id, type, fired_at, payload_json "
    "FROM events WHERE type = 'observation.captured'"
).fetchone()
con.close()
# prints the recovered id, type, timestamp, and the reasoning note in the payload

What this is — and isn't

This case study sits downstream of a field note published earlier on this site, “A faithful log of an unfaithful trace.” That note maps an agent's records against ALCOA+, the data-integrity framework used in regulated industries, and lands on an uncomfortable cell: a reasoning record can be perfectly contemporaneous — logged, time-stamped, captured as emitted — and still not be the true account of why the agent decided what it did. In the note's own table, a contemporaneous reasoning capture proves “the narrative existed at decision time” but is, in its exact words, “necessary, not sufficient.”

So here is precisely what this case study is, and nothing more: a worked illustration of the contemporaneous-and-recoverable leg of that record, caught in a real workflow. The note described a fuller record — contemporaneous, tamper-evident, and cross-run-comparable — that “isn't built yet.” This illustrates one part of it and leaves the other two — tamper-evidence and cross-run comparability — explicitly unbuilt. It does not close that problem.

This piece was checked against the shipped code (no log file is written at close; the events table carries no hash column) and passed a separate, in-studio adversarial review before publishing — a distinct pass, not a third-party audit. Its one job is to be honest about a small true thing.

Where this fits

One sentence of positioning, held humble: the architecture behind this is a deliberately unusual set of trade-offs — the only model in the loop is the user's own, and verification recomputes at the export step rather than being asserted after the fact — which is a different architecture, not a claim to beat the serious work others are doing on AI auditability. The reframe worth keeping is smaller and sturdier than any product pitch: stop asking only whether the model was right, and start asking whether its decisions are recoverable — because that is the question you can actually check, on a Tuesday, over a jar of sesame seeds.

Related work

If this way of thinking is useful, a few neighboring pieces go deeper — all public, all checkable: