The work is a graph. Truth is not a task list.

A coding agent can make a feature run in one session. Long-running engineering fails at a different boundary. The agent has to preserve what the product is supposed to mean while code, evidence, dependencies, reviewers, and human decisions keep changing.

That creates harder questions than whether the latest test passed. Which authority defined the behavior? Which exact snapshot did the test inspect? Can a valid artifact be replayed in the wrong session? Did a parallel worker finish a branch, or did the product actually integrate it? Can a later finding reopen something everyone had called complete?

Graph Climbing is the control system that grew out of answering those questions during the DACS Forge build. It separates durable product truth from temporary execution scheduling, then binds every completion claim to evidence from an exact snapshot.

A task list cannot own product truth

A task records work someone intends to perform. A product claim states something that must be true after the work is finished.

Those are different objects. “Implement settlement” is a task. “A completed delivery cannot become visible until every required settlement has been independently verified” is a claim. The second statement can name its dependencies, the probe that would falsify it, and the evidence that currently supports it.

Graph Climbing starts with a claim graph. Each leaf needs:

• a stable ID;
• one falsifiable statement about the product;
• real causal dependencies;
• a named probe;
• an honest state such as open, verified, blocked, or unknown;
• snapshot-bound evidence before it becomes verified.

The execution graph is optional. It describes the current verticals, owners, gates, and operational debt when a run is long enough to need them. It may change from serial work to a pipeline or parallel cohort without rewriting the product claims.

This separation targets a common failure. A worker closes a ticket, a branch goes green, and the project quietly treats activity as truth. Under the Graph Climbing protocol, that transition is invalid: a worker returns an evidence candidate, and only reconciliation can update official product progress. Whether this rule reduces false completion in controlled comparison remains an open research question.

Progress is allowed to fall. An accepted finding that has been verified against the relevant snapshot can reopen a claim. The old evidence remains part of the history, but it no longer proves the current product.

That sounds obvious until a dashboard, issue tracker, or release note assumes that completion only moves forward.

One climb is a bounded product iteration

The runtime is a small loop:

derive -> select -> build -> verify -> reconcile

Derive the reachable claim frontier from current authority and evidence. Select one bounded vertical with a named first probe. Build inside its file, runtime, and authority scope. Verify the exact snapshot. Reconcile the result into the surfaces that own product truth, execution state, decisions, and evidence.

Then derive again.

A vertical can contain several dependent claims when the whole unfinished dependency chain fits inside it. Splitting every node into a separate worker would add handoffs without creating independence. The graph should expose safe parallelism, not manufacture it.

This outer loop explains how a long project moves. It does not explain where most of the hard engineering happened in DACS Forge.

The inner review loop changed the product

DACS Forge began with a short bounty description: build a forkable reference DACS agent service. The resulting product contract now contains 165 falsifiable criteria covering signatures, canonicalization, identity, settlement, delivery, recovery, HTTP boundaries, containers, release provenance, and adoption.

The first implementation of a vertical was rarely its final form. The bilateral Vet vertical is the clearest completed example. Across 24 semantic review rounds, it produced 33 concrete findings:

• 32 were accepted;
• 23 were P1;
• 22 were classified as security-relevant;
• 16 correction commits followed;
• the final Codex review was clean at 0.96 confidence.

These findings were not about formatting. They found evidence accepted from the wrong authority, incomplete binding to a listing or agreement, replay paths, privacy-schema gaps, unsigned verification claims, non-canonical resolver JSON, and a migration path that could bless invalid state.

The first clean Codex snapshot arrived in Round 019. A deliberately different Fable review in Round 020 then found a privacy-schema gap. Later Codex rounds found more defects. A clean review meant that one reviewer found no accepted issue in one pinned snapshot. It never meant the code had become infallible.

The useful unit is the full provenance chain:

snapshot
-> counter-hypothesis
-> finding
-> independent disposition
-> correction
-> regression probe
-> clean reviewed snapshot

The reviewer does not become a new authority. Each finding is checked against source, tests, and the governing specification. A real issue is accepted and corrected. A wrong hypothesis is rejected with evidence. A valid issue outside the current scope is deferred to an owner that can resolve it.

This distinction matters for the phrase “one-shot production quality.” The useful version does not mean one prompt and one generated patch. It means that a long-running product vertical can contain many internal build, test, and review cycles before it hands a bounded, evidence-bearing snapshot to the next consumer.

Review provenance came after the first work

The first DACS Forge verticals had good commits, tests, and checkpoint notes, but incomplete native review provenance. Some early review rounds were reconstructed later. Their exact diff hashes or original reviewer outputs could not always be recovered.

That gap led to a small recorder inside the repository. Before each review, it stores the round ID, code head, diff hash, upstream pins, review engine, model, scope, prompt hash, expected test surface, and output destinations. After the review, it retains the native human and structured outputs and records whether the run was clean, produced findings, failed as a tool, or was interrupted.

The recorder does not decide policy and does not start an autonomous supervisor. It preserves what happened.

This makes review reusable. A repeated authority-confusion defect can become a regression vector. A local invariant can become a new project claim. Cross-implementation evidence may later justify an assurance profile. Promotion into a protocol standard still requires explicit scope, versioning, independent evidence, and maintainer review.

The finding alone is an opinion. The disposition and regression evidence make it engineering knowledge.

The control system also failed

The build produced a useful warning about assurance work itself.

An outer audit correctly found that product progress was scattered across checkpoint files and task notes while an older strategy document still reported 0/160. Moving the canonical ISA into the build repository fixed the underlying visibility problem.

The agent then overextended the correction. Review-control machinery became its own hill to climb. The detour produced 28 commits, 3,314 new lines, 18 semantic meta-review rounds, and 54 findings without completing another DACS lifecycle vertical.

Human steering froze that expansion. A second correction made the boundary precise: meta-governance receives a tight budget; product Autoreview does not receive an arbitrary round cap. Security-sensitive code may need many rounds as long as each one attacks the current product snapshot and produces useful findings.

The lesson was added to the method:

Add a new rule only when it prevents an observed failure. Guardrails bound product work. They do not become the product.

That correction matters as much as the clean feature seals. A method that reports only successful runs hides the decisions that shaped it.

Parallel work exposed an integration gap

The first DACS Forge parallel pilot is still running. It started with two independent verticals. One worker handled legacy Directory compatibility. Another continued the Active Write interruption matrix. They used separate worktrees and disjoint scopes.

The Directory worker completed its implementation, tests, Codex review, Fable pass, and evidence commit first. Its task still mixed two states: lane-local completion and later integration into the main product. The branch was independently sealed, but the final merge depended on human memory.

The sealed Directory lane exposed a control gap before the pilot reached integration. That gap produced the companion-join rule.

Every released cohort with two or more lanes now gets one reconciliation vertical at release time. Every lane blocks that join. Every successor that consumes the cohort blocks on the join rather than on an individual lane. A lane can become sealed after its own probes and review, but it cannot mark product claims verified or release ordinary successors.

When every lane has sealed, one atomic task claim chooses the join owner. That owner verifies the inputs, integrates the branches, runs combined probes and review, reconciles the claim graph and ledger, then derives the next frontier.

The contract is cardinality-independent, and source-blind local fixtures cover N=2, N=3, and N=4 without pairwise joins. Its live effectiveness remains unproven until the first DACS Forge companion join closes. The contract still refuses parallelism when workers share an unfinished dependency, file read, database, port, namespace, authority decision, probe, or stop rule. Worker count is an output of the dependency audit.

DACS Forge supplied the first field evidence

DACS Forge uses four existing surfaces rather than a new orchestration platform:

• the project ISA holds stable product claims, dependencies, probes, decisions, and official progress;
• ISA Features describe product decomposition;
• Beads holds smaller execution verticals, blockers, owners, steering, and companion joins;
• commits, tests, runtime probes, review dispositions, and upstream pins hold evidence.

The portable kernel is smaller:

claim graph + evidence + climber

A short serial change does not need a ledger. A longer run can use any task system that preserves ownership and dependency gates. Goals, hooks, schedulers, and supervisors may help with liveness, but none of them decides what is true.

Current boundary: July 22, 2026

This article snapshot was captured at 14:28 CEST.

• The master DACS Forge ISA reports 91/165 verified product claims.
• The Active Write vertical is still in progress at repository head 436bf65d4bb606dbbbb3740ee8a2b9d64efe4c28.
• Active Write Autoreview has reached Round 048. That round is non-clean and reports three findings.
• The Directory compatibility lane is sealed at bef1b965f89495aa8b85a67ea4ce75c3454e172a, but it is not integrated into main.
• The companion integration join remains open and blocked by Active Write.
• Product-ISA remodeling for the next parallel wave remains blocked by that join.
• Container release, the extension-only exemplar, public product seal, and adoption remain open.

The generic topology contract has local review and conformance evidence. The first live companion join has not run. This article therefore describes an implemented method and an unfinished product case. The final version will record the actual join and product outcome, complete review counts, final claim state, failures, and available cost data. It will include the integrated commit, combined gates, and release evidence only if those states are reached.

Why this is a research problem

Current swarm work suggests that decomposition and harness design can protect context and reduce coordination waste. Cursor’s agent swarm study reported large differences in conflicts, code size, model cost, and held-out SQL correctness after changing several parts of its harness together. It is a useful comparison, not controlled evidence for decomposition alone.

Graph Climbing asks a different question: what allows probabilistic work to count as durable product truth?

The DACS Forge case is enough for an engineering field report. A research paper needs controlled comparisons. The planned study will compare task-first and claim-first execution, serial and joined parallel topologies, and runs with or without persistent semantic review. Useful measures include false closure, held-out defect detection, claim reopen rate, reconstruction after context loss, integration failures, review yield, wall time, tokens, cost, and specification-to-ledger divergence.

The central hypothesis is testable: separating product truth from execution state, then requiring snapshot-bound reconciliation, should reduce false completion without forcing every project into one scheduler or one agent topology.

The public Graph Climbing repository currently exposes the experimental v0.2 claim-first protocol, starter specification, checker, examples, case material, and deterministic visual sources. A reviewed topology-invariant v0.3 candidate remains local. Its publication and Gist synchronization stay gated on the first live DACS Forge companion join and subsequent product-ISA reconciliation. The DACS Forge story will remain a living report until the product reaches either a seal or an explicit bounded stop and the corresponding publication evidence is recorded.