Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.cast.digitalfinancehq.com/llms.txt

Use this file to discover all available pages before exploring further.

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
DR/CR   ACCOUNT                       DEBIT        CREDIT
Dr      6100 · AP / inventory inbound 47,200.00    —
Cr      2000 · Accounts payable       —            47,200.00

Supported by: wo_8fa2c1 (confirmed)
Lineage:      7c0d…b48a
Every line traces back to the bilateral event. When the auditor asks, the answer is one click — no reconstruction.