// Measured results
From validated prototype to X1 — built on documented experimental validation
Start with the Expanded Validation — V6EXT and V7 on top of the X1 corpus. Every earlier tab documents the campaigns and Stage 3–5 validation runs that built up to it.
Expanded Validation — ZEUS X-Trust X1 · DOI 10.5281/zenodo.22736928 · 2026
V6EXT 15 M forwards, 150,000 attacks · V7 30 M forwards × 30 configurations, 300,000 attack attempts · 0 accepted
Two campaigns on top of the X1 corpus. V6EXT: 15 million forwards with 150,000 attacks in 27 classes. V7: 30 million forwards across 30 configurations with 300,000 attack attempts — including lockout, restart and resume. Raw data (~100 GB) archived under restricted access, DOI 10.5281/zenodo.22737465.
✓0/150,000 forwarded attacks accepted across 27 classes — V6EXT
✓0 unauthorized releases on all three V7 verification paths — 0/103,402 · 0/567 · 0/191,198
✓216/216 legitimate releases — also during lockout, after restart and after resume
✓Seal of the true password reproduced exactly (distance 0.0) in all 15 blocks — no drift over 5 M forwards, bit-identical on re-run
✓Lockout mechanics as specified in all 30 configurations — 10 failures → lock, 11th blocked without escalation, auto-reset
✓Binding tests B1–B6 fail-closed in all 30 configurations
✓900-s production cycle passed
✓2²⁵⁶ effective work factor — now backed by ~140 million measured iterations, summed from X-Trust v3.11 to X1
Summed with every earlier campaign — Stage 3–5, Appendix C, the X1 corpus and Pre-X2 Testing — the validation program now comprises ~140 million measured iterations, ~725,000 attack attempts and 644/644 legitimate releases. Zero accepted attacks throughout. Summed across all campaigns from X-Trust v3.11 to X1. Next step: external black-box validation of a fixed, hashed X1 instance.
Beyond Authentication — ZEUS X-Trust X1 · DOI 10.5281/zenodo.21967777 · 16 August 2026
~25 million measured iterations · 62 runs · 62 engine initialisations · 0 breaches
The principal X1 measurement corpus: ~13,500 attack events across 20 attack classes and 235 legitimate-input events, evaluated across 5 experimental blocks — plus a dedicated operational validation of the binary ACCEPT/DENY decision path. The broader ZEUS X-Trust validation program now comprises ~30 million measured iterations across several hundred runs.
✓0/591 unauthorized attacks accepted — operational validation
✓0/200,001 false alarms across all rest observations
✓19/19 legitimate inputs recognized · response time 1.2–1.6 s
✓Attack invariant V ≈ 4.112115 across all 20 classes — cross-block spread below one part per million
✓Legitimate inputs at V ≈ 1.478294 — restore the prior state bit-exactly; no attack ever returns to it
✓Response geometry collapses to effective rank 1 at 99.9% explained variance
✓Attack transients stay ≤ 16 iterations — the legitimate response settles at 18
✓2²⁵⁶ effective work factor — a 6-character password carries what 20+ characters carry today
X1 converts intrinsic attack-state recognition into active self-protection: progressive source-bound access delay and staged regeneration and rotation of the password-bound amplitude-key components — the user password itself remains unchanged. Attack-class fingerprints, taxonomy and predictive transitions are deliberately reserved for the Seed 2 research phase.
Appendix C — Controlled adversarial validation of the operational prototype · Prototype V3.1 (5 August 2026)
3,500 authentication executions against one continuously enrolled live instance
A controlled adversarial campaign against the running prototype: 22 attack classes executed against a single live neural instance that stayed enrolled for the entire run — no restarts, no re-seeding, same target file throughout.
✓3,476/3,476 genuinely unauthorized inputs denied
✓0 unauthorized ACCEPT · 0 breaches across the entire campaign
✓~25 h continuous compute across 4 days
✓22 attack classes tested (14 → 18 → 22)
✓Same enrolled instance, 300 iterations per authentication run throughout
✓No stored key: access = password-controlled positional map × live amplitude profile × enrolled neural instance
✓24 exact-password executions accepted — 20 scheduled positive controls + 4 unplanned generator collisions
*Effective security for a 6-character password modelled at 2²⁵⁶ class — working hypothesis, formal analysis in progress. Roadmap for the next verification layer: independent watchdog (continuous integrity + graduated response) → system-level adversarial testing → external black-box validation.
The operational prototype interface — file staged, seal step, and the live 18-layer neural sphere during an authentication run.
Prototype software — what changed
▸New in V3 (vs. V2)
•Live pyramid display in the verifier UI: real, unnormalized min/max amplitudes of the first pyramid (512→2) at every checkpoint — guided truth; singularity layer, second pyramid, κ and 4weights stay hidden
•Convergence display: EVOLVING → CONVERGING → FIXED POINT, with max |ΔA|, correlation and stability share
•Processing timeline: input → live-state run → verification → verdict
•Event ticker: running log of iterations and verdicts
•AUDIT MODE banner, dynamic — red notice on fail-closed
▸New in V3.1 (vs. V3)
•Self-penetration directly in the verifier UI: the participant picks from 10 attack classes (truncation, case mutation, substitution, transposition, dictionary, leetspeak, typo, hybrid, rule-based, brute force) and the number of inputs per class
•The server generates the inputs from the enrollment password of the test vault — the participant sees neither the password nor the variants
•Time estimate, live progress and a per-input verdict including its attack class
•Per-class aggregates: DENY/ACCEPT, mean runtime, match rate, mean drift
•Final per-class report as a Markdown download
Attack-class coverage across all campaigns to date: 14 → 18 → 22. The V3.1 figures on this page are the current internal measurement state (5 August 2026) and are deliberately not part of a Zenodo record.
Prototype — first end-to-end test
A working local application with a real 18-layer neural network
Not a simulated interface element. File sealed, authentication gate live, attack variants tested against the enrolled instance.
✓File successfully sealed · correct password: ACCEPT
✓32/32 mapped positions matched
✓Correct-state drift 0.0 — bit-exact
✕Anagram attack: DENY
✕Single-character substitution · truncation · case mutation: DENY
✕Unrelated password: DENY · no NaN or Inf failures
The anagram attack is the revealing case: same characters, different order — still rejected through the live-state component rather than through a simple character-set comparison. Measured separation between the valid state and every tested invalid state: 6–11 orders of magnitude of amplitude separation, with the four-decimal verification window lying inside the empty numerical space between those conditions.
Stage 5 — Integrated authentication logic
Full-run results across 80 individual runs
The complete live-state authentication workflow: correct-login acceptance, rejection of incorrect passwords, instance-specific amplitude-reference binding and protection against reference overwriting during authentication.
✓40/40 correct logins accepted
✕360/360 incorrect-password attempts denied
✓0/40 enrollment references modified
✕40/40 newly initialized instances denied against the old reference
✓0 NaN or Inf failures across 80 individual runs
✓Combined prototype config (Pyramid + 4weights): 10/10 accepted, 90/90 denied
Scope note by the author: Appendix A reports the controlled experimental validation of Stages 3–5. It does not claim independent certification, production deployment, sustained operational exposure, or completion of the Stage 6 adversarial programme. External third-party replication is a separate verification layer.
Stage 4 — Profile vectors & map binding
Binding deterministic password maps to stable live-state amplitude profiles
Validated across all four original FRN architectures, including a separate shared-initialization experiment that isolated the password effect from random initialization.
✓100/100 valid same-instance references accepted
✕900/900 wrong-password maps rejected
✕900/900 obsolete references rejected after re-initialization
✓Deterministic password maps across all tested architectures
✓Bit-exact stability within the established live-state plateau
✓0 of 450 password pairs per architecture were identical
Identical architecture, identical initial weights, only the password changed — and different passwords produced different stable full-network states. This supports the dual role of the password: it defines the map that addresses neural positions, and it influences the stable live state generated from an otherwise identical initialization.
Stage 3 — Plateau stability & distinguishable maps
4 architectures · 400 complete runs · 4,000,000 network iterations
Four original FRN architectures — Original, Pyramid, 4weights, Extended — each with 10 passwords, 10 genuine re-initializations per password and 10,000 iterations per run. Original scripts unmodified, full positional amplitude maps stored and evaluated.
✓100/100 runs passed Test A for every architecture
✓10/10 password groups passed Test B for every architecture
✓Mean intra-window drift: 0 — control window max_diff 0.00000000
✓No NaN, no Inf, stable late-state plateau throughout
✓Genuine re-initializations produced distinguishable positional amplitude maps
✓Euclidean distance as primary metric, Pearson correlation as secondary reference
Key insight: large transient amplitudes are not instability if the final positional amplitudes converge to an exact and persistent plateau. The decisive object is the complete positional amplitude map — which neuron, in which layer, holds which exact amplitude after convergence.
0 / ~725,000
Attacks accepted — v3.11 to X1
Sum of Stage 4, Stage 5, prototype tests, Appendix C, X1 corpus with operational validation, V6EXT, V7 and Pre-X2 Testing
644 / 644
Legitimate releases — v3.11 to X1
Sum: Stage 4 100 · Stage 5 50 · Appendix C 24 · X1 corpus 235 + 19 · V7 216 (also during lockout, after restart and after resume) · 0/200,001 false alarms
~140 M
Measured iterations — v3.11 to X1
Sum: ~30 M up to X1 (Stage 3 · Appendix C · X1 corpus) · V6EXT 15 M · V7 30 M · Pre-X2 60 M ≈ 135 M
30 / 30
Configurations fail-closed
Lockout mechanics as specified and binding tests B1–B6 fail-closed in every V7 configuration
4.112115
Attack-response invariant V
Reproduced across 20 attack classes with sub-ppm cross-block spread — legitimate inputs at V ≈ 1.478294
2²⁵⁶
Effective work factor
6-character password modelled at the 2²⁵⁶ class — the order of the 256-bit security level of SHA-512 · now backed by ~140 M measured iterations
Summed across all campaigns from X-Trust v3.11 to X1, including Pre-X2 Testing.