State & Memory — Concept

Entity state is the current snapshot of one entity instance — what entity.inventory.gold resolves to during rule evaluation.

Application memory is entity state that accumulates over time: concert counts, top artists, distance traveled — built by core rules on each relevant event, not set by hand.

Entity state

• Defined in state: blocks in .state.causet files
• Stored in entity_snapshots (per fork schema)
• Updated synchronously when core rules run (set, add, push, …)
• Read in preflight via LOOKUP_FIELD and in rules as entity.<path>

Application memory

Same storage mechanism as entity state — the distinction is intent:

Memory accumulates through core rules:

core:
  rules:
    - name: increment_concert_count
      when: {}
      then:
        - op: add
          path: /concert_count
          value: 1

Why event-sourced memory matters

• Rebuildable — replay ledger_events to any point in time
• Auditable — every change has a committed event
• Deterministic — same events + rules → same snapshot
• Tenant-isolated — per-fork PostgreSQL schema

Snapshots vs projections

Next steps

• Entity State — DSL reference
• Application Memory — building context
• Examples — concert-app fields