A useful triage result is not a long summary. It is a defensible decision tied to current sources, an explicit evidence gap, and one bounded check that could change the decision.
This workflow deliberately separates what a reporter says, what the public record supports, and what someone has independently reproduced.
The checklist
Eight steps before implementation starts.
- 01
Freeze the decision question
Write the choice in operational terms: reproduce, close, escalate, or consider funding repair. A vague decision creates an open-ended investigation.
- 02
Record the exact public input
Capture the repository, issue, reported version or environment, dates, and the few linked sources that could materially change the decision.
- 03
Separate claims from verified facts
Label reporter statements as reported. Reserve verified for facts directly supported by current source, release, test, or maintainer records.
- 04
Map linked implementation state
Check whether referenced pull requests are open, merged, closed, superseded, or unrelated. An open issue does not prove no repair exists.
- 05
Check release and version state
A merged change is not automatically present in the buyer's version. Identify the release, backport, or deployed build that would contain it.
- 06
Name the decisive evidence gap
State the one missing fact most likely to reverse the decision. Avoid a generic list of everything that might be useful.
- 07
Write one bounded acceptance check
Define a buyer-run check with a pinned environment, exact action, observable result, and pass or fail boundary.
- 08
Issue a decision with limits
Return GO, NO-GO, or NEEDS-INPUT, explain why, and state what the decision does not prove.
Evidence ladder
Use the narrowest truthful label.
Reporter-reported
The issue or comment states the behavior. No independent confirmation is implied.
Supported by public evidence
Current source, release, test, or maintainer records support the claim, but the target environment was not exercised.
Independently reproduced
The behavior was observed in a defined environment using a recorded procedure.
Insufficient public evidence
The record cannot support a decision without one missing version, source, reproduction, or authority fact.
Acceptance check
Make the next check smaller than the bug.
Given a pinned version, environment, and starting state
When one exact action is performed
Then one observable result must occur
Pass when the stated result is observed
Fail when the contrary result is observed
Limit what this check still does not establish
The acceptance check is a proposal for an authorized decision owner to run. Springfield Systems does not execute target code or claim runtime reproduction in this service.
Decision classes
End with an action, not a summary.
GO
The public record supports taking the named next step, subject to the stated limits.
NO-GO
Current evidence does not justify the proposed work, duplicate effort, or escalation.
NEEDS-INPUT
One decisive missing fact prevents a responsible GO or NO-GO.
Common mistakes
Five shortcuts that create bad triage.
- Treating an open issue as proof that the defect remains unfixed.
- Treating a merged pull request as proof every affected release contains the change.
- Calling a reporter’s result independently reproduced.
- Using a long source list instead of identifying the decisive source.
- Recommending implementation before defining the buyer’s acceptance boundary.
One public bug. One next move.
Want the decision made for you?
Use the six-question browser-only check. A verified Jake-only checkout appears only when every fixed boundary is eligible.
Check eligibility free Evidence review only. No runtime reproduction, patch, security work, private data, or guaranteed outcome. OpenAI Codex materially assists; no separate personal human review is promised.