Approach//Build method
Phases//01–05
How ARGV builds
One sequence, applied to every system — each phase ends with something concrete: a definition, a design, a build, evidence, or a handover.
Five phases from first signal to shipped system
Discovery & Definition
The phase that decides how the rest of the build goes — the questions asked here are the ones that would be expensive to ask later.
The problem, stated precisely
The requirement written in the customer's language, then translated into engineering terms without losing either.
Success, defined in advance
Acceptance criteria exist before design starts — measurable, testable, and agreed by both sides.
Constraints, declared early
Budget, timeline, environment, standards, and the systems we must live alongside — all on the table from day one.
Scope, written down
What is in and what is out is recorded in writing, so the boundary never drifts silently.
Architecture & Design
The design is argued while it is still cheap to change — interfaces, failure behavior, and trade-offs settled before the build commits to them.
Component boundaries
Every interface between pieces is specified before the teams on either side build — no guesswork at the seam.
Failure modes, mapped
Each component's failure behavior is designed and documented, not discovered in production.
Reviewed while it is cheap
The design is challenged and defended in review while a change still costs a conversation, not a rebuild.
The least that works
The smallest design that meets the acceptance criteria, chosen deliberately and defended against complexity in every review.
Build & Integration
The phase where design becomes something that runs — built to the specification, integrated continuously, and accepted at each gate.
Build discipline
Validation & Testing
The system is measured against what was promised, in conditions that resemble reality — evidence gathered, not opinions collected.
Tests against the criteria
Every acceptance criterion maps to a test. If it was not promised, it is not tested; if it was promised, it must pass.
Evidence, not anecdotes
Each result is recorded with the conditions it was measured under — reproducible, or it did not happen.
The environment that matters
Where it counts, validation runs in conditions close to production — not a clean room that flatters the build.
Failure is a finding
A failed test is a result, not a setback — it feeds the fix list and the next round of validation.
Delivery & Iteration
The system is handed over with everything needed to run it — and the loop closes back into the first phase.
Delivery is not the end — it is the point where the next iteration begins, driven by how the system behaves in real use.