Revision-Pinned Operational Graphs for Long-Horizon Agents

The problem: intent can drift between systems

A mutable workflow name and a package identifier do not establish which planning revision, acceptance criteria, or agent instruction set governed an execution. A reviewer can evaluate a rendered context derived from one candidate while a later command resolves the same name to changed content. The resulting ambiguity is temporal: object identity alone does not pin object state. Long-horizon work therefore requires provenance edges that terminate at concrete revisions and mutation commands that reject stale preconditions.

The data model combines several identity regimes. Mission and WBS records carry monotonic revisions. Promotion records the source node revision and candidate content hash. Work-package revisions carry a canonical subject hash and references to requirement-set, dependency-graph, artifact, baseline, and rendered-context inputs. Runtime binding sets carry their own revision identity plus node-to-agent revision selections. This is not a claim that every object is content-addressed; the graph combines stable IDs, revision numbers, and hashes according to each boundary’s contract.

Related sources: [1], [2]

Graph model: typed references and derivation edges

We use an analytic model, not a description of a stored graph: the product records the references below, and the model names the relations among them. Let an operational graph at time t be G_t = (V_t, E_t). A versioned vertex is v = (kind, id, revision); a hash-bearing vertex additionally carries h = H(Canon(payload)). In the model, edges encode typed relations such as parent-of, depends-on, derived-from, constrains, or selected-for-run; the product stores these as revision references on its records, not as a separate edge store. An edge to a versioned object includes the target revision, not only its mutable object ID. For example, a promoted package candidate stores its WBS node ID, SourceNodeRevision, shaping fields, and ContentHash. The candidate is a stable governed handle, but it is not itself canonical work-package truth.

A package-revision vertex contains the execution contract: scope binding, acceptance and closeout criteria, consumed baselines, requirement-set and dependency-graph revision references, artifact references, external bindings, and rendered-context hash. Its SubjectHash is computed from canonicalized revision content. The hash supports equality checks for that represented content; it does not establish that the constraints are complete or that the plan is sound. In provenance terms, the graph records selected entities and derivation context, while the application’s command/event records preserve mutation identity and transition history.

This structure is a revision-pinned operational graph with partial content-addressed provenance. IDs route references; revision numbers identify successive mutable states; hashes identify canonical payloads at boundaries that define a hash contract. These forms are complementary. A hash without a typed edge does not explain why one object was selected, while an ID without a revision can resolve to later state. A lineage reconstruction in this model, rather than an implemented query, must follow both the edge relation and the pinned target revision.

G_t = (V_t, E_t); v = (kind, id, rev[, H(Canon(payload))]); e = (relation, source_ref, target_ref)

Related sources: [1]

Trace: stale mutation and revision-pinned recovery

Consider mission m at revision 8, with WBS node n at revision 4 and dependency edge e from backup node b to migration node n. Promotion creates candidate c with SourceNodeRevision = 4 and a content hash over its shaping intent. A downstream package revision p records the selected scope, graph and requirement revisions, rendered-context hash, and canonical subject hash. The review subject therefore resolves to a particular package payload and its declared source lineage; it does not resolve to “the latest migration task.”

Now let an editor read n@4 while another command updates the node to n@5. If the first editor submits an update with ExpectedRevision = 4, the repository’s revision precondition detects the stale write and rejects it. The editor must read n@5 and issue a new command. A later candidate derived from n@5 is a different provenance vertex from c, even when both have the same title. Reusing the old candidate ID or mutable label would erase this distinction; the source revision and candidate hash preserve it.

At execution admission, the accepted workflow-agent binding set adds another temporal boundary. A run stores the binding revision and the selected AgentRevisionID for each workflow node. Thus the execution trace can identify the workflow configuration and agent revisions admitted at launch. This is a run-scoped configuration snapshot; it does not freeze unrelated tenant data, external artifacts, or every mutable system dependency.

Evaluation and guarantee boundaries

A conformance evaluation can vary one lineage component at a time: mission revision, WBS source revision, candidate content, package subject hash, rendered-context hash, workflow binding revision, or per-node agent revision. For each mutation, reconstruct the provenance path from the recorded references and determine whether it resolves to the intended revision. A stale expected-revision command should fail; a new revision should remain distinguishable from its predecessor; and runtime admission should use the accepted binding snapshot recorded for the run. This tests the graph’s identity semantics, not task quality.

The paper reports no empirical benchmark. Hashes identify canonical represented content, not semantic equivalence, correctness, or artifact availability. Revision pins do not make every downstream read immutable. The run-scoped workflow-agent binding freezes selected configuration revisions but does not claim global snapshot isolation across the database, tools, or external services. Evaluation should therefore separate lineage reconstruction, stale-write rejection, and configuration resolution from outcome quality and system-wide consistency.

Related work

The W3C PROV model represents entities, activities, and agents and defines relations for provenance interchange. PROV-AGENT examines provenance requirements in agentic workflows. Ground Control’s contribution is an application-level operational graph that binds those conceptual relations to revision-bearing mission, package, review, and runtime objects. The graph’s IDs, revision preconditions, canonical hashes, and binding snapshots are product contracts rather than a replacement provenance ontology.

Related sources: [1], [2]