How to make AI claim labels enforceable during bug triage

01 / Scenario

Start with the boundary, not the model.

A report says that a physical appointment slot was double-booked near a daylight-saving change. The word “timezone” appears in the ticket, but that is not evidence of a conversion defect. The workflow has to distinguish the observed symptom from the suspected path, the mechanism, and the repair boundary before anyone edits scheduling behavior.

02 / Workflow

A repeatable sequence.

1. 01

   Create a claim register before proposing a cause

   List every consequential statement: reported symptom, affected path, environment, suspected mechanism, working control, and proposed repair. Give each one a status: supplied, verified, inferred, or unknown.

2. 02

   Attach evidence to every verified claim

   A verified label needs a concrete observation: a reproduction log, code path, test output, trace, configuration value, or approved decision. A label without supporting evidence is an inference in disguise.

3. 03

   Define the gate

   Mark the claims that must be verified before a repair can proceed. For a root-cause fix, that normally includes the failing condition, the mechanism, and the authority boundary where the fix belongs.

4. 04

   Use a control path to reduce uncertainty

   Compare a nearby path that behaves correctly. The contrast can either support a mechanism or expose a new unknown; it should not be used to make the original ticket sound more certain than it is.

5. 05

   Spot-check model verification labels

   Periodically sample claims marked verified and follow their evidence links. Track relabelled claims so a model that calls guesses verified does not quietly create false confidence.

6. 06

   Only then issue a repair packet

   Produce the minimal fix boundary, regression cases, remaining unknowns, rollout signal, and next verification step. If a material claim remains open, return a conditional plan instead of a completed diagnosis.

03 / Fictional worked excerpt

What a bounded output looks like.

The table below condenses a fictional example included for demonstration. It is not a customer result, production test, approval, or performance claim.

04 / Failure modes

Where otherwise plausible AI output goes wrong.

• Using labels as decorative prose while allowing the workflow to proceed unchanged
• Calling a claim verified without pointing to the observation that supports it
• Treating the ticket’s vocabulary as proof of the root cause
• Expanding a narrow repair into a global scheduling rewrite before adjacent paths are checked

05 / Read-only checklist

Use this before calling the artifact complete.

• Every material claim has one status
• Every verified claim has a concrete evidence reference
• Unknown and inferred root-cause claims block the repair step
• A nearby working control is recorded or explicitly unavailable
• A sample of verified claims is rechecked
• The output separates a supported repair from remaining verification
• Regression cases protect the original invariant and a nearby control

This checklist is intentionally read-only: it helps you inspect a workflow without exposing the full native skill files, portable prompts, templates, or the bundle-exclusive orchestration skill.