Assertions

Assertions are the scenario’s declarative checks over a run’s recorded observations. They live in scenario-core (the spec vocabulary) and are evaluated by the assertions crate’s deterministic AssertionEngine.

Scope

The engine evaluates only what the run recorded — public observations, the event log, and the terminal status. It never reaches into adapter or fixture internals, so assertions behave identically across the mock harness, a real simulator, and a Soroban environment.

Kinds

• Success / failure — the run’s terminal status matched.
• Balance — balance.<actor>.<token> equals an independently expected public value.
• Ownership — ownership.<token> belongs to the expected owner.
• Authorization — an actor’s action was authorized as declared.
• Proof valid / invalid — a proof reference verified (or was refused).
• Commitment — a commitment reference equals its expected digest.
• Event / no event — a public event code was (or was not) emitted.
• Private not visible — a confidential field never appears in any public observation or report surface.
• State binding — an operation is bound to the referenced state.
• Replay rejected, serialization equal, version compatible — used by the adversarial, compatibility, and regression packs.

Privacy guarantee

Assertion diagnostics carry expected/actual values as strings that never contain private material: the messages module builds redacted, human-readable text. Assertions over confidential fields use the private_not_visible kind, which passes only when the field is absent from every public surface — the reverse of a leak check.

Failure semantics

Each failed assertion records its severity and a diagnostic. A critical assertion failure classifies the run as failed; the outcome carries the assertion results for the report. Expected-failure scenarios (negative, adversarial) declare the failure they expect, so a correct rejection is a passing run, not an error.