Build an evidence request, not a feature questionnaire
For every important claim, record the required evidence and the operating role that will assess it. A recovery claim may need a restore record; an integration claim may need an end-to-end event trace; an access claim may need a role demonstration.
Use a sample environment when production access would expose confidential information. Redacted records can still show the method, component boundaries and result. Treat unanswered questions as open dependencies rather than filling them with assumptions.
Review five practical boundaries
| Boundary | Evidence to request | Unresolved question |
|---|---|---|
| Architecture | Component map and dedicated/shared responsibilities | Which dependencies can interrupt the whole workflow? |
| Access | Role matrix and change approval example | Who can operate the environment after handover? |
| Integration | Supported interface versions and failure trace | Who owns a request that fails between systems? |
| Recovery | Protected dataset, restore procedure and test record | What has actually been restored and checked? |
| Exit | Configuration/data export and replacement prerequisites | What access remains if the service ends? |
Ask for platform-rights and commercial boundaries separately from the technical evidence. A working demonstration does not itself establish a licence, regulatory permission or contractual entitlement.
Close the review with an actionable register
Illustrative review: a supplier demonstrates account creation but cannot yet show how a timed-out request is reconciled. Record the gap, owner and required validation instead of accepting the demonstration as complete integration proof.
Classify unresolved items by whether they block launch, require a contract clarification or can be scheduled after acceptance. Keep the decision, evidence reference and responsible reviewer together. This makes later scope changes easier to assess and prevents procurement promises from disappearing into informal conversations.