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.

lineage() — a function over the five objects, not a sixth primitive.
Lineage is the immutable hash chain that links a posting back through the events, decisions, and policy version that created it. Because the chain is append-only and each link references the prior one, verifying a payment’s full history becomes fast and reliable.
Model lineage as a property of the chain — never as a sixth box beside Event, Policy Version, Work Order, Posting, and Case. It is what connects them.

Independent replay

The defining feature of lineage is that any third party can verify it without contacting either counterparty — using only the database rows, the committed canonicalizer source, and a standard cryptographic library.
verify.ts — independent replay
// Any third party, no counterparty contact
const ok = await replay(eventId);

// Standard libs only — no proprietary verifier
// - SHA256(canonicalize(payload, v1))
// - ECDSA-P256 signature check
// - X.509 chain validation

return {
  valid: ok,
  proves: "both parties confirmed",
  at: "signed timestamp",
  unmodified_since: true,
};

Why the proof is the asset

A signature must still verify years later, even after the schema has gained new fields. CAST signs canonicalized hashes, not rows — so a 2026 signature over a payment still verifies in 2031. The canonicalization rule for each version is committed to the repository with a version tag, so anyone can reproduce the exact bytes that were signed.
Every posting is traceable back through the events, decisions, and policy version that produced it. That traceability is what makes a transaction insurable, financeable, and survivable in audit. The subscription fee is the cost of producing this verifiable record.

The economics of verifiable proof

Why value accrues to whoever can underwrite the output.