Evidence Snapshots

Treat StateMirror like an oscilloscope or a flight recorder:

• You choose where to probe.
• You choose when to capture.
• The instrument preserves the reading faithfully.

The snapshot is the reading. The meaning is owned by your application and your support process.

StateMirror is fed a single envelope at evidence time:

• evidence_ref: your stable reference for this evidence moment
• evidence_type: a coarse category for retrieval
• captured_at: your timestamp for “when the evidence was captured”
• state_payload: the computed facts you chose to preserve (opaque to StateMirror)

This payload should be moment-level, not event-level. One snapshot per evidence moment is the intended shape.

• Intent. StateMirror does not store “why you tried to do something.”
• Events. It does not reconstruct history from event streams.
• Outcomes. It does not store or decide permit/deny as a system behavior.
• Truth. It does not prove your state was correct — only that it was preserved.
• Analytics. No searching inside payloads. No aggregations. No dashboards.

Logs answer: “what happened?” (usually short retention, unstructured, noisy).

StateMirror answers: “what did the system believe was true when it decided?” (long retention, structured, sparse).

This reduces “data archaeology” during disputes, appeals, audits, and Tier-3 escalations. The snapshot is a stable reference that can be attached to tickets and reviewed months later.

• Not captured. If you do not submit at evidence time, StateMirror cannot invent a record later.
• Partial capture. If your payload omits a fact, the snapshot will not contain it.
• Bad clocks. captured_at is your timestamp; received_at is StateMirror’s. Drift is expected.
• Retry duplicates. Use an idempotency key to make retries safe.