16. First Article: Fast, Disciplined Iteration

Thursday, 4:48 p.m., first-article scramble still running, someone's kid's practice already texted on the lock screen.

The first article build starts rough, as expected. By day three, every shift has made "small improvements." Yield is still unstable and no one can say which change helped or hurt. The two-shift delta cost three days of root-cause investigation because the configuration was not locked between shifts — every build had a different unknown baseline. Build throughput increased, but the run log did not produce decision-ready learning.

The team locked the build configuration at shift handoff: one baseline, one change per build cycle, signed off at handover. The first run log produced under that discipline answered two questions the previous log could not — which change moved yield and which did not. Root-cause investigation eliminated. The throughput was lower than the unlocked approach for the first two cycles; the learning was usable starting from cycle one. - Old process: build configuration unlocked between shifts; multiple simultaneous changes per cycle; run log captured throughput but could not attribute yield results to specific changes.

  • Artifact changed: locked-baseline discipline at shift handoff — one change per build cycle, configuration signed at handover, run log structured to answer what changed and what the yield result was.
  • Measured improvement: decision-ready learning from the first disciplined run cycle; three days of root-cause investigation for the prior shift delta eliminated.
  • Cost of the gap: three days of root-cause investigation to recover from two shifts of simultaneous, untracked changes — throughput without learning, not a substitute for it.

Objective of first article

First article is not a demo milestone.

It is a structured learning phase that reduces uncertainty fast enough to decide next commitments.

Primary objectives:

  1. validate critical functions under real build conditions,
  2. expose process and design failure modes early,
  3. convert findings into controlled changes with measurable outcomes.

A run log that carries decision-ready findings before the next commitment is made is the observable evidence that the phase ran as learning, not throughput.

If the phase optimizes only for throughput, it hides the very information you need most.

Iteration loop that actually learns

Use a repeatable cycle:

  1. Define current failure/constraint.
  2. Choose one controlled change set.
  3. Record baseline and expected effect.
  4. Run and capture results.
  5. Decide: keep, revert, or escalate.

Then repeat on the next highest-risk constraint.

This loop keeps iteration speed high while preserving a causal record for decisions.

Change discipline rules

Default rule: one-variable change where practical.

When multi-variable changes are necessary, require:

  • explicit rationale,
  • expected interaction risk,
  • rollback condition,
  • ownership of interpretation.

Without this, first article becomes untraceable trial-and-error.

Logging standard for first article

For each iteration, log:

  • unit/build ID,
  • baseline state,
  • change introduced,
  • result against criteria,
  • anomaly notes,
  • decision and owner.

If logs are optional, memory becomes the system and confidence outruns evidence.

Common anti-patterns

  • random edits between runs (change-introduced field blank or absent between runs),
  • lost baselines (baseline-state field blank at run start),
  • vague pass/fail definitions (result-against-criteria field contains narrative instead of a named criterion),
  • "good enough" calls without criteria (decision field names no predeclared threshold),
  • fixes merged before isolated effect is understood (decision field reads "keep" while anomaly-notes field remains open).

These patterns feel energetic and usually lengthen ramp.

Decision gates inside first article

Do not wait for formal program gates.

Use mini-gates within first article:

  • Is the change repeatable?
  • Did risk move enough to proceed (relative to the predeclared entry criterion or the prior-run baseline)?
  • Do we need deeper analysis before next run?
  • Should scope or sequence change now?

This protects speed while preserving decision quality.

Thursday, second week, same time of day. The change log is posted on the workbench before the next shift arrives. The incoming lead reads it in five minutes, starts from a known baseline, and when yield drops on run 14, the delta investigation takes twenty minutes — not three days — because the configuration is locked and the prior decision is on paper.