Pilot StateMirror

Pick a billing quantity, entitlement denial, subscription downgrade or trial expiry with a real investigation question. Keep the scope to one application path and one team. Write down how you investigate it today.

Working example: why did the application deny an additional seat while the customer’s plan was active?

List the values the application actually read: plan status, occupied seats, seat limit, read time and rule version. Include source and freshness information when available. Capture the values used by the decision, rather than querying them again afterward.

Decide which question each field helps answer. Do not copy whole customer records, credentials or unrelated personal data.

Use the smallest useful application-defined JSON. This is the same teaching payload used in the Quickstart; its fields are examples, not a SimpleStates schema.

{
  "subject": "customer_123",
  "inputs": {
    "plan_status": "active",
    "seats_used": 10,
    "seat_limit": 10,
    "read_at": "2026-06-15T18:22:30.000Z"
  },
  "rule_version": "access-rules@2026.06.12",
  "decision": "deny",
  "reason": "seat_limit_reached",
  "correlation_id": "request_001"
}

The payload hash covers state_payload. Put important business references, source timestamps and rule versions inside it when they need hash coverage; envelope metadata does not receive the same coverage.

Submit the evidence when the application makes the decision using POST /v1/snapshots, a write bearer key and an Idempotency-Key. Save the returned snapshot_id with the request or invoice reference. Use the submission recipe.

StateMirror records what the application submits. It does not discover hidden state, execute the action or make evidence capture atomic with your application transaction.

Choose what the application does if capture times out or fails. If you need a durable retry queue or outbox, your application owns it. Retry the identical submission with the same key; use a new key for a new decision. Review the retry limits.

Run long enough to accumulate real examples or reach a meaningful investigation. Choose the volume, data permissions and exit criteria with the operating team. There is no universal pilot duration.

Before using real evidence, review production responsibilities. Track failed captures, added request latency, missing fields and time spent operating the service alongside the investigations it helps.

1. Find the saved snapshot ID or query the application’s evidence reference.
2. Retrieve the payload and inspect the recorded facts and rule version.
3. Verify the snapshot; check a sequence range if continuity across records matters.
4. Compare the submitted facts with current state and other investigation records.

A verification pass establishes payload/hash/chain consistency within the documented trust boundary. It does not prove the input facts or application decision were correct. Follow the worked denial investigation.

• Did the evidence reduce reconstruction work compared with your existing process?
• Did it contain the facts and provenance needed to answer the question?
• Were capture failures, latency and operating work acceptable?
• Which decisions gained nothing from the extra record?
• What would make evaluation or operation easier?

Record examples and counterexamples. A verification pass alone is not evidence that adopting another service is worthwhile.

Adopt this narrow use, continue the pilot, change the payload, use existing tools or reject StateMirror. “Our current system already solves this” is a successful evaluation result.

Write a short decision record: workflow evaluated, investigation question, useful evidence, missing facts, operating cost and next step. Keep customer evidence in your own systems.

Tried StateMirror? Tell me what broke, confused you or would stop you from running it.