# Enigma Witness Vault Device Claims This document defines public wording for the Raspberry Pi Zero 2 W Enigma Witness Vault hardware package. Use it for launch copy, conference demos, buying pages, sales notes, captions, and Q&A. Core honesty boundary: > The Witness Vault raises assurance for Enigma-controlled custody, device identity, operator visibility, and witness/checkpoint workflows. It does not prove provider deletion, model forgetting, truth of memories, tamper-proof storage, or complete side-channel absence. ## Approved short description Use this exact paragraph when space allows: > Enigma Witness Vault is a small Raspberry Pi Zero 2 W appliance for local AI memory custody and witness demos. It pairs an Enigma vault with an ATECC608A secure-element sidecar, a 0.96 in OLED status display, and optional NFC capsule tap support. It can make Enigma-mediated memory receipts, deletion/tombstone evidence, opaque relay records, and witness checkpoints physical and inspectable. Its claims are intentionally narrow: custody and witness assurance for Enigma-controlled state, not proof that outside providers deleted data or that models forgot. ## Allowed claims ### Product and hardware Allowed: - Enigma Witness Vault is a buildable commodity hardware package. - The reference build uses a Raspberry Pi Zero 2 W, ATECC608A sidecar, SSD1306 OLED, and optional PN532 NFC module. - The enclosure is designed for 3D printing in PETG or ASA on a Bambu X1 Carbon-class printer. - The hardware target is a $50-$100 commodity-parts build depending on reseller, country, fasteners, and optional NFC. - The Pi Zero 2 W is a small Linux-capable board suitable for a local vault/witness appliance demo. - The OLED provides local status visibility for operators. - The optional PN532 supports a local NFC tap gesture for capsule selection or demo handoff. Do not say: - proprietary secure appliance - bank-grade vault - tamper-proof vault - unhackable hardware - hardware wallet for memories - guaranteed air gap - military-grade security ### Enigma custody and receipts Allowed: - Enigma keeps canonical memory state in an Enigma-controlled vault for this local path. - Enigma can emit receipts for Enigma-mediated memory lifecycle events. - Enigma can export proof bundles and verify them offline where the software supports that flow. - Enigma can show that a memory was written, packed into scoped context, tombstoned/deleted from active serving state, exported, and verified inside Enigma's boundary. - The device can make the local custody and witness loop visible and repeatable in a public demo. Do not say: - proves every copy is gone - proves the memory was true - proves the model used the memory correctly - proves no one saw the memory - replaces all audit, compliance, or governance systems - removes all trust from AI memory ### Hardware-backed witness and ATECC608A Allowed: - The ATECC608A sidecar can hold device key material for hardware-backed identity or signing workflows. - The sidecar is a custody/witness assurance component, not a complete security boundary by itself. - Hardware-backed witness means checkpoint or witness operations can be bound to a device key held by the secure-element sidecar when the software is configured to use it. - The ATECC608A uses fixed I2C address `0x60` in the reference build. - The sidecar helps avoid keeping every signing operation purely in ordinary filesystem key material. Exact wording: > The ATECC608A sidecar gives the Witness Vault a hardware-backed device-key component for witness/checkpoint identity. It strengthens the local custody story, but it does not make the enclosure tamper-proof or prove facts outside Enigma's declared boundary. Short version: > ATECC-backed device identity for Enigma witness/checkpoint workflows, not a tamper-proof guarantee. Do not say: - the ATECC stores all memories - the secure element makes memories impossible to extract - hardware proves provider deletion - hardware proves model forgetting - hardware prevents all side channels - hardware replaces operational security - the printed enclosure is tamper-evident unless a separate tamper-evidence design is actually installed and documented ### OLED status Allowed: - The OLED shows operator-visible status such as boot, ready, local mode, sidecar detected, receipt activity, checkpoint activity, or NFC tap state. - OLED status is a human-facing cue. - OLED status should be backed by terminal output or receipt verification before making proof claims. Exact wording: > The OLED makes device state visible during demos and operations. It is an operator display, not a cryptographic proof by itself. Do not say: - if the OLED says verified, the proof is automatically valid - the display is a tamper-proof audit log - the display replaces exported receipts or verifier output ### Deletion and tombstones Allowed: - Enigma can tombstone/delete a memory from Enigma active serving state. - Enigma can produce evidence that a tombstoned memory should not be included in later Enigma context packs. - Enigma deletion proof is about Enigma-controlled state and Enigma-mediated operations. - External provider deletion requires separate evidence from the external provider or system. Exact wording: > Enigma deletion evidence shows that a memory was tombstoned and removed from Enigma active serving state under the recorded policy boundary. It does not prove deletion from model providers, backups, screenshots, logs, derived stores, people, or model weights. Short version: > Deleted from Enigma active serving, not proven forgotten by every outside system. Do not say: - proves provider deletion - proves model forgetting - proves no derived copy exists - proves legal erasure by itself - proves every backup, log, screenshot, or transcript is gone - proves semantic paraphrases are absent ### No-network and local mode Allowed: - The local vault demo can run without hosted Enigma cloud services after install/setup. - Offline verification can validate exported Enigma proof bundles where supported by the CLI/verifier flow. - The Pi Zero 2 W has Wi-Fi/BLE hardware; no-network claims must refer to the configured demo path, not physical absence of radios. - Relay/gateway demos can be local developer demos rather than hosted production services. Exact wording: > Local/no-network mode means this demo path uses local Enigma state and verifier output without relying on hosted Enigma services after setup. It does not mean the Pi has no radio hardware, and it does not prove that external AI providers never received data in unrelated workflows. Short version: > Local proof path, not a claim that all radios or all outside systems are absent. Do not say: - air-gapped unless radios are disabled/removed, no network is connected, and the exact condition is true - zero network risk - impossible to exfiltrate - no outside data ever exists - hosted relay/gateway is live unless it is actually deployed and authorized for public description ### Relay and witness checkpoints Allowed: - Relays should carry opaque encrypted records, not raw memory plaintext. - Witnesses checkpoint opaque roots, receipt identifiers, commitments, and metadata. - Witness checkpoint verification can show that checkpoint data was signed/verified under the demo flow. - A local hardware device can participate in or represent the witness role during a demo. Exact wording: > The witness checkpoint proves an Enigma checkpoint event over opaque roots and metadata. It does not reveal or validate raw memory content, and it does not prove provider-side deletion. Do not say: - witness proves memories are true - relay saw no metadata at all unless the exact metadata minimization is documented - relay/witness removes the need for encryption - witness proves the provider complied - public chains should store raw memory, prompts, transcripts, embeddings, ACLs, or personal metadata ### Gateway demo Allowed: - Gateway decisions can show policy evaluation for operation, provider, model, region, purpose, sensitivity, legal hold, and related metadata. - Gateway demo output can include signed decision verification and plaintext-minimized SIEM evidence. - The gateway demo does not call AI providers unless a specific integration is implemented and shown. Exact wording: > The gateway demo proves an Enigma policy decision under a declared boundary. It does not prove that a model provider accepted, enforced, deleted, or forgot anything outside that boundary. Do not say: - gateway proves provider compliance by itself - gateway makes all model calls compliant - gateway eliminates legal review - gateway replaces enterprise approval, DLP, KMS, SIEM, or policy operations ### NFC capsule tap Allowed: - NFC is optional. - The PN532 module can support a local capsule tap gesture. - A tag may identify a capsule, select a demo flow, or trigger an operator-confirmed action. - For public demos, NFC tags should contain only an identifier or pointer, not raw memory or secrets. Exact wording: > NFC capsule tap is a local selection gesture. It can identify a capsule or demo flow, but it is not proof of ownership or security by itself. Do not say: - NFC proves identity by itself - NFC stores secure memory by default - NFC is a hardware wallet - tapping a tag authorizes irreversible actions without additional controls - NFC token implies investment, ROI, or special access rights ### Token and network language Allowed only with legal/board review where required: - If launched, a token may be described as planned utility/governance/network-access infrastructure for optional relay/witness/gateway roles. - Local Enigma vault, MCP use, export, and offline verification should remain useful without token ownership wherever legally and technically practical. - Network access, service metering, operator bonding, and bounded protocol governance are utility concepts, not financial promises. Exact wording: > The Enigma token, if launched, is intended for utility, governance, and network access within optional relay, witness, and gateway infrastructure. It is not equity, not a revenue share, not a claim on company assets or user data, and not marketed with any expectation of profit. Do not say: - buy the token for upside - token holders earn revenue - guaranteed rewards - passive income - investment opportunity - token ownership gives company ownership or rights to user data - hardware purchase includes, guarantees, mines, or appreciates a token ## Banned claims list Never use these claims in public hardware collateral: - Proves provider deletion. - Proves model forgetting. - Proves every copy is gone. - Proves a memory is true. - Proves the model acted on the memory correctly. - Proves complete absence of side channels. - Tamper-proof. - Unhackable. - Air-gapped by default. - Zero trust in the absolute sense. - Military-grade security. - Compliance guaranteed. - GDPR/CCPA/HIPAA/SOC 2 compliance by itself. - Legal erasure guaranteed. - Hardware wallet for all AI memory. - Secure element stores all memory. - NFC proves ownership by itself. - Token rewards, profits, ROI, yield, passive income, buy pressure, or investment upside. - Hosted relay/gateway/witness is live unless the deployment is actually live and approved for publication. ## Approved one-liners Use these in decks, signage, and captions: - `A printable local witness appliance for Enigma-controlled AI memory receipts.` - `Hardware-visible custody and witness checkpoints, with narrow proof claims.` - `ATECC-backed device identity for Enigma witness workflows; not a tamper-proof guarantee.` - `OLED status for operators; verifier output for proof.` - `Deletion evidence for Enigma active serving state, not provider forgetting.` - `Relays carry opaque encrypted records; witnesses checkpoint opaque roots.` - `Optional NFC capsule tap for local selection, not standalone authentication.` - `Local proof path first; token/network language remains utility-only and legally reviewed.` ## Presenter correction lines Use these when someone overstates the demo: - If someone says `So it proves OpenAI deleted it?` - `No. It proves the Enigma vault tombstoned it from Enigma active serving. Provider deletion needs separate provider evidence.` - If someone says `So the secure element stores the memory?` - `No. The secure element supports device key operations. The vault storage is separate.` - If someone says `So it is air-gapped?` - `This run is local/no-hosted-service. The Pi has Wi-Fi/BLE hardware unless specifically disabled or removed.` - If someone says `So NFC proves I own the capsule?` - `No. In this demo NFC selects or identifies a capsule. Ownership needs additional authentication and policy.` - If someone says `Is this a token miner?` - `No. The hardware demo is about local custody and witness workflows. Any token plan is utility/network-access language subject to legal review, not ROI.` ## Publication review checklist Before publishing hardware claims, confirm: - The copy says `Enigma-controlled` or `Enigma-mediated` when describing proofs. - Deletion wording says `active serving state` and excludes provider/model forgetting. - Hardware-backed wording mentions ATECC/device identity or signing support, not tamper-proofing. - No-network wording distinguishes configured local mode from radio absence. - NFC wording says optional gesture/selector, not standalone authentication. - Token wording contains no ROI, yield, revenue-share, appreciation, guaranteed reward, or investment language. - Hosted relay/gateway/witness language matches actual deployment status.