Chapter 7: Integration, Quality Systems and Maintenance Programmes

7.1 Mapping to AS9100D and AS9145

PHASE 4 of the standard opens with a short statement of intent: it defines continued-airworthiness evidence packaging, signed attestations to the type-certificate authority, and "the mapping of this PHASE's object types to AS9100D and AS9145 quality management expectations". The specification names the two quality standards but does not spell out the mapping. This section supplies it, because the mapping is what makes a WIA record useful to an auditor rather than merely tidy for a developer.

Why a data standard must speak the language of the QMS

Every organisation that designs, produces or maintains aircraft parts for a certificated product operates a quality management system. In practice that almost always means AS9100D (published in Europe as EN 9100 and in Asia as JISQ 9100), or its sector variants AS9110 for maintenance organisations and AS9120 for distributors. AS9100D takes the ISO 9001:2015 structure and adds aerospace requirements on top: configuration management, product safety, prevention of counterfeit parts, first article inspection, special-process control and key-characteristic management among them.

An auditor does not ask whether a database exists. The auditor asks to see how this serial number is known to come from the right material lot, the approval of the heat-treatment source, the first article report for the current drawing revision. If each such question has an obvious home in the WIA objects, the implementation becomes part of the QMS evidence; if not, it becomes one more system to reconcile by hand before every audit.

Clause-by-clause mapping

The table below pairs the AS9100D clauses that most directly concern component records with the WIA-SPACE-016 object that can carry the evidence. Where the reference types in types.ts have no suitable field, the table says so and names the metadata key that an implementation could use until an additive extension is agreed. The keys in the last column are suggestions by this book, not names defined by the standard.

Two observations follow from the table. First, most of the gaps are about linking: the WIA record identifies the part well but does not point to the documents an auditor already keeps (drawing revision, FAI report, release certificate, nonconformance report). Second, the Certification object conflates two different things. A design-level approval (a TSO authorisation, an STC, a PMA) and a release document for one physical item (an FAA Form 8130-3 or EASA Form 1) have different issuers, lifetimes and meanings. An implementation should record which one it holds, for example with metadata.certificateKind, until the object is split in a later version.

AS9145: planning quality before the first part

AS9145 is the aerospace adaptation of advanced product quality planning (APQP) and the production part approval process (PPAP). It organises new-product introduction into five phases: planning; product design and development; process design and development; product and process validation; and ongoing production, use and post-delivery. Its typical deliverables include design and process failure mode and effects analyses (DFMEA, PFMEA), a control plan, measurement system analysis, process capability studies, a first article inspection and, at the end, a PPAP submission that the customer approves.

These phases line up with the ComponentStatus enumeration more closely than one might expect. design covers the first two phases; testing covers process design and validation; the transition to certified should not happen until the validation evidence exists; production corresponds to the ongoing-production phase. The practical rule for implementers is that a status transition is itself a quality event. A transition from testing to production without an associated FAI record and PPAP approval reference is a finding waiting to happen, and a well-designed implementation refuses the transition rather than logging it silently.

Configuration management and counterfeit prevention

Configuration management asks one question over and over: is the physical item in front of me the one the approved design describes? For a component record that means the part number alone is not enough. The same part number can exist in several drawing revisions, and a service bulletin may change a part without changing its number (the modification status is then marked on the data plate). A record that stores only partNumber cannot answer the configuration question. Implementations should carry the drawing revision and the list of incorporated modifications, and should treat any change to either as an update that needs an author, a reason and a reference document.

Counterfeit and suspected unapproved parts (discussed as a pitfall in Chapter 6) are the other side of the same coin. AS9100D clause 8.1.4 requires organisations to plan and control processes for preventing counterfeit parts, including sourcing from original or authorised manufacturers and verifying documentation. The WIA contribution is modest but real: a verifyCertification call against the issuing party, and a traceability chain in which every change of custody is signed. Neither replaces physical inspection of the part and its markings; both make it harder for a paper trail to be invented after the fact.

7.2 Special Processes and Nadcap

A special process is one whose result cannot be fully verified by subsequent inspection or test of the finished part. Heat treatment is the classic example: a 7075 forging that was aged at the wrong temperature looks exactly like a correct one, and its hardness may even fall inside tolerance, but its fracture toughness and resistance to stress-corrosion cracking can be compromised. Because the product cannot prove its own correctness, the process must be proven instead, by qualified procedures, qualified operators, calibrated equipment and records of each run.

Which processes are "special"

The list is set by the customer and the quality system rather than by physics, but it consistently includes heat treating, chemical processing (anodising, plating, chemical conversion coating, chemical milling), coatings, welding and brazing, non-destructive testing, composite fabrication and bonding, shot peening and surface enhancement, and certain measurement and inspection activities. The PHASE 4 specification lists welding, heat treatment, NDT, chemical processing and composite materials; the Nadcap programme covers these and more.

Nadcap in outline

Nadcap is an industry-managed accreditation programme for special processes, administered by the Performance Review Institute (PRI). Prime contractors participate in task groups that write commodity-specific audit checklists; suppliers are audited against those checklists, and the accreditation is recognised by the participating primes in place of individual customer audits. Accreditation is issued per commodity and per site.

The specification's figures for audit frequency ("surveillance every 6–12 months, re-certification every 2–3 years") do not describe how Nadcap works and should not be used. Nadcap accreditation periods are merit-based: a supplier starts on a 12-month cycle and can extend its accreditation to 18 or 24 months by sustaining a good audit record. The exact criteria are set by PRI and the task groups and change over time, so an implementation should store the accreditation's actual expiry date rather than compute it.

Linking process records to serial numbers

For traceability, a special process is only useful if the record says which serial numbers went through which run. A heat-treatment furnace load may contain dozens of parts; a chemical-processing line may process a whole batch in one tank; an NDT technician may inspect a lot of fittings in a single shift. When a process escape is discovered, the question is always "which parts were in that load?" and the answer must come back in minutes, not weeks.

The reference AircraftComponent has no field for process history, so the record below shows one way to carry it in metadata. Everything under metadata.processRecords is an illustrative extension, not a normative structure; identifiers and certificate numbers are invented placeholders.

{
  "id": "cmp-7f3a91",
  "type": "landing-gear",
  "status": "production",
  "partNumber": "EXAMPLE-MLG-TL-0042",
  "serialNumber": "TL-000731",
  "manufacturer": "Example Forge & Machining",
  "manufacturingDate": "2026-03-18",
  "metadata": {
    "materialLot": "HEAT-EX-55120",
    "processRecords": [
      {
        "process": "heat-treatment",
        "specification": "customer process spec, rev C",
        "sourceAccreditation": {
          "program": "Nadcap",
          "commodity": "heat treating",
          "expires": "2027-01-31"
        },
        "loadId": "FURN2-2026-0311-04",
        "completed": "2026-03-11"
      },
      {
        "process": "penetrant-inspection",
        "specification": "customer NDT spec, rev F",
        "operatorCertification": "EN 4179 level 2",
        "result": "accept",
        "completed": "2026-03-15"
      }
    ]
  }
}

Two design choices in the example matter more than the field names. The accreditation is recorded as it stood on the day of the process, with its own expiry date, so that a later lapse does not retroactively invalidate a part made while the source was approved. And the furnace load is given its own identifier, so that the reverse question ("which serial numbers were in load FURN2-2026-0311-04?") can be answered by a simple query across records.

7.3 Maintenance Programmes

Once a component enters service, its record is driven less by the manufacturer and more by the operator's maintenance programme. Understanding how that programme is built explains which inspection dates and intervals end up in the record and why they are expressed the way they are.

From MSG-3 to the operator's programme

For transport-category aircraft the initial scheduled maintenance is developed with the MSG-3 methodology, maintained by Airlines for America (A4A). A Maintenance Review Board or equivalent working groups of manufacturer, operators and authority analyse each system, structural item and zone, and the result is published as the Maintenance Review Board Report (MRBR), approved by the authority. The manufacturer then issues a Maintenance Planning Document (MPD) that packages those tasks with practical information. Each operator builds its own approved maintenance programme from the MPD, adapted to its utilisation, environment and reliability data.

MSG-3 is task-oriented. For systems and powerplant it leads to task types such as lubrication and servicing, operational or visual checks, inspection or functional checks, restoration, and discard. For structures it evaluates three sources of deterioration: accidental damage, environmental deterioration (chiefly corrosion) and fatigue damage. Older terminology from MSG-2 described maintenance processes as hard time, on-condition and condition monitoring. Those terms remain in everyday use and are still a useful way to describe how a particular component is managed:

Check packages and intervals

Operators group tasks into check packages. The familiar names are line checks, A-checks, C-checks and heavy structural checks (sometimes still called D-checks). The intervals quoted in the specification (for example "A check every 500–800 flight hours" or "D check every 6–10 years") are plausible for some fleets but they are not a standard; they are set by each type's MPD and each operator's programme, and some modern programmes do not use lettered checks at all but schedule each task at its own interval ("equalised" or task-based maintenance). A WIA implementation should never derive a due date from the check name.

What a WIA implementation must handle is that a single task interval is often expressed in more than one unit: flight hours, flight cycles and calendar time, with "whichever occurs first" as the rule. The reference Inspection type offers only nextInspectionDate, a calendar field. For a component whose driving parameter is cycles (landing gear, pressurised structure) that is not sufficient. A pragmatic approach is to keep nextInspectionDate as a forecast computed from utilisation and to carry the governing limits explicitly:

{
  "id": "insp-2026-0412",
  "inspectionDate": "2026-04-12",
  "inspector": "MRO-EX / stamp 118",
  "method": "eddy-current",
  "result": "pass",
  "findings": "No indications at lug bore, both sides.",
  "nextInspectionDate": "2027-02-01",
  "metadata": {
    "taskReference": "operator AMP task, example ref 32-11-01-210",
    "interval": { "flightCycles": 3000, "calendarMonths": 24, "rule": "whichever-first" },
    "atInspection": { "flightCycles": 18450, "flightHours": 31200 },
    "forecastBasis": "fleet average utilisation, recomputed monthly"
  }
}

Here nextInspectionDate is only a forecast that drifts with utilisation; the authoritative due point is the interval plus the counters at inspection. Keeping both lets the organisation explain later why a date moved.

7.4 Non-Destructive Inspection Methods

Non-destructive inspection (NDI, or NDT in manufacturing contexts) is the set of techniques that find flaws without harming the part. It is the physical activity behind most Inspection records, and the choice of method determines what the record can and cannot claim. A "pass" from a visual inspection and a "pass" from an eddy-current inspection of the same fitting are not the same statement.

The main methods

Visual inspection, general or detailed, with lighting, mirrors, magnifiers and borescopes, remains the most common method. It finds corrosion, impact damage, leaks, missing fasteners and cracks large enough to see. Liquid penetrant inspection draws a coloured or fluorescent liquid into surface-breaking discontinuities by capillary action; after the excess is removed a developer draws it back out as a visible indication. It works on any non-porous material but only for flaws open to the surface.

Magnetic particle inspection magnetises a ferromagnetic part; a surface or near-surface crack disturbs the field and leaks flux, which gathers fine iron particles into a visible line. It cannot be used on aluminium, titanium, austenitic stainless steels or composites, which rules it out for most airframe structure but makes it a workhorse for steel landing-gear and engine-mount parts.

Eddy-current inspection induces alternating currents in a conductive part with a probe coil; a crack interrupts the current paths and changes the coil's impedance. Sensitivity is concentrated near the surface. The standard depth of penetration is

δ = 1 / √(π · f · μ · σ)

  f  excitation frequency (Hz)
  μ  magnetic permeability (H/m); μ0 = 4π × 10⁻⁷ for non-magnetic alloys
  σ  electrical conductivity (S/m)

Example (illustrative): 2024-T3 aluminium, conductivity about 30 % IACS
  σ ≈ 0.30 × 58 MS/m ≈ 17.4 MS/m,  f = 100 kHz
  δ ≈ 1 / √(π × 10⁵ × 4π × 10⁻⁷ × 1.74 × 10⁷) ≈ 0.38 mm

The formula explains why high frequencies are used for surface cracks and low frequencies for second-layer cracks in lap joints and for corrosion thinning.

Ultrasonic inspection sends high-frequency sound into the part and listens for reflections (pulse-echo) or for loss of the transmitted signal (through-transmission). It finds internal flaws, measures thickness and is the primary method for composites, where it detects delaminations and disbonds. Phased-array probes steer and focus the beam electronically and produce images rather than single traces. Radiography, with X-rays or gamma sources, records differences in absorption on film or a digital detector. It shows voids, inclusions, foreign objects and water ingress in honeycomb, but it is insensitive to cracks that are not aligned with the beam and requires radiation safety controls.

Choosing and recording the method

The table exposes a gap in the reference enumeration: liquid penetrant, one of the most widely used methods, has no value. Thermography, shearography and acoustic emission are also absent, although they are less common in routine maintenance. Adding values to an enumeration is technically additive, but Annex E's rule ("additive changes such as new optional fields are non-breaking") does not settle the question for enums, because a strict consumer that validates against the old list will reject a record containing "penetrant". Until a version of the standard adds the value, the safe choice is to record the closest honest description in findings and the true method in metadata.ndiMethod, and never to label a penetrant inspection as visual just to pass validation.

Three further facts should accompany every NDI record, because without them the "pass" cannot be evaluated: the procedure used (typically a task in the manufacturer's non-destructive testing manual), the qualification level of the inspector (aerospace NDT personnel are usually qualified to NAS 410 or EN 4179), and the identity and calibration status of the equipment and reference standard. The reference type holds only inspector as a free-text string.

7.5 Fatigue and Damage Tolerance

Fatigue is the reason most inspection intervals exist. Aircraft structure is loaded thousands of times per flight by gusts and manoeuvres and once per flight by pressurisation, and each of those cycles can advance a crack that no single load would ever start. Three design philosophies have been used to deal with it. Safe-life design retires a part before a crack is expected, with a large scatter factor; it is still used for landing-gear parts and some engine parts. Fail-safe design provides alternative load paths so that the failure of one member does not lose the structure. Damage tolerance, required for transport-category airframes by FAR/CS 25.571, assumes that flaws exist and shows that they will be found by inspection before they reach a critical size.

S-N curves and Miner's rule

Safe-life analysis starts from the S-N curve: the number of cycles N to failure at a constant stress amplitude S, measured on specimens or components. Real service loading is a mixture of amplitudes, and the most widely used way to combine them is the Palmgren-Miner linear damage rule:

D = Σ nᵢ / Nᵢ        failure predicted when D reaches 1 (by convention)

Example (illustrative numbers, not material data):
  block 1: n₁ = 20 000 cycles at a level where N₁ = 100 000   → 0.20
  block 2: n₂ =  5 000 cycles at a level where N₂ =  25 000   → 0.20
  D = 0.40   → 40 % of the predicted life consumed

Miner's rule ignores load-sequence effects and test results scatter widely around D = 1, which is why safe-life limits carry substantial factors. A record system should not calculate a safe life; its job is to store the approved limit and the consumed cycles accurately.

This is also the right place to repeat a warning from Chapter 5: the SDK helper ComponentAnalyzer.estimateFatigueLife implements N = 10^(8 − 3·log10(S/Su)), which returns 100 million cycles when the stress S equals the ultimate strength Su. A real part loaded to its ultimate strength fails in one cycle. The function is an anti-example and must not feed StructuralAnalysis.fatigueLife.

Crack growth: the Paris law

Damage tolerance works with crack growth rather than crack initiation. Linear elastic fracture mechanics describes the stress field at a crack tip with the stress intensity factor K, and in the middle range of growth rates the crack advance per cycle follows a power law of the stress-intensity range, known as the Paris law:

da/dN = C · (ΔK)^m          ΔK = Y · Δσ · √(π · a)

  a    crack length (m)            N   cycles
  Δσ   stress range (MPa)          Y   geometry factor (dimensionless)
  C, m material constants from crack-growth tests

Critical crack length from fracture toughness Kc:
  a_c = (1/π) · (Kc / (Y · σ_max))²

Integrating (Y constant, m ≠ 2):
  N(a₀→a₁) = [a₀^(1−m/2) − a₁^(1−m/2)] / [C · (Y·Δσ·√π)^m · (m/2 − 1)]

Example — ALL VALUES ILLUSTRATIVE, NOT DESIGN DATA:
  C = 1 × 10⁻¹¹ (m/cycle, ΔK in MPa·√m), m = 3, Y = 1.0
  Δσ = σ_max = 150 MPa (R = 0), Kc = 60 MPa·√m

  a_c = (1/π) · (60 / 150)² ≈ 0.0509 m ≈ 51 mm
  Assumed initial flaw     a₀    = 1.27 mm
  Reliably detectable size a_det = 5 mm (for the chosen NDI method)

  Growth a₀   → a_c : N ≈ 251 000 cycles
  Growth a_det → a_c : N ≈ 103 000 cycles

  With an example factor of 2 on each:
    inspection threshold ≈ 251 000 / 2 ≈ 125 000 cycles
    repeat interval      ≈ 103 000 / 2 ≈  51 000 cycles

The numbers are deliberately simple and far more generous than a real detail would be; stress concentrations at fastener holes raise Y well above 1, service spectra are not constant-amplitude, and the factors applied are those of the type-certificate holder's approved methodology. What the example shows is the logic that FAR/CS 25.571 requires: the inspection threshold comes from the growth of an assumed initial flaw, the repeat interval comes from the growth between the detectable size and the critical size, and the detectable size depends on the inspection method. Change the method from detailed visual to eddy current and the detectable size shrinks, the growth window widens and the interval can lengthen. This is why the method in an Inspection record is not a detail.

The specification's statements that the threshold is "50% of calculated life" and that inspections repeat "every 10,000 flights" do not follow from this logic and should not be used as rules.

Widespread fatigue damage, limit of validity and corrosion

Damage tolerance assumes that cracks occur one at a time. As an airframe ages, many small cracks can appear at similar details at once, for example along a lap joint, and together they can reduce residual strength before any single crack is detectable. This is widespread fatigue damage (WFD). In the United States, 14 CFR Part 26 requires type-certificate holders of large transport aeroplanes to establish a limit of validity (LOV) of the engineering data that supports the maintenance programme, expressed in flight cycles or flight hours; operators may not operate an aeroplane beyond it without further approved action. EASA has comparable requirements. For a WIA record, the LOV is a property of the aircraft rather than of a single component, but components installed in the structure inherit its consequences.

Corrosion is the other major cause of structural deterioration. Operators of transport aeroplanes run a corrosion prevention and control programme (CPCP), in which corrosion findings are graded by severity and fed back into task intervals. Corrosion findings belong in Inspection.findings with a grade and location, so that fleet trends can be analysed.

What goes into StructuralAnalysis

The reference StructuralAnalysis object holds an applied load, a calculated stress, a safety factor, a fatigue life in cycles, a date and an analyst. That is enough to record the result of a static strength check (Chapter 1) but not a damage-tolerance analysis. A damage-tolerance result needs, at minimum, the assumed initial flaw, the detectable size and method, the critical size, the threshold and repeat interval, and a reference to the approved analysis report. Until the standard defines such an object, implementations should store the report reference and the approved threshold and interval, and should not store a single "fatigue life" number that invites misreading.

7.6 Evidence Packaging

PHASE 4 asks for two things: continued-airworthiness evidence packaged as a CycloneDX 1.5 document, and signed attestations submitted to the authority using the in-toto Attestation Framework 1.0, signed with Sigstore (DSSE envelopes and entries in the Rekor transparency log). The specification names the formats but gives no example of how an aircraft component fits into them. This section proposes one.

A component as a bill of materials

CycloneDX began as a software bill of materials (SBOM) format, but it has component types for hardware (device) and embedded software (firmware), and it lets any component carry name–value properties. That is enough to describe an avionics LRU with its hardware part number, its loaded software part number and its serial number, and to point to the WIA record.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79",
  "version": 1,
  "metadata": {
    "timestamp": "2026-05-02T08:14:00Z",
    "component": {
      "type": "device",
      "bom-ref": "lru-vhf-00417",
      "name": "VHF transceiver (example)",
      "version": "HW mod status 3",
      "supplier": { "name": "Example Avionics" },
      "properties": [
        { "name": "wia:partNumber",   "value": "EX-VHF-9000-01" },
        { "name": "wia:serialNumber", "value": "00417" },
        { "name": "wia:componentId",  "value": "cmp-a02c55" },
        { "name": "wia:status",       "value": "maintenance" }
      ]
    }
  },
  "components": [
    {
      "type": "firmware",
      "bom-ref": "sw-vhf-ops",
      "name": "VHF operational software (example)",
      "version": "EX-SW-VHF-0305",
      "hashes": [
        { "alg": "SHA-256",
          "content": "9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08" }
      ]
    }
  ],
  "dependencies": [
    { "ref": "lru-vhf-00417", "dependsOn": [ "sw-vhf-ops" ] }
  ]
}

The wia: property names are this book's suggestion; CycloneDX only requires that property names be strings, and a namespace prefix avoids collisions with other taxonomies. Note that the software part number is recorded as a first-class component with a hash. That fills the gap noted in Chapter 4, where the reference AircraftComponent type has no place for a software part number: the BOM, not the component record, becomes the authoritative list of what is loaded.

Attesting an inspection

A BOM says what an item is. An attestation says what was done to it and by whom. The in-toto Statement wraps a subject (identified by a cryptographic digest) and a predicate of a declared type. The predicate type below is invented for illustration; WIA-SPACE-016 does not define one, and a working group would need to publish it before it could be relied upon.

{
  "_type": "https://in-toto.io/Statement/v1",
  "subject": [
    {
      "name": "wia-record/cmp-7f3a91.json",
      "digest": { "sha256": "2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7ae" }
    }
  ],
  "predicateType": "https://example.org/wia-space-016/inspection/v0.1",
  "predicate": {
    "inspectionId": "insp-2026-0412",
    "method": "eddy-current",
    "result": "pass",
    "procedure": "NDT manual task (example ref)",
    "inspectorQualification": "EN 4179 level 2",
    "organisationApproval": "Part-145 approval reference (example)"
  }
}

The Statement is serialised, base64-encoded and placed in a DSSE envelope (payloadType application/vnd.in-toto+json), which is then signed. With Sigstore, the signer can use a short-lived certificate bound to an organisational identity, and the signature is recorded in the Rekor transparency log, so that anyone can later verify when the attestation was made and that it has not been altered, without trusting a private certificate authority. Tooling such as cosign attest and cosign verify-attestation performs these steps.

Signing does not make a record true: it proves who asserted something and when, not that the inspection was done correctly. Its value is that later alteration becomes detectable and every assertion has an accountable party, which is what a back-to-birth trail needs.

Retention

Annex E states that a 7-year retention window satisfies ISO/IEC 17065 audit expectations in most jurisdictions and that deployments must extend it where regulators require more. For aircraft components, "more" is common. Records that establish the status of life-limited parts and the back-to-birth history of a component must follow the part for as long as it is in service, and are often kept beyond its retirement. Seven years should therefore be treated as a floor for audit logs, not as the lifetime of component records. The signed packages should be stored with their transparency-log entries, so that they can still be verified after signing certificates have expired.

7.7 Integrating Existing Systems

No organisation starts a WIA implementation with an empty database. Suppliers run ERP systems with item masters and lot tracking; MRO organisations run maintenance information systems with work orders and shop findings; airlines run technical-records systems with installed-part histories that go back decades. The WIA implementation succeeds only if it can exchange data with these systems without creating a second, disagreeing version of the truth.

Existing industry vocabularies

Two established families of specifications already cover much of the ground. ATA Spec 2000, maintained by Airlines for America, defines e-business standards for the aviation supply chain, including permanent part marking and automated identification (2D codes on parts), electronic exchange of release certificates and reliability data. ATA iSpec 2200 and the older ATA 100 define the chapter-section-subject numbering used throughout maintenance manuals, while S1000D is the international specification for technical publications based on a common source database. A WIA record does not replace any of these; it should reference them. The most immediate use is to tag each component with its ATA chapter, so that records can be joined to manuals, task cards and reliability reports.

The table also shows why the nine ComponentType values are too coarse for integration on their own. avionics spans communications, navigation, indicating and recording systems, and a search by type will return everything from a VHF radio to a flight data recorder. Storing the ATA chapter in metadata.ataChapter is a cheap way to add the missing resolution.

Identifier reconciliation

Migration projects fail on identifiers far more often than on formats. Part numbers arrive with and without dashes, with trailing spaces, in different case, and with supplier prefixes added by an ERP system. The same serial number can be assigned by two manufacturers. Superseded part numbers remain in old records. A part may have been re-identified after modification and now carries two data plates. The rules below keep reconciliation honest:

• Compose the key, do not assume it. The natural identity of a physical part is the combination of manufacturer (ideally its CAGE code or equivalent), part number and serial number. Neither P/N nor S/N is unique on its own.
• Normalise for matching, store as marked. Remove spaces and fold case to find candidates, but keep the identifier exactly as it appears on the data plate and on the release certificate. Those two must match character for character.
• Record supersession and re-identification as events. A new part number after a modification is a new state of the same physical item, not a new item. Losing that link breaks the back-to-birth trail.
• Never merge silently. Two source records that normalise to the same key but disagree on history are a finding, not a duplicate. Park them in a conflict queue with both sources attached and let a qualified person decide.

The reference SDK adds a practical constraint: ComponentSearchQuery filters by type, status, manufacturer, certification requirement and material type, but not by part number or serial number, so it cannot be used to look up the reconciliation key. The sketch below does the matching locally on exported records and reports conflicts instead of merging them.

import type { AircraftComponent } from '@wia/aircraft-component';

const norm = (s: string): string => s.replace(/[\s-]/g, '').toUpperCase();

function naturalKey(c: AircraftComponent): string {
  const cage = String(c.metadata?.cageCode ?? c.manufacturer);
  return [norm(cage), norm(c.partNumber), norm(c.serialNumber)].join('|');
}

interface Conflict { key: string; records: AircraftComponent[]; reason: string; }

function reconcile(records: AircraftComponent[]): {
  unique: AircraftComponent[]; conflicts: Conflict[];
} {
  const byKey = new Map<string, AircraftComponent[]>();
  for (const r of records) {
    const k = naturalKey(r);
    byKey.set(k, [...(byKey.get(k) ?? []), r]);
  }
  const unique: AircraftComponent[] = [];
  const conflicts: Conflict[] = [];
  for (const [key, group] of byKey) {
    if (group.length === 1) { unique.push(group[0]); continue; }
    const asMarked = new Set(group.map(g => `${g.partNumber}/${g.serialNumber}`));
    conflicts.push({
      key,
      records: group,
      reason: asMarked.size > 1
        ? 'identifiers differ as marked; check data plate and release certificate'
        : 'same identifiers, separate histories; review before any merge',
    });
  }
  return { unique, conflicts };
}

What the reference implementation does and does not give you

The @wia/aircraft-component SDK defines types and the endpoints for components, analyses, inspections and certification, but its makeRequest method returns the request body as mock data rather than calling a server. It has no methods for the maintenanceEvent, serviceBulletin or traceability operation groups named in PHASE 2. The api/openapi.yaml file referenced by the specification does not exist in the repository, and PHASE 4 names CycloneDX, in-toto and Sigstore without defining WIA-specific predicates or properties. An integration project therefore has to make and document its own choices in these areas. The suggestions in this chapter are one consistent set of such choices, written so that they can be promoted into the standard later as additive changes.

Chapter Summary

• WIA records become quality evidence when each AS9100D question an auditor asks has an obvious home in them; most current gaps are missing links to drawing revisions, FAI reports, release certificates and nonconformance reports.
• ComponentStatus transitions line up with AS9145 phases, and a transition without its validation evidence should be refused, not logged.
• Special processes are proven by their records, not by the part; process runs must be linked to serial numbers, and Nadcap accreditation expiry should be stored, not computed.
• Maintenance intervals come from MSG-3 analysis through the MRBR, MPD and operator programme, are often expressed in several units, and cannot be derived from a check name.
• The NDI method determines what an inspection proves and, through the detectable crack size, the inspection interval; penetrant inspection is missing from the reference enum.
• Damage-tolerance intervals follow from crack growth between assumed, detectable and critical sizes; a single "fatigue life" number and the SDK's estimateFatigueLife must not stand in for that analysis.
• CycloneDX can describe a component with its embedded software, and in-toto Statements signed through Sigstore make each assertion attributable and tamper-evident; seven years is a floor for retention, not the life of a component record.
• Integration succeeds or fails on identifier reconciliation: compose the key from manufacturer, P/N and S/N, store identifiers as marked, and never merge conflicting histories silently.