White paper 04 / Evaluation and governance

Subject-Bound Evaluation in Multi-Agent Systems

Evaluation provenance, configuration drift, and stale-evidence rejection across governed transitions

Ground Control · 16 October 2026

Abstract

Evaluation provenance requires a stable binding between a judgment, its candidate revision, and the context supplied to the evaluator. Ground Control freezes workflow-definition candidates into review subjects containing candidate version, content hash, rendered-context hash, authority references, actor, and time. A review return binds that subject, its findings, a return destination, and evidence references; the approval and issuance handoffs then carry validation state and must agree with the subject’s revision and evidence. This creates a lifecycle invariant: a decision may advance only when its declared subject agrees with the revision and evidence presented at that boundary. The mechanism detects accidental stale or mixed-subject handoffs. It does not establish that evidence is true, complete, or persuasive.

Contribution. We describe a revision-bound review protocol across subject freezing, review return, approval handoff, and issuance handoff. Its main contribution is an explicit consistency relation between candidate identity, rendered context, validation state, findings, and evidence references, with a separate revision boundary for runtime workflow-agent bindings.

Implemented architecture.

Stale-evidence failure model

A review decision is a relation between a judgment and a subject. Let C denote a candidate revision, R its rendered review context, V its validation state, and E the referenced evidence. A verdict over (C,R,V,E) cannot safely be interpreted as a verdict over (C′,R′,V′,E′) merely because both candidates share a workflow name. Mutable names identify a place in a process; they do not identify the bytes and state a reviewer saw.

This mismatch can arise without malicious behavior. An author can edit the candidate after a review, the renderer can change the context, or a handoff can combine a current revision with an earlier validation result. In each case, downstream actors may make a correct decision about the wrong subject. The system therefore needs both a stable subject identity and checks at transitions where one subsystem hands the decision to another.

Agent-evaluation research studies performance across task classes, failure modes, and evaluation conditions. Subject binding addresses a narrower systems question: does the lifecycle preserve which candidate and context the evidence describes? It makes provenance inspectable, while leaving evaluation quality to the criteria, reviewer, and evidence itself.

Related sources: [1], [2]

Subject identity and transition admissibility

Subject freezing begins with a validated workflow-definition revision candidate. The freeze operation requires a subject identifier, actor reference, and timestamp. It canonicalizes the rendered context, computes its digest, and requires equality with the expected rendered-context hash. It then constructs and hashes the review subject and requires equality with the expected subject hash. These preconditions implement a compare-and-freeze protocol over explicitly represented candidate and context state; missing or mismatched expectations reject the operation.

A compact model is S = (tenant, candidate, version, hC, hR, authority, t), where hC identifies the represented revision content and hR identifies the rendered context. A review return D binds S together with its findings, a return destination, and evidence references; it records no verdict or validation state, and is admissible only if subject(D) = S and its evidence references are well formed for S’s tenant. Validation state, and agreement between the presented evidence and the evidence bound to S, are enforced later, at the approval and issuance handoffs. This notation describes identity and consistency checks; it is not a proof that the underlying review logic is sound.

The review subject includes more than hashes. It also carries the actor and time, review authority information, and evidence references. A later handoff checks the relationships among these fields: validation must point to the candidate revision and content identity; its state reference must match the reviewed subject; evidence references must agree with those bound to that subject; and findings must remain associated with that subject. Approval and issuance are separate lifecycle boundaries, so each validates the state it receives instead of assuming an earlier check covers all later transitions.

The protocol can be expressed as an invariant over accepted transitions: for every handoff H, subject(H) = S and evidence(H) = evidence(S) at the approval boundary; issuance compares against the approved handoff. Validation bindings must agree on candidate version, candidate content hash, and validation-state reference. These checks reject a handoff assembled from incompatible subjects. A changed candidate requires a subject whose bindings describe that candidate. The earlier decision remains attached to its original subject; it is not rewritten or silently transferred.

Runtime configuration uses a related but distinct identity. An execution run resolves an accepted workflow-agent binding set with its own binding revision and a selected agent revision for each workflow node. Launch admission rejects executable agent nodes when required binding data is absent. The review subject’s candidate revision and the runtime binding revision are not interchangeable: one identifies the workflow-definition candidate submitted for review, while the other identifies the agent configuration chosen for execution.

This separation matters when agent instructions change. A change to an instruction source changes its agent revision and may produce a new workflow-agent binding revision. It does not, by itself, mean the workflow-definition candidate changed. Conversely, changing a dependency edge in the authored workflow changes the workflow candidate even if its selected agent revisions remain the same. The records let a reviewer and runtime operator inspect both axes without conflating them.

The mechanism catches disagreement at defined boundaries. It does not infer semantic equivalence between revisions or decide whether a change is important. Hash equality identifies represented data under the chosen serialization and hash procedure; it does not establish semantic correctness, reviewer independence, or evidence quality.

S = (tenant, candidate, version, hC, hR, authority, time); accept(H) only if subject(H) = S and validation(H), findings(H), and evidence(H) satisfy S’s reference rules; workflow-agent binding revision is a separate runtime identity

Counterexample: stale validation after topology mutation

An author prepares a workflow candidate whose topology includes a sequence of work and review nodes and a dependency edge from node A to node B. The system renders the review context and freezes a subject with the candidate revision, content-subject hash, context hash, authority information, and evidence references. Freezing requires matching expected subject and context hashes. The resulting subject binds the candidate state selected for evaluation.

A reviewer examines that subject and returns a finding. Before approval, the author changes the dependency edge so node B now depends on node C, then creates a new workflow candidate revision. This is a workflow-candidate content change. If the approval request combines validation for the first candidate with the new candidate revision, the subject checks reject the handoff because the revision and content identity differ. If the rendered context changes before freezing, the expected-context comparison rejects the freeze operation.

Now consider a separate edit to the instruction text for the agent assigned to node A. That edit produces a new agent revision and may require a new accepted workflow-agent binding revision for a later run. It is not the dependency-edge change and should not be described as if it rewrote the reviewed workflow candidate. Keeping these identities separate tells the operator which review subject changed and which runtime configuration changed.

The original review remains a valid record about the original subject. To advance the changed workflow, the team submits the new candidate as a distinct subject and evaluates it under the applicable authority rules. The protocol prevents accidental transfer of an old verdict; it does not decide whether the edge change is safe or whether the new evidence is sufficient.

Evaluation method and limitations

A protocol evaluation should vary one reference at a time: candidate revision, content hash, rendered-context hash, validation state, finding subject, and evidence reference. The expected result is rejection when a handoff mixes subjects and acceptance when every required reference agrees. A second set should independently mutate the rendered context and expected hashes, then attempt to freeze the subject and construct approval and issuance handoffs with stale validation-state references. Runtime cases should independently vary the workflow-agent binding revision and selected agent revision to confirm that those fields remain distinct from workflow review identity.

This paper reports no benchmark, defect rate, or formal proof. A cryptographic digest identifies represented input under the implementation’s canonicalization; it does not say whether two revisions mean the same thing or whether a claim is correct. Two reviewers may share data, instructions, and blind spots, so different role names do not prove independent judgment. The protocol also cannot correct incomplete criteria or missing evidence. Future work can measure stale-handoff frequency and review quality across task classes, but those are empirical questions beyond the binding mechanism.

MAST provides a taxonomy and dataset of failure cases in multi-agent systems, while PROV-AGENT addresses provenance in agentic workflows. These works motivate systematic evaluation and provenance capture. Ground Control applies binding checks to a product lifecycle: the subject, rendered context, validation state, evidence, and handoff must refer to the same revision before a review transition can proceed.