Determinism and Resource Profiles

Determinism covers declared observations under a named runtime profile; resource ceilings are part of that profile rather than an unbounded execution promise.

When this matters

Use this contract when a run must be compared, replayed, or audited. “Same input” is incomplete until source bytes, runtime identity, resource profile, and observed channels are all named.

Read the example

A deterministic run is not a promise to finish every program. It promises that a declared run either produces the pinned observations or reaches a clean named failure under its resource profile. Wall-clock duration is operational evidence, not a guest semantic value.

How to reason about it

  • Observed axes are stdout bytes, diagnostic bytes, exit status, warning order, resource report, value projection, and artifact/provenance identity where applicable.
  • Native and WASM can have different limit pins while still reporting clean profile-specific resource outcomes.
  • Replay fixes source, runner identity, limits, and observation projection before comparing bytes.

Choose quickly

Fix before comparisonWhy it mattersExample observation
source and input bytestext normalization would change identityvalue or diagnostic bytes
runner and profilelimits and supported surfaces are namedexit status and resource report
observation projectionunobserved host details stay outside the claimstdout and warning order
corpus and baselineoutcome cannot choose the test setagree, mismatch, not-comparable
artifact identity where usedevidence must name what was checkedreceipt or engine digest

A common mistake

Wall-clock timeout alone is not a semantic resource report.

Current boundaries

  • Agreement on a bounded campaign is not whole-language equivalence or proof of no divergence.

Keep going

Runtime Backends explains the provenance-labelled runners. Checked Surfaces shows exactly what the maintained comparisons cover.

Runtime backends · Checked surfaces