# Enigma Witness Vault Demo Script This script is for public demos of the Raspberry Pi Zero 2 W Enigma Witness Vault: a small local custody and witness appliance with an ATECC608A secure-element sidecar, 0.96 in SSD1306 OLED, and optional PN532 NFC capsule tap. Say this boundary early and repeat it at the end: > The Witness Vault raises assurance for Enigma-controlled custody, local status visibility, key-backed device identity, and witnessed checkpoints. It does not prove provider deletion, model forgetting, truth of a memory, tamper-proof storage, or complete side-channel absence. ## Demo kit Bring these items already assembled and labeled: - Enigma Witness Vault in PETG or ASA enclosure. - USB power cable and known-good power adapter or laptop USB port. - microSD card installed with the demo image. - Demo laptop with Enigma CLI installed and a clean demo workspace. - Optional NFC capsule card/tag if the PN532 module is installed. - Spare USB cable, spare microSD card, and one printed placard showing the proof boundary. Hardware expected on the device: - Raspberry Pi Zero 2 W: 65 x 30 mm, quad-core A53, 512 MB RAM, Wi-Fi/BLE, microSD, USB OTG. - ATECC608A I2C secure element sidecar at fixed address `0x60`. - SSD1306 0.96 in 128 x 64 I2C OLED, usually `0x3C` or `0x3D`. - Optional compact PN532 NFC module in the longer NFC-capable enclosure. Presenter setup before doors open: 1. Boot the device once from wall power. 2. Confirm the OLED shows a stable ready state. 3. Confirm the laptop can reach the device or use the prepared local CLI fallback. 4. Confirm `enigma relay demo` and `enigma gateway demo` are available in the demo environment if the technical demo will include them. 5. If NFC is installed, tap the tag and confirm the displayed capsule id or capsule-ready state. 6. Clear the demo workspace so generated receipt ids, roots, timestamps, and signatures are live. Do not promise exact receipt ids, roots, signatures, timestamps, OLED frame timing, or NFC tap range. Those are runtime values. ## 5-minute conference demo Audience: conference floor, press walk-up, founders, community, non-specialist technical audience. Goal: make the hardware tangible: plug in a device, show local status, create a memory, compile scoped context, delete it from Enigma active serving, and show a witnessed checkpoint without claiming more than the system proves. ### Timing overview | Time | Action | Proof point | | --- | --- | --- | | 0:00-0:30 | Plug in device | Local appliance boots and shows status. | | 0:30-1:15 | Explain hardware | Pi runs vault workflow; ATECC sidecar backs device identity/witness signing; OLED makes state visible. | | 1:15-2:10 | Remember | Enigma writes a memory and emits a receipt. | | 2:10-2:55 | Context | Enigma compiles scoped context for a task. | | 2:55-3:45 | Delete/prove | Enigma tombstones/removes the memory from active serving and verifies the proof bundle. | | 3:45-4:30 | Witness, relay, gateway snapshot | Relay accepts opaque records/rejects plaintext; gateway shows a signed policy decision; witness checkpoint verifies opaque proof metadata. | | 4:30-5:00 | Optional NFC + close | Tap capsule tag; restate exact boundary. | ### Stage directions and talk track #### 0:00 — Plug in the device Action: 1. Hold the Witness Vault so the audience can see the enclosure and OLED window. 2. Plug in USB power. 3. Wait for the OLED to move from boot to ready. Expected OLED states: ```text ENIGMA VAULT BOOTING 01 ``` then: ```text VAULT READY I2C: OLED + ATECC NET: LOCAL / DEMO ``` Talk track: > This is the Enigma Witness Vault. It is a commodity Raspberry Pi Zero 2 W appliance in a printable enclosure. The OLED is there so the operator can see state without trusting a hidden process. The ATECC608A sidecar gives the device a hardware-backed key slot for identity and witness-style signing. This is custody and witness assurance, not magic security. Boundary sentence: > If I delete a memory here, I can prove the Enigma vault stopped serving it. I am not claiming a closed AI provider deleted internal copies or that a model forgot. #### 0:30 — Show physical components Action: - Point to the service opening and OLED. - If using a clear or open demo unit, point to the ATECC608A sidecar and optional PN532 antenna. Talk track: > The design target is intentionally boring: commodity Pi, I2C secure element, I2C OLED, optional NFC, PETG or ASA shell, and no conductive filament near radios. The point is a buildable witness appliance in the $50-$100 parts range, not a proprietary black box. #### 1:15 — Remember Action on laptop: ```sh enigma init --bundle ./.enigma/witness-demo-bundle.json --subject conference-demo --display-name "Conference Demo" enigma remember --bundle ./.enigma/witness-demo-bundle.json --text "Conference demo prefers short hardware proof explanations." --purpose user_memory --tags witness,demo ``` Expected output predicates: - `ok: true` - `schema` for the vault bundle or memory event - `memory_addr` - `receipt_id` OLED cue if integrated with the status daemon: ```text MEMORY WRITTEN receipt: rcp_demo_4f2a91c7 ``` Talk track: > We just wrote a memory into an Enigma-controlled vault. The important part is not the sentence. The important part is the receipt: Enigma can later show what it did inside its own boundary. #### 2:10 — Compile scoped context Action: ```sh enigma context --bundle ./.enigma/witness-demo-bundle.json --query "hardware proof explanations" --purpose stage_demo --out ./.enigma/witness-context-pack.json ``` Expected output predicates: - `ok: true` - context pack written to `./.enigma/witness-context-pack.json` - context is scoped to query/purpose Talk track: > Instead of handing a provider the whole durable memory store, Enigma prepares a scoped context capsule for a purpose. The provider gets only the context we choose to send for this task. Boundary sentence: > This does not prove the memory text is true. It proves Enigma selected and packaged context according to the declared local state and purpose. #### 2:55 — Delete and prove Action: Use the `memory_addr` from the remember output: ```sh enigma delete --bundle ./.enigma/witness-demo-bundle.json --memory-addr --reason demo_cleanup enigma export --bundle ./.enigma/witness-demo-bundle.json --out ./.enigma/witness-demo-export.json enigma verify --bundle ./.enigma/witness-demo-export.json ``` Expected output predicates: - delete/tombstone operation returns `ok: true` - export returns `ok: true` and non-zero receipt count - verify returns `ok: true`, a verification report schema, and `errors: []` - context after deletion should not serve the tombstoned memory from active state OLED cue: ```text TOMBSTONED VERIFY: OK ``` Talk track: > This is the most important honesty moment. Enigma can prove the memory was tombstoned and no longer belongs in Enigma active serving state. It cannot prove every external provider, backup, screenshot, log, or person forgot it. #### 3:45 — Witness checkpoint, relay, and gateway snapshot Action: ```sh enigma relay demo enigma gateway demo ``` Point to one relay/witness predicate and one gateway predicate. If the 5-minute slot is tight, run these before the audience arrives and show the fresh terminal output; do not claim a result you did not observe in that run. Expected relay/witness output predicates: ```json { "ok": true, "pushed_opaque_record": true, "rejected_plaintext_record": true, "witness_checkpoint_verification_ok": true } ``` Expected gateway output predicates: ```json { "ok": true, "allowed_retrieval": true, "signed_decision_verification_ok": true, "siem_event_plaintext_minimized": true } ``` Talk track: > The relay path accepts opaque encrypted records and rejects plaintext-looking memory fields. The witness path checkpoints opaque roots and metadata. The gateway path signs a policy decision. None of these paths should receive raw memories in public proof artifacts, and none of them proves provider-side deletion. #### 4:30 — Optional NFC capsule tap Use this only if the PN532 module is installed and tested. Action: 1. Hold up the NFC capsule card/tag. 2. Tap it to the NFC-marked surface. 3. Show the OLED capsule cue. Expected OLED cue: ```text NFC CAPSULE cap_demo_7b41c2a0 READY ``` Talk track: > The NFC tap is a local capsule selection gesture. It can identify or unlock a demo flow, but it is not a magic security token by itself. Do not put raw memory or secrets on the tag for public demos. Close: > What you saw is the complete physical loop: plug in a local witness appliance, create a memory, compile scoped context, tombstone it from active serving, verify the evidence, checkpoint opaque proof metadata, and show relay/gateway policy surfaces. The claim is narrow and useful: Enigma-controlled custody and witness evidence, not provider-side forgetting. ## 15-minute technical demo Audience: developers, security reviewers, enterprise AI engineers, hardware-curious buyers, technical press. Goal: show the same user-facing loop plus implementation boundaries: device status, I2C modules, CLI/MCP style flow, delete/prove behavior, relay and gateway demos, optional NFC capsule tap, and failure-safe claim language. ### Timing overview | Time | Segment | Outcome | | --- | --- | --- | | 0:00-1:30 | Hardware boot and status | Device visibly boots; OLED reports ready/local state. | | 1:30-3:00 | Architecture | Explain Pi, ATECC, OLED, optional PN532, enclosure choices. | | 3:00-5:00 | Initialize and remember | Create clean vault and memory receipt. | | 5:00-6:45 | Context pack | Produce scoped context and explain provider boundary. | | 6:45-9:00 | Delete/prove | Tombstone, export, verify, and explain exact deletion claim. | | 9:00-11:00 | Witness checkpoint/relay | Show opaque relay record, plaintext rejection, checkpoint verification. | | 11:00-13:00 | Gateway decision | Show policy decision and signed decision boundary. | | 13:00-14:00 | Optional NFC capsule tap | Show local capsule selection gesture. | | 14:00-15:00 | Q&A close | Repeat allowed and banned claims. | ### Segment A — Boot, OLED, and operator status Action: 1. Plug in the Witness Vault. 2. Narrate the OLED states. 3. Keep the laptop terminal visible but do not start with software; start with the physical device. Expected OLED progression: ```text ENIGMA VAULT BOOTING ``` ```text ATECC: 0x60 OK OLED: 0x3C OK MODE: LOCAL ``` ```text READY receipts: live witness: armed ``` Talk track: > The OLED is deliberately simple. In a public setting, it answers three questions: is the vault awake, are the sidecars visible, and what mode is it in? It is not a security proof by itself; it is operator visibility. If a module is not present: - Say `OLED-only demo mode` or `NFC not installed on this unit`. - Do not pretend a missing sidecar is active. - For an ATECC miss, switch to software-only fallback and state that the hardware-backed witness portion is not being demonstrated. ### Segment B — Hardware architecture in plain English Talk track: > The Pi Zero 2 W runs the local Enigma workflow. The ATECC608A sidecar is a hardware key sidecar on I2C address 0x60. The SSD1306 OLED shares I2C and shows human-readable state. The optional PN532 module supports a capsule tap gesture. The enclosure is printable on a Bambu X1 Carbon in PETG or ASA; we avoid conductive or carbon-filled filament near Wi-Fi, BLE, and NFC antennas. Exact claim to use: > Hardware-backed witness means this device can bind witness/checkpoint operations to a key held by the ATECC sidecar and can make local device state visible. It does not make the enclosure tamper-proof and does not prove anything outside the Enigma-controlled boundary. ### Segment C — Initialize and remember Action: ```sh mkdir -p .enigma enigma init --bundle ./.enigma/witness-tech-bundle.json --subject witness-tech-demo --display-name "Witness Tech Demo" enigma remember --bundle ./.enigma/witness-tech-bundle.json --text "Technical demo prefers exact claim boundaries and compact receipts." --purpose user_memory --tags hardware,witness,demo ``` Expected output predicates: - init returns `ok: true` - remember returns `ok: true` - remember output includes a `memory_addr` - remember output includes a `receipt_id` Narration: > The receipt is the artifact to watch. We are not asking the audience to trust the OLED or my terminal. We are creating an exportable proof trail for Enigma-mediated events. Presenter note: - Copy the `memory_addr` into the next delete command. - Do not paste private or unrehearsed memory text into a public terminal. ### Segment D — Context pack Action: ```sh enigma context --bundle ./.enigma/witness-tech-bundle.json --query "claim boundaries" --purpose technical_demo --out ./.enigma/witness-tech-context.json ``` Expected output predicates: - command returns `ok: true` - output path is written - context is scoped to query and purpose Narration: > Durable memory stays in the vault. The model or tool receives a scoped context pack. That distinction matters for demos: Enigma can prove what Enigma packed and served; it cannot prove a downstream model interpreted it correctly. ### Segment E — Delete/prove and active-serving boundary Action: ```sh enigma delete --bundle ./.enigma/witness-tech-bundle.json --memory-addr --reason technical_demo_cleanup enigma context --bundle ./.enigma/witness-tech-bundle.json --query "claim boundaries" --purpose post_delete_check --out ./.enigma/witness-tech-post-delete-context.json enigma export --bundle ./.enigma/witness-tech-bundle.json --out ./.enigma/witness-tech-export.json enigma verify --bundle ./.enigma/witness-tech-export.json ``` Expected output predicates: - delete returns `ok: true` - post-delete context does not serve the tombstoned memory from active state - export returns non-zero receipts - verify returns `ok: true` and `errors: []` Narration: > This is deletion from Enigma active serving state with a tombstone and receipts. The proof is useful because it is narrow. It does not prove provider deletion, backups, screenshots, human memory, model weights, or external logs. If asked whether this is a deletion proof: > It is an Enigma deletion/tombstone proof for Enigma-controlled state. For external systems, you need independent evidence from those systems. ### Segment F — Witness checkpoint and relay demo Action: ```sh enigma relay demo ``` Expected output predicates: ```json { "ok": true, "pushed_opaque_record": true, "rejected_plaintext_record": true, "witness_checkpoint_verification_ok": true, "pairing_challenge_ok": true, "pairing_complete_ok": true } ``` Narration: > The relay/witness path handles opaque encrypted records and checkpoints. A good demo shows two things: the opaque record succeeds, and plaintext-looking memory fields are rejected. Witnesses should see commitments, roots, receipt ids, and metadata, not private memory text. Hardware tie-in: > The Witness Vault can be the visible local node for this checkpoint story: dedicated power, visible status, serviceable enclosure, and key-backed identity through the ATECC sidecar. ### Segment G — Gateway demo Action: ```sh enigma gateway demo ``` Expected output predicates: ```json { "ok": true, "allowed_retrieval": true, "denied_disallowed_region": true, "denied_legal_hold_delete": true, "signed_decision_verification_ok": true, "siem_event_plaintext_minimized": true } ``` Narration: > Gateway decisions are policy evidence. The gateway signs decisions about provider, model, region, operation, purpose, sensitivity, and legal hold state. It does not call providers in this demo, and it does not prove provider deletion or model forgetting. Bridge sentence: > In a deployment, the hardware vault, relay, witness, and gateway are separate roles that can be combined for a demo but should remain conceptually distinct. ### Segment H — Optional NFC capsule tap Use only with the NFC enclosure and installed PN532. Action: 1. Show the NFC mark on the enclosure. 2. Tap the prepared capsule tag. 3. Confirm the OLED or terminal identifies the capsule id. 4. Continue only after the operator acknowledges the capsule. Expected display: ```text NFC TAP capsule: cap_demo_01 operator: confirm ``` Narration: > NFC is an operator gesture for capsule selection or demo handoff. For public demos, the tag should contain only an identifier or pointer. It should not contain raw memory, private prompts, seed phrases, API keys, or token promises. ### Segment I — Close and Q&A boundaries Close with: > The technical proof loop is: local vault, receipt, scoped context, tombstone, verifier, opaque relay, witness checkpoint, and gateway decision. The hardware makes that loop physical and visible. The security claim stays precise: better custody and witness assurance for Enigma-mediated state, not universal deletion or tamper-proof memory. Fast Q&A answers: - **Is this required for Enigma?** No. Local Enigma can run without this appliance. The appliance is a dedicated witness/custody demo and deployment option. - **Does the secure element store all memories?** No. It is for key-backed identity/signing support. Memories remain in the Enigma vault storage model. - **Does delete mean OpenAI/Anthropic/Kimi forgot?** No. It means Enigma tombstoned the memory from Enigma active serving state and can verify that evidence. - **Does no-network mean no radio exists?** No. The Pi has Wi-Fi/BLE hardware. Say local/no-network mode only when the demo path is configured not to use hosted services after install. - **Does NFC prove ownership?** No. NFC is a tap gesture or capsule selector unless paired with additional authentication. - **Is there a token return angle?** No. If token/network language appears, it is utility/governance/network-access planning subject to legal review, not ROI or investment language. ## Presenter safety checklist Before going live: - Use demo memory text that is safe to show on a projector. - Keep private keys, seed phrases, API tokens, Wi-Fi passwords, and real customer data out of the terminal and NFC tags. - Confirm the ATECC sidecar is present before saying hardware-backed witness. - Confirm the PN532 is installed before inviting an NFC tap. - Use `local demo`, `local relay demo`, or `gateway demo`; do not imply hosted cloud is live unless the production deployment is actually live and authorized. - Repeat the proof boundary after deletion and at the close. If something fails: - OLED fails: continue with terminal proof and say the display/status path is not active. - ATECC is not detected: continue only as software/local vault demo; do not say hardware-backed witness for that run. - NFC misses: skip the tap; do not troubleshoot antenna range on stage. - Relay/gateway demo unavailable: finish with local receipt export and verifier; say network-role demos are not active in this run. - Verification fails: stop the proof claim and show the error honestly. Do not call a failed verifier a successful proof.