Keep the test fixed.
Then judge the control.

The important artifact in Microsoft’s worked example is not the generated policy alone. It is the evaluation that travels with it into the next run. Microsoft introduced run-assert-eval on September 24, 2026, describing a workflow that connects risk discovery, measurable behavior requirements, runtime controls and reevaluation. Its Command Line article says the behavior definition, cases and judging approach remain constant while the policy is the intended intervention. For an enterprise reviewer, that creates a concrete question: can the team identify the exact evaluation reused and explain what changed around it? A fresh set of easier cases could produce a better result without answering whether the original failure was addressed. Preserving the test is therefore a condition for interpreting the intervention, not a shortcut to proving causality.

The distinction matters when discovery and acceptance share a workflow. Discovery asks what else might go wrong; an intervention assessment asks how the agent behaves against a specified requirement after a reviewed change. Both are useful, but they produce different evidence. Our proposed acceptance practice is to retain the original evaluation as an identifiable record and add newly discovered coverage separately. Define prohibited behavior narrowly enough that a failure can guide a targeted decision. Alongside it, state what authorized, legitimate work should still succeed. Otherwise, a control that simply refuses more requests can look effective while making the agent less useful. Microsoft explicitly separates those outcome categories; neither should disappear into a single favorable score.

Microsoft reports reusing the baseline evaluation’s cached material for the governed run. Yet the headline baseline and governed aggregates have different counts of applicable conversations. Case-level reconciliation is needed before interpreting those aggregates. The fixed test set and the applicable subset are not interchangeable concepts: keeping cases available does not, by itself, explain which conversations qualified for each reported measure. Ask which cases were applicable in each run, why any classification changed and how each outcome maps back to its case. Do not read the headline figures as an identical-denominator paired comparison or draw a numerical before-and-after chart from them. A consistent judge helps preserve the measurement approach, but it does not make the judge infallible or resolve applicability differences. The useful comparison begins with traceable cases, not an assumption that two totals describe the same population.

The source explicitly says generation is not automatic approval: the policy, its enforcement description, intervention point and target wiring need review before the governed run. That is a substantive handoff, not administrative cleanup. Reviewers need to understand what decision is enforced, where it takes effect and whether the evaluated agent actually reaches that boundary. A rerun cannot compensate for an unclear enforcement contract. Our proposed review record would distinguish generated material from the version people accepted for evaluation, identify the intended control change and disclose other changes that could affect interpretation. If the team must alter cases or judging criteria, retain that as a new evaluation version rather than quietly calling it the original comparison. The objective is an inspectable decision trail, not a claim that automation has approved its own output.

Microsoft’s worked example still contains prohibited-behavior failures after the control is applied. Those remaining failures belong in the decision record, not beneath a general claim that the problem is solved. The reported sample also has no observed legitimate-work violations in the governed results; that is not proof that legitimate work is universally unaffected. Before accepting a control, ask: which requirement does this evidence address, which cases remain unresolved and who owns the next action? What legitimate-work expectations were tested, and what relevant work was outside the sample? Can the reviewer inspect applicability decisions and distinguish an observed refusal from a successful authorized outcome? The owner should record whether to accept the evaluated scope, narrow it or request further work, with reasons. These are proposed acceptance questions, not findings from a deployment we tested. The accompanying process diagram organizes those checks; it does not represent measured success.