Refusal reference

Every named way a run can refuse.

A stage that cannot refuse is a stage that cannot be trusted. Each boundary below is reachable through the same entry point with one scenario token, and each one records what it refused rather than staying quiet.

All 15 tokens Reproduce one Quickstart

live:falsesimulation-onlyabstain is a resultrejection is recorded

Explore

Find the boundary you are looking for.

Filter by the stage that owns the refusal, then open one to read its trigger, its behaviour, and the token that reproduces it.

All fifteen named scenarios the operator entry exposes: fourteen boundaries and the admitted path.

Unavailable evidence

evidence

Trigger

A fact was published after the decision time.

What the run does

Refused before inference. No belief is produced and nothing downstream runs.

Scenario token

--scenario unavailable-evidence

Scenario tokens are the published operator contract: the same input path, one named boundary. Full commands live in the quickstart.

Complete table

Token, trigger, behaviour.

The token column is the operator contract: it is the value you pass to the scenario flag. The behaviour column is what the run does instead of acting.

Evidence

Facts that cannot be admitted at the decision time, refused before any model runs.

Candidate

Promotion gates that stop a candidate before it can plan or reach an adapter.

Mandate and risk

Authority, bounds, and confidence, each of which turns an intended act into a reasoned abstention.

Effect

What the adapter does with a repeated request, and what it refuses to repeat.

Named refusals, the token that shows each one, and the behaviour to expect
Scenario token	Stage	Trigger	What the run does
unavailable-evidence	Evidence	A fact was published after the decision time.	Refused before inference. No belief is produced and nothing downstream runs.
invalid-timeline	Evidence	Observation times contradict the market or each other.	Refused before inference. The run records the invalid timeline instead of guessing.
oos-leak	Candidate	A candidate is evaluated on cases used to develop it.	Refused before candidate evaluation. The holdout stays sealed.
in-sample	Candidate	Promotion is attempted on in-sample fit alone.	Promotion is rejected. In-sample fit can never promote a candidate.
coverage	Candidate	Out-of-sample coverage falls below the declared floor.	Promotion is rejected, with abstentions still counted in the coverage figure.
reject	Candidate	The candidate fails a declared acceptance criterion.	Rejected candidates cannot plan and cannot reach an adapter.
missing-mandate	Mandate and risk	No authority is presented for the requested effect.	Reasoned abstention. No effect intent is emitted, and the run still settles.
expired-mandate	Mandate and risk	The mandate has passed its expiry at decision time.	Reasoned abstention. Expiry is evaluated at the decision clock, not later.
invalid-mandate	Mandate and risk	The mandate is malformed or internally inconsistent.	Reasoned abstention. Nothing is interpreted loosely on the caller’s behalf.
prohibited-effect	Mandate and risk	The requested effect is not permitted by the mandate.	Reasoned abstention even when the belief is strong.
exposure-limit	Mandate and risk	The request exceeds the declared exposure or stake bound.	Reasoned abstention. The bound is enforced before the decision, not at execution.
ruin-policy	Mandate and risk	The request breaches the domain risk policy.	Reasoned abstention. Risk policy composes with the mandate, it does not replace it.
abstain	Mandate and risk	The belief is inside the zone where acting is not justified.	Reasoned abstention with the low-confidence reason recorded.
idempotency-conflict	Effect	A retry presents a known key with a different requested effect.	Fails closed. The original receipt stands and the effect is not repeated.
act	Effect	Every gate passes and the mandate permits the effect.	The act is admitted, simulated, receipted, settled, and learned from.

Reproduce one

One token, one domain, one refusal.

Every boundary runs through the same entry point you use for a normal run. What changes is the token you pass and the domain module that supplies the evidence.

shell

# One named boundary, one domain module
cargo run --bin kalkas -- run --domain sport --scenario unavailable-evidence

# Any published token works through the same entry point
cargo run --bin kalkas -- run --domain quant --scenario in-sample

# A fresh history file keeps the count of verified outcomes clean
cargo run --bin kalkas -- run --domain financial --scenario missing-mandate --history walkthrough.history

Run from the product source. Local, simulation-only, no external effect.

How to read itTwo shapes of refusal, both recorded

Some boundaries stop the run before inference: the entry point prints a named fail-closed error and exits non-zero, and no receipt is written. Others end in a completed receipt with decision=none for a rejected candidate, or decision=abstain with a reason. None of them acts.

Not an errorWhat a refusal is not

A refusal is not an exception to be retried into an act. A rejected candidate cannot plan and cannot reach an adapter, and an abstention settles like any other run. Retrying with a conflicting effect key fails closed, and the original receipt stands.

The quickstart walks three of these from the command line and shows which receipt fields change. The proof surface explains what still counts as a verified outcome when a run refuses: quickstart, proof and receipts.

The boundary is part of the product.

Refusals are named, tokenised, and recorded, because a decision system is only as trustworthy as the things it declines to do.

Walk three refusals Verification method