V-Model Build Workflow — spec (v0, pending founder)

Origin: founder shared a NASA "V"-model systems-engineering diagram + a tweet arguing it's "the perfect model for developing code with LLMs … if you're explicit in your docs it's never been easier to build, test, and verify" (2026-05-29). Founder: "Let's just do B" — draft the workflow spec. This is the spec; building/running it is a separate founder go.

The core idea (why the V-model fits LLM coding)

The V-model's discipline: every left-side specification is paired with a right-side verification that is written AT THE SAME TIME as the spec, not after the code. Decomposition flows down the left arm (ConOps → system requirements → subsystem/high-level design → component detailed design → implementation); verification flows up the right arm (component verification → subsystem verification → system verification → system validation). "Traceability" runs up the middle — every built thing traces back to a requirement, every requirement forward to a test.

LLM coding's default failure mode is the inverse: the model builds, then you scramble to check it. Planning-mode is a thin left-arm-only approximation with no paired right arm. The V-model forces the pairing, which is exactly the verification discipline our /verify-* + station-critic machinery already encodes — this workflow just imposes the sequencing (test-before-code, per layer) and the traceability (every layer's output checked against its own pre-written acceptance).

Maps onto machinery we already have

The novelty vs the existing 4-station brigade: the current brigade runs the 4 stations once over one artifact. The V-model workflow runs them per decomposition layer, bottom-up on verification, with a hard gate: a layer's code is not written until its paired test exists, and a layer is not "done" until its verification passes AND traces to its parent requirement.

The workflow shape (Workflow-tool JS orchestration)

Phases, expressed for the Workflow tool (dynamic-workflow JS, fan-out per layer):

1. Decompose (left arm, top-down). One station-spec-author agent per layer produces: ConOps → system requirements → subsystem/high-level design → component detailed design. Each layer's spec artifact names its OWN acceptance criteria (the paired right-arm test target). Output: N layer-specs in the run scratch dir, each with an explicit verifies_against: parent-layer reference (the traceability link).

2. Author paired tests (right-arm definition, per layer, BEFORE any code). station-test-author fan-out — one per layer — writes the verification for that layer's acceptance criteria, seeing ONLY that layer's spec (rubber-stamp isolation preserved). This is the load-bearing V-model move: tests exist before implementation.

3. Implement (bottom of the V). station-code-author writes the actual artifact (code/config/doc) against spec+tests. For a real codebase this is the component layer; for the Markov case it's the engine modules.

4. Verify bottom-up (right arm, ascending). station-critic + /verify-* run component verification → subsystem verification → system verification → system validation, in that order, each gate checking the built thing against its pre-written layer test AND confirming the traceability link holds. A failed gate drops that layer back to spec-author with critic feedback (the convergence loop); ascent does not continue past a failed layer.

5. Traceability report. Final artifact: a matrix showing every requirement → its test → its verification result → pass/fail, with the implementation-notes file as the running decision log. This is the thing that makes an LLM build auditable — the founder can see every spec layer was independently verified, not self-graded.

Domain-general, with Markov Phase-1 as the first real test case

The workflow is domain-agnostic (same reason build-haiku-generator is a thin domain wrapper over the 4 utility seats). The natural first non-toy run is the Markov Phase-1 engine build ([[2026-05-27-markov-equities-pipeline-spec]]):

• ConOps = "calibrated regime/price-bucket Markov that times entries within a chip-cycle phase"
• system reqs = walk-forward, survivorship-free, ≥30 obs/state, calibration-vs-base-rate
• component layer = regime-labeler / transition-matrix / Monte-Carlo / calibration modules
• right-arm verification = each module's pre-written test + the /investing:backtest-thesis harness as system validation
• This is exactly the spec→test→build→verify-per-layer shape the founder was circling with workflows + ultracode, applied to the build that's already parked and spec'd.

Open questions for founder

1. First run target: Markov Phase-1 (recommended — already spec'd, real, parked) vs a smaller canary (a single well-bounded skill build) to shake out the workflow mechanics first? (build-haiku-generator was the toy smoke-test for the 4-seat pipeline; this V-model workflow may want its own toy run before Markov.)
2. Effort tier: run under ultracode (autonomous workflow spawn) or explicit-kickoff at xhigh? Given the doc-discipline emphasis of the V-model, explicit-kickoff first run is the more conservative choice.
3. Where the traceability matrix lives: run scratch dir only, or promoted to the bet's vault folder as a durable audit artifact?

Gates / guardrails

• Building/running this workflow is a separate founder go (this is the spec only).
• PR-only on any repo it touches ([[feedback_pr_only_workflow]]).
• Implementation-notes file required (it IS the traceability spine).
• No live trading from the Markov first-run — Phase-1 is backtest-only, founder-gated to advance ([[feedback_paper_trade_deploy_authorization]]).

Related

• [[2026-05-12-multi-agent-pipeline-architecture]] — the 4-seat pipeline this composes
• [[build-haiku-generator]] — the proven toy composition of the same seats
• [[2026-05-27-markov-equities-pipeline-spec]] — the first real test-case build
• [[2026-05-19-verification-as-independent-worker-pattern]] — the verify-gate discipline the right arm uses
• [[feedback_implementation_notes_sub_agent_pattern]] — the traceability-spine mechanism
• Source of the prompt: NASA "V" model (Forsberg & Mooz 1991 → NASA SE Handbook SP-2007-6105 Rev 1); founder-shared tweet 2026-05-29