SKIP TO CONTENT
Monospace

AI proposes, a hardened executor applies

Letting a model hold the write path is the mistake. Separating proposal from execution — structured previews on one side, a validating executor on the other — is what makes AI safe to point at real data and real money.

There is a version of an AI feature that works in a demo and cannot ship. It looks like this: the model is given a set of tools, the tools write to the database, and the prompt asks it to be careful.

The failure is not that the model is unreliable, though it is. The failure is architectural. A component whose output distribution you cannot fully characterise has been handed the write path, and no amount of prompt engineering converts a probabilistic system into a transactional one.

Split proposal from execution

The pattern that holds is a hard boundary. The model produces a proposal — a structured description of what it believes should happen. A separate executor, written in ordinary code with ordinary tests, decides whether that proposal is valid and applies it.

The executor is not intelligent and does not need to be. It validates against a schema, checks permissions and tenancy, enforces business invariants, and writes inside a transaction. It is the same code you would have written if a form had submitted the values instead of a model.

  • The model never holds a database handle, an API key, or a write credential.
  • Every proposal is a typed object, not a free-text instruction to be interpreted at write time.
  • The executor rejects anything that fails validation, and a rejection is a normal outcome rather than an error condition.

Previews make the boundary visible

Once a proposal is a structured object, it can be rendered. That turns the safety boundary into a product surface: the user sees exactly what is about to happen, in the shape it will happen, before it does.

This is the difference between "the assistant categorised your transactions" and a diff showing forty rows with their proposed categories, three of which are highlighted as low confidence. The second one is reviewable. The first one has to be trusted or undone.

It also changes what a mistake costs. A wrong proposal that a person declines is a minor annoyance. A wrong write that a person discovers a month later during reconciliation is an incident.

What the executor has to do

The executor is where the unglamorous guarantees live, and it is worth being explicit about them because they are easy to skip when the feature looks finished.

  • Validation: the proposal parses against a schema, and fields outside the schema are dropped rather than passed through.
  • Authorization: the acting user can perform this operation on these specific records, checked at write time rather than inferred from the session that produced the proposal.
  • Tenancy: every row touched belongs to the tenant in scope. This is checked in the query, not in a conditional.
  • Invariants: business rules that must hold regardless of what was proposed — a ledger that balances, a total that matches its line items.
  • Atomicity: the whole proposal applies or none of it does. Partially applied AI output is the worst available state.
  • Audit: what was proposed, what was applied, by whom, and when. Including the model and prompt version that produced it.

Audit trails are not optional

The audit trail deserves its own paragraph because it is the thing most often deferred and most expensive to add later. When an AI-assisted system touches money or compliance data, the question is not whether someone will ask how a value got there. It is when.

Recording the proposal alongside the applied result — with the model version, the prompt version, and the confidence attached — means that question has an answer. Recording only the final state means the answer is an investigation.

The shape generalises

Propose-then-apply is not an AI pattern. It is the same shape as a pull request, a migration plan, a staged deployment, and a bank transfer that shows you the details before you confirm. Each of those exists because a system that can act irreversibly should show its work first.

Language models make the pattern more necessary, not different. They are an unusually good proposal generator pointed at an unusually large surface area — which is exactly the situation the pattern was invented for.