Mental Model

Causet is a deterministic state runtime for important workflow state.

Your app submits intents. Causet records events. Queries and projections expose current state. The timeline can be inspected, forked, replayed, or repaired.

Causet sits beside your existing app. It does not replace your frontend, database, queue, or services.

The loop

Existing endpoint / webhook / job / agent
        ↓
     Intent          (requested action)
        ↓
     Events          (what happened)
        ↓
     State           (durable workflow state)
        ↓
  Projection / Query (what the app reads)
        ↓
     Timeline        (full history)
        ↓
 Inspect · Fork · Replay · Repair

State

State is the durable workflow state for an entity — the current truth Causet maintains from events.

For an access request entity ar_123:

You do not UPDATE this row from the API route. Intents and events produce it.

See State.

Intent

An intent is a requested action — a command your app (or agent, or human) submits.

Examples:

• request_access
• approve_access
• record_payment_dispute
• escalate_ticket

actions:
  request_access:
    state: access_request
    entity_id_expr: intent.request_id
    input:
      request_id: { type: string, required: true }
      email:      { type: string, required: true }
      reason:     { type: string, required: true }

Your endpoint validates HTTP input, then submits the intent. Causet owns what happens next.

See Intents.

Event

An event is something meaningful that happened — an immutable fact on the ledger.

Access-request events might look like:

access_requested
approval_required
access_approved
notification_sent
notification_failed

Events are past tense. They are never edited. Projections, queries, and repair all derive from them.

See Events.

Query

A query is a named way to read state — usually against a projection.

queries:
  access_request_status:
    from: access_request_status
    input:
      request_id: { type: string, required: true }
    where:
      request_id: { eq: input.request_id }

Your app can keep reading its own tables, or call Causet queries, or both. Causet does not force a frontend rewrite.

See Queries.

Projection

A projection is a view of state for the app — a read model derived from events.

Example: access_request_status table with request_id, status, updated_at.

Because projections are derived, they can be rebuilt. If a notification failed and the status row is stale, you fix the handler or replay — you do not invent a one-off SQL patch as the long-term strategy.

See Projections.

Timeline

The timeline is the full history of state transitions for an entity (or workflow).

When something looks wrong, open the timeline:

request_access
  ✓ access_requested
  ✓ approval_required
  ✓ access_approved
  ✗ notification_failed   ← here

You see what completed, what failed, and in what order — not a pile of unrelated log lines.

See Timeline.

Replay

Replay means re-running from recorded state/events — rebuild a snapshot, re-process projection handlers, or re-evaluate rules on a fork.

Use replay when:

• a projection is wrong after a bug fix
• you need state at a past cursor
• you want to verify corrected logic before touching production

See Replay.

Fork

A fork is a branch from a known point in the timeline.

Use a fork to:

• try a repair safely
• test new rules against real history
• simulate “what if we had sent the notification again?”

main stays production. The fork is the sandbox.

See Forks.

Repair

Repair means correcting state safely after failure — usually after inspect → fork → replay → apply.

Example failure:

1. Request submitted
2. Approval succeeded
3. Notification failed
4. Projection still says pending_notification
5. Developer inspects timeline
6. Developer replays the notification step or repairs the projection

Repair is a supported workflow, not an emergency UPDATE in production with no history.

See Replay and repair.

Access request, end to end

Same mental model for payment disputes, support escalations, and AI agent decisions — only the events change.

AI is additive

Causet is useful anywhere state changes matter. AI agents make the problem worse because decisions, memory, tool calls, and side effects need to be inspectable.

AI is not the only use case. It is the sharpest version of the problem.

Causet gives backend workflows and AI agents the same thing: a durable, replayable timeline of meaningful state changes.

See AI in Causet.

Next steps

1. What runs today?
2. 5-Minute Quickstart
3. Retrofit an Existing App
4. When Not to Use Causet