Make unresolved exclusions visible before accepting a project

Anchor the claimed exclusion to the agreement

Locate the exact behavior in the statement of work, accepted proposal or other written project record. Preserve the document date and wording, then check the agreed changes that followed it. Identify which record the implementer cites for excluding the behavior. A broad project label does not settle the details, and a late statement that something is extra does not explain how it relates to an earlier promise.

Classify the record without deciding a contract dispute from a worksheet. An exclusion stated in the agreed scope is different from a delivered behavior that fails to match an included item. A claimed exclusion with conflicting documents, or no shared written basis, remains disputed or unconfirmed. Preserve both positions rather than changing the original scope record to make them agree.

Describe the usable result at the promised step

Record where the merchant encounters the gap: the affected page, action or handoff, and what actually happens. Tie the observation to a date and the delivered version where known. Distinguish something that is absent from something present but unusable, and distinguish both from something that has not been observed. A polished page or a contractor’s completion message does not establish the behavior of an unexamined step.

Use genuine observations and existing operational records. Do not create a fictional order or claim that a backend, payment or notification was checked when only the visible page was reviewed. If the evidence stops at a screen, state that limit. A dependency that prevented observation should be named with its owner; it is not evidence that the behavior works.

Describe business impact from the actual workflow: which intended action is blocked, whether an agreed alternative is usable, and which part of the handoff remains unavailable. Avoid invented lost-sales estimates. The effect on a real merchant action is enough to explain why a scope exception matters.

Give each exception a decision that preserves what is open

For an item confirmed as included but unfinished, name the responsible party, the agreed corrective work and the observable result needed to close it. Record a date only when one has actually been agreed. For an exclusion the merchant agrees to retain, record the narrower delivered scope and any separate work the merchant chooses to pursue. Accepting that limitation is a decision about scope, not evidence that the omitted behavior was implemented.

For a disputed item, retain the competing document references, the unresolved question and the person responsible for resolving it. Do not convert silence into agreement or label a new price as an accepted change before the merchant has decided. If the team accepts a usable portion while other items remain open, identify both explicitly in the delivery note.

Keep acceptance wording, any commercial decision and the technical finding separate. This register does not decide payment obligations, legal remedies or contractual rights. It provides the factual comparison needed for the people responsible for those decisions.

Make completion statements match the narrower result

Review the handoff summary and any public statements that depend on the missing behavior. Describe only the work and capabilities supported by the record. A deferred feature remains deferred even if the rest of the project is accepted. Keep customer-facing information consistent with the actual service the merchant can provide.

The FTC’s truth-in-advertising guidance states a general expectation that advertising, including website claims, be truthful, not misleading and substantiated. It does not determine whether this project was contractually completed or whether particular wording is lawful. Assigning an owner to a claim or an exception does not itself establish compliance.

For a Prism checkout consultation, bring the affected public pages, the promised behavior and a concise account of the unresolved exclusion. Prism’s published process defines the pages, questions, follow-up, scope, fees and terms before work; the merchant decides which changes to make. Confirm the requested review and responsibilities rather than treating the inquiry as acceptance certification or automatic implementation. The contact form needs the website, research-only products and question, without passwords, card details or customer records; follow-up is by email.

Acceptance exception register

Complete one trace for every real disputed or newly disclosed exclusion. Read the written promise, observed result and claimed exclusion together before recording the merchant’s decision. Keep unresolved items visible in any acceptance note; do not fill unknown dates or evidence with estimates.

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.