What happens
grapharc.examples.plan_incident is the only shipped registry, and it is built to demo refusal: four chain-shaped kinds, one denied edge. Nothing shipped demos the other half of the planner's contract — a model decomposing one goal into a parallel topology: fan-out from START, a join, a fork, a fan-in.
We built exactly that registry out-of-tree for a demo and a real local model (qwen3:8b) used it well on the first try, proposing 9 nodes with a 4-way parallel evidence pull (pull_logs, pull_metrics, pull_deploys, pull_tickets) joining into correlate, a fork into test_hypothesis + estimate_impact, and a fan-in to write_report — admitted, executed with the pulls genuinely running concurrently, goal_met. The prompt's parallelism paragraph works; there is just no in-tree registry a reader can point --registry at to see it.
Why it matters
Fan-out/fan-in is the reason to use a graph runtime at all — a chain demos nothing LangGraph-shaped. It is also where the governance story gets interesting: per-kind write permissions are what make a 4-way parallel join safe (each branch may only write its own state field, so the join cannot race), and no shipped example exercises that.
What to consider
- Add
grapharc.examples.plan_research (or similar): ~9 investigative kinds, a distinct state field per kind with WRITES scoped one-field-per-kind, a policy-denied kind (page_oncall) for continuity with the incident demo's thesis, and a goal check on the final report field. - Mention it in the README's planner section and the plan cookbook page as the second
--registry target. - A scripted-planner reply that proposes the parallel shape keeps the demo runnable with no model, same as
plan_incident.
Acceptance criteria
grapharc plan "<question>" --registry grapharc.examples.plan_research:build_registry runs to goal_met with the scripted planner, the topology event shows the fan-out/join/fork/fan-in edges, and a test asserts each kind may only write its own field.
What happens
grapharc.examples.plan_incidentis the only shipped registry, and it is built to demo refusal: four chain-shaped kinds, one denied edge. Nothing shipped demos the other half of the planner's contract — a model decomposing one goal into a parallel topology: fan-out from START, a join, a fork, a fan-in.We built exactly that registry out-of-tree for a demo and a real local model (qwen3:8b) used it well on the first try, proposing 9 nodes with a 4-way parallel evidence pull (
pull_logs,pull_metrics,pull_deploys,pull_tickets) joining intocorrelate, a fork intotest_hypothesis+estimate_impact, and a fan-in towrite_report— admitted, executed with the pulls genuinely running concurrently,goal_met. The prompt's parallelism paragraph works; there is just no in-tree registry a reader can point--registryat to see it.Why it matters
Fan-out/fan-in is the reason to use a graph runtime at all — a chain demos nothing LangGraph-shaped. It is also where the governance story gets interesting: per-kind write permissions are what make a 4-way parallel join safe (each branch may only write its own state field, so the join cannot race), and no shipped example exercises that.
What to consider
grapharc.examples.plan_research(or similar): ~9 investigative kinds, a distinct state field per kind withWRITESscoped one-field-per-kind, a policy-denied kind (page_oncall) for continuity with the incident demo's thesis, and a goal check on the final report field.--registrytarget.plan_incident.Acceptance criteria
grapharc plan "<question>" --registry grapharc.examples.plan_research:build_registryruns togoal_metwith the scripted planner, the topology event shows the fan-out/join/fork/fan-in edges, and a test asserts each kind may only write its own field.