Ephemeral by Default: Privacy Architecture for Local-Only Behavioral Attestation Author: AURiX Protocol | April 2026 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ABSTRACT AURiX's privacy model is not a policy — it is architectural. The system is structurally incapable of being a surveillance tool. This paper documents the LPI posture (Local. Private. Identity-free.), ephemeral receipt design, the privacy flip, and the structural promise that separates observation of page behavior from observation of user behavior. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ LPI POSTURE: THREE CONSTRAINTS Local: Everything runs on-device. Nothing phones home. No network calls to AURiX infrastructure for signal detection, inference, or analysis. The browser itself contains the complete observation engine. Deployers can run AURiX entirely offline if required. Private: No profiles, no telemetry, no data collection. The system observes the page, not the user. It does not log what the user read, how long they lingered, which words they searched, or what they clicked. All observation is structural (page behavior), never personal (user behavior). Identity-free: No user identity is created, tracked, or required. AURiX does not need an account, a login, a device fingerprint, or a persistent identifier. In a commercial deployment, the only persistent data point would be an email address for payment. That is structurally unavoidable. Everything else is structurally prevented. The LPI posture is not rhetorical. Each constraint is mechanically enforced in the design: Local-Only is enforced by architecture: there is no network layer. No API exists to call. No backend service processes AURiX data. Private is enforced by signal selection: the 600 signals in the inventory are all observable from the browser's resource loading, storage access, and DOM mutation APIs. No signal captures user input, keystroke patterns, or behavioral timing. Identity-free is enforced by receipt design: both Receipt instrument logs (browser-side, ephemeral) and AUDiT attestations (desktop-side, on-demand, exportable) are session-scoped unless the user explicitly exports. No persistent behavioral trail is created. No cross-session identity is established. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ EPHEMERAL RECEIPTS: SESSION-SCOPED, USER-CONTROLLED AUDiT receipts are ephemeral by default — session-scoped, in-memory only. Nothing persists to disk unless the user explicitly exports. Export is a conscious act, like saving a document. No ambient logging. No persistent behavioral trail. This design has direct consequences: A device seizure finds nothing, because nothing was stored on disk. A subpoena cannot demand records that don't exist. Malware cannot exfiltrate persistent behavioral data because there is no persistent data. The user's own compliance audits or regulators cannot demand "all AURiX observations for the past six months" because that data was never collected. Ephemeral design also prevents the classical data-liability problem: companies that promise "we delete your data after 30 days" still have the problem that they collected it in the first place. If subpoenaed, the deletion policy doesn't matter. Ephemeral-by-default solves the earlier problem: the data was never stored in the form the attacker wants, so there's nothing to secure. The default is in-memory. The user chooses to export. That inversion of control is the entire privacy architecture. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ THE PRIVACY FLIP: OBSERVING THE OBSERVERS AURiX watches what the PAGE does, not what the USER does. This distinction enables a structural inversion: because AURiX observes page behavior, it can expose who IS collecting user data. The page itself reveals its own surveillance infrastructure through observable mechanisms: Resource loading signals (Signal Family 12): which third-party domains the page loaded, in what order, with what bandwidth priority. Reveals tracker networks. Cross-origin requests (Signal Family 8): CORS calls, beacons, pixel requests. Reveals real-time data exfiltration. Tracking parameters (Signal Family 1): URLs containing fbclid, gclid, utm parameters, and first-party cookie identifiers. Reveals advertising networks. Storage writes (Signal Family 14): localStorage, sessionStorage, IndexedDB modifications. Reveals persistent client-side tracking. Fingerprinting attempts (Signal Family 11): Canvas, WebGL, navigator object access patterns that suggest device identification. The instrument shows: "this page made 47 cross-origin requests in 3 seconds." That's a signal, not a verdict. The user decides what it means. But the user now KNOWS that 47 third parties received requests, even if the user didn't initiate them. This is the privacy flip: instead of asking "how can we protect the user's data from us," AURiX asks "how can we show the user who else is collecting their data." The answer comes from observing page behavior, which is inherently observable and cannot be hidden. The page cannot hide that it made a request. The page cannot hide that it loaded a tracker. The page cannot hide that it sent a beacon. These are structural facts, not opinions. AURiX exposes them without needing to track the user. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ THE STRUCTURAL PROMISE "If your data leaks, it wasn't from us — because we never had it. And we can show you who does." This is not marketing. It is architectural fact enforced by LPI and the 8 invariants: You cannot extract what was never collected. AURiX knows less about the user than the user's own browser does. You cannot subpoena what was never stored. Ephemeral receipts have no persistence layer. You cannot identify who is sending data if you don't build a profile. Identity-free architecture prevents cross-session tracking. The structural promise is mechanically enforceable. It doesn't rest on AURiX's goodwill or corporate promises. It rests on the code's inability to do anything else. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ SELFiX: SEPARATION OF CONCERN SELFiX is a separate application from AURiX, not a toggle within AUDiT. AURiX observes the page. SELFiX allows the user to observe themselves. Both use the locked grammar (Impetus → Encounter → Observed State → Extent), so they are compositionally compatible. But they are separate binaries. This separation prevents users from accidentally storing personal reflections in an external-observation container. A user might want to audit "why did I spend three hours on social media" (personal, SELFiX). But that same user should not confuse that with "this page is loading 40 trackers" (structural, AURiX). Physical separation prevents cross-contamination. AUDiT outputs are structural. SELFiX outputs are personal. They should not be mixed. Deployers of AURiX in regulated environments (healthcare, financial, legal) can install AURiX without SELFiX. Deployers who want personal reflection can install both. The separation is clean. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ARCHITECTURAL VALIDATION The privacy architecture has been stress-tested against: 1. Adversarial data collection: Is there any signal family that captures user behavior? No. All 600 signals are page-observable only. 2. Persistent tracking: Is there a mechanism to create persistent behavioral trails? No. Receipts are session-scoped. Export is user-initiated. 3. Identity linkage: Can the system build profiles across sessions? No. No persistent identifier exists except the user's optional payment email. 4. Third-party extraction: Can external parties access AURiX observations? No. Everything runs locally. There is no API to call. 5. Silent collection: Can AURiX collect data without user knowledge? No. Every observation is part of the AUDiT record, which the user controls. Each test passed mechanically. The privacy architecture is not a promise. It is a constraint. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ CONCLUSION AURiX is not a privacy policy. It is a privacy architecture. The difference is enforceability. Policies can be changed. Architectures require code changes to violate. In AURiX, the structural conditions that make surveillance possible have been removed entirely. The system cannot be made to surveil. That is not a feature. That is a design constraint. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ End of Document