StateMirror vs Logs, Audit Logs, Databases and Event Sourcing

• Your existing audit or event system preserves the exact consulted facts, ties them to the decision and meets your retention and integrity requirements.
• Historical decisions are rarely investigated, or current state is sufficient.
• You cannot yet define the evidence needed to answer a useful question.
• The operational cost exceeds the investigation value.

Before a pilot, ask whether relevant state changes, whether decisions are disputed, whether exact inputs can already be reconstructed and whether durable references and integrity checks would help. No score decides this for you. If existing tools meet the need, keep them.

StateMirror may replace an ad hoc decision snapshot table or a custom evidence store when its retrieval and integrity model fits. It complements logs, observability, event systems, the application database and provider APIs. Application logic, policy and authorization remain yours.

Evaluate one real decision →

Logs tell you what the system emitted. Current state tells you what is true now. Event systems tell you which events occurred. StateMirror preserves the application-submitted evidence describing what it knew when it made a consequential decision.

This is a comparison of common uses, not a claim that other tools cannot preserve evidence. A carefully designed audit log, event model or database can satisfy the same requirements.

Why consider it: Request diagnostics, failures and emitted messages. You already search them when investigating a disputed action.

Decision-time gap: A denial message may omit input values, their freshness and the rule version. Capture, retention and integrity depend on your logging design.

Alongside StateMirror: Record the snapshot ID or evidence reference in the log so an investigator can move from the request to its preserved context.

Why consider it: Reading and updating operational state. The customer, plan and entitlement rows are close to the business question.

Decision-time gap: A row after an upgrade does not establish its earlier value, or whether the application read a cache or external service instead.

Alongside StateMirror: Keep the database as the operational source and submit the actual values consulted at the decision moment.

Why consider it: Retaining earlier row versions and inspecting changes over time. Historical queries can reconstruct a past subscription or entitlement.

Decision-time gap: A history table does not necessarily identify the versions actually read across services, caches and external inputs. You must also preserve the relationship to the decision.

Alongside StateMirror: Use row-version references alongside consulted values in evidence. History remains useful for reviewing how state changed.

Why consider it: Recording actor, action, target and time for an activity trail. They may already record account changes and access denials.

Decision-time gap: An audit record may identify the action without its full input context. Some audit systems do preserve that context and integrity; evaluate your actual implementation.

Alongside StateMirror: Link the audit activity to a snapshot when a separate decision evidence record helps. If the audit log meets your requirements, another ledger may add little.

Why consider it: Persisting domain events and rebuilding application state through replay. Replay can explain how the application reached a historical state.

Decision-time gap: Reconstructed state does not necessarily capture external responses, read freshness or the exact inputs consulted. These can be included in an event model, but require deliberate design.

Alongside StateMirror: Keep domain events authoritative for the application. Capture a focused evidence snapshot when the consulted context is useful independently of replay.

Why consider it: Publishing, retaining and consuming streams of events. A retained stream may already contain subscription and entitlement changes.

Decision-time gap: Transported events do not automatically identify which inputs a particular decision used. Topic retention and compaction choices also affect what remains available later.

Alongside StateMirror: Keep events in the stream and preserve the application’s selected decision context by reference. Any consumer that submits evidence is application-owned; Core does not supply a Kafka connector.

Why consider it: Capturing a data structure in a portable representation. Writing the decision inputs to JSON is a reasonable starting point.

Decision-time gap: Serialization alone does not supply durable retrieval, idempotent ingest, canonical hashing or chain verification. A custom implementation can add those properties.

Alongside StateMirror: Submit the selected JSON as state_payload. Choose StateMirror if maintaining a separate evidence ledger is preferable to building those facilities yourself.

Why consider it: Instrumenting and correlating traces, metrics and logs. A trace helps follow a request across services and locate a failed operation.

Decision-time gap: Telemetry content, sampling, processing and backend retention determine which decision inputs survive. Instrumentation alone does not establish an intact decision evidence package.

Alongside StateMirror: Include a trace or correlation ID in submitted evidence, and a snapshot reference in telemetry. Continue using observability for system behavior and performance.

Use it when a consequential decision needs a separately retrievable evidence record, and your current systems leave you reconstructing which facts the application used. The application must choose the capture moment, submit enough context and handle ingest failures.

StateMirror does not recover evidence you omitted. Its hashes check preserved payload integrity, not the truth of the inputs or correctness of the decision. Operators still own database protection and retention.