Objective
Independently determine whether Fractapp's Base-4 integer address can serve as a correct, useful shared structure for byte storage, direct seek, ordered streaming, exact reconstruction, and executable instructions.
The tested machine must preserve this boundary:
canonical identity = exact integer route
geometry = deterministic projection of that route
physical storage = replaceable paged implementation
The linked project contains project-local tests and measurements. Those results are implementation evidence, not an independent Glyphd Labs result. B19 begins at AWAITING_LOCAL_RUN and retains every failure, mismatch, unsupported condition, and comparison loss.
Required suites
A. Version and profile pinning
Record the exact repository commit, production deployment, Fractapp machine version, address profile, page size, storage backend, browser or runtime versions, operating systems, CPU architecture, and corpus digest. A floating branch or unpinned deployment invalidates the run.
B. Address correctness and uniqueness
For a broad object-and-offset corpus, independently verify:
V_next = 4 × V_current + branch for every appended digit;- complete route recovery from each integer;
- a full 256-bit object namespace represented by 128 Base-4 levels;
- a 64-bit byte offset represented by 32 Base-4 levels;
- exactly 160 post-root levels for every reference byte address;
- correct decoding of offsets including
0, page boundaries, 2^32, and 2^64 - 1;
- no address collision in the tested corpus;
- stable parent, child, prefix, depth, and region relationships.
C. Geometry derivation
Independently calculate the dyadic cell selected by each route and compare exact numerators, denominator, displayed location, distance, and rotation.
The integer route remains authoritative. Floating-point display equality is not sufficient proof of identity.
D. Byte write, seek, range, and reconstruction
Write versioned corpora containing:
- empty and one-byte objects;
- structured text;
- random and highly repetitive binary data;
- files crossing one and many 4 KiB pages;
- image, audio, and video samples;
- at least one object near each tested backend's practical size limit.
For each object:
- record the original SHA-256;
- write through the tested backend;
- seek deterministic and random offsets without replaying earlier bytes;
- read ranges crossing page boundaries;
- stream under multiple chunk sizes;
- reconstruct after clearing runtime caches;
- compare every output byte and final SHA-256;
- mutate a page and confirm fail-closed verification.
E. Portable memory packs
Export and import memory packs through a clean backend. Mutate metadata, page order, one raw byte, the claimed object hash, the root address, page count, page size, and duplicate page indexes.
Every mutation must either produce a distinct valid object or be rejected. Silent acceptance is failure.
F. Path-as-data
Encode byte streams directly as Base-4 routes and verify exact round trips, including leading zero bytes and arbitrary binary values.
Report:
- original bytes;
- Base-4 iteration count;
- integer bit width;
- encode and decode distributions;
- memory overhead;
- maximum practical tested path;
- round-trip agreement.
This suite is invalid if exact representation is described as compression. Four Base-4 turns carry one byte and preserve all eight original information bits.
G. Fractal VM correctness
Compile and execute a versioned program corpus covering:
- stack operations;
- integer arithmetic;
- comparisons;
- mutable RAM load and store;
- unconditional and conditional jumps;
- loops;
- emitted bytes and printed integers;
- halt, step-budget, invalid-opcode, stack-underflow, division-by-zero, and out-of-range failures.
Each instruction fetch must be tied to the program object's fractal byte address. Compare output, final stack, RAM snapshot, program counter, step count, and trace against an independent interpreter.
H. Backend and index comparisons
Implement or adapt at least these storage/index baselines over identical bytes and workloads:
- flat byte array or file offset;
- conventional paged file;
- key-value page store;
- B-tree or ordered key index;
- trie or radix tree over the same route digits;
- Merkle DAG or content-addressed block tree;
- Fractapp namespace-plus-offset addressing.
Measure where Fractapp's recursive address carries useful information beyond a flat offset: prefix grouping, hierarchical invalidation, region traversal, sparse allocation, cache partitioning, parallel scheduling, or geometric projection.
I. Streaming and playback
Measure first-byte latency, sustained throughput, memory use, seek latency, and reconstruction latency for text, image, audio, video, and generic binary objects.
Media playback may use an ordinary decoder after bytes are reconstructed or streamed. The original authoring application must not be treated as a required dependency.
J. Persistence, concurrency, and recovery
Run the same corpus through browser IndexedDB, a file-backed implementation, and at least one object-storage or distributed-block prototype.
Test:
- process restart;
- partial write interruption;
- concurrent readers;
- concurrent writes to different objects;
- duplicate content;
- corrupted or missing pages;
- page-size migration without logical-address changes;
- cache deletion and reconstruction.
K. Failure honesty and security
Verify explicit refusal for malformed addresses, invalid branches, negative or overflowing offsets, missing pages, mismatched hashes, oversized browser writes, unsupported programs, step-budget exhaustion, and unavailable storage backends.
Analyze denial-of-service risks from extremely deep path integers, oversized manifests, malicious page counts, and unbounded VM programs.
Required metrics
- address encode/decode agreement rate;
- byte-address depth agreement;
- tested address-collision count;
- exact dyadic-coordinate agreement;
- random-seek accuracy and latency distribution;
- cross-page range-read accuracy;
- stream byte agreement and throughput distribution;
- reconstruction SHA-256 agreement;
- tamper rejection rate by mutation class;
- path-as-data round-trip agreement, time, and memory;
- VM program agreement, output agreement, and failure agreement;
- backend write, read, seek, stream, recovery, and storage overhead;
- cache and prefix locality measurements;
- logical-address stability across physical backend and page-size changes;
- missing-page and invalid-address refusal accuracy.
Invalid conditions
A run is invalid when:
- the source commit, deployment, address profile, or environment is not pinned;
- generated fixture expectations are used as their own independent reference;
- a logical
2^64 offset range is described as available physical capacity;
- Base-4 path representation is described as arbitrary compression;
- only sequential reads are used to support a random-access claim;
- the originating runtime cache is reused for a clean reconstruction claim;
- floating-point coordinates replace the exact integer address;
- one backend's page layout is treated as the canonical byte identity;
- the original authoring application is silently required for byte recovery;
- project-local measurements are relabeled independent reproduction;
- failed, divergent, slow, or memory-exhausting rows are removed;
- repository access control is omitted from the reproduction boundary.
VERIFIED_MECHANISM requires a pinned version, public-safe corpus or releasable receipt projection, independent address calculations, exact byte rows, complete tamper results, at least two physical backends, independent VM comparison, raw artifacts, invalid-condition checks, limitations, and a signed or attributable reviewer receipt.
Claims of superior storage, database, networking, streaming, or compute performance require separate workload-specific comparisons. A correct recursive address alone does not establish market superiority.
