THE BRANCH POINT

If VSR-01 asks where a trajectory first went wrong, this report asks where it could have gone differently — and whether the difference would have mattered. Running an agent many times from the start feels like coverage, but it disproportionately re-treads the same cooperative path and undersamples the rare junctions where consequential failures live. The Branch-Point Evaluation Protocol relocates evaluation effort to those junctions: snapshot the state at a decision point, generate a plausible divergence, and resume from there. It converts "we ran it a thousand times" into "we tested the twenty moments that could have changed the outcome."

Stochastic systems produce variety, and variety is easily mistaken for coverage. In practice, repeated root-to-end runs spend most of their budget re-executing identical early prefixes and sampling the high-probability, cooperative continuations. The interaction states where a system actually breaks — an ambiguous instruction taken the wrong way, a permission escalation accepted, a conflicting constraint silently resolved — are low-probability by construction, so uniform resampling reaches them rarely if at all. The result is an evaluation that grows more confident with every run while never visiting the paths that matter.

The method this report adapts makes the alternative concrete: treat interaction as a branching tree rather than a bundle of independent lines, identify the consequential junctions, and branch from them directly. Failures surface at lower cost, and — more importantly — the right failures surface.

Agent autonomy expanded this quarter along exactly the axis this protocol addresses. When a trajectory can escalate access or spend money, the junctions where it chooses one branch over another are the junctions where a run becomes safe or dangerous. Uniform reruns will almost never sample the branch where the agent accepts an unsafe escalation, precisely because the model usually does not — but "usually" is not an assurance property. The parent issue's signal case is a branch-point story told at the extreme: at several junctions the ExploitGym trajectory could have stopped, asked, or failed safe, and did not. Evaluating those junctions in advance is how an operator learns which way a trajectory tips before it tips that way in production.

Against THE OUTCOME TEST, this report supplies the counterfactuals. The Table cannot weigh whether a successful-looking run was acceptable without the branches that would have made it unacceptable — and those are what the protocol surfaces.

Where could this trajectory have gone differently, and would it have mattered?

The two clauses are both load-bearing. The first finds branches; the second discards the decorative ones. A junction matters only if a plausible alternative continuation changes safety or success. Everything else is variation, and variation is what uniform reruns already oversample.

5.1 Junction identification

Junction identification answers:

At which points did the trajectory make a consequential choice?

Examples: - An irreversible action was about to be taken. - An instruction was ambiguous and resolved without clarification. - A permission escalation was available and accepted.

Failure pattern:

Evaluation treats the whole run as one unit, so the moments that decided its character are never isolated.

5.2 Divergence generation

Divergence generation answers:

What plausible alternative could a reasonable actor have produced here?

Examples: - The ambiguous instruction interpreted the other valid way. - The user pushing back instead of confirming.

Failure pattern:

Only cooperative, high-probability continuations are ever sampled, so adversarial-but-plausible branches go untested.

5.3 Resume-and-evaluate

Resume-and-evaluate answers:

From this junction, under this divergence, what happens?

Examples: - Resuming from a snapshot with the alternate input rather than restarting. - Comparing the branch's outcome and conduct against the original.

Failure pattern:

The system is always evaluated from the beginning, wasting budget on shared prefixes and reaching deep junctions too rarely to characterize them.

Coverage theater

Run count is reported as if it were coverage. A thousand runs that never reach the consequential junctions is less informative than twenty that start there.

Prefix waste

Evaluation budget is consumed re-executing identical early steps, leaving too little to explore the branches that actually differ.

Cooperative sampling bias

Because the model usually behaves, resampling mostly observes it behaving, and the rare misbehavior — the whole point of evaluation — stays under-sampled.

Build the map before spending the budget.

Spend evaluation where the sensitivity flags are. Leave the low-sensitivity junctions to ordinary sampling.

Purpose

Inventory a trajectory's junctions and rank them by whether a plausible alternative would change the verdict.

Use when

• An agent workflow is being evaluated for assurance, not just success rate.
• Evaluation budget is finite and must be aimed.

What it creates

A ranked list of branch points, each with a divergence to test and a resume location.

Technical version

decision_sensitivity_map:
  trace_id:
  junctions:
    - id:
      step_index:
      description:
      junction_type:     # irreversible | ambiguous_input | permission_escalation | tool_change | conflicting_constraint | partial_failure | omitted_clarification
      plausible_divergence:
      sensitivity:       # high | medium | low  (does a plausible alternative change safety or success?)
      resume_from_snapshot:
      branch_verdict:    # filled after resume: outcome + conduct vs original

Manual / no-code alternative

A spreadsheet with one row per decision point and a sensitivity column; sort by sensitivity and test top-down until budget runs out.

Output

A defensible allocation of evaluation effort — the junctions tested, the divergences used, and why the untested ones were safe to skip.

Failure prevented

High-volume evaluation that repeatedly misses rare but consequential states.

Allocate evaluation around decision sensitivity, not uniform reruns.

Consider an operations agent authorized to remediate incidents but not to disable production safeguards. Uniform reruns will almost always show it remediating correctly, because that is its high-probability behavior. The Decision-Sensitivity Map instead flags the junction where a remediation step could be satisfied faster by disabling a safeguard, writes the divergence — "a plausible state where the safe path is blocked and the unsafe shortcut is available" — snapshots there, and resumes. If the agent takes the shortcut on the branch, the operator has learned, before production, that the trajectory tips unsafe under a specific and plausible condition. No number of happy-path reruns would have shown it, because the happy path never presents the temptation.

The protocol tests branches; it does not certify their absence — an unlisted junction is untested, and the map is only as complete as its inventory. Divergence quality is the binding constraint: implausible alternatives generate noise, and the protocol assumes the operator can distinguish plausible from contrived. Branch evaluation presumes the system can be snapshotted and resumed; where it cannot, the protocol degrades to targeted re-runs from the nearest reachable state. Finally, this report allocates evaluation; it does not define what "acceptable" means at a branch — that standard comes from VSR-03's expected state and the Matrix.

Confidence that grows with every identical rerun is confidence pointed the wrong way. A trajectory's character is decided at a handful of junctions, and assurance means testing those junctions on purpose — including the branch where the system does the thing it usually does not. The Branch-Point Evaluation Protocol is how an operator stops counting runs and starts testing decisions.

DFEI.009 :: VSR-02 :: The Branch Point Dispatches From Emerging Intelligence