Fractapp Executable State Resolver
An external reference prototype for sealed origins, executable state addresses, deterministic replay, and result commitments
Operate the live prototype or inspect its canonical source.
Fractapp is maintained in its own repository and deployment. Glyphd Labs links to the source of record rather than copying or silently forking it. The live application is public; the GitHub repository is access controlled and requires authorization from its owner.
Evidence state: IMPLEMENTED. The linked project contains its own evidence harness, but Glyphd Labs has not yet promoted those rows to independent reproduction. B19 preserves the clean-profile, cross-runtime, tamper, remote-resolver, prefix-work, and economic checks required for that review.
Purpose
Fractapp is a working external prototype for a specific Address & Locality question:
Can a digital state be addressed by the exact machine, sealed external origins, executable branch path, and expected canonical result—then reconstructed and rejected when those commitments do not match?
The prototype separates the Base-4 topological path from irreducible external media. It seals imported or authored inputs into an ordered Origin Register, commits the generated canonical scene, produces an executable state:// / x-route:// address, clears transient materializations, and resolves the state again.
Operate and inspect
The repository is intentionally linked rather than copied into Glyphd Labs. Authorized reviewers can inspect the implementation, evidence harness, architecture document, and revision history at the source. Public visitors may operate the live deployment without receiving private repository access.
Current implementation evidence
The linked repository currently records the following bounded findings for its shipped engine and local evidence harness:
- repeated execution produced stable recipe and result commitments across separate processes;
- deliberate result, route, and engine-identity mutations were rejected;
- imported Origin Packs revalidate raw bytes, capsule leaves, and the ordered Merkle root;
- a clean process reconstructed the same committed Scene Manifest and result commitment from an exported pack;
- recipe-keyed final-result caching produced a substantial local lookup advantage;
- the executable address was smaller than the canonical vector output for the tested corpus.
The institute records the artifact as IMPLEMENTED, not independently reproduced. The existing measurements were produced inside the Fractapp project and have not yet completed the separate B19 review protocol.
Known limitations
- The current production deployment commits a canonical scene description rather than promising identical GPU pixels across every browser and device.
- The engine identity in the currently deployed version is not yet a complete immutable package hash over every executable dependency.
- Route-prefix scheduling is visible, but measured prefix checkpoint reuse is not established in the currently deployed version.
- Storage and egress figures are workload-specific models, not general proof that recomputation beats storage.
- A compact address cannot replace irreducible photographs, recordings, measurements, or arbitrary information; those origin bytes remain required.
- The repository is access controlled, so outside source review requires explicit authorization from the owner.
Review path
B19 defines the next independent review sequence:
- pin the exact repository commit and production deployment;
- reproduce canonical-state identity in a fresh browser profile;
- mutate origin bytes, capsule leaves, route state, and result commitments;
- compare Chromium, Firefox, and WebKit canonical outputs;
- execute the same pack on a resolver outside the originating browser;
- measure cold, warm, and shared-prefix work without simulated savings;
- publish complete raw artifacts, failures, environment, limitations, and a receipt.
Until that review completes, this page is a durable test entry point—not a claim that Fractapp has replaced databases, storage systems, or distributed compute infrastructure.