StateMirror — Spec Sheet

[ DOWNLOAD DATASHEET ]

Inputs

• Evidence reference (evidence_ref) supplied by your application
• Evidence category (evidence_type)
• Captured timestamp (captured_at) supplied by the submitting system
• Computed evidence payload as opaque JSON
• Optional provenance metadata such as source_system, source_version, or correlation_id
• Optional idempotency key for safer retries

Outputs

• Snapshot identifier (snapshot_id)
• Instance-local sequence number
• Receipt timestamp (received_at)
• Integrity hashes such as payload_hash and chain_hash
• Snapshot retrieval by snapshot_id or exact evidence_ref

Verification export

• Commercial tiers may include a verification export path for offline review and dispute workflows.
• Export contents are evidence-level receipts, not decisions: snapshot_id, received_at, evidence_ref, evidence_type, payload_hash, chain_hash, and instance-local sequence.
• Verification is procedural: re-hash the stored payload using the published hashing rules, compare it to payload_hash, and validate chain continuity using chain_hash sequencing.
• This is integrity tooling only. It is not a compliance claim, legal non-repudiation claim, or guarantee of real-world truth.

Guarantees

• Stores the submitted payload immutably after ingest
• Returns the stored payload faithfully by reference
• Provides tamper-evidence through integrity hashes and hash chaining
• Does not mutate state on read
• Does not execute application outcomes

Non-guarantees

• That your payload was correct, complete, useful, or timely
• That your application captured evidence at the correct moment
• That timestamps reflect real-world time without clock skew
• That a missing snapshot implies anything about an outcome
• Security, compliance, admissibility, or legal non-repudiation

Invariants

• Snapshots are immutable once written
• Payload meaning is application-owned
• Retrieval is reference-driven, not predicate-driven
• Payload contents are not interpreted by StateMirror
• No dashboard or hosted control plane is required

Failure modes

• Ingest failure → snapshot does not exist
• Duplicate writes without idempotency
• Incomplete payload → faithful but insufficient evidence
• Database corruption or tampering → integrity verification fails
• Large payloads → rejected or operationally expensive
• Hot evidence_ref patterns → retrieval or indexing pressure

Performance characteristics

• Write path: PostgreSQL insert plus integrity/hash-chain work
• Read path: point lookup by primary key or indexed evidence_ref
• Concurrency: limited by PostgreSQL pool and write serialization needs
• Scaling model: run separate instances per domain when isolation is preferred

Out of scope

• State computation
• Outcome decisions
• Authorization or enforcement
• Analytics, search, dashboards, or alerting
• Event sourcing or reconstruction
• Retention automation
• Webhooks or notifications

Implementation details

• Language: TypeScript (Node.js)
• Interface: HTTP ingest + HTTP retrieval
• Database: PostgreSQL
• Deployment: self-hosted service + self-hosted database