Use this technical discovery acceptance checklist to decide whether a specific deliverable supports the next commitment. For incomplete architecture evidence, Pharos Production's IT consulting and architecture review describes a process that produces written risk registers and specifications with explicit integration boundaries.
One row represents one discovery deliverable and one decision. Keep acceptance evidence separate from the existence of a file. A document can be delivered while the decision it was meant to support remains unresolved.
Duplicate this page into your own private workspace before recording project information. Open the child database Working Discovery Matrix. It starts without assessment records; add a row for each deliverable in the agreed discovery scope. The fictional demonstration below is separate from that database.
Set the decision owner and the next commitment outside the matrix: for example, whether to fund a bounded feasibility experiment. Name the required gates before reviewing the outputs. This template does not make every possible discovery artifact mandatory.
| Field | What belongs here |
|---|---|
| Deliverable | A named output and its version, such as an integration-boundary specification |
| Decision supported | The specific commitment this output must inform |
| Acceptance criterion | An observable completeness condition agreed before review |
| Evidence reference | A document location or recorded demonstration with version and relevant section |
| Reviewer | The person who checks that criterion, rather than the author by default |
| Assumption | A consequential statement that has not yet been established |
| Assumption owner | The person responsible for obtaining evidence or escalating the assumption |
| Next-stage dependency | The next activity that relies on this finding and must wait if it is unresolved |
| Required gate | Required or Optional for the stated next commitment |
| Outcome | Pending, Proceed, Re-scope or Stop, using the rules below |
| Follow-up and owner | A specific correction or investigation and the responsible person |
| Review date | The date of an actual review; leave it empty until that review happens |
An evidence reference should let the reviewer find the relevant version. A folder link with no document or section is insufficient when several incompatible versions exist. Keep confidential documents in their appropriate restricted system and record references only in your private copy.
Separate outputs that need different acceptance decisions. If one architecture document contains both an accepted ownership map and an unresolved throughput assumption, use separate rows when those findings gate different activities. Cross-reference the same document version rather than pretending that every section has the same outcome.
Pending: the output has not been reviewed or the evidence needed for a decision is missing. An empty field does not mean acceptance. Keep dependent work waiting while a required gate is pending.
Proceed: the named reviewer has inspected the cited version and the agreed criterion is satisfied for the stated next commitment. Record the review date and the remaining assumptions. Proceed is limited to that commitment; it does not certify the whole system or authorize production deployment.
Re-scope: useful evidence exists, but the proposed commitment depends on an unanswered question or a changed boundary. Specify the narrower activity that can proceed, what remains excluded and who will resolve the gap. Obtain the decision owner's agreement before committing to the revised scope.
Stop: the evidence contradicts a required condition, or no acceptable next commitment can be defined within the agreed constraints. Record the reason and route it to the decision owner. Do not replace a stop decision with an optimistic average of other rows.
At the package review, examine every Required row. A Pending, Re-scope or Stop outcome needs explicit resolution before the original dependent commitment can proceed. Optional rows may still change the decision if their findings expose a new mandatory constraint; record that change rather than hiding it in a score.
This example is invented for the worksheet. The document label, roles and observations do not describe a real client engagement. No integration, load test or project assessment was performed.
| Deliverable and decision | Acceptance evidence | Unresolved assumption | Outcome and follow-up |
|---|---|---|---|
| EXAMPLE-ARCH-03: integration-boundary specification; decide whether to commit to the proposed full-volume integration build | The fictional version identifies the sending system, receiving system, message owner and failure owner. Its capacity section leaves the provider's permitted request rate unconfirmed. | The proposed traffic fits the provider's available capacity; owner: client integration lead | Re-scope. Technical reviewer requests provider capacity evidence. Decision owner may authorize a bounded capacity investigation separately; the full-volume build remains outside that authorization. |
Here, a complete ownership diagram supports an ownership decision. It does not establish capacity. The review date remains blank because the example records no real review. If capacity evidence later satisfies the agreed criterion, create a dated review entry against the new evidence version instead of silently replacing the original uncertainty.