Evidence and receipts

Record attachments belong to a work package. Each attachment has a title, evidence type, upload date, uploader and visibility. The file itself can be attached to the record. The available evidence types include Requirement, Design, Contract, Evidence, Report, Screenshot and Other. The visibility choice distinguishes Internal from Shared material, giving the team a clear cue before using a file in a review.

The attachment should answer a question about the scope or delivery. A screenshot might show the revised screen, while a report might show verification results. The Independent Reviewer can inspect the attachment beside the impact assessment and task work. An attachment title alone is not the evidence; the team should check that the file and its context match the revision under review.

• Attach to the package. The uploader adds the file, title, type and visibility under the relevant change.
• Review with context. The reviewer reads the file against the package revision, assessment and task work.
• Track governed actions. Operation receipts hold the action, actor, expected revision, result and any failure reason for an attempt recorded by the team.

Agree which evidence types are expected for common changes and who may mark a file Shared. Decide how to handle a revised file: its title and notes should let the reviewer distinguish it from the earlier one. The uploader reference and upload date support the handoff. Keep private material under the right visibility setting and rehearse access with the roles that will review it.

Operation receipts have an operation key for repeat attempts, an expected revision and a result state of Pending, Completed, Failed or needs review. Agree who investigates failures and how the team correlates a receipt with the package and action that produced it. The Operations Overview page can direct attention to failed operations; staff still need to read the recorded failure reason before retrying or correcting work.

A Business Analyst adds a design attachment to a reporting change package and marks it Shared for the review team. A Delivery Contributor later adds a screenshot showing the delivered screen. Before Review, the Project Manager checks that each file is attached to the right package and that the titles distinguish the proposal from the delivered result.

In the rehearsal, Admin records a Failed receipt for an attempted action whose expected revision differs from the current package revision. The Delivery Lead opens Failed operation receipts, reads the reason and compares the revisions. They do not treat that receipt as an approval. The reviewer records a separate decision against the revision they actually examined.

• Package evidence — Shared attachments with type, uploader and upload date.
• Failed operation receipts — Failed actions, their package and recorded reason.

Evidence and exception handling covers files and failed attempts. Revision and decision shows how evidence supports a specific review.