Persistence, Revision & Lineage
Implemented — BackwardLabs/daejang-db @ 26904fb
PostgreSQL DDL, migrations, and a public Go client are implemented. The storage layer preserves revisions, lineage, outcomes, and failure states rather than overwriting them.
Storage areas
| Area | Contents |
|---|---|
| Artifacts | Content-addressed artifacts with reference and pin metadata |
| JIT | Runs, command queue, candidate outcomes, inclusion revisions, execution cache, outbox |
| Subject evidence | Evidence fragments, observations, dispositions |
| Chain and source evidence | Evidence bundles with lineage and revisions |
| Ledger | Assertions, hypotheses, interpreted events, event revisions |
| Postings | Legs, postings, valuations, reconciliations |
| Lots | Lot runs, allocations, basis, current pointer, outbox |
Public Go packages
| Package | Scope |
|---|---|
artifactstore | Content-addressed artifacts and pinning |
evidencestore | Chain and source evidence bundles, lineage, revisions |
jitstore | JIT runs, command queue, candidate outcomes, execution cache |
ledgerstore | Assertions, hypotheses, interpreted events, postings, valuations |
lotstore | Lot runs, allocations, basis, current pointer |
The distinction that matters most
The presence of ledgerstore and lotstore does not mean an Event engine or a lot calculation engine exists.
The database can store an economic Event, a Posting, a valuation, and an acquisition cost. It does not compute any of them. The runtimes that would produce those values are Planned — see Event, Posting & Valuation and Tax Inventory & Report.
This is the most common way to misread the repository, so the site restates it wherever the ledger and lot packages appear.
Content addressing
Artifacts are addressed by the SHA-256 of their content. Public execution artifacts contain provider execution evidence only — they must not include subjectId, account IDs, or ownership windows. This is what allows the same execution artifact to be shared across multiple users' accounts without exposing the relation between them. See Security & Privacy.
Revision and lineage
Revision handling is what makes a result explainable after it changes:
- Inclusion revisions record reorg history rather than replacing the previous inclusion.
- Evidence bundle lineage links a bundle to what it supersedes, and why.
- Outcome persistence stores terminal states, including failures, so coverage is derived from stored outcomes rather than recomputed optimistically.
- Outbox tables on the JIT and lot paths support reliable downstream delivery without dual-write inconsistency.
Together these support the revision integrity principle described in the Technical Overview: when input, policy, or judgment changes, a new revision is produced with its cause recorded, rather than a prior result being overwritten.
Verification
make check, go test ./..., go vet ./..., and go build ./... pass on the base branch.
PostgreSQL integration tests only execute when DAEJANG_DB_TEST_POSTGRES_URL — or a ledger-specific URL — is set in the environment. The passing results above therefore do not demonstrate live PostgreSQL integration.
A reproducible demonstration of JIT → schema validation → PostgreSQL persistence is listed as required evidence in Current Limitations.