GDAD
Graph Driven Agentic Development. A project-legibility tool that keeps intent in a human-owned dependency graph, places the invariants where agents work, evaluates evidence while they run, and keeps acceptance human. The rebuild of GDDP.
Why this exists
The goal is one line: make it safe to not be watching.
The first attempt, GDDP, ran on "humans determine what, agents determine how." It got to about 78,000 lines across two repos before I admitted the agents' how had been rewriting the what the whole time. The night that decided it, an always-on agent planned an overnight dispatch, confirmed it was ready, and then didn't dispatch anything. Nothing in the system could tell me that, because a request to dispatch and evidence of dispatch were the same bit of state. The full story is in GDDP became GDAD.
GDAD is the second attempt, with the premise inverted: prevent drift where the work happens, observe what actually gets committed, and never let an evaluator or an executor hold acceptance authority.
What it does
GDAD is a project-legibility tool, not an agent harness. It does four things and refuses to do more:
- Represents intent as a dependency graph. Nodes carry acceptance criteria and depends-on edges. The graph lives in the project repo at
.gdad/, committed next to the code it governs. - Places constraints at the site of work. The invariants are plain-language rules in
AGENTS.md, read by the agent before it writes a line, instead of reconstructed by an evaluator afterward. - Evaluates evidence while the run happens. The evaluator watches commits on the attempt branch, judges which milestones are actually reached at each SHA, and appends typed records. It never halts execution.
- Preserves the human completion gate. Accept, reject, and revoke are the only transitions that write acceptance records. Everything else is derived state.
How it works
Nothing derivable is stored. Node and project YAML carry no status field. gdad status derives each node's state on read from the journal, receipt files, committed acceptance records, and dependency edges: blocked, ready, dispatched, dispatched-without-evidence, unevaluated, failed, needs-graph-change, provisional, accepted.
Machine state lives outside git. Progress is an append-only JSONL journal in ~/.gdad/state/<project>/. Every line carries a timestamp, actor, node, event, and reason. A torn final line is reported and skipped; nothing rewrites earlier lines.
A dependency is satisfied by evidence only. Either a committed acceptance record, or a provisional event whose referenced receipt exists, is a pass, and is the node's latest. A provisional event without a resolvable passing receipt satisfies nothing and shows as a warning.
Acceptance is a self-describing record. Node id, accepted commit, receipt digest and verdict (or evidence: none, stated plainly), operator, timestamp. Committed under the operator's git identity, from an interactive TTY, never by an agent.
Executors are replaceable. GDAD requests execution and reads what gets committed. It does not supervise, retry, kill, or manage worktrees. Pi Agent, Codex, Claude, and Jules are all valid executors because the contract is just a base commit and a branch.
The nine invariants that govern all of this are in AGENTS.md in the repo, written to be read by both the humans and the agents working in it.
Where it stands
GDAD is self-hosted from day one: its own build is the first graph it governs. The seed graph has seven nodes. The bootstrap set, graph-reader, accept, evaluator, and dispatch, is built outside the loop and accepted with evidence: none stated in the record, because nothing pretends an evaluation happened when it didn't. The first integrated proof is a node-drafter attempt run through dispatch, evaluated on its commits, and accepted at the gate.
A hosted Jev shadow evaluator prototype already observes GDDP receipts and answers closed questions about outcomes, intent alignment, and graph integrity with calibrated probabilities. That is the evaluator's likely backend.
The first version
GDDP still exists as evidence and as a working dispatch loop, and most of its ideas survive. The receipt wall, the human-owned graph, SQLite for receipts, executor-agnostic dispatch: all kept. What didn't survive was the two-repo split, the end-of-run receipt as the only evaluator signal, and the assumption that agents are a black box you detect drift in after the fact.
Repos: gddp-config (the human-owned graph) and gddp-runtime (the machinery). Read-only now.