Applications

Three ways Decision Gate sits inside an LLM product: answers checked before they render, claims proven on demand, and plans that carry their own finish conditions.

The answer arrives already checked

User

How much did we spend with Acme in Q2?

Draft answer, held for verification

You spent $12,480 with Acme in Q2, across 3 invoices.

Decision Gate Define

The draft contains two factual claims. Decision Gate holds the answer while it turns the stated total and invoice count into conditions tied to the billing records.

billing.total('acme', 'Q2') == 12480 Observed 12480 PASS

billing.invoices('acme', 'Q2').count == 3 Observed 3 PASS

Decision Gate Evaluate

Both conditions resolve True against the admitted records, so this exact answer is now eligible to render.

Assistant

You spent $12,480 with Acme in Q2, across 3 invoices.

Verified 2 claims checked against billing records

Decision Gate Result

The reader receives an answer with a checkable chain from each figure to the evidence that supported it—not merely a nearby citation.

Proves: the stated figures matched the declared billing records at evaluation time.

Does not prove: the prose is complete, or the billing records themselves are error-free.

The reader pushes back

Assistant

All customer data is stored in EU regions.

User

I don't believe you.

Decision Gate Define

Decision Gate does not ask the model to reconsider its wording. It turns “all customer data is stored in EU regions” into the obligations that must all be true.

Object storage lives in EU regions
Databases live in EU regions
Backups live in EU regions

Decision Gate Evaluate

For backups, the broad claim becomes exact: every vault must be in an allowed EU region. The gate checks that predicate against the admitted backup inventory.

Retrieve the backup inventory
Construct the gate vaults.all(region in ['eu-central-1', 'eu-west-1'])
Evaluate against the observed inventory

Observed vault 'archive-7': us-east-1 FAIL

FAIL

One vault is outside the EU. The claim is false as stated, and now there is a record of why.

Decision Gate Result

One US vault is enough to make the universal claim False. The answer is rejected with the counterevidence preserved instead of inviting another ungrounded response.

Proves: the declared inventory showed a non-EU vault at evaluation time.

Does not prove: the inventory itself is complete. That is an evidence-scope fact the policy has to name.

The plan carries its own finish conditions

plan.md

Reproduce the reported bug
Fix it and add five tests
Prepare the tested change for delivery

Decision Gate finish conditions

new_test_count == 5
required_tests.all(status == 'PASSED')
tested_commit == delivery_commit

Agent

All done. Five tests added, everything passes.

Decision Gate Define

“Done” was defined before work began: five new tests, every required test passing, and the tested commit matching the delivery commit. Decision Gate now evaluates the agent’s claim against those conditions.

new_test_count == 5 Observed 5 PASS

required_tests.all(status == 'PASSED') Observed all PASSED PASS

tested_commit == delivery_commit Observed digest mismatch FAIL

Decision Gate Evaluate

The test count and statuses pass, but the artifact binding fails: the evidence belongs to a different commit. Good results for one artifact do not prove another.

HELD

The tests passed on a different commit than the one being delivered. Completion is not accepted.

The agent re-runs the suite on the delivery commit and resubmits.

tested_commit == delivery_commit Observed digests match PASS

ACCEPTED

Completion is recorded with its evidence. The loop closes on proof, not on prose.

Decision Gate Result

After the suite is rerun on the delivery commit, every finish condition passes and completion is accepted. The plan closes on evidence, not on the agent’s confidence.

Proves: the declared conditions held for the exact delivery commit.

Does not prove: the five tests are good tests. Test quality is a different claim that needs different evidence.

On this page The shape they share

In each pattern the same thing happens at a different moment. An actor proposes something: an answer, a fact, a finished task. The claim that matters is stated as typed conditions. Evidence is admitted under an explicit policy, the conditions are evaluated, and the result is recorded with the evidence that produced it.

What changes is where the boundary sits. It can run before a reader ever sees the output, so verification is invisible infrastructure. It can run on demand, when someone asks the question every fluent answer should be able to survive. Or it can be written into the work itself, so that “done” is a set of conditions the workflow must satisfy rather than a sentence the workflow gets to say.

None of these patterns make the model more careful. They make the product stop accepting the model’s word for it.

Keep going

How It Works walks through the machinery these storyboards rely on: typed conditions, evidence assurance, three-valued results, and accepted progress. Docs has the full reference.