Replay flow & state transitions

Replay is grounded in determinism, not cryptography. This page is precise about what is implemented and what is a reserved seam.

Replay flow

Replayability in VerifAIer is a property of determinism, not a stored transcript. Because construction is pure and identifiers/timestamps are injectable, re-running the same inputs through the same engines yields byte-identical output and the same content-derived ids.

flowchart LR
  subgraph NOW["Implemented today"]
    DET["Deterministic construction
injectable clock + id_factory"]
    CID["Content-derived ids
agent_ / pass_ / rep_ / sig_ / sigx_"]
    SER["Byte-identical serialization"]
  end
  subgraph RESERVED["Reserved (inert placeholder)"]
    RB["envelope.replay = {status:pending, replayable:false, input_ref:null}"]
    HK["Evidence hook seams (no-op)"]
  end
  DET --> REPRO["Re-run with same inputs → same ids & output"]
  CID --> REPRO
  SER --> REPRO

Replay model, determinism is real and testable today; the replay block itself is a reserved placeholder. Source: evidence/envelope.py, engine.py.

Mechanism	Guarantee
Injectable `clock` / `id_factory`	envelope, receipt, provenance share one timestamp; ids are pinnable in tests and reproducible in production
Content-derived ids	`agent_` / `pass_` / `rep_` / `sig_` / `sigx_` are SHA-256 over stable inputs (no timestamp), same input, same id
Object-or-dict engines	an assessment re-run from a persisted envelope dict reproduces the original result

Honest scope. The envelope carries an inert replay block, {status:"pending", replayable:false, input_ref:null}: reserved for a future phase. There is no cryptographic replay, no input capture, and no signed re-execution today. What exists is deterministic reproducibility, which is real, tested, and sufficient to re-derive any assessment from a stored evidence envelope offline.

State transitions

Several small, explicit state machines run across the runtime. They are enumerated here so behavior is predictable end to end.

Provider result

mode ∈ {live, mock, disabled, error} and status ∈ {ok, fallback, error}. The adapter state machine that produces them is on the provider routing page. The router then derives execution_status = fallback if it fell back, else primary.

Passport status

stateDiagram-v2
  [*] --> unknown: no identity, no profile
  [*] --> provisional: data present, trust level None/unknown
  [*] --> active: data present, concrete trust level
  provisional --> active
  active --> provisional

AgentPassport status. Source: passport/engine.py.

Assessment levels

Every assessment carries an ordered level with a first-class unknown state when inputs are insufficient, never a fabricated value:

Assessment	Ordered levels (best → worst) + unknown
Trust	`trusted` · `acceptable` · `caution` · `untrusted` · `unknown`
Risk	`low` · `medium` · `high` · `critical` · `unknown`
Quality	`excellent` · `good` · `fair` · `poor` · `unknown`
Reputation	`excellent` · `strong` · `stable` · `weak` · `unknown`
Compliance	`complete` · `incomplete`

See trust scoring and reputation scoring for the thresholds that drive these transitions.