# LoopGrid — Synthetic Evidence Demo
### Technical explanation · Reference demonstration · September 2026

**Purpose.** This is a clean-room, browser-based reference demonstration of the evidence lifecycle proposed for LoopGrid: Capture → Seal → Investigate → Prove. It is designed for prospect discovery and technical inspection, not as proof of a production integration or an independently audited LoopGrid release.

**What is simulated.** Four fictional workflows cover a voice-agent refund, mortgage income-file update, insurance reserve adjustment, and enterprise role grant. A deterministic script stands in for an AI agent; no LLM or voice provider is called. Identities, authority grants, policies, and reviewer decisions are synthetic. The reviewer buttons simulate approval or rejection. An in-memory adapter stands in for the downstream business system and returns a state revision or simulated failure. No money moves, no patient or loan decision is made, and no customer system is contacted.

**What actually runs.** The browser creates a fresh, non-extractable Ed25519 private key for each new synthetic run. It records the request/agent context, policy evaluation, simulated review, action request, mock response, and observed outcome as applicable. It computes SHA-256 content commitments and workspace/decision-scoped chain links, signs each event, and signs a checkpoint binding event count and final chain hash. The browser then independently recomputes the hashes and verifies the signatures and a separately supplied signer fingerprint. The bundled reference fixture was signed offline; its private key is not distributed.

**Portable proof.** The reference ZIP contains `bundle.json`, `manifest.json`, `events.jsonl`, `checkpoint.json`, and `public-key.pem`. The standalone Python verifier checks consistency of the split ZIP evidence files and supports this synthetic format, uses the established `cryptography` package, and makes no network calls. Its external `--pin` or `--pin-file` argument is mandatory. The browser and Python implementation use the same documented, restricted canonical JSON subset. This is a versioned demonstration protocol, not a claim of compatibility with production LoopGrid exports or SDKs.

**Verification and trust.** The verifier checks content hashes, contiguous sequence and previous-hash links, Ed25519 signatures, workspace/decision identity, signer identity, and the signed checkpoint. Changing a field, deleting or truncating history, or substituting a key produces a failed check. Re-signing with another key can create mathematically valid signatures but must fail against the original trusted signer fingerprint. The public key inside a bundle cannot establish its own trust. A real deployment needs a separately established signer identity and key-management policy.

**Assurance boundaries.** A valid bundle establishes integrity and provenance of the captured records under the expected signing key. It does not prove upstream statements were true, every real-world event was captured, a genuine human approved, the action was correct, or any legal or regulatory requirement was satisfied. A signed mock response is evidence of a mock response—not proof that a bank, payment processor, EHR, or insurer acted. The demo uses local browser timestamps, not trusted timestamps. Its generated keys, simulated policy, and local adapter are not substitutes for hardened production capture, identity, authorization, retention, availability, or operational controls.

**Production relationship and next step.** The existing LoopGrid project materials describe a v0.8 Design Partner baseline with REST/SDK integration, signed evidence, privacy modes, and offline verification. This page is a separate reference implementation; the actual backend, SDKs, production signing boundary, and export protocol were not independently tested for this deliverable. A real pilot should connect one authorized workflow through a trusted server-side capture point, record the authoritative downstream response, validate privacy and key-management requirements, and verify the actual product export with the production verifier. Customer data and live actions should only be introduced after the appropriate security, consent, and contractual review.