Stateful Triggers and Exact Replay

An event rule needs state when it depends on persistence, previous activation or the disappearance of an input. Hypercube’s Circuit example records those decisions alongside the analytical generations that produced them, then recalculates the recording from a fresh engine.

The threshold rule

The callback watches liquid_residual_score. It requires two consecutive values at or above 1.0 before entering an active state. Once active, it exits at or below 0.5.

The two thresholds supply hysteresis: activation and exit use different conditions. The consecutive-observation requirement adds persistence. The terminal displays the qualifying count, active state, entry and exit events, and recent score paths for each entity.

Each live frame represents one completed Hypercube generation. The callback’s decision is tied to that generation’s inputs and retained state.

Missing input and invalidation

At generation four the example removes the active entity SIM0006. The callback emits INVALIDATED.

An absent entity has not supplied a low score that satisfies the normal exit condition. Recording an explicit invalidation preserves the reason for the transition and prevents missing input from being interpreted as ordinary observed evidence.

That distinction matters for event factors: inactive, active and invalid can carry different meanings even when a downstream numeric exposure is zero.

What replay compares

After 28 generations the example seals its in-memory JSON Lines recording. A fresh engine and fresh callback state then replay it. The final frame compares factor cells, trigger-state cells and transitions, and reports zero divergent generations for this deterministic run.

The check covers the state machine as well as the score. Reproducing a displayed value alone would not establish that the same sequence of entries, exits and invalidations occurred.

Replay verifies the declared computational contract for recorded inputs. It does not establish forecasting quality or reconstruct an unrecorded external execution system.

Run and verify

cargo run -p hypercube-circuit --example circuit

A separate bounded recording and verification workflow is available through the replay binary:

cargo run -p hypercube-circuit --bin hypercube-replay -- \
  record-demo /tmp/hypercube-factor.jsonl 40 32

cargo run -p hypercube-circuit --bin hypercube-replay -- \
  verify /tmp/hypercube-factor.jsonl

The recording command declares its own generation and entity counts; it is not the 28-generation animation capture. The replay guide specifies the exactness contract and isolation rules for effectful callbacks.

Source and related material

• Callback recording walkthrough.
• Replay contract and isolation.
• Circuit example.
• Hypercube architecture.