Issues and evidence

An issue records a defect or change item against project work. It carries severity, status and an owner, with the reporter’s note providing context. When an existing issue is raised as Open, the triage workflow checks its current state and severity before moving it to Triaged and recording the operation result.

A reported fix still needs verification. Exception Triage keeps fixed-but-unverified issues visible alongside schedule concerns, giving QA Engineer a direct route to the work that needs checking. Delivery evidence, review decisions and operation receipts help Project Manager understand both the issue’s outcome and any action that failed to update it.

• Qualified triage. Developer or QA Engineer raises the issue against the correct project and supplies severity. The workflow acts only while the existing issue remains Open; a missing severity or changed state blocks triage.
• Fix verification. QA Engineer inspects the reported fix and supporting evidence before moving the issue from Fixed to Verified. Project Manager checks the remaining delivery effect before treating the concern as closed.
• Evidence trail. Attach files to the intended record and retain the decision subject or operation reference. These references help the next reviewer find the relevant work instead of relying on a status label alone.

Agree how severity is assigned and what the reporter should include when describing the problem. Decide which evidence QA Engineer needs for verification and where that file or link is retained. Keep ownership current so an overdue fix does not remain in the queue without a person responsible for the next step.

Define how attachment parent labels and record identifiers resolve to the actual project, task or issue. Choose how decision subject references and operation references identify their targets. A familiar title is useful to people, but reliable evidence navigation needs a reference that resolves to the intended record and remains within the reader’s authorized scope.

Use an Open issue describing a task result that fails its agreed check. Leave severity empty and attempt triage. Inspect the failed operation receipt and confirm the issue has not been forced to Triaged. Add the appropriate severity and repeat the eligible action, then inspect the successful state change and recorded result.

Try triage again after the issue is already Triaged. The guard should block the attempt because the issue is no longer Open. Later, Developer marks the issue Fixed and attaches supporting evidence. QA Engineer opens it from the unverified-fix queue, checks the actual result and records verification. Finish with an attachment that points to another issue and ensure the team resolves that mismatch before accepting it as support for this fix.

• Open Issues — Open issue records with severity, project and assigned owner for triage preparation.
• Unverified Fixes — Fixed issues waiting for evidence-based verification.
• Operation Follow-up — Failed and pending actions with their subject reference, actor and notes.

Use Triage and verify issues, then Review delivery exceptions to connect the result with the wider commitment.