Work Graph

A work graph, also called an execution graph or ledger, is the operational layer under a claim graph: it records who owns which piece of work, which gates are still shut, and what is owed. It is optional. Short serial work does without it, because what can start right now is derivable from the claims themselves. A work graph earns its place when runs are long, when an external gate has to be waited on, or when several writers work at once: none of that state survives being regenerated from scratch each pass.

What runs is the frontier: the claims whose dependencies are all verified, none blocked, none unknown. A blocked claim blocks only the claims that depend on it, which is the practical reason to derive the frontier fresh each pass instead of following yesterday’s plan. Scheduling a dependency graph is ordinary practice; a build system resolves one every time it works out what to recompile. An edge exists only where one job needs something another produced (a file, a result, a decision that has to hold, a gate that has to be open), so the order the steps were written in creates no edge. Parallel workers, called lanes, get disjoint sets of files and processes, because two writers on one file silently overwrite each other. A finished lane is sealed, done but untrusted, and unlocks nothing until a combined pass tests the lanes together.

The failure a work graph exists to prevent is the tracker turning into a second spec. Once a ticket carries a requirement written nowhere else, the product has two definitions of done that can disagree, and the one people read is the one with the checkboxes. So the work graph points at claims and never restates them: an item names the claim it advances, and closing it produces a candidate result, which counts as progress only once it is checked against the claim’s test and recorded.