A discovery dossier is useful when every proposed work package can be traced to an observed workflow, requirement, dependency, assumption, or explicit buyer decision.
Start with the problem and current workflow
Describe who performs the workflow, what starts it, each human and system step, the information that crosses boundaries, exceptions, delays, manual work, and the observable end state. Include the systems and teams outside the proposed build. A preselected feature list can hide the larger process and create an estimate for the wrong boundary.
The GOV.UK Service Manual says discovery should understand users, wider context, constraints, and opportunities before committing to build. It also advises reframing a presented solution as a problem and identifying what is outside the problem. Apply that discipline even when the buyer already expects software: record the intended change, current cost or failure, and credible non-build alternatives.
Connect target state to requirements and evidence
Write the target workflow in the same end-to-end structure, then derive functional requirements, quality attributes, data rules, integration behaviors, operational responsibilities, and non-goals. Give each requirement a stable identifier and connect it to a user need, constraint, system contract, policy supplied by the buyer, or explicit decision. Mark requirements inferred from incomplete evidence as assumptions.
Separate hard constraints from preferences. A regulatory obligation, fixed vendor contract, unavailable API, and immovable launch event affect the plan differently from a favored framework or interface pattern. For each constraint, record its source, owner, date, and whether it has been verified. Discovery should expose when a proposed option works only if a supposedly fixed boundary changes.
End with options, holds, and acceptance
Present a small number of architecture or delivery options with consequences, dependencies, reversibility, and evidence gaps. Link work packages and estimate ranges to the selected option rather than combining mutually exclusive designs into one number. List decisions required before authorization and identify any hold that makes an estimate provisional or prevents a responsible statement of work.
Scope Ground prepares the dossier through Reality Contact, LLC. The accountable buyer chooses the option, approves requirements and assumptions, and decides whether to authorize, narrow, or stop. The dossier records the evidence available at a named date; it does not guarantee cost or schedule and cannot control later changes in requirements, vendors, data, or external systems.
Where the service stops
Reality Contact, LLC performs bounded technical discovery and estimation but does not guarantee cost or delivery dates, provide legal or procurement advice, select vendors for the buyer, authorize a build, certify architecture or security, or control requirement and dependency changes after the dossier date. The accountable buyer resolves listed holds, selects or rejects an architecture option, approves assumptions and acceptance scenarios, and decides whether to authorize an internal plan, request a vendor statement of work, narrow the initiative, or stop. This technical discovery service does not replace the buyer's engineering, security, legal, procurement, finance, architecture, or production-readiness review. Estimate ranges remain conditional on the recorded option, assumptions, exclusions, access, dependencies, and acceptance scenarios.
Sources: GOV.UK Service Manual on the discovery phase; GAO Cost Estimating and Assessment Guide.