5-Minute Quickstart

You’ll define a state, an event, an intent, and a query, then run it and inspect the resulting timeline — the same core loop every Causet app uses, whether it’s a support-ticket workflow or an AI agent’s memory.

1. Open the Tutorials

Go to Causet Tutorials. On first visit you’ll land on a page titled “Learn how Causet works” with one guided tutorial available: the Todo List Application.

Click Start Todo List tutorial →.

2. Walk through the guided steps

The tutorial has 7 steps, each editing a real .causet file in a multi-file editor (tabs across the top, just like a real project’s states/, events/, actions/, projections/, and queries/ folders):

Each step tells you exactly what to add before you can continue — you can’t get stuck on syntax you haven’t been shown yet.

3. Compile, run an intent, inspect the timeline

On the last step:

1. Click Run compile / deploy. This compiles your DSL locally (in-browser) and deploys it to the in-memory local runtime.
2. Click Run CREATE_TODO to submit your first intent. A modal lets you set the todo’s ID and title, then submit.
3. Click Run COMPLETE_TODO to submit a second intent against the entity you just created.
4. Use the output tabs below the run panel — Events, Projections, Queries, State, and Timeline — to see exactly what happened: the events that were appended to the ledger, the projection rows that were derived from them, and the query results read back out.

The Timeline tab is the same concept as causet inspect timeline in the real CLI: a deterministic, replayable record of every intent and the state changes it caused.

What you just did

CREATE_TODO intent → rules run → TODO_CREATED event → ledger
                                        ↓
                              projection updated
                                        ↓
                          query reads the projection

This is the same pipeline described in What is Causet? — intent in, deterministic rules run, event recorded, projection updated, query reads it back. Nothing here talked to Causet Cloud or any external service.

The shape of a minimal app

The Todo tutorial uses a todo list, but the same four-file shape works for any domain. Here’s a support-ticket example with the same structure — state, event, intent, projection/query — that you can adapt by pasting into any of the editor’s file tabs in the Tutorials (click Explore freely after finishing the Todo tutorial to load one of the other curated examples as a starting point, then replace its files):

# states/ticket.state.causet
state:
  ticket:
    entity_key: ticket_id
    fields:
      - name: status
        type: string
        default: "open"
      - name: subject
        type: string
        default: ""

# events/ticket.events.causet
events:
  TICKET_OPENED:
    state: ticket
    entity_expr: event.ticket_id
    payload:
      ticket_id: string
      subject:   string

# actions/ticket.actions.causet
actions:
  OPEN_TICKET:
    state: ticket
    entity_id_expr: intent.ticket_id
    input:
      ticket_id: { type: string, required: true }
      subject:   { type: string, required: true }
 
    core:
      rules:
        - name: set_status_open
          when: {}
          then:
            - op: set
              path: /status
              value: "open"
 
    side_effects:
      rules:
        - name: emit_opened
          then:
            - op: emit
              event_type: TICKET_OPENED
              payload:
                ticket_id: intent.ticket_id
                subject:   intent.subject

# projections/ticket.projections.causet
projections:
  tickets_by_status:
    source_events: [TICKET_OPENED]
    target:
      table: tickets_by_status
      primary_key: [ticket_id]
    fields:
      ticket_id: TEXT
      subject:   TEXT
    derive:
      ticket_id: event.ticket_id
      subject:   event.subject
    mutations:
      TICKET_OPENED: { op: upsert }

# queries/ticket.queries.causet
queries:
  tickets_by_status:
    from: tickets_by_status
    order_by:
      ticket_id: asc
    limit: 50

Submitting OPEN_TICKET emits TICKET_OPENED, which upserts a row into tickets_by_status, which the tickets_by_status query reads back — the exact same loop as the Todo tutorial, applied to a different domain. (This minimal version only ever adds tickets; a TICKET_CLOSED event with a delete mutation would remove them from this table when a real status filter is worth adding — see Projections for derive: and aggregate patterns.)

Next steps

• Retrofit an Existing App — primary adoption path
• What runs today? — availability labels
• Quickstart: Concert App — full CLI + Cloud walkthrough (Early access)
• Mental Model
• Install Causet