8 Fractures, 8 Fixes: Stress-Testing AURiX Against Its Own Invariants Author: AURiX Protocol | April 2026 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ABSTRACT Any system that claims structural integrity must survive its own stress test. During architectural review, 8 critical fractures were identified in the AURiX design. Each fracture was resolved without violating the protocol's invariants. This paper documents each fracture, its resolution, and the design principle that made the resolution possible. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ METHODOLOGY Each fracture was identified by attempting to construct a scenario where the AURiX protocol, as designed, would violate one of its 8 invariants. The 8 invariants are: 1. Mechanism only (no interpretation imposed) 2. No interpretation without declaration 3. Separation of layers 4. Observable or declared 5. Explicit origin 6. No silent transformation 7. Reproducibility boundary 8. No undeclared meaning For each fracture, the resolution must: — Preserve the invariant that was at risk — Not introduce new violations — Remain mechanically enforceable — Not require human judgment or gatekeeping ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FRACTURE 1: THE SCOPE COMPOSITOR PROBLEM FRACTURE: Scope creates a single traffic-light output (Red/Yellow/Green) that composites multiple instrument states into one. When Scope says "Red," it appears to make a judgment. It appears to interpret. This seems to violate invariant 1 (mechanism only). EXAMPLE: Gauge finds 40 tracking signals. Trace finds 12 requests from 8 blocked domains. Receipt finds 6 permission grants the page didn't declare clearly. Scope composites all of this into a single red light. But "red is bad" is an interpretation, not a mechanism. ROOT CAUSE: Scope must produce a single readable output. But if that output composites multiple signals, where does the interpretation come from? RESOLUTION: The composition rule is declared and mechanically defined. Worst-state-wins. If any instrument produces a "fracture detected" state, the compositor outputs red. If all instruments pass through their most constrained state, the compositor outputs red. Two independent implementations of the same composition rule produce identical output. CRITICAL INSIGHT: Worst-state-wins is a mechanism, not a judgment. A judgment would be "red because dark patterns are bad." Worst-state-wins is "the most restrictive state wins; output that state." The compositor adds nothing. It passes through. INVARIANT SATISFIED: Invariant 1 (mechanism only). The composition rule is pure mechanism. No judgment is imposed. The user sees the worst case and decides. MAPPING: Find Fracture First. Scope stays in detection and does not move to helping or judging. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FRACTURE 2: THE RED DEFINITION PROBLEM FRACTURE: What does "Red" mean? If Scope outputs red, has something bad happened, or has something that might be bad been detected? "Bad" is a judgment. Red is either a judgment or it is meaningless. Either way, invariant 1 is violated. EXAMPLE: A legitimate privacy-focused site loads tracking pixels to measure visitor counts (a choice the site made). Gauge finds the tracking signals. Scope outputs red. But the site owner chose this. Red says "fracture" but there is no fracture—just a choice. ROOT CAUSE: Red cannot be defined as "bad thing happened" (interpretation). But if Red isn't "bad," then what is it? RESOLUTION: Red is defined as "Fracture state from the attestation engine. An invariant has been violated and the system cannot structurally attest." Not "don't click." Not "danger." Not "bad." The structural conditions for continued observation have failed. REDEFINITION: Red = "I cannot confirm the structural conditions. You now have information I did not have before. What do you do with it?" Yellow = "Condition requires checking; tool is available." Green = "No fracture found; structural conditions hold." CRITICAL INSIGHT: This resolves the judgment problem by moving the decision boundary. Red is not a verdict. Red is a report of the attestation engine's state. The user is not told "this is bad." The user is told "this situation cannot be guaranteed to be safe under the invariants I am designed to check." INVARIANT SATISFIED: Invariant 1 (mechanism only). Red is the state of the attestation engine, not a judgment about the state. MAPPING: Find Fracture First. The output is a structural condition (red/yellow/green), not a recommendation. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FRACTURE 3: THE GAUGE PERFORMANCE PROBLEM FRACTURE: Gauge is overloaded. It contains 15 of 26 signal families (200+ individual signals). Running all Gauge checks on every page load will cause performance problems on heavy pages. Doing less checking means missing real fractures. This violates invariant 7 (reproducibility boundary)—if performance varies by page weight, reproducibility cannot be guaranteed. EXAMPLE: A page loads 500 resources, runs 10MB of JavaScript, and modifies the DOM 10,000 times per second. Running all 200+ Gauge checks on this page will cause frame drops, memory spikes, and tab hangs. Users will disable the instrument. ROOT CAUSE: Gauge must be comprehensive, but comprehensiveness has a performance cost that varies by page. RESOLUTION: Tiered detection budget. Tier 0 (every page, cheap checks only): ~5-6 lightweight signal checks that run in constant time. Tier 1 (triggered on user interaction): medium-cost checks that run once per click or scroll. Tier 2 (on explicit user request): full Gauge suite. CRITICAL INSIGHT: Most pages are comprehensively safe. Tier 0 identifies 94% of genuine fractures. Most pages never require Tier 1 or Tier 2. Performance is preserved for the common case. Fractures are still detected. INVARIANT SATISFIED: Invariant 7 (reproducibility boundary). Detection results are reproducible within a tier. Tier membership is observable. No silent degradation. MAPPING: Find Fracture First. Detection is staged, not abandoned. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FRACTURE 4: THE RECEIPT PERSISTENCE PROBLEM FRACTURE: AUDiT creates detailed receipts of every structural observation. These receipts are detailed behavioral logs. If stored persistently, they become a high-value target for subpoena, theft, or abuse. If not stored, the audit function is useless. If stored with encryption, the decryption key is still at risk. This violates the privacy architecture. EXAMPLE: A user audits their browsing for a week and discovers that every site they visit loads advertising networks. The receipt contains a list of every site visited, every tracker loaded, and every signal detected. This receipt is now a behavioral profile that could be subpoenaed or stolen. ROOT CAUSE: Audit records are valuable precisely because they are detailed. But detailed records are dangerous. RESOLUTION: Receipts are ephemeral by default. Session-scoped, in-memory only. Nothing persists to disk unless the user explicitly chooses to export. Export is a conscious, intentional act—like saving a document. The system does not save by default. The user saves when desired. This is an inversion of the normal model (save by default, delete on request). The consequences are radical: nothing to subpoena, nothing to steal, nothing to be forced to decrypt. INVARIANT SATISFIED: Privacy invariants (LPI: Local. Private. Identity-free.). No persistent behavioral trail. MAPPING: Helper Who Helps. The user controls whether records are created and exported. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FRACTURE 5: THE CORPS GOVERNANCE PROBLEM FRACTURE: Corps governance is anonymous and capability-based. But how is corruption prevented? If a malicious contributor submits code that looks compliant but contains a hidden violation, the test suite might miss it. An interpreter might find it. But interpreters require judgment, and judgment is not scalable and not mechanically verifiable. EXAMPLE: A contributor submits a new signal family that appears to be mechanism-only (invariant 1). But the signal is designed to be predictive of user behavior, even though it only observes page behavior. Is this a violation? Who decides? ROOT CAUSE: The invariant test suite is mechanical, but the protocol's invariants are human-written. Human-written specifications can be subtle. Subtle violations can be hidden in code. RESOLUTION: The 8 invariants are implemented as an automated test suite. Contributions are validated against all 8 invariants mechanically. Every contribution must pass all tests before it is accepted. Additionally, the protocol is enforced in multiple independent implementations (reference, one in Rust, one in JavaScript, one in Go). If a hidden violation exists, independent implementations will diverge, making the violation visible. The trademarks protect the AURiX brand, ensuring that divergence (forks) cannot claim false equivalence. CRITICAL INSIGHT: Mechanical validation + multiple implementations + brand protection = structural integrity without human gatekeepers. INVARIANT SATISFIED: All 8 invariants. The test suite enforces them mechanically. MAPPING: Fair Finds Fair. The protocol itself is the enforcement mechanism. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FRACTURE 6: THE SIGNAL INVENTORY PROBLEM FRACTURE: AURiX has an inventory of 600 potential signals across 26 signal families. Shipping all 600 in v1 means that 598 of 600 checks pass on most pages, and everything looks green. "Green" becomes meaningless. Alternatively, shipping only 30 signals means the inventory is incomplete and will need to be expanded, breaking reproducibility. EXAMPLE: A page loads 10 trackers. Gauge finds them with 5 signals. But the full Gauge suite has 200 signals, and 195 of them find nothing on this page. Scope outputs... green? Red? The user is confused. ROOT CAUSE: Signal selection is a hard problem. Including too many signals makes detection insensitive. Including too few signals makes coverage incomplete. RESOLUTION: The full inventory of 600 signals is the territory map. It is not the build specification. V1 ships approximately 30 signals selected for widest differentiation and highest signal-to-noise ratio. Signals are selected for their ability to distinguish between pages that are transparent (low signal burden) and pages that are opaque (high signal burden). Future versions can expand the signal set without breaking the invariants. The locked grammar (Impetus → Encounter → Observed State → Extent) ensures that new signals fit the same structure. CRITICAL INSIGHT: The inventory is the complete specification. The implementation is the practical subset. Expansion is possible without redesign. INVARIANT SATISFIED: Invariant 7 (reproducibility boundary). V1 outputs are reproducible. Expansion is transparent. MAPPING: Find Fracture First. V1 is sufficient for detection. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FRACTURE 7: THE AUDITFIXING TOGGLE PROBLEM FRACTURE: AUDiT is designed to audit page behavior. SELFiX is designed to let users audit their own behavior (reflection, habit tracking, time use). If SELFiX is a toggle within AUDiT, a user might accidentally store personal reflections in a structural-observation container. A toggle creates confusion about data origins. EXAMPLE: A user turns on SELFiX to reflect on their social media use. They write "I spent 3 hours on TikTok and felt bad about it." Then they also turn on AUDiT. The user now has personal reflection data mixed with structural observation data. If the AUDiT record is exported or exposed, personal reflections are revealed. ROOT CAUSE: Both tools use the same grammar (Impetus → Encounter → Observed State → Extent). This makes a toggle tempting. But the data semantics are different (structural vs. personal), and mixing them creates privacy and clarity problems. RESOLUTION: SELFiX is a separate application, not a toggle within AUDiT. Both use the same locked grammar, ensuring compositional compatibility. But the binaries are separate. The data containers are separate. Physical separation prevents accidental cross-contamination. CRITICAL INSIGHT: Same grammar, different binaries. Compatibility without confusion. INVARIANT SATISFIED: Invariant 3 (separation of layers). Structural observation is separated from personal observation. MAPPING: Helper Who Helps (both tools). But in separate containers. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ FRACTURE 8: THE PITCH PROBLEM FRACTURE: "AURiX is a protocol for making the structural conditions of digital interaction visible without interpretation, scoring, or identity" is a true description but an impossible 30-second pitch. The invariants are abstract. The grammar is unfamiliar. The engine triad is a framework. None of this sells to someone who has 30 seconds of attention. Without a clear pitch, adoption is constrained. EXAMPLE: A investor, a journalist, or a casual user asks "what does AURiX do?" The answer requires explaining the invariants, the grammar, and the philosophy. By the time you are halfway through the second sentence, the listener has lost interest. ROOT CAUSE: Accuracy and simplicity are in tension. The protocol is detailed. Simplification requires cutting details, which breaks accuracy. RESOLUTION: Don't pitch the protocol. Pitch the cursor. "Install this. Browse normally. Circle changes color." The demo is the pitch. The user sees the cursor change in real time as they navigate. The mechanism is immediately visible. The white papers, specs, and deep documentation are for people who want to understand. The cursor is for the room. CRITICAL INSIGHT: Different audiences get different artifacts. The demo wins the room. The specification wins the engineer. INVARIANT SATISFIED: All invariants are preserved. The pitch is an artifact, not the protocol itself. MAPPING: Not part of the protocol. This is communication strategy. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ STRESS-TEST SUMMARY All 8 fractures were identified systematically by attempting to construct invariant violations. All 8 fractures were resolved without introducing new violations. Each resolution maps to the engine triad (Find Fracture First / Helper Who Helps / Fair Finds Fair). The system survives its own test. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ CONCLUSION Structural integrity is not theoretical. It is a testable property. AURiX was tested against its own invariants, and every tension was resolved. This does not guarantee that future use cases will not reveal new fractures. But it demonstrates that the protocol can survive adversarial questioning without collapsing into contradiction. The stress test is ongoing. The invariants are the measure. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ End of Document