> ## 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.

# Event

> An immutable record of something that happened.

<Info>**`primitive.event`** — the only source of truth. Every other object in CAST is a projection of the event log.</Info>

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

<Warning>
  **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.
</Warning>

## 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

<AccordionGroup>
  <Accordion title="Proposed — one side initiates">
    `invoice_ingested`, `payment_intent_created`, `trade_message_sent`, `trade_message_viewed`
  </Accordion>

  <Accordion title="Bilateral — the pivot">
    `vendor_confirmed`, `change_requested`, `disputed` — the moment proof is created. A bilateral event requires confirmation from both parties.
  </Accordion>

  <Accordion title="Control — policy evaluation">
    `policy_evaluated`, `auto_approved`, `routed_for_approval`, `controller_approved`
  </Accordion>

  <Accordion title="Settlement — value moves">
    `posting_generated`, `erp_exported`, `payment_settled`
  </Accordion>

  <Accordion title="Case — governed exceptions">
    `case_opened`, `case_escalated`, `case_resolved`
  </Accordion>

  <Accordion title="Vendor — the counterparty's own record">
    `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](/foundations/vendor-event-layer).
  </Accordion>
</AccordionGroup>

## Example

```json A bilateral confirmation event theme={"dark"}
{
  "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.

<Note>
  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.
</Note>

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.