Timeline

The timeline is the ordered history of what happened to an entity — intents, events, rule steps, and failures.

When the runtime processes an intent, it records a decision route: which IF branch was taken, whether a lookup matched, what values were written, and which events were emitted. You see not only what changed (the ledger) but why.

request_access
  ✓ access_requested
  ✓ approval_required
  ✓ access_approved
  ✗ notification_failed

That view is what you open after a retrofit — before you fork, replay, or repair. See Replay.

Live inspection requires Causet Cloud (Early access). Browser tutorials show a learning timeline without a deployable runtime. See What runs today?.

Not the same as AI Decisions. Decision routes are runtime forensics for all rule operations. AI Decisions are LLM calls in the DSL. When a rule runs op: decision, that call is one step in the route — not the whole product.

Why it is helpful

Without a decision route, debugging looks like guessing: the entity state is wrong, but you cannot tell whether a condition failed, a lookup returned empty, or a rule block never ran.

Decision routes let you:

Explain behavior — show exactly which rule blocks ran and in what order
Trace branches — see whether an IF took the then or else path and what expression was evaluated
Inspect lookups — confirm a FIND or LOOKUP returned the record you expected
Audit side effects — review each SET, PUSH, or MERGE with the path, new value, and previous value
Catch silent failures — intents that matched no rules still leave a trace, so “nothing happened” is visible instead of invisible
Replay and diff — branch or replay from a cursor in the Decision Log using the same history the runtime recorded

What gets recorded

The runtime always records at least one step per intent — even when nothing matched.

Situation	What you see in the route
Rules ran normally	One step per operation: branches, lookups, writes, emits, AI calls, etc.
No rules matched	A single no-op step marking that the intent committed with no rule effects
Intent rejected	A rejection step with the rejection code and message
Empty commit	A no-op step so the cursor still appears in history

Every step in a route shares the same cursor as the corresponding ledger commit for that entity. That is how you connect “how rules ran” to “what was persisted.”

What each step contains

Each step in a decision route captures a specific kind of information:

Stored as	What it is
Intent type	The action that was submitted (e.g. `CHECKOUT`, `ADD_TO_CART`)
Rule block	The named block in your rules that produced this step (e.g. `RESET_CART`, `APPLY_DISCOUNT`)
Step order	Position in the sequence — step 0, 1, 2, … within one intent
Operation type	The kind of operation: conditional, lookup, state write, emit, block boundary, etc.
Outcome	The result label for that operation — which branch was taken, whether a record was found, etc.
Input	The expressions, paths, and values the runtime evaluated for this step
Effects	The state changes that resulted — field path, new value, previous value, and cross-entity targets where applicable
Intent payload	A copy of what was submitted with the intent
Cursor	The entity’s position in its timeline when this intent committed
Compute usage	Estimated and actual compute units for that step

Effects are the most useful field when debugging wrong state: they show per-step mutations. The ledger stores the merged result of all effects at commit time.

Operation types

During rule evaluation, the runtime labels each step with an operation type and an outcome. Common pairings:

Operation type	Typical outcomes	What happened
Block	Enter / Exit	Start or end of a named rule block — used to group the timeline
If	Then / Else	A conditional branch was evaluated and one path was taken
Find	Found / Not found	A collection lookup succeeded or returned nothing
Foreach	(varies)	Iteration over a collection
Lookup	(varies)	Cross-entity or relationship read
Set, Push, Merge, Filter, …	(effect-specific)	Entity state was mutated
Emit, Emit each	(varies)	A domain event was produced
Decision	(varies)	An AI Decision LLM call ran
No-op	No rules matched	Intent finished with no rule effects
Rejection	Rejection code	Intent was rejected before commit

How the timeline is grouped

In the control plane Decision Log, steps are grouped by intent and rule block so you can read them like nested code:

Intent CHECKOUT

  [RESET_CART]
    SET cart.items → []
    SET cart.view_total → 0

  [APPLY_DISCOUNT]
    IF discount_eligible → then
    SET cart.discount → 10

Block enter/exit markers create these groups. Steps that fall outside a block still appear as their own group.

Internal bootstrap traffic is hidden from the Decision Log — it is infrastructure, not application behavior.

How to use it

In the control plane

Open the Decision Log for your application. Pick a stream, entity, and fork (main by default). You get a scrollable timeline of intents, expandable into rule blocks and individual steps.

From there you can:

Filter by intent type, time range, or cursor range
Open a step to see inputs, outcomes, effects, and a before/after state diff
Search across entities when you have an intent type or error pattern but not a specific entity ID
Replay from a cursor to re-run downstream processing
Branch from a cursor to fork timeline exploration without affecting production

When debugging an intent

Start from the intent ID or find the entity in the Decision Log.
Confirm the intent outcome (committed, rejected, or failed) — see Ledger Events.
Walk the decision route step by step: did the expected rule blocks run? Did the IF take the branch you expected?
Compare effects on the last relevant steps with what appears in the ledger commit at the same cursor.

From the CLI

causet inspect timeline --entity order-123 --stream order_stream

Each timeline step’s id is a decision ID — use it with causet forensics repair-plan when you need to undo that step’s field changes in a sandbox fork.

Common questions decision routes answer

Question	Where to look
Why did nothing happen?	Look for a no-op step — often no rule `when` clause matched the intent type
Why was this rejected?	Rejection step or the last if branch before commit failed
Why is state wrong?	Follow effects on set / push / merge steps — check path and previous value
Why is my event missing?	Find an emit step — if absent, rules never reached emission
Did the AI call run?	Look for a decision step with inputs and effects