A risk spike earns its place when its result changes an option, estimate, dependency, or acceptance rule and leaves an inspectable receipt.
Design spikes around one decision
Write each spike as a question whose answer affects the plan, such as whether the legacy API can sustain the required write pattern, whether a representative export preserves stable identifiers, or whether identity roles propagate to the downstream service. Define the input, safe environment, time box, test action, observed evidence, and support, narrow, or invalidate outcomes before beginning.
A spike is not a miniature production build. Use the smallest code or probe needed to inspect the risky boundary and preserve commands, configuration, output, and limitations. If the result depends on a vendor sandbox or synthetic data, state that difference. Do not promote prototype code into the implementation plan without a separate engineering decision about quality and support.
Translate findings into options and acceptance
Update the dependency map and architecture options with the observed result. A supported path should identify remaining scale, security, migration, and operations questions. A failed path may remove an option or create a prerequisite. A mixed result may narrow the workflow. Connect the decision to the work packages and estimate range so the spike changes the dossier rather than living in an appendix.
Write acceptance scenarios from observable end states. Name the starting role and data, action, system response, stored record, failure behavior, and evidence required for acceptance. Cover the primary flow and material edge cases discovered during review. Keep non-goals and buyer responsibilities nearby so a statement of work does not imply responsibility for unlisted systems or policy decisions.
Authorize with holds and change control visible
The final decision record should list selected option, rejected options, open holds, assumptions, estimate range, acceptance scenarios, owner, and authorized next step. Change control should explain how new requirements, vendor changes, inaccessible data, or altered acceptance affect scope and price. A buyer can authorize only the supported work packages while holding the rest.
Scope Ground produces the dossier through Reality Contact, LLC. The accountable buyer resolves holds, approves scope and acceptance, selects the option, and decides whether to authorize an internal plan or request a vendor statement of work. The dossier does not guarantee estimates, select a vendor, provide procurement advice, or certify the eventual implementation.
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 discovery decisions and moving to alpha; AWS Well-Architected Framework documentation.