Evidence & Ledger Contracts
Implemented — BackwardLabs/schema @ 95ed7eb
The schema is the shared language between Daejang's evidence, interpretation, accounting, and reporting layers. It defines what each record means, how records refer to one another, and which conditions must hold before a result can be treated as complete.
It does not calculate economic meaning, value assets, or generate a tax report.
Why this layer exists
A final number is not enough. A reviewer also needs to know:
- which source and evidence the number came from;
- where an observed fact ended and an interpretation began;
- whether anything was unsupported, incomplete, or unresolved; and
- which revision and policy produced the result.
The contracts keep those links explicit so later stages can add meaning without replacing the original evidence.
Data model at a glance
This is a meaning model, not a runtime sequence or service topology. A record may stop early when it is not economically relevant, lacks evidence, or does not require valuation or inventory processing.
| Layer | Question it answers | Current boundary |
|---|---|---|
| Source & Evidence | What did the source actually contain or execute? | EVM evidence path Implemented |
| Observation | What can be stated without economic judgment? | JIT Observation path Implemented |
| Interpretation | What economic event best explains the facts? | Contracts implemented; runtime Planned |
| Ledger | How should movements, value, and basis be represented? | Contracts and storage boundaries implemented; calculation runtime Planned |
| Report | How can a reviewer retrace a presented figure? | Manifest contract implemented; report generator Planned |
Four rules the contracts preserve
1. Preserve the evidence
Public chain execution and a user's account relationship are stored as different concerns. The same transaction evidence can support more than one account-scoped Observation without duplicating or changing the public fact.
2. Separate observation from interpretation
An Observation records what was directly seen. Labels such as swap, self-transfer, reward, or taxable disposal belong to a later interpretation. This prevents uncertain meaning from being written back as if it were a source fact.
3. Keep gaps and uncertainty visible
Every selected item must reach an explicit result such as normalized, unsupported, failed, or not relevant. Missing evidence remains missing; unknown basis remains unknown. Summary counts are derived from those outcomes rather than entered separately.
4. Correct by revision, not replacement
Validated records are not edited in place. A correction creates a new revision that points back to what it supersedes. Historical results therefore remain reviewable against the evidence and rules available at that time.
What is implemented
The repository contains CUE contracts, valid examples, invalid and mutation fixtures, and validation commands that check record structure, cross-record references, completeness, and publication evidence.
This proves that the shared data contracts and validation rules exist. It does not prove the runtime behavior of an RPC parser, database, interpretation engine, valuation engine, tax inventory, or report generator.
For runtime behavior, continue with JIT Evidence Reconstruction, Persistence, Revision & Lineage, and Event, Posting & Valuation.
Verification
make check passes against the origin/main archive.