Phase 01
Read the actual requirement, not the summary.
Every requirement in the solicitation is extracted into a structured matrix and allocated: in scope, optional, or out. Coverage is counted, not asserted — a percentage that comes from a query rather than from a confident sentence in a proposal.
The uncomfortable output of this phase is a list of requirements nobody on the team can trace to a source. Those get asked about. The temptation is to quietly allocate them to something plausible and move on, and that decision is invisible until the moment it is expensive.
Phase 02
Ask the questions everyone else skips.
Questions to the customer are generated from the requirement matrix itself and prioritized by what they decide, so the gaps raised are the ones that determine whether the objectives are achievable — not the ones that are comfortable to ask.
Which questions go unanswered is itself a finding, and it is tracked as one. An unanswered question about scope is a risk with a name; an unasked one is a surprise with a date.
Phase 03
Build the thing, then argue from it.
A working prototype is built during the pursuit and used as the argument, in place of slideware. It is inspected by the evaluation team, clicked, and challenged. Multi-persona, multi-role, exercising the parts of the problem that are actually hard rather than the parts that photograph well.
Built on synthetic data and fictional locations by construction, so there is never a question about what it is sitting on. It also demonstrates structural refusals — the system declining to reveal sensitive information, with the refusal itself auditable — which is a claim that reads very differently when you can click it.
Phase 04
Make traceability mechanical.
Requirements, tests, stories, roles and controls are linked, and the linkage is validated by a script that fails when it breaks. A claim that cannot be walked back to its source does not ship.
Traceability asserted in a document decays the moment the document is edited. Traceability enforced in CI does not. That is the entire difference, and it is worth the day it costs to build.
Phase 05
Decide in writing, in advance.
Architecture decisions are recorded before they are implemented, with the alternatives considered and the cost of the choice stated plainly. When a decision later changes — and some will — the record changes with it and the reason is visible rather than archaeological.
The secondary effect matters more than the primary one: a decision you have to write down before you make it is a decision you argue about while it is still cheap.
Phase 06
Be honest about provenance.
What the contractor proposed and what the customer validated are marked differently and never blended. Unmapped controls and open decisions are flagged rather than allowed to look settled.
This is unusual and it is deliberate. A package that looks cleaner than the facts support is a liability at exactly the moment it matters — the moment someone competent starts pulling on a thread. We would rather hand over a document with visible gaps than one with invisible ones.
Phase 07
Ship through the factory from commit one.
Containerized, hardened, digest-pinned and gate-scanned from the beginning rather than as an integration phase at the end. A security finding should surface at an engineer's desk on the day it is introduced, not at a promotion gate in month five when it has become a schedule event.
The corollary is a dependency surface kept deliberately small and treated as a budget. In this environment a blocked scan is not a ticket, it is a payment event.