Accept technical discovery deliverables only when the cited evidence supports a named next commitment. A delivered architecture deck can still depend on an unverified interface assumption. Pharos Production's IT consulting and architecture review describes written risk registers, decision recommendations and specifications with explicit integration boundaries. Use this checklist to inspect the connections between those outputs before approving further work.
The decisive check is whether a changed finding reaches every document that depends on it. In the fictional DD-47 review below, a source-history limitation changes the recovery design, the estimate and the proposed build decision. Accepting the diagram alone would miss that chain.
Open the Discovery Acceptance Matrix beside the delivered package. The matrix holds your review records; this article explains how to judge the evidence and reconcile conflicting outputs. The worked package is invented for this guide. It describes no client engagement, executed experiment or demonstrated supplier capability.
Write the requested commitment at the top of the review. Funding a feasibility investigation requires different evidence from commissioning the proposed implementation. Avoid a general approval of technical discovery when the actual decision concerns a specific integration, migration or product boundary. Name the person authorized to make that decision and the activities their approval would release.
Keep receipt of files separate from acceptance of their content. Receipt establishes that the promised outputs arrived. Acceptance establishes that the reviewer inspected a particular version against an agreed criterion.
Authorization establishes what happens next. Your agreement may connect these events commercially, but the technical record should make their different meanings visible.
The GOV.UK Service Manual's discovery guidance states:
Your discovery is finished when you’ve decided whether or not you want to move on to alpha.
That guidance concerns government services, where alpha is a further investigation phase. It does not prescribe a universal software procurement checklist. Its useful principle here is that discovery ends in a decision whose scope is explicit. A well-supported finding that the original approach cannot proceed may complete the agreed investigation successfully.
Before opening the deck, locate the agreed discovery scope and its acceptance conditions. If those conditions were never defined, agree a review basis with the responsible parties. Do not quietly invent retrospective obligations because a different document format would now be convenient. Record a newly requested investigation separately from correction of an omitted agreed output.
Create a manifest with each output's identifier, version, author and reviewer. Add the question it answers and its relevant section. One file may answer several questions; several files may support one conclusion. This manifest gives the review a stable starting point when a slide export and an editable diagram carry different revision dates.
Check practical access using the receiving team's permissions. A supplier can open its own repository while your engineering reviewer cannot. Record that as unavailable evidence until access is resolved. A screenshot of a folder establishes neither readable contents nor access to the source material required for continued work. Keep restricted project information in your private copy of the matrix.
Use the following table to inspect the expected content. These are proposed checks to adapt to the purchased scope, not mandatory documents for every discovery. A short investigation can combine several rows into one readable memo. The acceptance question still needs an answer wherever that answer affects the next commitment.
| Output | Minimum decision-bearing content | Return for clarification when |
|---|---|---|
| Problem and scope | Intended user outcome, included workflow, boundaries and non-goals | The proposed solution adds a workflow absent from the agreed problem |
| Current-state and dependency map | Relevant systems, record owners, external dependencies and evidence sources | A necessary provider behavior is presented as an established fact without support |
| Options and architecture recommendation | Comparable alternatives, decision criteria, rationale and consequences | The favored option assumes away a constraint applied to its alternatives |
| Risk and assumption register | Consequence, owner, evidence status and next action | A material unknown appears only as a general caution in the conclusion |
| Validation record, if purchased | Question, method, environment, observations and limits | A planned test is described as completed or a mock is treated as provider evidence |
| Next-stage scope and estimate | Included work, exclusions, dependencies and conditions that reopen the estimate | The estimate relies on an architecture version superseded during review |
The manifest also exposes missing combinations. A dependency may appear in the architecture without an owner in the register. An estimate may include work omitted from the recommendation. These inconsistencies matter even if each file, read alone, looks reasonable. Record the relevant references together so the authors can correct the relationship rather than polish each document independently.
Check version consistency before assessing technical quality. If the recommendation cites an earlier scope, establish which scope the estimate actually prices. Ask the package owner to identify the intended baseline. Reviewers should not have to infer that the newest modification date makes one document authoritative over another. Preserve superseded versions where they explain a changed finding, but make the current baseline easy to locate.
Record an access failure separately from a content defect. If an appendix cannot be opened, the review cannot establish whether its criterion is satisfied. If it opens and omits the required observation, the gap is now a content finding. Those cases have different follow-ups and owners. Avoid recording both as a failed architecture review when the reviewer has not seen the relevant material.