#Replay Workflows

Replay is the enterprise path for turning captured runtime state into a controlled audit and, when policy permits, a controlled re-execution.

#1. Capture an incident bundle

Start from the runtime that saw the problem:

byteor-runtime incident-bundle --out=/tmp/byteor-bundle --spec=/path/to/spec.kv --config=/path/to/runtime_config.txt --ring-path=/path/to/ring

That bundle is the unit of reproducibility. It captures the spec, validation result, runtime identity, policy audit, environment snapshot, and any available ring or lane state.

#2. Inspect before replay

Before replaying, review:

• spec_validation.json
• policy_audit.json
• single_ring_snapshot.json or lane_graph_state.json when present

Do not treat replay as a shortcut around diagnosis. The bundle is supposed to make the diagnosis reviewable.

#3. Start with dry-run replay

Dry-run replay should be the default first step. It exercises the replay path while keeping side effects disabled.

Typical operator intent:

• confirm the selected journal slice and input volume,
• inspect the generated replay audit,
• verify that policy decisions align with the expected environment posture.

#4. Promote to execute only with approval

If the replay needs to execute side effects, move to execute mode only after the correct approval has been verified for the target spec and environment.

Pair live replay with:

• an explicit approval credential,
• a clearly bounded scope,
• review of the resulting replay audit artifact.

#5. Keep the audit artifact

The replay audit is the durable record of what the replay selected, what policy mode applied, and which actions were attempted or denied. Treat it as a required operator artifact, not optional debug output.