# Proof specification — simulation and intended protocol

## Implemented simulation checks

The browser uses Web Crypto SHA-256. Policy and observation objects are serialized in fixed property order. A transition payload binds its sequence number, simulated timestamp, observation hash, policy hash, decision and previous hash.

The simulated proof is SHA-256 of `{ mode: "simulation", transition: payload }`. The block hash binds the payload and this checksum.

The inspector recomputes:

1. The observation commitment and expected deterministic input.
2. The genesis policy hash.
3. The policy decision.
4. The simulation proof checksum.
5. The previous block hash and contiguous sequence.
6. The final block hash.

These are local consistency checks, not a signature, a zero-knowledge proof, economic security, consensus or evidence of real-world observations. Anyone can reconstruct this public demo and its checksums. The word VALID in the interface is explicitly scoped to SIMULATION.

## Intended relation

`a_t = Policy_M(o_t)`

Both HOLD and STRIKE require the same verification relation. A future circuit would bind a committed observation and genesis policy to the decision. Witness design, public inputs, field encoding, hash selection, circuit constraints and trusted-setup requirements remain to be specified and audited before deployment.

## Solana

A future Solana program would verify the selected proof system and enforce sequence, previous-hash linkage and lifecycle rules. No program code or mainnet verifier is included here. Missing, forged or policy-swapped transitions must be rejected by that intended verifier.