Skip to main content
primitive.posting — the journal-ready output. “Ledger” is the layer; Posting is the object.
A posting is a journal-ready ledger entry, created only after mutual authorization is complete. It carries the full history back to the original event.

​
Constraint

A posting cannot exist without a completed mutual-authorization record. This is enforced as a non-nullable foreign key to the bilateral event — at the schema level, not in application code. A posting with no co-authored event behind it cannot be inserted.

​
Why schema-level enforcement

Application code changes weekly. Schemas change rarely. By the time an auditor inspects a 2026 transaction in 2031, the application that ran in 2026 may not exist — but the constraint will. A future verifier reading the database alone must be able to confirm that every ledger entry reflects co-authored reality. That is only possible if the rule lives in the schema.

​
Example

JE-2026-04-0618 — supported by a confirmed bilateral event
Every line traces back to the bilateral event. When the auditor asks, the answer is one click — no reconstruction.