A finished unit fails test, is stripped, gets a replacement component and passes on the second attempt. What has to happen to its genealogy record?

The record is a history, not a picture of the unit

Almost every wrong answer to this question shares one assumption: that the genealogy record describes what the unit is made of. It does not. It describes what happened to the unit, in order, and the current configuration is something you derive by replaying that history. The distinction sounds academic until the replacement component arrives, at which point the two models diverge permanently.

If the record is a picture, the natural action is to update it. Change the component serial on the unit's bill of material, keep the passing test result, and the record now says a correct and useful thing about the unit as it stands. It also says something false about the past: that this unit was built with that component, which it was not, and that it passed test, which it did on the second attempt. Six months later, when the supplier of the original component reports a defect batch, a query for units containing that component will not return this one, and the unit will be omitted from a recall it belongs in.

If the record is a history, the same event produces three entries rather than one edit. The original component was installed at a station at a time by an operator against a work order. It was removed at a different time, in a different place, for a stated reason. A replacement was installed. Nothing that was true stops being true, and the configuration you get by replaying to now is the same configuration the picture model would have shown. You have lost nothing and gained the ability to answer questions about any point in the unit's life.

That is the whole design principle, and everything else in the answer follows from it. Genealogy is append-only. Corrections are new events that reference the ones they correct, never overwrites.

The failing test is part of the record

The second thing that gets quietly discarded is the first test result. It is tempting to treat a fail followed by a pass as a pass, because the unit that ships is the unit that passed, and because a fail on the record looks like an admission.

Keep both, and keep them distinguishable. The failing result is evidence about the process, and it is the input to every question the plant will later want to ask: whether this failure mode is rising, whether it clusters on one station or one shift, whether the component that was replaced is failing across many units and therefore has a supplier problem behind it rather than a workmanship one. A plant that erases first-attempt failures cannot compute its own first-pass yield, which means it cannot see a process drifting, and first-pass yield is one of the few numbers that tells you the truth about a line's health.

There is also the awkward case where the retest is a retest of a marginal measurement rather than a test after a repair. Testing a unit repeatedly until it passes is a real behaviour, it is different in kind from repairing and retesting, and the record has to be able to distinguish them. Which means a test event carries the attempt number and what intervened, and a policy exists about how many attempts are permitted without an intervening repair.

Disposition is a decision, and it has an owner

Before the strip-down happens, something has to authorise it. In a plant with functioning quality processes, a unit that fails test becomes a non-conformance: a record that states what was found, against what specification, on what unit, and it stays open until somebody with the authority to do so decides what happens to the unit. The available decisions are a small enumerated set, and they are genuinely different objects in the record.

• Use as is, where the deviation is judged acceptable, which requires justification and is the one an auditor will read most carefully.
• Rework, returning the unit to the specified condition by repeating or completing an operation.
• Repair, bringing it to an acceptable condition without necessarily restoring it to specification, which is what a component substitution often really is.
• Scrap, ending the unit's life, which must be recorded rather than merely ceasing to update it.
• Return to supplier, where the fault sits in incoming material.

The distinction between rework and repair matters more than candidates expect, because a repaired unit may be sold with a different status, may need customer concession, and in some sectors must be identifiable for its whole service life. Collapsing all five into a "fixed" flag is how a system loses the ability to answer the question a customer will eventually ask.

stateDiagram-v2
  [*] --> InProcess
  InProcess --> TestFailed
  TestFailed --> NonConformanceOpen
  NonConformanceOpen --> Rework
  NonConformanceOpen --> Repair
  NonConformanceOpen --> Scrap
  Rework --> InProcess
  Repair --> InProcess
  InProcess --> Released

The transition to watch is the one back into the process, because that is where a unit re-enters a routing partway through and every downstream station must be told which operations it still owes rather than assuming a fresh unit.

The component that came out has a future

Here is the part that most often has no design at all, and it is where the genealogy actually breaks. A component was removed. It physically exists. It is now sitting on a bench.

Every removal needs a destination recorded at the moment of removal, and the destination is a small set: scrapped, quarantined pending investigation, returned to the supplier, or returned to usable stock. Each has different consequences and only the last is dangerous by default. A component pulled from a failing unit, found to be undamaged, and dropped back into the parts bin is now indistinguishable from new stock and will be installed in a different unit. If it was in fact the cause of the original failure, you have moved a defect from a unit you know about to a unit you do not. If it was not the cause, it is still a part with a history of having been installed, removed and handled, which for some components is enough to disqualify it.

So the rule is that a component with a serial or lot identity never re-enters stock silently. It re-enters with an event saying where it came from, why it was removed, who inspected it, and against what criteria it was judged fit. That event is what allows the eventual recall query to run in both directions: from a suspect batch forward to every unit that ever contained one of its parts, and from a failing unit backward to every other unit that received a component with the same provenance.

Cannibalisation makes this concrete. When a component is pulled from unit C to repair unit B, the record must show one part leaving one unit and entering another, so that a defect discovered later reaches both. Systems that model installation but not removal produce a genealogy in which that component exists in two places forever, and neither entry is trustworthy.

Where the work happened, and who signed for it

The last piece is that rework frequently occurs outside the flow. A repair bench, a rework cell, sometimes a different building, often without the station terminal that would normally capture the events. The path of least resistance is that the work happens, and somebody keys a summary in afterwards from memory or a paper slip.

That is acceptable only if the record says that is what happened. A manually entered event, identified as manually entered, with the person who entered it, when, and against what evidence, is a defensible record. The same event recorded as though a station captured it is a false statement on a document that may be read by a customer, an auditor or a lawyer, and the difference costs nothing at the time and everything later. The related discipline is that the person who performs a repair and the person who confirms it are not the same person where the operation is consequential, and that the record shows both.

Two smaller things that get missed. First, the bill of material against which the unit was built must be pinned by version, because engineering will revise it, and a genealogy that resolves the current revision will misdescribe every unit built before the change. Second, the unit's identity must survive the strip-down: if the serialised identity lives on a label attached to a component that was removed, the plant has just lost the thread, and pre-allocating and recording identity at the level that persists is a decision made long before this unit failed.

Genealogy answers questions about the past, so the only operation it can safely support is appending. Every edit you make to make the record tidier is a question a future recall will not be able to ask.