01
Same inputs
Replay recomputes from the sealed inputs the run admitted: the same evidence, the same mandate, the same decision clock.
Kernel and contracts
One kernel, seven typed contracts, one receipt per run.
Every domain module answers to the same seven contracts, in the same order, and every run ends in the same kind of receipt. This page is that contract surface: what each one holds, what it refuses, and what you can do with it. It sits between the worked walkthrough and the proof surface, and it does not repeat either of them.
A contract here is a typed agreement between the kernel and one part of a run. It says what may cross the boundary and what a refusal looks like. Nothing is passed as a loose shape that a later stage has to reinterpret, because a decision is only as trustworthy as the weakest binding in the chain that produced it.
The seven contracts are the same in every domain, and in every deployment state. The shipped effect adapter is simulation only, so an admitted act is simulated rather than performed; every other contract behaves as described here.
ScopeStructure here, results elsewhere
This page describes what each contract holds and what it refuses. What one run looked like belongs to the walkthrough, and what would falsify a claim belongs to the verification method.
Run order
One run, seven contracts, always in this order.
Each contract hands the next one something narrower than it received. Open any of them to read what it holds, what it refuses, and what you can do with what it hands back.
- MarketThe subject of the run
- ObservationOne admitted fact
- BeliefWhat the model concluded
- MandateThe authority to act
- DecisionOne typed outcome
- ExecutionThe effect record
- OutcomeSettlement and the lesson
- NoteExecution is the one contract a run can skip. A reasoned abstention ends at the decision and still settles.
Contract 1 of 7 · The subject of the run
Market
The one thing a run is about, with the domain facts that identify it.
A market carries the identity of the subject and the typed facts the domain module declares for it: the field and its runners, the instrument and its window, the company and the question being analysed. The kernel gives that subject one identity for the whole run, so every later contract refers back to the same thing.
Refuses
- A subject that does not fit the shape its domain module declares.
- Facts outside that shape, or an identifier that cannot be resolved.
- A run that drifts to a second subject part-way through.
What you can do with it
- Look a decision up by the subject it was about.
- See every recorded run for one subject in one place.
Contract 2 of 7 · One admitted fact
Observation
A fact with when it was observed, when it became available, and where it came from.
Observation time and availability time are separate and both required. The source identity travels with the fact, a content digest binds the evidence itself, and for priced markets a quote snapshot records the price that was actually reachable at the decision time.
Refuses
- Anything that became available after the decision clock, refused before a model runs.
- Observation times that contradict the market or each other.
- A fact with no source, no digest, or no availability time.
What you can do with it
- Check which facts a belief used, and when each of them became knowable.
- Confirm that nothing in a run arrived from the future.
Contract 3 of 7 · What the model concluded
Belief
A value, an interval around it, and the lineage that produced it.
Every model class emits the same shape of belief: a value, a lower and upper bound, the model and artifact identity that produced it, the inference receipt for recorded models, and the observation and source it was formed from.
Refuses
- A point estimate without usable uncertainty.
- Lineage that does not resolve to a version that actually ran.
- A replay that recomputes a different number. The run stops instead of writing a receipt.
What you can do with it
- Read the number with the uncertainty that belongs to it.
- Name the exact model version behind a belief.
Contract 4 of 7 · The authority to act
Mandate
An objective, permitted effects, bounds, and an expiry.
The mandate states what may be done and up to what limit: the objective, the effects it permits, exposure or stake bounds, a confidence floor, an expiry, and the risk policy of the domain — ruin bounds where a stake is involved, capital risk where positions could be, analysis only where nothing may be executed.
Refuses
- Acting with no authority at all.
- A mandate that has expired or is internally inconsistent.
- An effect the mandate does not permit, even when the belief is strong.
- A request outside a declared bound. The bound is enforced before the decision, not at execution.
What you can do with it
- State the authority you are willing to carry, once, and see whether a run stayed inside it.
- Read the refusal when a run went outside it, instead of discovering it later.
Contract 5 of 7 · One typed outcome
Decision
An admitted act, or an abstention that names its reason.
A run ends in exactly one outcome: a specific act its mandate admits, or an abstention with a named reason — no authority, invalid authority, an expired mandate, a prohibited effect, confidence below the floor, an exposure bound, the domain risk policy, or the domain declining on its own terms.
Refuses
- Two outcomes for one run, or a second outcome appended to the first.
- An act recorded without the mandate and bounds that admitted it.
- An abstention with no reason attached. A refusal that hides its reason is not an answer.
What you can do with it
- Read what was decided, and which gate decided it.
- Count a reasoned abstention as the result it is: complete, reproducible, and settled.
Contract 6 of 7 · The effect record
Execution
One adapter call, one idempotency key, one receipt.
An execution binds the run it belongs to, the idempotency key it was requested under, and the receipt the adapter returned. The first call records the effect; an identical retry reads the same receipt back; a retry that conflicts with the recorded intent fails closed. Today the shipped adapter is simulation-only, so the receipt records a simulated effect and states that in its own encoding.
Refuses
- Any route to an adapter from a rejected candidate, a final abstention, or a replay.
- A key reused for a different intent.
- A second effect under a key that already carries one.
What you can do with it
- Show that an effect took place once, under a key you can name.
- Show that a retry returned the original receipt and changed nothing.
Contract 7 of 7 · Settlement and the lesson
Outcome
The settled result bound to the exact run, with what was learned from it.
The resolved value settles against the run that produced the decision — and against the execution when one exists. Evaluation compares what was believed with what happened, and the learning record is written under the same lineage. A correction appends a new record and leaves the original readable.
Refuses
- A settlement that cannot be bound to its run.
- One outcome credited to two runs.
- A correction that rewrites the record it corrects, or a deletion that tidies the trail.
What you can do with it
- Close the loop: compare the belief with what happened.
- Read the lesson, and see corrections as records rather than edits.
One kernel, many domains
A domain module changes the meaning of the facts. Never the path they travel.
A domain module is where a domain’s knowledge lives: what counts as evidence there, what a belief means, what may be done about it, and how it settles. The kernel keeps everything else — the authority check, the replay, the effect boundary, and the settlement.
What a module adds
- The evidence a domain admits, and the shape its facts take.
- How a belief is expressed there: a ranked field, a two-sided event, an analysis stance.
- The action and the effect intent the domain can express.
- The risk policy that composes with the mandate: ruin bounds, capital risk, or analysis only.
- What a settlement means in that domain, and how evaluation reads it.
What a module can never add
- A second decision path, a private gate order, or a branch around the kernel.
- A way to reach an adapter that skips admission, replay, or the idempotency rules.
- A wider mandate. Authority comes from whoever carries the exposure, not from a module.
- A run that settles without evaluation or a learning record.
- A compatibility route that admits untyped facts to keep an older caller working.
Three modules ship today — sport and racing, quant research, and financial analysis — and each one arrives with the same kernel behind it. The domain reference lists what each module supplies.
Replay law
Same inputs, same model version, same receipt — and no effect.
Replay is how a recorded decision is shown to be the decision those inputs produce. It is a recomputation, not a re-read of the answer that was written down.
02
Same model version
The model and artifact identity is part of the run, so a replay cannot quietly use a newer version.
03
Same receipt
The recomputed belief and decision have to match the record. A mismatch stops the run before anything downstream happens.
04
No effect, ever
Replay makes zero adapter calls. It cannot place an order, take a wager, move funds, or deploy anything, and it can never become a second effect.
LimitWhat replay refuses
A replay that disagrees with the record, a model identity that cannot be resolved, or evidence that has moved since it was admitted all stop the run before anything downstream happens. No receipt is written for the differing run, and no adapter is reached.
NoteA retry is not a replay
An effect retry under the same idempotency key reads the original receipt instead of acting again. Reuse that key for a different intent, and the retry fails closed while the original receipt stands.
Adapter boundary
Only one thing can reach an adapter.
An act that a mandate admitted, replayed and verified, is the single thing that may cross into an adapter. Everything else stops before the boundary, and the boundary itself is the last place authority is read.
The crossing, in words
Sealed evidence forms a belief. A mandate admits or refuses what the belief would justify. If it admits, the decision is replayed and verified. Only then may the act cross into an adapter, under an idempotency key the receipt records.
The shipped adapter is simulation only. Its receipt says so in its own encoding, and no order, wager, transfer, or deployment exists in it: no broker, sportsbook, exchange, or provider is contacted, and no funds or accounts are touched.
- neverA rejected candidate never plans and never reaches an adapter.
- neverA final abstention reaches nothing.
- neverA pure replay makes zero adapter calls.
- neverA retry under a conflicting key fails closed, and the original receipt stands.
The verification method lists what would falsify each claim made here, and the walkthrough shows the same boundary inside one worked run.
Why this shape
Why one kernel, and not a pipeline of services.
If evidence, belief, authority, effect, and settlement lived in separate services, every seam would be a place where the clock, the identity, or the authority could drift — and no single receipt would cover the whole run. One kernel keeps one identity from the first admitted fact to the learning record, checks every stage against that same run, and records each refusal at the stage that owned it.
That is also why there is no second decision path. Data can be distributed; the semantics cannot fork. A domain module, a model, or a deployment cannot decide differently about authority, replay, or settlement, because none of them owns those decisions.