Distinguish an unfinished promise from a new request

Describe the requested result before naming the work

Write the affected page, the action a visitor or administrator needs to take, and the result expected from that action. Avoid classifying the whole conversation as a defect or an upgrade before identifying the behavior. A request can contain both unfinished work and a new capability; separate those parts so agreement on one does not conceal disagreement on the other.

For each part, distinguish the current observation from the desired result. Keep dated screenshots, release references and existing issue records that show the actual behavior. Do not turn a missing observation into a claim that the feature never worked. A dated record of failure establishes what was observed on that version, within the conditions recorded.

Locate the promise and the evidence used to accept it

Use the actual scope, approved changes and acceptance criteria the parties relied on. Record the document version and the clause or message that names the behavior. If two records conflict, retain both and ask the parties which scope they understood to apply; do not silently select the wording that favors one position.

Then compare the delivery evidence with that requirement. Identify the URL or version examined, the behavior demonstrated, any conditions excluded from the check, and defects left open at handoff. A completion message without behavior evidence cannot show that every disputed requirement worked. Conversely, a record showing one path working does not establish that every device, user role or checkout path was covered.

Prism’s published process confirms scope, fees and terms before work and leaves the merchant to choose updates. That supports defining the requested review carefully. It does not supply terms for a separate agency agreement or establish what another contractor promised.

Classify the evidence without assigning liability

Use repair of the agreed result when the requirement is documented and the observed behavior falls short under the agreed conditions. State the precise gap and the evidence that would show it closed. Keep responsibility for the cost separate: a technical shortfall alone does not decide the parties’ contractual rights.

Use new request when the desired behavior expands the documented result, audience, page coverage or operating conditions. Record what would be added and preserve the original result as the comparison point. The amount of effort is not the classification rule: a small addition can still change scope, while a difficult repair can concern the original requirement.

Use changed dependency or unresolved scope when the evidence does not support either conclusion. Compare the delivered version with subsequent software, configuration and content changes where records exist. A later change is an investigation lead, not proof of causation or fault. If the promise itself is ambiguous, write the competing interpretations and the missing agreement instead of presenting either interpretation as settled.

Agree on the next action and its completion evidence

For a supported repair, name the behavior to restore and the person responsible for proposing the correction. For an addition, define the expanded result and obtain the parties’ agreement on scope, fees and timing. For an unresolved case, name the exact record or observation needed next and who can supply it. Keep disputed commercial terms visible rather than hiding them in a technical task.

Agree what the next evidence should show: the affected page and version, the conditions under which it must work, and the result the parties will review. Treat this as a proposed acceptance check until agreed. This worksheet cannot decide breach, warranty coverage, payment withholding or other contractual remedies; those questions belong with the parties and qualified advice when needed.

For a Prism checkout-review consultation, describe the website, research-only products, disputed behavior and requested review. Confirm any scope-comparison or implementation work before it begins. Leave private contracts, customer records and credentials out of the public form; start with a concise description. Follow-up is by email, and an inquiry does not book an appointment or purchase a service.

Change-request classification

Complete one copy for each separable requested behavior using genuine project records. The final classification is provisional until the parties agree. A missing clause or observation remains unknown; it does not automatically make the work chargeable or free.

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.