Check delivery updates against task and code evidence
Compare reported work with the original task and implementation artifacts to surface missing or inconsistent evidence.
How this works
Compare reported work with the original task and implementation artifacts to surface missing or inconsistent evidence. Use this when a delivery update says work is complete and the team needs to see whether the agreed outcome is supported. The review assesses artifacts and coverage, not the contributor's motives or personal productivity.
Map each completion claim to the original requirement and available implementation, test and release evidence. Distinguish implemented, tested, deployed and unverified states. Missing evidence becomes a clarification request rather than proof that work was not done.
Before you start
Agreed task scope
Obtain the original requirements and accepted changes.
Delivery update
Preserve the exact completion claims and date.
Evidence access
Use relevant code, tests, screenshots and release records within the permitted scope.
Prepare the inputs
- task_requirements
- Required
IDs and acceptance conditions
Exclude abandoned or superseded scope.
- reported_completion
- Required
claim text and author-provided references
Separate status assertion from supporting evidence.
- artifacts
- Required
diffs, test outputs and visible results
Verify artifacts correspond to the claimed revision.
- release_state
- Required
deployment or availability records
Do not equate merged code with shipped behavior.
Implementation, step by step
Decompose the claims
- Turn the update into distinct statements of completed behavior.
- Map each statement to an agreed requirement.
Checkpoint: A claim-to-scope table exists.
Inspect implementation evidence
- Read relevant diffs or artifacts for the claimed behavior.
- Avoid broad repository judgments unrelated to the task.
Checkpoint: Each claim has an implementation status.
Inspect validation evidence
- Check test results and observable outputs at the relevant revision.
- Distinguish a test existing from a test having passed.
Checkpoint: Validation status is explicit.
Compare release state
- Check whether the behavior reached the intended environment or audience.
- Keep deployment and feature availability separate from implementation.
Checkpoint: The review distinguishes completion stages.
Prepare clarification
- List supported claims, evidence gaps and genuine contradictions.
- Use neutral questions and let the responsible owner resolve them.
Checkpoint: The review is actionable without personal inference.
Decisions along the way
Code exists but tests were not run
Mark implemented with validation pending.
Evidence belongs to an older revision
Request current evidence and retain the mismatch.
Requirement changed during delivery
Use the approved scope change rather than the obsolete requirement.
What you will produce
delivery-evidence-review.md
MarkdownA neutral assessment of delivery support.
Include: claim · requirement · evidence · status · question
evidence-gaps.csv
CSVFocused follow-up items.
Include: requirement · missing_artifact · owner · next_check
Check the result
- Verify every finding refers to the agreed scope.
- Check artifact revisions and timestamps.
- Separate implementation, validation and release states.
- Remove claims about effort, intent or honesty unsupported by evidence.
When something goes wrong
Repository access is unavailable
Mark implementation unassessed and request relevant artifacts.
Test output is truncated
Do not infer a pass; obtain the complete result.
Conflicting completion records exist
Present both and ask the owner to reconcile them.
A worked example
SYNTHETIC EXAMPLE · NOT A REPORTED BUSINESS RESULT
Request
Synthetic: review 'saved filters are shipped.'
Inputs
PR P4 implements saving and is merged. Test output shows persistence passing, but deployment remains on the prior commit.
Expected result
Synthetic result: report implemented and tested at P4, release unverified or not yet included in the recorded deployment. Ask for the intended release record rather than accuse the contributor of false reporting.
Run a small pilot
Start small
Review a few completed tasks with their owners.
Record the baseline
Record clarification time and missing evidence found.
Agree success criteria
Agree status accuracy and usefulness before applying the review more broadly.
Stop or revise
Stop conclusions when artifacts cannot be tied to the claimed revision.
Keep the scope clear
- Missing evidence is not proof of misconduct or low productivity.
- The workflow does not authorize changing task status or performance records.
Check before using
Assess the work, not inferred employee motives or productivity. Missing evidence is a request for clarification, not proof of misconduct.
Business activities
- Review business performance
- Plan products and business changes
FROM A RECIPE TO YOUR WORKFLOW
Bring the company context together.
This workflow needs reliable inputs before it needs a better prompt. Moat8 Vault brings working information into a readable archive for the AI tools you use.
For this recipe: Task requirements · Status updates · Relevant commits and review artifacts
Start with one recurring task, agree which sources to use, and review the first result with your team.
Discuss this workflow