Skip to content

Life-limited parts

LLP traceability review against modification-baseline sources

Modifications complicate LLP trace in ways ordinary usage does not: an SB can change a part number, an STC can alter a limit's applicability, and a configuration change can reassign which status sheet a part lives on. This check reads the LLP status sheet against the modification-baseline source file, verifying that every part's identity, cycle history, and life limit survive the modifications the configuration-control logs record. It is run by or for configuration managers when a baseline is declared, a fleet changes hands, or a status sheet must be defended. You receive an exception list per part with the exact break point named.

When this review is needed

  • An SB re-identified life-limited hardware and the status sheet must show one continuous history across the old and new part numbers.
  • A configuration baseline is being certified and the LLP sheet is among the documents the baseline vouches for.
  • Parts moved between positions or assemblies during a modification campaign and cycle attribution needs proving.
  • A buyer or lessor has sampled one part's back-to-birth trace and the team wants the rest verified before further sampling.

The problem

The LLP status sheet presents a settled table of part numbers, serials, and cycles, but modifications rewrite the identities underneath it. A part re-marked under an SB carries its history under a superseded number in older records; a part relocated during a modification accumulates cycles under two positions; an STC can introduce hardware whose limits come from a different document set entirely. The status sheet gets updated by whoever executed the change, and the connecting evidence stays in the work package where the connection was made.

What gets reviewed

  • Each LLP's identity chain followed through every re-marking, re-identification, or supersession the SB and STC files record
  • Cycle histories reconciled across position moves and assembly changes noted in the configuration-control logs
  • Life limits on the status sheet checked against the limit source valid for the current configuration
  • Release documents behind each installed part matched to the part identity the sheet now carries
  • Effectivity notes checked so parts introduced by modification carry limits from the right document set
  • Status-sheet arithmetic verified: cycles used, cycles remaining, and the utilization basis behind them

Scope this review

Tell us the asset, the event, and the evidence in scope, and we will outline a focused first engagement.

Send a representative, redacted record set and we will scope the review.

What gets validated

  • Every part-number change on the sheet is anchored by the SB or work-order record that performed the re-identification
  • Cycle totals sum correctly across each part's installation segments, with no segment double-counted or dropped
  • The life limit quoted for each part matches the current configuration's limit source, including any STC-carried limits
  • Each serial number on the sheet appears in a release document consistent with its claimed identity and standing
  • No configuration-control log entry moves a part in a way the status sheet fails to reflect

Evidence normally required

  • The current LLP status sheet with utilization figures and limit references
  • SB records and STC files covering re-identifications and introduced hardware
  • Configuration-control logs and embodiment evidence for position and assembly changes
  • Release certificates such as FAA Form 8130-3 or EASA Form 1 for installed parts
  • Prior status sheets or operator records where histories predate the current sheet

Common discrepancies

  • A re-marked part whose pre-modification history exists only under the superseded part number, unlinked on the sheet
  • Cycles attributed to the wrong installation segment after a part moved positions during a campaign
  • A limit quoted from the baseline document set for a part whose applicable limit actually comes from an STC
  • A release certificate that predates the re-identification and so names a part number the sheet no longer shows

What is at stake

A trace that breaks at a part-number change reads to a reviewer as two different parts with two partial histories, and partial history for an LLP means the conservative assumption: unknown cycles, retirement math against the worst case, and a scrap-or-prove decision on hardware that may have decades of legitimate life. Because status sheets are copied into transactions, a single unproven identity chain repeats itself at every future sale, lease, and shop visit until someone pays to resolve it.

Move from findings to resolution

Move from findings to a documented resolution path.

How the work runs

01

Inventory the identities

List every LLP with each identity it has held, using SB and STC files to map re-markings and supersessions.

02

Rebuild each chain

Follow every part through installations, moves, and modifications, tying each segment to its evidence.

03

Test limits and math

Verify the applicable limit source per part and recompute cycles used and remaining.

04

Name the breaks

Report each broken chain at its precise break point with a recovery route and the verified annex for the rest.

What the buyer receives

  • A per-part exception list naming the exact document or event where each trace breaks
  • A verified-trace annex for parts whose chains close, citing the anchoring evidence
  • A recovery route for each break: which organization, package, or archive likely holds the missing link

Who uses the output

  • Configuration managers who must stand behind the baseline's LLP sheet
  • Powerplant and fleet engineers planning removals against proven remaining life
  • Transaction teams pre-empting the back-to-birth sampling a counterparty will run

How the work fits into the transaction or program

Within the modification-baseline review family, the LLP check depends on the SB, STC, and configuration-log evidence that neighboring reviews verify, and it feeds the release-document review whenever a certificate fails to match a re-identified part. Its exception list flows into remediation, where trace breaks are pursued with prior operators and shops before the retirement math forces a decision.

Jurisdiction-specific considerations

FAA practice around life-status documentation, shaped by 14 CFR 91.417 retention duties and Order 8130-21 on release documentation, differs in form from EASA's Regulation 1321/2014 requirements, and parts crossing between systems collect certificates of both kinds. Re-identification under an SB accepted by one authority may be documented differently for the other, so the review confirms the identity chain works under whichever authority the current configuration answers to.

Regulatory limits

The review reconstructs and verifies documentation. It does not extend or approve life limits, does not certify parts for installation, does not issue release documents, and does not make scrap-or-retain determinations. Where a trace cannot be closed, the operational decision on the part rests with the operator and its authority.

What this review does not cover

  • Physical inspection, measurement, or NDT of any part
  • Procurement of replacement hardware for unprovable parts
  • Engineering evaluation of the modifications themselves

Specific to this review

  • Re-identification SBs are where more LLP traces die than anywhere in ordinary service, because the old and new part numbers each look internally consistent and nothing forces the join except a reviewer.
  • Cycle attribution errors from position moves are invisible on a sheet that still sums correctly, since the total survives while the per-part history is wrong.
  • A release certificate is only as strong as its match to current identity: a pristine EASA Form 1 naming a superseded part number raises questions instead of settling them.
  • The economics are asymmetric: a day of records work that closes a trace can preserve hardware whose replacement cost runs to six or seven figures on large engine parts.

Sources

Frequently asked questions

We already have back-to-birth paperwork for these parts. Is this redundant?

Back-to-birth files are usually assembled per part at acquisition and then left static. This review tests those files against the modification history that has accumulated since, which is where identities and positions change. If the files still hold, the verified annex documents that; where they no longer match, the exception is found before a counterparty finds it.

Relevant glossary terms

Related pages

Where this fits

Talk to an engineer who has done this work

We will walk through your current state, the records or evidence involved, and a scoped first engagement.

Talk through the aircraft, records, evidence, deadline, and next useful step.