From raw EVM execution to reviewable financial evidence.
A fact-bounded view of the infrastructure that exists today, the schemas that connect it, and the Event → Report product flow still being built.
Follow the evidence chain
Start with execution evidence, move through typed contracts and persistence, then see how the planned accounting flow builds on top.
EVM JIT Evidence
Reconstruct traces into deterministic observations with explicit validation and failure semantics.
ExploreSchemas & Lineage
Review the CUE contracts and PostgreSQL boundaries that keep evidence, revisions, and derived records traceable.
ExploreEvent → Report
Understand the planned progression from normalized events to postings, valuations, lots, and reviewer-facing reports.
ExploreHow to read the status labels
The four labels below are the complete vocabulary. Every capability claim on this site uses exactly one of them.
| Label | Meaning |
|---|---|
| Implemented | Code exists on the repository's base branch and a verification command runs against it. |
| Prototype | The component exists but is a static shell — it does not yet perform the function end to end. |
| Planned | A data contract, schema, or design exists. The execution runtime does not. |
| Not verified | Not found during the 2026-07-25 survey of the four repositories below. |
Not verified means, preciselyNot verified means we did not find a working implementation path and verification evidence in the base branches of the four surveyed repositories. It does not mean the capability does not exist anywhere, and it is not a statement about the status of any internal issue tracker.
Where work exists outside the surveyed repositories, it is outside this document's evidence chain, and this site does not cite it as proof. Connecting that work to a reviewable evidence chain is listed under Current Limitations.
The distinction the labels are built to preserve is this one: the existence of a schema, a migration, or a client library is not the existence of a runtime that computes anything. A storage layer that can persist a valuation is Implemented; the valuation engine that produces one is not.
Repositories behind these claims
| Repository | Base branch commit | Role |
|---|---|---|
BackwardLabs/daejang | 21d063f | React product and onboarding UI shell, plus design documents |
BackwardLabs/daejang-jit-engine | 8cb725d | EVM JIT evidence reconstruction, Observation generation, gRPC daemon |
BackwardLabs/schema | 95ed7eb | CUE evidence, ledger, and manifest contracts with validation fixtures |
BackwardLabs/daejang-db | 26904fb | PostgreSQL migrations and artifact/evidence/JIT/ledger/lot storage API |
The four repositories are currently private. A GitHub link to them is therefore not usable as public evidence for a reviewer. Verifying the claims on this site requires either reviewer access or a public source snapshot, neither of which is in place yet.
This is a genuine gap in the submission, not a formality. It is tracked in Current Limitations.
A repository named daejang-engine appears in some earlier internal material. It does not exist in the Backward Labs organization; the product repository is daejang. This site uses the four names above.
Site structure
- Technical Overview — the single page intended as the submission link.
- Implemented Infrastructure — what runs today, in detail, with its boundaries.
- Product Roadmap — what the implemented foundation is intended to connect to. Nothing here is claimed as working.
- Trust — failure semantics, privacy boundaries, the explicit list of claims we do and do not make, how we intend to prove what is still unproven, and what is currently missing.