I would not start by tuning the model. First reconstruct exactly what it saw. Which branch produced the cited text, which tool call produced the correct answer, what was written to scratch memory, and what assembled prompt and citation map reached the final model call? “The tools were correct” says nothing about whether the right result was attached to the right branch and claim.

Here is a plausible race. Branch A searches policy version 7 and stores its citation in one scratch entry. Branch B searches version 8 and stores a note in a different entry. Each branch has a correct result in its own trace. If the final assembler reads B's note alongside A's citation, or treats a branch-local citation [1] as globally unique, it combines B's conclusion with A's source. The model faithfully copies the citation it was handed. The scratch store may hold legitimate working notes, but an unscoped mutable key is not an evidence identity.

Branch A supplies a version seven citation in one scratch entry, while branch B supplies version eight answer text in another. The assembler combines them into a claim bound to the wrong revision.
The evidence binding must follow an immutable branch result, not whichever scratch value is latest.

My assembly contract would require each tool result to carry a run ID, branch ID, tool-call ID, attempt ID, source object and revision, authorized principal, content digest, and the excerpt or pointer used as evidence. The branch publishes an immutable result object. The final assembler reads a particular set of completed branch results from a consistent run snapshot, checks authorization and freshness, deduplicates by source identity where appropriate, and assigns citation labels only after assembly. The rendered citation maps to the exact excerpt supplied to the model. A branch can make a recommendation, but cannot write an unqualified “the answer” into another branch's namespace.

Attempt ID matters. A retry can produce two technically correct results against different revisions. The runtime must decide which completed attempt is accepted for that logical call and keep the rejected one out of final context. An append-only event log plus an accepted-result pointer is one way to do that. A plain latest key is convenient for a human scratchpad, not for a proof of what supported a claim.

What if the branches truly need to share findings? Share references to immutable artifacts with explicit owners and scopes. A merger can resolve conflicts with both source revisions visible. If a branch's tentative hypothesis is useful, label it as a hypothesis, never as a citable source. The W3C's PROV-O vocabulary provides useful language for entities and derivations, but the run and authorization rules here are our application contract.

I would freeze this incident's prompt bytes and citation map, then replay the interleavings: A finishes first, B finishes first, B retries, a branch times out, and the scratch key is overwritten between context and citation assembly. Each supported sentence must resolve to the span the model actually saw, with the same source revision and principal. If a reference cannot be resolved or was visible only to another branch's principal, fail assembly or omit that claim. A final answer with a nice-looking citation is not enough to pass the test.

The design also gives us a better incident trail. From one citation we can walk backward to the assembled excerpt, accepted attempt, tool result, source revision, and authorization check. Without that chain, logs that say “both tools succeeded” still cannot explain the wrong answer.