AURiX WHITEPAPER: The Signal Inventory
================================================================================

Title: The AURiX Signal Inventory: 600 Observable Mechanisms for Structural Transparency

Author: AURiX Protocol | April 2026

================================================================================

ABSTRACT

The AURiX protocol rests on a fundamental principle: digital interaction can be made visible without interpretation, scoring, or identity inference. This document presents a complete inventory of 600 observable signals grouped into 26 mechanism families, each verified against the protocol's 8 invariants. The Signal Inventory serves as a territory map for instrument development, ensuring no observable mechanism is forgotten and establishing clear boundaries between what AURiX can measure (factual, reproducible states) and what it cannot (inferred intent, meaning, or judgment). This inventory is not a specification for a single product or version, but a foundational reference ensuring structural completeness as instruments mature.

INTRODUCTION

Digital interaction surfaces 600 distinct observable mechanisms. A user visiting a web page encounters scroll locks, overlay elements, form validation, redirect chains, script executions, permission requests, layout constraints, focus traps, timing sequences, visual obstructions, and hundreds more—each one technically present and structurally measurable. Most are invisible to ordinary users. All are opaque to instruments that rely on categorical judgment.

The AURiX protocol inverts the typical approach to digital transparency. Rather than asking "Is this page safe?" (which requires interpretation), AURiX asks "What structures are present?" (which requires only observation). The Signal Inventory catalogs what can be asked and answered without crossing into judgment.

INVARIANT FOUNDATION

All signals in this inventory satisfy the 8 AURiX invariants:

1. Mechanism only: The signal describes what is present, not what it means.
2. No interpretation imposed: The signal does not carry verdict, score, or judgment.
3. Separation of layers: Signals are partitioned by scope and temporal window.
4. Observable or declared: Every signal is either directly measurable or explicitly declared by the system.
5. Explicit origin: The source of every signal is unambiguously identified.
6. No silent transformation: No signal is modified without declaration.
7. Reproducibility boundary: Two independent implementations must produce identical signals from identical inputs.
8. No undeclared meaning: No signal carries encoded or implicit meaning.

Signals that would require judgment—malicious, suspicious, deceptive, manipulative—are explicitly excluded. If a determination requires inference of intent, meaning, or risk assessment, it is not an AURiX signal.

THE 26 MECHANISM FAMILIES

Signals are grouped into 26 families, each covering a distinct structural domain. Coverage is exhaustive within the AURiX scope (browser-layer interaction, not network, server, or user behavior):

1. Page Identity: Origin, protocol, certificate state, domain ownership signals, declared metadata.
2. Navigation/Redirect: URL transitions, redirect chains, cross-origin moves, history manipulation.
3. Transport/Security: TLS version, cipher strength, HSTS presence, certificate transparency signals.
4. DOM Structure: Element count, nesting depth, ID/class patterns, semantic markup presence.
5. Layout/Viewport: Fixed positioning, viewport locks, scroll constraints, layout shift triggers.
6. Overlay/Obstruction: Modal dialogs, sticky headers, floating elements, rendering layer ordering.
7. Input/Form: Form element count, field types, autofill presence, validation logic, submission targets.
8. Interaction Interception: Event listener attachment, preventDefault() calls, stopPropagation() usage, synthetic input triggering.
9. Scroll/Motion/Focus: Scroll event handlers, scroll locks, focus management, animation frame usage.
10. Frame/Embedding: iframe presence, cross-origin frame relationships, frame nesting depth, postMessage usage.
11. Script/Execution: Script source classification, execution timing, dynamic code generation, eval() usage.
12. Resource Loading: Script load timing, stylesheet parsing, image load patterns, resource ordering.
13. Content-Type/Delivery: MIME type declarations, encoding specification, compression signals, chunked transfer.
14. Storage/Persistence: Cookie count/domain/expiry, localStorage/sessionStorage usage, IndexedDB presence, cache control headers.
15. Permission/Capability: Permission API requests, microphone/camera capability claims, geolocation requests, clipboard access.
16. Worker/Background: Web Worker instantiation, Service Worker registration, SharedWorker usage, message passing patterns.
17. Temporal/Sequencing: Request timing, load order dependencies, render-blocking resources, requestAnimationFrame usage.
18. Volatility/Change: DOM mutation frequency, property value changes, style recalculation triggers, reflow events.
19. Visual/Render: Color contrasts, font metrics, image dimensions, text rendering signals, display mode declarations.
20. User-Choice/Consent: Consent UI presence, cookie banners, permission prompts, user interaction patterns.
21. Download/File/Handoff: Blob creation, file download triggering, clipboard write operations, data URI generation.
22. Auth/Session: Authentication method, session token presence, login flow signals, credential storage.
23. Accessibility Mechanisms: ARIA attribute presence, alt text declaration, keyboard navigation support, screen reader markers.
24. Browser/Environment: User agent classification, feature detection results, capability flags, browser mode signals.
25. Receipt/Binding: Cryptographic signatures, deterministic rendering proofs, moment-binding declarations, attestation markers.
26. Corpus/Post-Reclaim: Archival metadata, historical change records, retrieval index markers, recovered state pointers.

SIGNAL CHARACTERISTICS

Each signal has three essential characteristics:

Observability: The signal can be detected through DOM inspection, event monitoring, network observation, or rendering analysis. Signals without a concrete observational path are excluded. A scroll lock is observable (the browser will not scroll despite user input). A "malicious intent" is not observable.

Reproducibility: Two independent implementations implementing the same signal detection must produce identical results on identical inputs. A scroll lock either prevents scrolling or it does not—no subjective interpretation. The result is binary or numeric, never categorical.

Origin Clarity: The source of every signal is explicitly identified. A signal might originate from a DOM element, a network response header, a declared API call, or user interaction—but the origin is always traced and declared. Signals arising from inference chains are excluded.

EXCLUSION CRITERIA

The following categories are explicitly excluded from the Signal Inventory despite being common concerns in digital safety literature:

- Inferred intent: "This redirect is deceptive," "This overlay is predatory," "This form harvests data." These require judgment.
- Risk scoring: Any aggregation that produces a risk level, trust score, or threat assessment.
- Behavioral inference: "The user is being tracked," "The site is profiling behavior," "This is dark pattern X." These require interpretation of intent.
- Semantic categorization: "This is spam," "This is malware," "This is clickbait." These require classification judgment.
- Identity inference: "This belongs to Company X," "This is a government surveillance tool," "This is a scam site." These require association and judgment.

TERRITORY COMPLETENESS

The 600 signals distributed across 26 families represent the complete territory of observable mechanisms in browser-layer digital interaction. This distribution is not uniform. Mechanisms that occur with high frequency—scroll manipulation, overlay rendering, DOM mutation—appear multiple times across different signal types because they have multiple observable properties (timing, frequency, targeting, effect).

No family is complete in isolation. A single mechanism might have signals in three families: DOM Structure (what elements exist), Layout/Viewport (how they constrain the viewport), Interaction Interception (what events they intercept). This overlap is by design. It ensures that complex behaviors are captured from multiple angles without creating redundant signals.

The inventory serves as the design reference for AURiX instruments. As each instrument is developed, its signal coverage is validated against this inventory. If an observable mechanism is not surfaced by any instrument, the inventory flags it. If an instrument attempts to surface a signal not in this inventory, it fails validation.

APPLICATION TO INSTRUMENTS

The Signal Inventory is not a specification for a single instrument or version. It is a reference terrain. The AURiX instrument system collectively covers all 600 signals — 5 browser instruments (Gauge, Scope, Trace, Ledger, Receipt) and 6 desktop apps (AUDiT, reClaim, Answer, Anonymize, SELFiX, Record). Different instruments cover different temporal windows and mechanism families:

- Gauge surfaces real-time state signals (15 families) — absorbs prior Lens overlay-detection role
- Scope composes instrument states into a single visual signal (compositor; reads from siblings, applies worst-state-wins)
- Trace detects navigation paths and origin transitions (5 families)
- Ledger records state changes over time (7 families); also Exterminator aggregator
- Receipt logs permission/consent events session-scoped, browser-side
- AUDiT binds a specific moment using the locked grammar (7 families); desktop, on-demand
- reClaim recovers signals from the deep past (1 family)
- Answer (:A) queries recovered state (1 family)
- Anonymize prepares corpora for sector-grade safe release with hash-chain audit receipts
- SELFiX: personal counterpart, separate signal inventory pending
- Record: 6-layer egress ladder, Layer 1 (Cowork session auto-archive) live

Authoritative enumeration: /AURiX/extensions_shared/SUITE_MANIFEST.json. Prose here is downstream.

INVARIANT VALIDATION

Each family was validated against all 8 invariants. Example validation for the Navigation/Redirect family:

1. Mechanism only: The family describes URL transitions and redirect chains without interpreting intent (legitimate navigation vs. malicious redirect).
2. Separation of layers: Navigation signals are partitioned into pre-engagement (Scope reads the initial page), during-engagement (Gauge monitors live transitions), and path analysis (Trace reconstructs chains).
3. Observable or declared: Every redirect is observable in the network layer or DOM; CSP meta-refresh declarations are explicitly declared.
4. Explicit origin: Each redirect has a source (user click, script, meta tag, HTTP header) that is traced.
5. No silent transformation: No redirect is filtered or hidden; all are reported.
6. Reproducibility boundary: Two implementations checking identical navigation paths produce identical signal lists.
7. No undeclared meaning: The signals report what happened, not why.
8. No undeclared meaning: No signal encodes judgment about the legitimacy or safety of the redirect.

Families that failed validation were excluded. The Inventory reflects only those families that maintain invariant compliance across all 8 criteria.

IMPLICATIONS FOR TRANSPARENCY

The Signal Inventory establishes a boundary: AURiX is complete within the domain of observable mechanisms and incomplete by design in the domain of interpretation. This is not a limitation—it is the foundation of trustworthiness.

A user cannot deceive themselves about what an AURiX instrument is reporting. If the instrument reports a green cursor (Stable state across all active instruments), the user knows exactly what signals contributed to that state. They can inspect the mechanisms themselves. They decide what the mechanisms mean. They retain judgment. The instrument provides structural visibility, not judgment export.

This boundary also protects against scope creep. Each invariant violation—adding interpretation, hiding origins, collapsing layers—introduces exactly one failure mode: opacity. The Signal Inventory prevents these violations by maintaining exhaustive coverage of what can be measured without crossing into interpretation.

CONCLUSION

The AURiX Signal Inventory catalogs 600 observable mechanisms across 26 families, establishing complete coverage of browser-layer digital interaction without requiring or imposing interpretation. The inventory is validated against the 8 AURiX invariants and serves as the foundational reference for all instrument development. It establishes the boundary of what AURiX can measure (observable, reproducible, mechanistic states) and what it cannot (inferred intent, risk assessment, judgment-dependent categorization). This boundary is not a gap—it is the guarantee that every statement AURiX makes is verifiable by the user without relying on faith in the instrument's design or judgment.

================================================================================
END OF WHITEPAPER