Glossary

Quick reference for every term you’ll encounter in Causet. Each entry includes a one-sentence definition, why it matters, and a small example.

Causet

The replay layer for AI agents and backend systems.

Causet is a deterministic compiler and runtime for intents, events, decisions, memories, projections, workflows, queries, forks, replay, and repair.

Intent

A request for something to happen.

An intent is what your application, an AI agent, or a person submits to the Causet runtime. The runtime validates it, runs your rules, and either accepts it (producing events) or rejects it (producing nothing). A rejected intent leaves the ledger unchanged.

Why it matters: Intents enforce your business rules at the boundary. Nothing enters the ledger unless an intent validates and is accepted.

Example: CHECK_IN_TO_SHOW, CANCEL_ORDER, REQUEST_REFUND

See also: Intents

Event

An immutable fact that something happened.

Events are facts, written in the past tense. Once written to the ledger, they are never updated or deleted. Everything downstream — memory, decisions, projections, queries, replays — is derived from events.

Why it matters: Events are the source of truth. If you need to know what happened and when, the event ledger is authoritative.

Example:

events:
  SHOW_CHECK_IN_CREATED:
    state: user
    entity_expr: event.user_id
    payload:
      user_id:  string
      show_id:  string
      venue_id: string

See also: Events, Replay

Agent memory

State an AI agent may use in future interactions.

In Causet, memory is event-driven, not just a blob of embedded text. A memory should have provenance, scope, retention, correction history, and links to the decisions that used it. Declared under memories:, ingested asynchronously from ledger events, and retrieved by similarity search at decision time.

Why it matters: Vector search can retrieve memory. Causet explains why the memory exists, whether it was corrected, and what used it.

See also: Vector Memory, Memory provenance

AI decision

A structured decision made by an AI model, ruleset, or hybrid flow.

A Causet decision includes typed input, retrieved context (memory), prompt/rule version, provider/model metadata when applicable, an output schema, confidence, an emitted event, and an optional human approval or override.

Why it matters: AI output is schema-validated and recorded as a domain event — not a free-text response nobody can audit later.

Example: triage_ticket — retrieves customer_history memory, calls a provider, emits TICKET_AI_TRIAGED.

See also: AI & Decisions, Decision ledger, Support Copilot

Decision ledger

A durable history of decisions, including inputs, context, model/rule execution, outputs, confidence, approvals, overrides, and emitted events.

Every decision Causet executes is recorded in the same timeline as everything else — not a separate, disconnected log.

Why it matters: When a decision needs to be explained to a customer, an auditor, or a regulator, the decision ledger is the answer.

See also: Timeline

Tool call

An external action requested by an agent or workflow — checking billing, issuing a refund, updating a CRM, or calling a payment provider.

Tool calls run as side_effects after the core ledger commit. They are traced in the timeline but not replayed from ledger history the way core rules are, because they are external I/O.

Why it matters: Teams need to inspect what happened before and after external state changed, not just that a call was made.

Human approval

A durable state transition representing a person approving, rejecting, or overriding a decision or workflow step.

A human approval is submitted as an intent, like any other, and recorded as an event linked to the decision it acts on.

Why it matters: Approvals must be durable and replayable — “someone clicked approve” is not an audit trail on its own.

Ledger

The append-only table that stores all events.

The ledger (ledger_events) is the authoritative record of everything that has ever happened in your application. It is never mutated — only appended to.

Why it matters: Because the ledger is immutable, you can always rebuild any derived state by replaying it from the beginning.

See also: Replay

Timeline

The ordered history of events, decisions, memories, approvals, workflow steps, and state transitions for an entity or process.

The timeline is what you inspect when you ask why the system is in its current state, what decision used a given memory, or what would happen if you replayed a sequence differently.

Why it matters: Logs describe what a service said happened. The timeline is the record of how state actually changed.

See also: Timeline

Projection

A materialized read model derived from events.

Projections are the answer to “how do I query my data?” They subscribe to one or more event types and maintain a PostgreSQL table that your app reads from.

Why it matters: Projections decouple your write model (events) from your read model (tables). They can be rebuilt at any time from the ledger and are independently scalable.

Example:

projections:
  user_concert_stats:
    source_events: [SHOW_CHECK_IN_CREATED]
    target:
      table: user_concert_stats
      primary_key: [user_id]
    fields:
      user_id:        TEXT
      shows_attended: BIGINT
    derive:
      user_id:        event.user_id
    mutations:
      SHOW_CHECK_IN_CREATED: { op: upsert, set: { shows_attended: { aggregate: count } } }

See also: Projections

Query

A named, compiled read against a projection.

Queries are declared in your .causet files and compiled to parameterized SQL. Your app calls the query service to execute them against projection tables.

Why it matters: Queries are typed, versioned, and served from a dedicated read path. There is no ad-hoc SQL in your application code.

Example:

queries:
  my_concert_stats:
    from: user_concert_stats
    filter:
      where: { user_id: { eq: input.user_id } }
    input:
      user_id: { type: string, required: true }

See also: Queries

Workflow / saga

A long-running, multi-step process where progress, failures, retries, compensations, and approvals should be durable and inspectable.

In Causet, a workflow is either a saga (a state machine on one entity) or a submit chain (op: submit across entities in side_effects). Progress is recorded in the same timeline as every other state change — there is no separate orchestration engine or disconnected workflow history.

See also: Workflows

Listener

A deterministic, synchronous reaction to an event.

Listeners resolve related entities and mutate them in-process, in the same commit as the event that triggered them. Use listeners when two entities must stay consistent immediately; use projections when eventual consistency is fine.

See also: Listeners

Relationship

A declared edge between entity types.

Relationships are stored and queried as first-class graph data — not ad-hoc join tables in application code.

See also: Relationships

Fork

An isolated branch of state and history used to test changes, replay behavior, debug issues, or verify repairs.

Each entity fork has its own monotonic cursor. main is the production timeline; branches let you explore from a historical point without affecting it.

See also: Forks

Replay

Reprocessing events or timelines to reconstruct state, test new logic, debug behavior, or verify a repair.

Because Causet rules are deterministic, replaying the ledger rebuilds the exact same state it originally produced — or, with corrected rules, shows you what would have happened instead.

Why it matters: Replay is a feature, not a recovery hack. Because events are immutable, any derived state can be rebuilt at any time.

See also: Rebuilding Projections, Replay

Repair

A controlled correction process for bad state, performed after inspection, forking, and replay.

The pattern: inspect the timeline, identify the bad event/memory/decision, fork before the mistake, replay with corrected logic, then apply the verified correction.

Why it matters: Production state fixes should be verified against history, not applied as one-off emergency SQL.

Audit trail

A durable record of the events, decisions, approvals, and state transitions that explain how a system changed over time.

Why it matters: “What happened and why” needs to be answerable after the fact, not reconstructed from memory or scattered logs.

Application state

The durable facts and derived views that describe what an application currently believes to be true.

Two kinds of accumulated state in Causet:

Memory provenance

The origin and history of a memory: what event created it, who or what supplied it, when it changed, whether it was corrected, and which decisions used it.

Why it matters: A memory without provenance cannot be trusted or safely corrected — you cannot tell what would break if you removed it.

Vector database

A system for storing embeddings and retrieving semantically similar context.

Causet does not replace vector databases. It records the state timeline and provenance around memory and retrieval — what created a memory, what decision used it, and what would happen if it were corrected or removed.

See also: Vector Memory

Determinism

The guarantee that the same intent, entity state, and ruleset produce the same result — excluding explicitly modeled side effects such as AI calls or external tool calls.

Causet rules must be deterministic: no now(), no random numbers, no external I/O in preflight or core. Given the same entity state and the same intent, the runtime always produces the same events.

Why it matters: Determinism is what makes replay safe. If rules weren’t deterministic, replaying the ledger might produce different results than the original run.

Idempotency

The property that processing the same event multiple times produces the same result.

The projection worker uses at-least-once delivery — an event may be processed more than once (e.g., after a crash). Handlers must be idempotent so that duplicate processing doesn’t corrupt data.

Why it matters: Causet uses upserts (not inserts) in projections precisely to ensure idempotency.

See also: Idempotency

Snapshot

A cached point-in-time copy of an entity’s current state.

Rather than replaying all events every time a command arrives, Causet stores snapshots of entity state. When processing a new command, it loads the latest snapshot and applies only recent events.

Why it matters: Snapshots keep intent processing fast for entities with long event histories.

See also: Entity State

Cursor

The per-entity lock and position that ensures serial, ordered command processing within a fork.

Before processing an intent against an entity, Causet acquires a cursor lock on that entity. This ensures that two intents against the same entity cannot run concurrently, preventing race conditions.

Why it matters: Per-entity ordering is what makes Causet’s rules deterministic under concurrent load, and what a fork branches from.

Partition

A logical division of the event stream for parallel projection processing.

Events for different entities can be materialized in parallel while preserving order within each entity stream.

Why it matters: Partitioning enables horizontal scale for high-throughput applications.

See also: Projections

DSL

Domain-Specific Language — the .causet YAML files you write.

The Causet DSL is the set of .causet files you write to define your application: state, events, actions/intents, decisions, memories, projections, queries, relationships, listeners, and sagas.

Why it matters: The DSL is compiled into runtime artifacts. You never write SQL migrations for projections by hand — the compiler generates them.

See also: DSL Reference

Compiler

The tool that validates .causet files and translates them into runtime artifacts.

The Causet compiler reads your DSL files and produces causet.runtime.json, causet.projections.json, and optionally causet.decisions.json — the IR artifacts the runtime services load.

Why it matters: The compiler catches errors before deployment — invalid field types, missing event references, undeclared query inputs, non-deterministic expressions. It is your first line of defense.

See also: Compiler Errors Reference

IR (Intermediate Representation)

The compiled output of the Causet compiler — causet.runtime.json, causet.projections.json, and optionally causet.decisions.json.

The IR is what the runtime and projection worker actually load. It encodes your DSL definitions in a format the services can execute without parsing YAML. The decisions IR holds providers, prompts, decisions, and vector memory definitions for op: decision.

Why it matters: The IR is versioned. Multiple forks of an application can run different IR versions simultaneously, enabling zero-downtime deploys.

Runtime

The Causet component that processes intents, runs rules, and writes events to the ledger.

When your app or agent submits an intent, Causet validates it, applies your rules deterministically, and persists the resulting events before returning a response.

Why it matters: Events are durably recorded before projection updates or side effects fan out.

See also: Mental Model, Intents

Handler

The code that processes an event and updates a projection.

Handlers are the functions that run inside the projection worker. They receive an event and apply it to the projection table via an upsert, delete, or replace operation.

Why it matters: Handlers must be idempotent — they may run more than once for the same event due to at-least-once delivery.

See also: Defining Projections, Idempotency

Provider (AI)

A logical name for an LLM backend (executor + model) used by decisions and memory embeddings.

providers:
  reasoning:
    executor: openai
    model: gpt-4o-mini

See also: Providers & Prompts