16. First Article: Fast, Disciplined Iteration

The first-article build ran three days before anyone clocked that the problem was not the hardware. It started rough, as expected; every shift made "small improvements." By Thursday afternoon yield was still bouncing and no one could say which change had moved it.

Three days went into root-cause investigation that found nothing wrong with any single change — only that the configuration was never locked between shifts, so every build started from a different unknown baseline. Throughput had climbed the whole time. The run log had quietly stopped producing anything you could decide from.

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.

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.

First article has three jobs: isolate each change so the run log is readable, lock the build configuration at handoff so yield is attributable, and run mini-gates so problems surface within the article — not in production.

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

  • unlogged changes between runs (change-introduced field blank or absent),
  • 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" closure (decision field names no predeclared threshold, only a judgment),
  • change accepted while anomaly notes remain open (decision field reads "keep" while anomaly-notes field is unresolved).

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.

Field test: find your last first-article result. Is there a written learning extraction that links specific findings to specific design or process changes? If the findings fed the conversation but not a written record, the iteration is fast but not disciplined — and the next yield drop starts from zero again.

If you cannot point to the supplier measurement behind a part on that locked build — the real measured capability, not the certificate that shipped with it — then the change log is recording the truth about your process and guessing about the parts.