A completion receipt should point to usable behavior

Translate the completion claim into the agreed outcome

Keep the implementer’s completion message and find the exact deliverable it says is finished. Compare that claim with the agreed scope and any approved changes. Identify the intended user, the starting point and the result that user should obtain. If the scope describes only a review with findings, opening those findings may be the relevant outcome. If it describes a working change to checkout, a report about that change does not by itself establish the promised behavior.

Prism’s published process defines pages, processing questions and follow-up before work, with the merchant choosing which updates to make. That is a useful boundary when interpreting a consultation deliverable: a completed review and an implemented change are separate commitments. Do not add an implementation promise that the scope never made, or accept a promised implementation solely because someone delivered review notes.

Give each receipt only the meaning its evidence supports

Read the receipt for what it actually identifies: a file, version, destination, date or completed operation. A successful build message can document that the named build step finished. It does not, on its own, show which URL serves that version or whether the merchant can use the agreed journey. An upload receipt can identify a transferred artifact while leaving access and contents unconfirmed.

Match the receipt to the deliverable you can open. Record the real URL or file location without copying a private access token. If you cannot establish that the accessible result is the version named in the receipt, leave that connection unresolved. A screenshot of the contractor’s screen does not answer whether the merchant can open the same result with the access agreed for delivery.

This comparison is about evidence, not how many files or tasks were completed. Retain useful production receipts, but place them beside the behavior they support. Several receipts for the same preparatory step do not supply evidence for a missing user outcome.

Observe the promised behavior at its actual route

Open the agreed deliverable using the access the merchant is supposed to hold. Record the starting route, what you did within your authority, the result and the observation date. If access fails, name that obstruction before calling the underlying feature defective. If the item opens but the agreed action is unavailable, record the action that stops and the visible message.

Keep the extent of the observation explicit. Reading a page establishes what was visible at that time; it does not establish a payment, an email delivery or a downstream order handoff. Where the scope includes those outcomes, compare existing real records for the same event and state any evidence that is unavailable. Do not submit a payment, inquiry or customer message merely to make an acceptance sheet appear complete.

Choose a finding that matches the observation: the agreed behavior was observed; the result contradicts the agreement; or the evidence is insufficient to decide. Insufficient evidence is not a successful result, and it is not proof that the implementation failed. This distinction lets the responsible person supply the missing route, access or record without obscuring a concrete defect.

Return one precise gap for resolution

For an unresolved item, connect the scope line, the claimed receipt, the route checked and the observed gap in one note. Identify the owner who can correct the behavior or supply the missing evidence. If the scope itself is ambiguous, clarify the outcome with the merchant and implementer before changing the acceptance standard. Preserve the original finding and add the later resolution rather than rewriting an earlier failed observation as a pass.

Use narrow completion language when discussing the result publicly. The FTC’s truth-in-advertising guidance calls for truthful, non-misleading, substantiated claims on the web. It does not define your project contract or certify this worksheet. A merchant’s acceptance decision cannot support an unrelated statement that the provider approved the business or that all future orders will succeed.

For a scoped Prism checkout-review consultation, send the website, research-only products and a concise description of the gap between the delivery claim and the accessible behavior. Do not attach credentials, private logs or customer records through the public form. Scope, responsibilities, fees and terms are confirmed before work; the request receives email follow-up and does not buy implementation or book an appointment.

Behavior-to-delivery comparison

Complete one sheet for one claimed deliverable. Follow the chain from the agreed outcome to the route you opened and the result you observed. Use the final decision to distinguish an observed match, a concrete contradiction and insufficient evidence. This is a comparison method, not an acceptance certificate.

Worksheet entries are not submitted by Prism’s worksheet and are not saved by the site. Use record types, availability, anonymized observations, or match/mismatch results. Do not enter government identifiers, customer names or addresses, customer messages, receipt-access links, card or bank details, passwords, or keys. Send sensitive documents only through the provider’s verified secure channel.

These are temporary notes. Leaving or reloading this page may clear them. Worksheet entries are not sent automatically. If you copy notes into the consultation message and submit the form, Prism receives them as part of your request.