State & Memory Overview
Causet models two related concepts: entity state (what rules read and write during an intent) and application memory (accumulated history on an entity over time). Both are derived from events — neither is manually patched in application code.
The derivation chain
Entity snapshots update synchronously on the write path. Projection tables update asynchronously.
Declaring state
# app.causet
includes:
states: [./states/**/*.state.causet]state:
user:
entity_key: user_id
fields:
- name: concert_count
type: int
default: 0
- name: following_count
type: int
default: 0In this section
| Page | What it covers |
|---|---|
| Concept | Entity state vs application memory |
| Entity State | Field types, paths, state: DSL |
| Application Memory | Accumulated context from events |
| User Memory | Preferences, history, statistics |
| Derived State | Why all state is derived |
| Event-Sourced State | Pattern and trade-offs |
| Rebuilding Memory | Replay to reconstruct snapshots |
| Best Practices | Paths, defaults, _tmp/ |
| Examples | Concert-app memory patterns |
Next steps
- Intents — rules that mutate entity state
- Replay — source of truth for replay
- Entity State — field reference