The mechanism, in full
The unabridged argument: the failure mode, why memory is not an account, the four steps of the governed edge, the gate you tighten, and the full boundary. The short version is on the front page ←
01 / Failure mode
A model that reads fifty rows well reads row five thousand just as well — what changes is how much unrelated table it is holding while it does.
It works, and it keeps working right up to where it doesn't. Attention spreads across thousands of rows the agent is not currently deciding about, the early ones slide out of the window, and the failure is quiet — no error, no exception, just answers that drift. And when the session ends, the run ends with it.
Cheap, fast, repeatable — and the judgement that needed a model has been compressed into string matching. "Is this company a manufacturer or a trader?" becomes a regex over its name. The script is now the only statement of the rule, nobody reviewed it, and the rows it got wrong look exactly like the rows it got right.
Your agent asks for the next batch, computes it, submits it, asks for another: the model still does the semantic work, but it only ever holds the rows it was handed. And because your agent does the computing, a flat-rate coding-agent subscription does the work a per-token API bill would have.
The choice was never model versus script. It is whether the process lives in a context window that forgets, or in a structure that doesn't.
02 / Why an account
This is about a run whose referee, whose state, and whose reasons all live inside the worker.
The agent writes the extraction logic in this session. When a row looks wrong, the same agent adjusts the validator — and the batch passes. Nothing prevented that, because nothing was outside the agent.
Which rows were leased, which came back, which were rejected and why — all of it lived in a transcript. A new session sees files and partial output, and rebuilds the run from clues instead of resuming it.
Which rule version accepted this row? Which model produced it? Was it ever rejected first? If the answer is "check the chat history", there is no account — there is a recollection.
If the worker can rewrite the referee, you don't have a gate. You have another prompt.
03 / The governed edge
Tablize governs four steps and refuses to claim the rest. The bottom line of each box says whether that step is yours or ours.
Append-only source rows — a crawl, an export, a hand-assembled CSV. Duplicates are kept: they are a fact about collection, not an error.
Collected by you or your agent · Tablize does not fetch it
Your agent leases a bounded batch to disk, runs your prompt against your model, and submits the results as one batch with the model and prompt hash attached.
Runs on your machine, your model key · Tablize supplies no model
Build the line without goldens and there is no gate: nothing is judged and rows land unverified. Supply them and check rows with known answers ride in every batch — expected values held server-side, never returned by a lease, one miss refuses the whole batch.
Held by Tablize once the line has goldens · the submitting agent can never read or approve them
Not a fourth table — a reading of the process table showing the latest row per source row. With the gate on it shows accepted rows only and refused attempts move nothing; with the gate off it shows what landed, marked unverified.
Projected by Tablize · you decide whether anyone downstream uses it
The one thing that has no CLI command: on a gated edge, when your agent writes the check rows itself, the line is created as a draft and hands out no work until a person opens the gate in the app. That is the 403 · pending_signoff in the recorded run on the front page. An agent that could approve its own answer key has not been checked by anyone. An ungated edge never reaches that question: it hands out work immediately and marks what lands unverified.
04 / The gate you tighten
Nobody, until you write the check. There is no switch to leave off: a gate built on goldens you were not ready to write is a noise gate — and a noise gate is worse than none. The mode is fixed when the line is built, so tightening means rebuilding it: a deliberate step, taken when the pipeline is worth protecting. The results the old line already produced stay where they are.
Everything is still accounted for: every batch, model, standard version and timestamp is on the record. What is missing is the check — nothing compares the results to an answer a person confirmed, so they arrive unverified. This is the right first run and the wrong last one.
Every batch is compared to the goldens and the score is recorded, but no batch is ever stopped, so results still arrive unverified — even a clean sweep. When the gate cannot hold, a pass is a measurement, not a certification. Use the scores to decide whether these goldens are the right ones before you let them block anything.
Goldens are hidden and binding. A failing spot-check rejects the whole batch, and consecutive rejections halt the edge rather than letting it grind. Only enforce can grant "accepted" — which is the entire reason that word is still worth something.
The gate is the first thing on the ledger you can tighten. It is not what makes the pipeline durable — that part is already running with the gate off.
05 / More evidence
The line and the batch ledger are on the front page. This is the remaining shot of the same recorded run — with the gate on (enforce). Unretouched, at 100% zoom, cropped only where the header says so.
Filter to rejected and the 62 refused rows are still there — the company, the category the model chose, and the evidence text it was judged on.
That is what makes the next attempt arguable instead of guesswork: you can read what the weaker model actually said before you decide what to change.
The screenshot comes from a local instance on 2026-07-28. The mechanism, ids, counts, verdicts and system columns are the product's own state; the supplier rows are sample data generated for that run. It was captured in the product's light theme and is shown that way in both site themes — we would rather label a screenshot than retouch one.
06 / Honest boundary
The most load-bearing section of the argument. An account that overstates its own scope is worse than no account, because people stop checking the part it never covered.
A row marked accepted passed the rules and check rows as they existed at that moment, and the version is recorded. A row marked unverified was never judged — the label tells you which you have.
Every attempt, batch, model and rule change is accounted for — who, when, under which recipe version.
Failed attempts are kept and readable, and they never enter the accepted view. With the gate off there are no refusals to keep — nothing is judged, so nothing is refused.
The next run continues from server-side state — open batches, leases, verdicts — with no transcript required.
That the source data is true or complete. Evidence a row never carried cannot be recovered at the gate.
That the fields you defined are the fields downstream actually needs. Tablize enforces your contract; it does not discover it.
That anyone used the accepted result. In our own first end-to-end tenant, 128 of 136 accepted rows were never picked up by anything downstream — five rounds, unnoticed, while the ledger stayed accurate the whole time.
That your agent writes nothing outside Tablize. It has your machine and your keys; this account covers one edge, not the agent.
Public beta · free · macOS, Linux and Windows