Fractapp Executable State Resolution Benchmark Contract
Objective
Independently determine whether Fractapp can bind an exact executable state to its engine identity, active sealed origins, Base-4 route, canonical Scene Manifest, and expected result—then reproduce or reject that state across clean environments without relying on the originating browser's transient memory.
The linked project contains its own evidence harness. Those rows are useful implementation evidence but do not become an independent Glyphd Labs result merely by being linked. This contract begins from AWAITING_LOCAL_RUN and preserves failures, mismatches, and unsupported claims.
Required suites
A. Commit and deployment pinning
Record the exact repository commit, production deployment, engine identity, protocol version, Origin Pack format, browser versions, operating systems, and test corpus digest. A floating main branch or unpinned deployment invalidates the run.
B. Canonical-state replay
Create states containing procedural content, authored text, pointer strokes, imported files, and at least one image. Export each pack, erase browser storage, import into a clean profile, resolve, and compare:
- active Origin Root;
- recipe commitment;
- Scene Manifest commitment;
- result commitment;
- ordered active origin indexes;
- route and operation program;
- canonical viewport and composition fields that the tested version claims to bind.
C. Tamper rejection
Mutate one field at a time while retaining all unrelated fields:
- raw origin byte;
- capsule content;
- claimed origin leaf;
- ordered Merkle root;
- route branch;
- operation program;
- engine identity;
- expected result commitment;
- manifest placement or transform field where supported.
Every mutation must either produce a new identity or be rejected. Silent acceptance is a failure.
D. Cross-runtime determinism
Run the same canonical corpus in pinned Chromium, Firefox, and WebKit environments. Compare canonical objects and commitments rather than assuming pixel identity. Any runtime-specific decoder, floating-point, font, color, or serialization dependency must be reported explicitly.
E. Independent resolver
Resolve the exported pack in a process that has no access to the originating browser's memory, IndexedDB, localStorage, decoded images, or materialization cache. The resolver must obtain the exact engine version and independently reproduce the expected canonical commitments.
F. Cache and prefix behavior
Measure cold execution, exact recipe-key cache hits, and shared-prefix child execution. A planner message is not evidence of saved work. Prefix reuse counts only when measured executed work decreases while the final state remains identical.
G. Address and materialization size
Compare the executable address with the exact canonical object it regenerates, both raw and under a declared compression method. Report the one-time engine and dependency transfer separately. Do not compare against arbitrary-resolution raster exports unless the raster contract and resolution are part of the claim.
H. Storage and compute tradeoff
Use measured execution, measured payload sizes, explicit request billing, storage prices, transfer prices, cache hit rates, and workload read frequency. Report the crossover surface rather than one universal savings number.
I. Failure honesty and access boundary
Verify that missing origin bytes, unavailable engines, unsupported addresses, private repository access, unavailable external services, and version drift produce explicit blocked or unsupported states. A public link to an access-controlled repository is not proof of public reproducibility.
Required metrics
- canonical replay agreement rate;
- manifest commitment agreement rate;
- result commitment agreement rate;
- tamper rejection rate by mutation class;
- cross-browser divergence count;
- clean-resolver agreement rate;
- cold execution distribution;
- exact-cache lookup distribution;
- actual prefix steps or operations skipped;
- address bytes;
- canonical output bytes raw and compressed;
- engine and dependency bytes;
- transfer and storage cost assumptions;
- crossover bandwidth and read-frequency surfaces;
- missing-origin and missing-engine refusal accuracy.
Invalid conditions
A run is invalid when:
- the source commit or deployment is not pinned;
- the same browser profile or materialization cache is reused for a clean replay claim;
- GPU pixels are treated as canonical without a pinned rasterizer and color contract;
- an engine descriptor string is treated as the exact executable package without qualification;
- simulated prefix savings are reported as measured work reduction;
- origin bytes are omitted from media-bearing state costs;
- arbitrary information is described as compressed into a short route;
- modeled cloud economics are labeled measured production savings;
- failed or divergent cases are removed;
- repository access control is omitted from the reproduction boundary.
VERIFIED_MECHANISM requires a pinned version, a public-safe corpus or releasable receipt projection, clean-profile replay, independent resolver agreement, complete tamper rows, cross-runtime results, raw artifacts, invalid-condition checks, limitations, and an independent reviewer receipt.
A claim that the architecture generally replaces databases, storage, networking, or cloud compute requires separate workload-specific studies. No such universal claim is promoted by this contract.
