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.event — the only source of truth. Every other object in CAST is a projection of the event log.
An event is an immutable record of something that happened. Proposed events come from one side; bilateral (mutual-authorization) events require confirmation from both parties.

​
Constraint

Append-only. No updates. No deletes. Ever. Every state transition appends a new event — it never overwrites a prior one. A correction is a new event, not an edit.

​
Why it matters

The event log is the system of record. If every other table were deleted and the log replayed, all other objects would reconstruct exactly as they were. The audit trail is not a byproduct of the system — it is the primary output.

​
Event categories

invoice_ingested, payment_intent_created, trade_message_sent, trade_message_viewed
vendor_confirmed, change_requested, disputed — the moment proof is created. A bilateral event requires confirmation from both parties.
policy_evaluated, auto_approved, routed_for_approval, controller_approved
posting_generated, erp_exported, payment_settled
case_opened, case_escalated, case_resolved
vendor_portal_accessed, vendor_confirmation_viewed, proof_export_requested, proof_export_generated, proof_export_shared, vendor_trust_tier_updated, vendor_network_milestone — the events behind a vendor’s portable proof history. See the Vendor Event Layer.

​
Example

A bilateral confirmation event
{
  "event":        "bilateral.confirmed",
  "work_order":   "wo_8fa2c1",
  "payload_hash": "3a9f…e21b",
  "signature": {
    "method":  "webauthn-p256",
    "bound_to": "payload_hash",
    "signer":  "agent_riverdale"
  },
  "policy_version": "POL-v4.2",
  "lineage_hash":   "7c0d…b48a"
}

​
Who the event belongs to

Every event carries a non-nullable agent_id — the agent responsible for the event’s existence. In the current build, a bilateral.confirmed event is born only at the moment the seller signs it, so its agent_id is the seller who finalized it. Future event types may be buyer-authored, in which case the agent_id is the buyer’s. The principle is constant: the event records which agent brought it into being, not merely that some action occurred.
This is stronger than “no anonymous writes.” It ties every event to a specific, enrolled signer whose key is on file — which is what makes a confirmation non-repudiable rather than just attributed.
Every event also declares its actor mode — human, agent, system, or counterparty — and names the accountable human owner whenever the action can change financial state.