CONFIDENTIAL — Pre-disclosure — NDA only — Not for distribution
Integrated Demonstration · BIS WLL · May 2026
Section 01 · ARIA-AUT family

Channel Integrity & Authentication

Channel Provenance Protocol — per-counterparty cryptographic authentication of electronic communications. Three sender profiles. Four attack scenarios. Cooperative-consensus verification at the recipient. Trust-mark rendered in user-agent chrome, outside sender-controlled content.

REAL · Web Crypto HMAC-SHA-256 REAL · Per-counterparty KDF REAL · Cooperative consensus USPTO · MP21 P1 · Filed 2026-04-27

Enrolled senders — registry

REAL · sender_secret per profile

Each profile holds a sender_secret in HSM-equivalent storage. Selecting a profile binds the next compose action to that profile’s identity.

Compose communication

Banque Populaire BPCE

Per-counterparty key: HMAC-SHA-256(sender_secret, recipient_id || content_hash || session_nonce). Signature attaches as channel header. The verification client at the recipient independently re-derives the same key from registry-published material.

Adversary console

REAL · 4 attack types

Four named attack types from the MP21 P1 specification. Each demonstrates a distinct verification-failure mode caught by the recipient client.

Per-counterparty KDF — live values

--:--:--Awaiting first send to populate KDF state...

Signing key is unique per (sender, recipient, content, nonce) tuple. A leaked key for one pair does not compromise any other pair.

Inbox — recipient verification client

v1.0 · synced

The trust-mark below is rendered in user-agent chrome by the verification client — outside any sender-controlled content area.

Inbox is empty. Send a communication from the compose card to populate.

Live message flow

SENDER Enrolled HMAC sign REGISTRY ARIA Service Trap layer RECIPIENT Verify client UA chrome signed verify Idle · click an attack or send a message

Binôme cooperative verifier consensus

REAL · consensus protocol

Three independent verifier instances, optionally from different organisations. Default mode: 3-of-3 unanimous. Other modes supported by protocol: 2-of-2, 2-of-3 quorum (one endpoint may be compromised, two-of-three legitimate-state persists).

Verifier · Anthropic Org A · Claude-class idle
Verifier · OpenAI Org B · GPT-class idle
Verifier · Mistral Org C · Mistral-class idle

Adversarial inputs optimised against any one verifier’s training distribution still fail at the other two — the cooperative requirement is the defence.

Trust-mark at user-agent level

The “Authenticated by ARIA — [sender]” badge is rendered by the verification client in trusted browser or OS chrome, not in the message content area.

Authenticated by ARIA — BPCE user-agent chrome — cannot be spoofed

Bonjour, votre virement de 2 500 EUR a ete execute...

“Authenticated” (drawn in message body) spoofable — rendered by sender content

Same protection model as TLS lock icons, OS-level OAuth consent screens, and platform-level biometric prompts.

Trap & attribution feed

REAL-TIME · LAST 30 DAYS

Verification failures populate this feed with forensic context routed to the impersonated sender’s threat-intelligence team. Gated on cryptographic verification failure — not on passive scanning.

0Verification failures
0Decoy-recipient hits
0Blocked at recipient
0Authenticated delivered

Event feed

--:--:--No events yet. Launch an attack from the adversary console.

Multi-channel coverage

The protocol is channel-agnostic. Same per-counterparty KDF, same trust-mark architecture, same cooperative-consensus modifier across every carrier.

EmailCustom header
WebHTTP response header
SMS / RCSAppended payload
VoiceParallel signaling
VideoFrame watermark
IoT telemetryPayload field
Push notif.Metadata field
In-app msgOut-of-band

Architectural summary

Channel Provenance Protocol binds the signature to (sender_secret, recipient_id, content_hash, session_nonce), optionally extended to channel state (sequence number, hop topology, cooperative consensus). The four attack types share a common verification-failure mode: at least one KDF input cannot be reproduced by the attacker, so the re-derived signature does not match the received signature.

The defence is architectural, not detective. The recipient client does not need to recognise the attack as anomalous — the cryptographic re-derivation either matches or it does not. False positives under legitimate traffic are structurally zero. Graceful degradation under partial compromise is provided by the cooperative-consensus modes.

Cross-references: MP21 P1 channel-protocol; MP20 P92 / P94 physical-document family with the same KDF substrate; MP19 P88 Binôme cooperative primitive; FLE-PROSODY-2025-PCT-001 prosody embodiment (Track A platform-licensing reserved — not surfaced in this demo).

Section 02 · ARIA-COD

Per-Counterparty Continuity

The primitive specifically targeting the SolarWinds-class attack. Each bilateral relationship maintains a per-counterparty cryptographic continuity record derived from interaction history through HMAC-SHA-256 with character-extraction fingerprints plus fake-phrase obfuscation. An attacker holding stolen credentials cannot reproduce the relationship’s internal state — substitution is detected at the bilateral protocol layer.

REAL · HMAC continuity chain REAL · Character-extraction fingerprints PART · Fake-phrase obfuscation (mock generator) USPTO · §7-bis filed · MP21 family
Architectural property: The continuity record is internal to the relationship — neither party stores it as a standalone secret, neither relies on a third-party authority. Defence does not rely on attacker behaviour being anomalous, only on attacker lack of access to the relationship’s internal state.

Legitimate pair · vendor ↔ customer

REAL · evolving HMAC chain

A vendor (software update distributor) and a customer (enterprise IT) have built up continuity across eight interactions. The continuity record at each side evolves with every legitimate exchange. Below: the record state on the customer side after each interaction.

Continuity record — live state

--:--:--Run a legitimate update to populate the continuity chain.

Continuity record at step N is HMAC-SHA-256(record_{N-1}, fingerprint_N || obfusc_N || content_hash_N). The chain is one-way; rewinding requires the inputs at every step, which requires the relationship’s history.

Stolen-credential attacker — substitution attempt

REAL · mismatch detection

The attacker has the vendor’s signing credentials (e.g., from a build-pipeline compromise — SolarWinds-class). The attacker can produce signed updates that pass PKI verification. What the attacker cannot do is reproduce the customer’s continuity record — the attacker has not participated in the eight prior interactions.

CUSTOMER SIDE

The customer’s verification client holds record_8 from the legitimate chain. When the attacker’s update arrives, the client computes expected_record_9 based on the attacker’s payload + customer’s held record_8. The attacker has no way to forge a fingerprint and obfuscation that match what the legitimate vendor would have produced.

Disabled until the legitimate chain has at least 5 interactions.

ATTACK RESULT

--:--:--Build the legitimate chain first, then run the substitution attack.

Character-extraction fingerprint

Each interaction’s content yields a fingerprint that is stable for the relationship (same patterns produce the same fingerprint) and not directly invertible (fingerprint does not reveal content). The construction combines bigram statistics, token-length distribution moments, and a relationship-keyed hash. The fingerprint is one of three KDF inputs to the continuity step.

fp_methodbigram-stats + length-moments + hkdf-keyed-mix fp_size256 bits fp_stabilityStable on same content; differs on substitution fp_invertibilityOne-way w.r.t. content recovery current_fp

Fake-phrase obfuscation

PART · stable seeded generator

Each step contributes an obfuscation input that is not directly observable from interaction logs. Generated from a relationship-keyed PRG seeded at enrollment. Defeats the offline-replay variant where an attacker has logged communications — logs alone do not yield the obfuscation input.

obfusc_sourceHKDF(enrollment_secret, step_index) obfusc_size128 bits observable_from_logsNo — not on the wire attacker_recoveryRequires endpoint compromise current_obfusc

Composition with the rest of the suite

COD composes with AUT (authentication provides per-message integrity; COD provides per-relationship continuity above it). COD composes with Storage (storage operations require continuity-verified counterparty before authorisation). The two-layer defence — per-message authentication and per-relationship continuity — is the architectural answer to SolarWinds-class supply-chain attacks where the attacker holds legitimate per-message credentials but does not hold per-relationship state.

The Signal Protocol’s double-ratchet maintains per-counterparty state for forward secrecy — the closest cited prior art. ARIA-COD distinguishes by using per-counterparty state specifically as a substitution-detection primitive, with character-extraction fingerprints and fake-phrase obfuscation as KDF inputs that produce a stable per-relationship fingerprint while remaining resistant to direct content disclosure. The combination is filed as the inventive core.

Cross-references: AUT (per-message integrity, MP21 P1 filed); Storage (per-operation authorisation, MP21 P5 filed); Internal-Channel Encryption (within Binôme cooperative-verification, MP21 P4 filed). The SolarWinds end-to-end walk-through using all three primitives composed is in Section 5.

Section 03 · ARIA-ENC

Authenticated Deniable Communication

Written-channel protocol. Real Shamir GF(2^8) threshold sharing (k=3 of N=5, configurable). Sequence-locked silent-failure: wrong-order chunk opening returns an error indistinguishable from insufficient-chunks — denying the attacker oracle access. Cover-message generation is bound to the per-counterparty key.

REAL · Shamir GF(2^8) REAL · Sequence-locked AES-GCM REAL · Silent-failure attack SIM · AI cover generation USPTO · MP21 P2 · Filed 2026-04-28

Anna · sender (enrolled)

cp_id pending

The real message is composed locally. It is never transmitted as ciphertext — a cover message, plausible business correspondence between Anna and Bernard, carries the real message embedded steganographically.

SESSION STATE

K_recover σ_session cover_len thresholdk=3, N=5 permutations5! = 120

The wire — what any observer sees

5 transport paths

Five transport paths carry one cover message plus four chunk-bearing packets. None are distinguishable from each other on casual observation. The cover is plausible business correspondence. The chunk packets look like opaque transit traffic.

Wire is silent. Send a message to populate.

Bernard · recipient (enrolled)

σ_session in Secure Enclave

Bernard’s recipient client receives the cover and chunks. σ_session is retrieved from local Secure Enclave (set at enrollment, never on the wire). Recovery: select k=3 chunks, order by σ, attempt authenticated decryption.

RECEIVED

--:--:--— no cover yet —

RECOVERED REAL MESSAGE

--:--:--— recovery pending —

Silent-failure attack mode: wrong σ returns the same error as “insufficient chunks.” The attacker gets no oracle signal.

Six layers — wire to real meaning

L6 Real-message layer The actual content. Never on the wire. Reconstructed only at Bernard’s endpoint.
L5 ARIA-KEY layer K_recover split into N=5 chunks, k=3 threshold, sequence-locked by σ_session. Reconstruction needs k chunks AND correct σ.
L4 ARIA-INK layer Steganographic embedding within the cover. Real message recoverable only with K_recover.
L3 ARIA-MSG layer The cover message: plausible business correspondence between Anna and Bernard.
L2 Authentication layer Cover signed by Anna’s per-counterparty key. Both endpoints enrolled (bilateral authentication).
L1 Wire layer What an adversary observes: ARIA-MSG covers plus opaque chunk-bearing packets. Not distinguishable.

Sequence-locked threshold — the cryptographic novelty

REAL · GF(2^8) Shamir + AES-GCM wrap

K_recover is split via Shamir polynomial interpolation over GF(2^8) into 5 chunks; any 3 are mathematically sufficient. Each chunk is ALSO wrapped using a key derived from the contents of all chunks scheduled to precede it in σ_session. σ_session is a permutation of the 5 indices, set freshly at session establishment, stored only at Bernard’s Secure Enclave and at the registry. It never travels on the wire.

σ_session set after first send

Wrong-order opening fails an authenticated-decryption integrity check. The error is indistinguishable from “insufficient chunks collected” — the attacker gets no oracle access by which to brute-force σ. With 5 chunks, an attacker without σ faces 5! = 120 permutations, each test requiring Bernard’s enrollment credential AND producing no signal about which positions are correct. With N=8, 40,320 permutations; with N=12, 479,001,600.

Coercion-resistance under legal compulsion

Suppose Bernard is compelled by legal authority to disclose received content. He can comply with a partially-honest disclosure:

1. Hand over the cover message — which is what arrived on the wire, decrypts truthfully to itself, internally consistent.
2. Optionally claim σ_session was rotated and is no longer in Secure Enclave (true after session end; verification requires registry-record access).
3. Optionally claim not all chunks were received from all 5 paths (plausible for cooperative key distribution; one path may have failed to deliver).

The compliance is harder to disprove than with simple threshold sharing. The real message remains hidden.

What ARIA-ENC does NOT defend against

HONESTY

Endpoint compromise. If Bernard’s device is compromised AND σ_session is exfiltrated before session end, the recovered message is exposed.

Forward secrecy across credential compromise. Compromise of registry-stored long-term enrollment credentials may permit retroactive decryption depending on protocol parameters.

Anonymous operation. Both endpoints are identified to the registry. Registry metadata (which endpoints, when, what duration) is available to legal process. This is by design — the architectural answer to dual-use concerns.

Voice-channel ENC

FILED · Demo in queue

Voice-channel embodiment. Written cover serves voice: at the sender, voice content is reduced to a written-form transcript that is embedded in a written cover; at the recipient, voice is locally reconstructed from the recovered text using pre-registered sender voice profile. The wire carries no voice or text of the real content — only the cover correspondence. Latency and quality constraints are operationally stringent and the demonstration build is queued.

filingMP21 P2 family · written cover applied to voice channel statusFiled · operational demo queued distinctionDifferent primitive from Embodiment G prosody authentication (reserved Track A)

SyncVid — video-channel ENC

FILED · Demo in queue

Video-channel deniable communication with synchronised state attestation across multiple parties. Architectural design parallels voice-channel: written cover carries video reconstruction parameters; recipient locally reconstructs from pre-registered profile. Synchronised state attestation handles multi-party video where each participant must reconstruct a coherent shared video state.

filingMP21 P2 family · synchronised state attestation across multiple parties statusFiled · operational demo queued
Section 04 · ARIA-STORAGE family

Authenticated Deniable Storage

Six sub-inventions are filed at USPTO. Operational demo artifacts are queued for build. This section presents the architecture honestly — what each sub-invention is, how it composes with the rest of the suite, and what the comparison to conventional encrypted storage looks like.

USPTO · MP21 P5 · Filed 2026-04-28 Demo artifacts in build queue
Honest framing. The six sub-inventions are filed as a single family with explicit cleaving strategy for PCT conversion (three options for national-stage splitting based on jurisdictional fit). What follows is the architecture as filed. No operational behaviour is fabricated. The Section 5 chain composition demonstrates one storage primitive composed with COD against credential-theft lateral movement; this section presents the full family architecture for reference.

ARIA-DSK

Filed · demo in queue

Persistent storage on conventional storage media (disk, SSD, cloud-storage backend). Provides authenticated deniability with the disk-resident format indistinguishable from generic encrypted storage under casual inspection. Cover-content is selected from the user’s authentic data, per-document KDF derives from cover identifier and content hash, protected content is embedded steganographically into authentic cover documents.

claim_range4-8 (MP21 P5) cover_sourceUser’s authentic data (photos, documents, audio) cleavageSI-1 sub-invention

ARIA-MEM

Filed · demo in queue

Volatile-memory variant for in-process secret protection. Memory contents survive cooperative-verification challenge but become unrecoverable after process termination. Hardware-enclave integration: Intel SGX, AMD SEV, ARM TrustZone.

claim_range9-12 enclave_supportSGX · SEV · TrustZone terminationProcess end ⇒ unrecoverable cleavageSI-2 sub-invention

ARIA-VAULT

Filed · demo in queue

Virtual mailbox credential storage. Pseudo-email-accounts on conventional providers carry credential split. Inter-account correspondence has cover-coherence (the messages between accounts read plausibly), credentials are embedded steganographically in selected messages, account-level threshold distribution spreads the credential across N independent providers. Addresses the password-manager attack class: compromise of one vault does not yield the credential population.

claim_range13-16 providersN independent (k-of-N threshold) attack_classPassword-manager compromise cleavageSI-3 sub-invention

Self-Cooperative

Filed · demo in queue

Self-cooperative architecture across user devices. A single operator runs cooperative-verification across their own devices (phone + laptop + secure-element token). Provides quorum-based access from operator’s own devices without requiring a counterparty. Mutual device authentication on recovery; cooperative revocation flow on device loss.

claim_range17-21 quorumk-of-N across operator’s devices revocationCooperative flow on device loss cleavageSI-4 sub-invention

Hardware embodiment

Filed · demo in queue

Dedicated storage-device hardware integrating the ARIA-STORAGE primitive at the firmware level. Embedded controller, secure element, hardware RNG, cover-content flash region, embedded-protected-content flash region, sideband authentication channel. Default mode presents host file-system view as ordinary cover content; authenticated mode presents the extended view with protected content recovered.

claim_range22-25 substrateEmbedded firmware + secure element attack_classFirmware attacks on generic storage cleavageSI-5 sub-invention

Trusted-custodian

Filed · demo in queue

Trusted-custodian configuration for institutional contexts where a regulated custodian holds part of the cooperative-verification quorum (legal escrow, financial trustee, regulated data fiduciary). Day-to-day access path: user portion only. Extraordinary access path: user + custodian cooperation under registry-recorded terms.

claim_range26-30 custodian_typesLegal escrow · Financial trustee · Data fiduciary access_pathsRoutine + extraordinary (with terms) cleavageSI-6 sub-invention

Conventional encrypted storage vs. cover-from-authentic-data

CONVENTIONAL ENCRYPTED STORAGE

LUKS / dm-crypt, VeraCrypt, BitLocker, FileVault, encrypted file systems, encrypted cloud-storage backends. All produce identifiable encrypted storage observable on inspection. Forensic examination reveals the presence of encrypted data even when content remains undecryptable.

Steganographic file systems exist (StegFS, RubberhoseFS) and provide deniability properties, but lack per-document key derivation, sequence-locked threshold recovery-key distribution, and cover-from-authentic-data architecture — they use generic decoy content rather than the user’s actual data.

ARIA-STORAGE COVER-FROM-AUTHENTIC-DATA

Cover-content is the user’s authentic data (photos, documents, audio, scans) with independent retention value. To an inspector, the storage substrate is indistinguishable from generic personal data. There is no encrypted blob to find — the protected content is embedded in authentic cover documents.

Per-document key derivation, sequence-locked threshold recovery-key distribution, opening-sequence-ordered chunk opening with silent-failure denial of oracle access. Composes with AUT (authenticated access), COD (continuity-verified counterparty), Binôme (cooperative consensus for high-stakes recovery).

Composition with the rest of the suite

Storage operations require authenticated access via AUT (per-message integrity), continuity-verified counterparty via COD (per-relationship state), and optionally cooperative consensus via Binôme (multi-verifier quorum). The composition is the suite’s full architectural posture for data-at-rest.

In Section 5, the credential-theft lateral-movement scenario shows COD + Storage composing against an attacker who has stolen working credentials: the attacker can authenticate at the AUT layer but cannot reproduce the per-relationship continuity required by COD, and cannot locate sensitive material in the storage substrate where ARIA-STORAGE cover-from-authentic-data has hidden it among ordinary user data.

Section 05 · Composition

Chain Composition — the architectural moat

The strategic value of ARIA is not in any single primitive but in the composition. Three scenarios. The principal walk-through is SolarWinds-class supply-chain compromise — six steps, walked twice (primitives off / primitives on) with a toggle mechanic in between. Two adjacent scenarios round it out: synthetic-audio executive impersonation and credential-theft lateral movement.

REAL · toggle mechanic REAL · primitives compose SIM · SCIM-routed custom scenario

Primitive toggles — observe the composition

REAL

Toggle the five primitives on/off and observe how the SolarWinds-class attack outcome changes below. The mechanic is the central didactic device of this section — the composition value, not the individual primitive value.

SolarWinds-class supply-chain compromise — six steps

2020 · 18,000+ customers · 9-month dwell time

The canonical attack timeline. The all-primitives-off column is the actual 2020 historical outcome. The primitives-on column is what ARIA delivers as configured by the toggles above.

STEP
ATTACKER ACTION
ALL PRIMITIVES OFF
PRIMITIVES TOGGLED
1
Compromise build pipeline
Pipeline compromised — outside ARIA scope. PKI assumes credentials can be stolen.
Out of ARIA scope. ARIA does not defend against build-pipeline compromise per se.
2
Sign malicious update with legitimate key
Signature verifies. Standard PKI says: signed by vendor ⇒ trusted.
Toggle primitives above
3
Distribute via normal update channel
Distribution succeeds; mass delivery to 18,000+ customers.
Toggle primitives above
4
Customer verifies signature, installs
Signature valid ⇒ installation proceeds. PKI provides no relationship-continuity layer.
Toggle primitives above
5
Persistent access — lateral movement
Attacker has admin access; reads sensitive material; exfiltrates.
Toggle primitives above
6
Maintain access for months
9-month dwell time. Detection only after FireEye disclosure.
Toggle primitives above
Toggle primitives above to populate the per-step defence narrative.

Adjacent scenario · Synthetic-audio executive impersonation

Attacker calls the treasury function impersonating the CFO with a cloned voice. Requests urgent wire transfer to attacker-controlled account.

1 Attacker generates voice clone from public audio (interviews, earnings calls).
2 Attacker calls treasury, presents urgent wire-transfer instruction.
3 ARIA-AUT carrier-state binding: the call carrier itself is part of the signature input. Attacker’s call cannot reproduce the carrier-state from a registered CFO endpoint.
4 Channel Provenance Protocol: the trust-mark renders in user-agent chrome. Treasury function sees no chrome-rendered authentication for this call. Standing procedure: block.
5 Outcome: transaction blocked. Trap-and-attribution feed populates with forensic context routed to the impersonated CFO’s threat-intelligence team.

The defence is architectural — not detection-based. The treasury function does not need to detect the voice clone; the absence of authentication is the signal.

Adjacent scenario · Credential-theft lateral movement

Attacker has working credentials. PKI / MFA accepts them. Standard IAM provides no architectural defence against legitimate-credential lateral movement.

1 Attacker authenticates with stolen credentials. PKI / MFA accepts.
2 Attacker attempts to access a counterparty relationship (vendor portal, partner API, internal team workspace).
3 ARIA-COD per-counterparty continuity: the counterparty’s verification client computes the expected continuity record. Attacker has not participated in the relationship history — record mismatch.
4 ARIA-STORAGE cover-from-authentic-data: attacker reaches the storage substrate but the sensitive content is embedded in authentic cover documents. Attacker sees ordinary user data; the structure of the protected content is not visible without per-document key derivation.
5 Outcome: lateral movement blocked at the relationship-continuity layer. Even if the attacker bypasses COD on one relationship, the per-relationship structure means each new counterparty is independently a fresh continuity-check.

The per-customer continuity record is the SolarWinds amplification killer — the attacker has to compromise each victim individually rather than achieving one-to-thousands amplification.

Try your own SolarWinds-class scenario

SIM · SCIM-routed

Describe a supply-chain or substitution-class scenario from your own experience or threat model. The input routes through SCIM (Semantic Confidence Intent Mapping) for intent analysis, then through the studio-brain proxy to generate an architectural analysis of which ARIA primitives apply and what the composition outcome would be. Both SCIM and the AI proxy are real production endpoints.

SCIM endpoint: scim-api.soaf01.workers.dev · AI proxy: studio-brain.soaf01.workers.dev/ai · Model: claude-sonnet-4-20250514. No browser-to-Anthropic call. Falls back gracefully if the endpoints are unreachable.

Section i · About this demo

About this demonstration

Honest framing of what is and is not operationally shown, the architectural principles documented even where no operational surface exists, and the filing status of every primitive referenced.

Demonstrated vs. architecturally presented

PRIMITIVE
SECTION
DEMONSTRATION MODE
FILING STATUS
Channel Provenance Protocol
S1
REAL · operational
MP21 P1 · Filed 2026-04-27
AUT — Channel embodiment
S1
REAL · KDF + cooperative consensus
MP21 P1 · Filed 2026-04-27
AUT — Physical-document embodiments (A–F)
Out of scope this demo
MP20 P92 / P94 · Filed 2026-04-28
AUT — Embodiment G prosody
Track A reserved — not surfaced
FLE-PROSODY-2025-PCT-001 · Filed
ARIA-COD
S2
PART · continuity REAL, obfuscation mock
§7-bis filed · MP21 family
ARIA-ENC written channel
S3
REAL · Shamir GF(2^8) + sequence-lock
MP21 P2 · Filed 2026-04-28
ARIA-ENC voice channel
S3
Architectural only · filed, demo queued
MP21 P2 · Filed 2026-04-28
SyncVid — video channel
S3
Architectural only · filed, demo queued
MP21 P2 family · Filed 2026-04-28
Internal-Channel Encryption
S5 toggle
PART · toggle effect REAL
MP21 P4 · Filed 2026-04-28
ARIA-STORAGE family (6 sub-inventions)
S4
Architectural only · filed, demos queued
MP21 P5 · Filed 2026-04-28
Binôme cooperative computation
S1 + S5
REAL · 3-of-3 consensus
MP19 P88 · Filed
Chain composition (SolarWinds + adjacents)
S5
REAL · toggle mechanic

SCIM-first architectural principle

All free-text → AI surfaces in SoafAii applications route through SCIM (Semantic Confidence Intent Mapping) for analysis, clarification, and brief generation before reaching any generation model. The demo’s single free-text surface is the Section 5 “Try your own scenario” input — that input goes through SCIM’s analyze and brief endpoints with graceful fallback if unreachable.

endpointscim-api.soaf01.workers.dev flowanalyze → clarify → brief filingMP19 P65 · Filed

AI proxy isolation

No browser-to-Anthropic call. Every AI invocation routes through the studio-brain proxy (Cloudflare Worker holding the API key as a Wrangler secret). The model string used by this demo is fixed: claude-sonnet-4-20250514.

endpointstudio-brain.soaf01.workers.dev/ai modelclaude-sonnet-4-20250514 api_key_storageWrangler secret (worker-side)

Runtime health monitoring

REAL · ARIA-H embedded

The Health badge in the header is the SoafAii Health module — aviation-grade tiered reporting (GREEN/AMBER/RED) with fingerprinting, periodic checks, self-healing for DOM regressions, and security isolation. Click the badge or press Ctrl+Shift+Q for the embedded QA panel.

app_idaria-mehler-demo health_workeraria-health.soaf01.workers.dev filingMP19 P85 · Filed

Two-tier guided tour

5-step quickstart · 14-step full

First-launch detection via aria_mehler_tour_seen_v1 in localStorage. Two-tier picker on first launch: 5-step quickstart for the productive-in-five-minutes path, or 14-step full walkthrough for the comprehensive orientation. Re-openable at any time from the (?) help button in the header. ESC or click outside to dismiss.

Filing status summary — portfolio context

As of May 2026 the primitives referenced in this demo are all filed at USPTO at provisional stage. PCT conversions are scheduled across 2026–2027. The applicant at provisional is the inventor personally; assignment to BIS WLL (Bahrain) is scheduled at PCT conversion within twelve months of each filing.

DOCKET NAME STATUS MP21 P1ARIA-AUT Channel Provenance ProtocolFiled 2026-04-27 MP21 P2ARIA-ENC Authenticated Deniable CommunicationFiled 2026-04-28 MP21 P4Internal-Channel Encryption (Binôme)Filed 2026-04-28 MP21 P5ARIA-STORAGE (6 sub-inventions)Filed 2026-04-28 MP20 P92Voxel Embodiment B Granular (physical document)Filed MP20 P94Unified Voxel Authentication FamilyFiled MP19 P88ARIA Multi / Binôme Cooperative ComputationFiled MP19 P85ARIA-H runtime healthFiled MP19 P65SCIM Semantic Confidence Intent MappingFiled MP15 P1Misalignment DetectorFiled FLE-PROSODYEmbodiment G prosody (Track A reserved)Filed

Twenty-one master patents are filed at USPTO across the broader SoafAii portfolio. The list above covers the primitives directly referenced in this demonstration.

Technical infrastructure

app_idaria-mehler-demo deploy_targetCloudflare Pages scim_apiscim-api.soaf01.workers.dev ai_proxystudio-brain.soaf01.workers.dev/ai health_workeraria-health.soaf01.workers.dev cryptoWeb Crypto API (HMAC-SHA-256, AES-GCM, SHA-256) shamirGF(2^8) polynomial interpolation (in-browser) i18nEN · FR · ES · DE themesDark default · Soft earth · Light

Single-file HTML. No external script CDNs at runtime (fonts are the only external dependency). The file works offline once loaded; only the SCIM analyze and AI proxy calls (Section 5 free-text input) require network. All other primitives run entirely in-browser.