// Measured results
A fully tested prototype — built on documented experimental validation
Start with Appendix C — the completed adversarial validation of the running prototype. Every earlier tab documents the Stage 3–5 validation runs that built up to it.
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.
3,476/3,476
Unauthorized inputs denied
0 breaches across 22 attack classes, ~25 h continuous compute — Appendix C
6–11
Orders of magnitude
Amplitude separation between the valid state and every tested invalid state
~6 M
Network iterations (estimated)
Estimated cumulative total across all campaigns to date — Stage 3 alone is documented at 4,000,000
1,300+
Denied attempts
900/900 wrong-password maps, 360/360 wrong passwords, 40/40 stale instances
0
NaN / Inf failures
Numerically clean across every documented validation run