ZizkaDB bets agent debugging on edges you declare, not spans you read

The interesting part of this design is where the labour moves. In ZizkaDB the causal edge is not discovered, it is asserted: `db.log()` hands back an `event_id` and you pass that value as `parent_id` on whatever event it caused ^[5]. The post is explicit that `parent_id` is optional ^[4], and nothing in it suggests the store can reconstruct a link you did not supply. An event logged without one is a root with no history behind it.

That gives you the arithmetic for the whole feature. The walkthrough's example is three events carrying two edges ^[6]; a linear chain of n events needs n-1 correct parent references, every one of them typed at the call site ^[15]. `why()` is cheap to run because somebody already paid at write time ^[7]. The cost does not disappear, it relocates to the least reliable place in the stack, which is a developer under deadline deciding whether this particular log line needs threading.

It is worth looking closely at what `why()` actually returned in the modelled incident. It surfaced that `search_policy_docs` had pulled an outdated FAQ chunk rather than the current policy ^[8]. But that same chunk name is sitting in the `tool_call` payload in the replay output as well ^[10]. The fact was already logged. What the edge bought was reachability from the failed response backwards, without a human scanning the session and inferring causation, which is the exact gap the post says span trees leave open ^[3].

The stateless SDK reinforces the point rather than softening it. Passing `agent`, `session_id` and `event_id` explicitly on every call avoids hidden global state and is meant to hold up across multiple agents and worker processes ^[11]. It also means the ids have to travel through your own function signatures and across process boundaries. The completeness of the graph becomes a property of your call plumbing.

Scale is the awkward bit. The sample session runs from `session_start` at 14:01:58 to the assistant response at 14:02:12, about fourteen seconds with a single tool call ^[10][14]. At that size you can read the log with your eyes. The graph earns its keep on sessions long enough that scanning fails, and those are the same sessions where a hand-passed parent id is most likely to have been dropped somewhere in the middle.

One source, and it is a walkthrough written to demonstrate the database, with the incident described as modelled rather than reported ^[8]. The post says it covers two features, causal lineage and session replay ^[16]; drift detection against a baseline is listed in the pitch ^[2] but is not what gets demonstrated. Standing up a local instance is a clone plus a quickstart script, with the API on port 8000 and a dashboard on 3001 and no signup for local development ^[12], against an SDK pinned at 0.2.7 or later ^[13]. Cheap enough to try on one agent. The question that matters is not whether `why()` works on three events, it is whether the parent ids survive contact with a codebase nobody is watching.