One change can create several different questions
An evaluation result is tied to the system, cases, rubric and execution conditions that produced it. A later revision may fix a grading mistake, change the product requirement or introduce a new candidate. Those are different decisions. Treating all of them as a simple rerun can erase the reason an earlier acceptance decision was made. This guide proposes a small change-control record; it is not a claim about a completed XIVTech engagement.
Classify the change before running again
Record whether the request changes the evaluated system, the evidence set, the judging rule or only a failed execution. A prompt edit creates a new candidate. Removing an ambiguous case changes coverage. Correcting a grader changes how outputs are interpreted. Repeating an interrupted invocation may be an execution retry, but external dependencies can still have changed. Preserve the original record in every case.
Keep a baseline manifest
Identify the case set, rubric revision, model or application configuration, tools and relevant environment, timestamp, expected cases, completed cases and unresolved execution states. Store the accepting owner and the decision the run was meant to inform. Do not put confidential examples or credentials into a shared report; use permitted identifiers and controlled evidence locations.
Use a decision record, not a silent edit
For each proposed change, name the reason, affected cases, expected visible difference and approving role. Decide whether earlier outputs can be regraded or whether new executions are required. If the standard changed, label the comparison as a new evaluation basis. A higher score under easier criteria is not evidence that the candidate improved. Approval of the change is separate from approval of the release.
Illustrative example: correcting a citation rule
Suppose an answer cites a relevant source but omits a required locator. The team discovers that the rubric never specified locator presence. Adding that requirement is a criterion change, not proof the old judge malfunctioned. Preserve the earlier run, revise the requirement openly and evaluate under the new rule. If a parser instead dropped a locator that existed in the output, record a grading defect and identify the affected judgements. This example is not a XIVTech client project.