Threat model

Shadow assumes the record-keeper may be the adversary: a lender’s own logs can be edited after the fact. Evidence bundles are therefore hash-chained and signed at capture time, so tampering after issuance is detectable by anyone with the public key — without trusting the party that produced the record. The public site itself has no server, no database, and no user accounts; its attack surface is static asset hosting, served with nosniff, a strict referrer policy, restricted permissions, and a report-only Content Security Policy. A malformed or tampered case fails validation loudly rather than rendering a misleading audit state.

Key management

Bundles are signed with Ed25519. Keypairs are generated by the open-source CLI on the operator’s own machine; the private key never leaves that machine and is never held by this site or any hosted service. Verification needs only the public key (SPKI/PEM), which is safe to distribute to examiners, auditors, and counterparties. Key rotation and custody are the operator’s responsibility today — HSM/KMS integration is on the roadmap below, not claimed now.

What verification does — and does not — prove

Verification proves that the supplied evidence matches the sealed record: the hash chain is unbroken and the signature is valid for the stated public key, so nothing was added, removed, or reordered after sealing. Verification ≠ correctness: it does not prove analytical correctness, business correctness, or regulatory compliance, and it never substitutes for the accountable human reviewer whose sign-off the record preserves.

• Proves: integrity, ordering, and authorship of the record under a key.
• Does not prove: that the decision was right, fair, or compliant — that judgment stays human.

Data handling

Local-first by default: cases, packages, and preferences are processed and stored in your browser (IndexedDB / localStorage). Nothing is uploaded — there is no Shadow backend to receive it. The public demo uses a fixed synthetic banking case only.

Optional features that touch a network

All are off by default, disclosed at the point of use, and work only with your explicit action:

• AI command understanding (bring your own key): sends your command text and the list of view names to api.anthropic.com — only after you supply your own Anthropic API key, which is stored only in this browser. Case content is never included.
• Voice commands: audio is processed by your browser vendor’s speech service (e.g. Google in Chrome, Apple in Safari). We never receive the audio; the transcript is handled locally.
• Internet sync (experimental): shares only the tour step and focused node via a public signaling server (signaling.yjs.dev) — never case content. Joining requires a room code you enter.

Compliance roadmap

Current status, honestly dated. Nothing below is a certification Shadow already holds.

• 2026 Q3 — shipped: MIT-licensed verifier CLI with CI-friendly exit codes, an automated privacy/secrets scan on every commit, and the security & architecture brief below.
• 2026 Q4 — planned: third-party penetration test, scoped together with the first guided pilot.
• 2027 H1 — planned: SOC 2 Type I examination, contingent on a production pilot. Not started, not held.
• Under evaluation, no committed date: ISO/IEC 27001; HSM/KMS-backed key custody for managed deployments.