The scenario is the test.
The test is the contract.
A Scenario is a timeline of events and the exact world that must result. It reads like a product requirement, runs like a test, and binds the production system like a contract — because it is executed by the same evaluator.
There is no glue gap
Classic BDD joins scenarios to systems with hand-written step definitions — a translation layer where drift lives. A step can keep passing while the system quietly diverges from the sentence it claims to implement. Tarski has no translation layer to fudge.
Every arrow is a place where the words and the behavior can part ways.
One deterministic evaluation. The distance from scenario to implementation is zero adapters.
Written for the person who owns the requirement
A drive-thru voice parser mishears an order as eighteen thousand waters. The scenario states what must be true: the absurd order stays staged, the POS receives nothing, and the customer is asked to confirm.
A PM can read every line. A risk officer can sign the expectation. An agent can regenerate rules until it holds. The same artifact serves all three.
scenario "absurd parse stays staged" given the timeline obs mic.audio "...eighteen waters..." obs candidate.order water × 18_000 ← llm parse obs menu.bounds water ≤ 24 per order expect the world order.state = staged pos.tickets = none prompt.customer = "confirm: 18,000 waters?" — the parse exists, pinned with provenance; — it simply cannot reach the POS.
Deterministic, so decisive
Fixed inputs, deterministic evaluator: a Scenario cannot flake. If it fails, the behavior changed. If it holds, it holds for every replay, forever.
Grown from production
Any provenance-pinned timeline — including a real misbehavior — promotes into a Scenario in one step. The corpus grows where reality found a gap.
Honest about scope
Scenarios verify behavior for the declared corpus; invariants hold everywhere, at every fixpoint. Together they are the evidence you approve — stated precisely, never oversold.