# Enigma Overnight Build Master Plan

Purpose: give reviewers a concrete, claim-bounded sequence for turning the launch collateral into demonstrable product evidence. This plan is not a financial forecast, promotional token material, or unmeasured performance claim.

## Claim boundaries

- Receipts prove declared Enigma-mediated events: signatures, ordering, commitments, policy hashes, and exported verifier results.
- Receipts do not prove provider-side erasure, model-side memory removal, semantic erasure, factual truth, or activity outside the instrumented Enigma boundary.
- Hardware language is limited to custody, locality, and verification workflows. Do not describe any device as attack-proof.
- Token language, if used, is limited to utility, governance, and network-access posture pending board and legal review.

## Build order

1. **Proof core** — keep receipt generation deterministic, chain each receipt to a prior hash, and keep verifier output offline-readable.
2. **Boundary harnesses** — exercise vault, context-pack, MCP, browser, desktop, relay, witness, and gateway paths with minimized payloads.
3. **Launch demos** — show local install, first Memory Passport, context export, verifier report, and clear limitations before any network narrative.
4. **Hardware ladder** — present Witness Vault as the proof/custody object, Memory Vault One / Memory Node as a locality-cache prototype, and Enterprise Memory Gateway as the governed team boundary.
5. **Review package** — publish only the claims that have matching repository evidence, static docs, and legal/security review where required.

## Evidence checklist

- Local install path works from the static guide and repository checkout.
- Receipt examples avoid raw memory plaintext in public proof material.
- Launch pages link only to relative static assets.
- Competitive language compares memory layers without claiming processor-performance dominance.
- Token, governance, and network-access wording remains review-gated.