Chapter 6: The Supplier–MRO–Operator–Authority Protocol

6.1 Actors and messages

PHASE 3 of the standard states its purpose in one sentence: it defines the protocols between component supplier, MRO, operator and certification authority. It also makes a deliberate choice about what it does not do. The development assurance processes of ARP4754A (aircraft and systems), ARP4761A (safety assessment), DO-178C (airborne software) and DO-254 (airborne electronic hardware) already define what evidence exists and who produces it. PHASE 3 says its protocol schemas reflect the message types in those documents but do not redefine them. The practical meaning is that a WIA message carries evidence; it never replaces the plan, analysis or review that the evidence came from.

The rest of the PHASE 3 document, as Chapter 1 noted, is engineering content about flight controls, hydraulics and fuel, which Chapter 3 has already covered. The protocol itself is therefore assembled from three sources: the PHASE 3 introduction (the four roles), the five operation groups of PHASE 2 (the verbs available to those roles), and the implementation notes of Annex E (time synchronisation, retention, schema evolution). This chapter fills the gaps between them with established aviation practice and marks clearly where it is proposing something the standard does not yet specify.

The four roles

A single company can play several roles. An airline with its own engineering department is both operator and MRO; a Tier 1 supplier that also holds a repair station approval is both supplier and MRO. The protocol cares about the role in which a message is sent, not about the legal entity, because accountability attaches to the approval under which the work was done.

• Supplier — the organisation that manufactures the part under a production approval, or under the quality system of a production approval holder further up the chain. It originates the identity of every serial number and the first release certificate.
• Operator — the airline or other entity responsible for the continuing airworthiness of the aircraft on which the part is installed. It records installation, flight hours and cycles, removals, and compliance with airworthiness directives.
• MRO — an approved maintenance organisation that inspects, repairs, overhauls or modifies the part and releases it back to service. It originates inspection records and maintenance release certificates.
• Certification authority — FAA, EASA, the Korean Ministry of Land, Infrastructure and Transport (MOLIT) or another national authority, and organisations acting under delegated approval. It approves designs, issues airworthiness directives and verifies that certificates are genuine.

The design approval holder (the type certificate or STC holder, or the TSO/PMA holder for a part) is not listed as a fifth role in PHASE 3. In practice it acts through the supplier role when it issues service bulletins and through the certification-package exchange when it applies for approval. This book follows that simplification but keeps the originator's approval reference in every message so that the distinction can be recovered.

Principles every message follows

Four rules make the difference between a protocol and a shared spreadsheet. First, every message has one accountable originator, identified by organisation and approval number, and that originator is the only party allowed to correct it. Second, records are append-only: a wrong entry is superseded by a new entry that references it, never edited in place, because an auditor must be able to see what was believed at the time a decision was taken. Third, the subject of every message is a triple — manufacturer, part number, serial number — not a database identifier, because the id field of AircraftComponent is local to one system while the triple is what is engraved on the data plate. Fourth, paper still wins: where regulation requires a signed release certificate, the WIA message references and carries that certificate; it does not become a substitute for it.

A message envelope

The standard names operation groups but does not define a common envelope for them, and the reference SDK sends bare request bodies. An exchange between independent organisations needs more: an identifier for de-duplication, the originator, the subject triple, two timestamps and a signature. The envelope below is the structure this book uses in the remaining sections. It is a proposal consistent with the standard's rules (additive fields, DSSE signing as PHASE 2 already uses for manifests), not a normative schema; all values are fictitious.

{
  "messageId": "0d9c2f6e-5b1a-4c55-9d3e-2a71c4e0b8a4",
  "idempotencyKey": "mro-kr-017:wo-2026-00418:inspection:1",
  "operationGroup": "maintenanceEvent",
  "originator": {
    "role": "mro",
    "organisation": "Example Aero Repair Co.",
    "approvalRef": "EXAMPLE-145-0000"
  },
  "subject": {
    "manufacturerCage": "0XXX0",
    "partNumber": "EX-4410-203",
    "serialNumber": "EXS-00117"
  },
  "subjectSequence": 42,
  "occurredAt": "2026-03-14T06:20:00Z",
  "recordedAt": "2026-03-14T06:31:12Z",
  "supersedes": null,
  "payload": { },
  "signature": { "format": "dsse", "keyId": "mro-kr-017-2026" }
}

subjectSequence and the two timestamps are explained in Section 6.6; supersedes is how the append-only rule is implemented. The empty payload is filled with an operation-specific object, such as the maintenance event shown in Section 6.3.

6.2 New-part release

A serial number is born at the supplier. Before the first unit of a new or changed design ships, three things must be true: the design is approved, the production process has been shown to produce parts that conform to that design, and each unit leaves with a release document. The protocol has to capture all three, and the ComponentStatus field has to move only when the evidence exists.

First article inspection

AS9102, the aerospace standard for first article inspection (FAI), requires a complete, documented verification that the production process produces a part matching every requirement of the engineering definition. Its report is organised in three forms: part number accountability (which part, which revision, which subassemblies), product accountability (raw material, special processes and functional tests, each with the approved source and certificate), and characteristic accountability (every design characteristic — each dimension, note and specification requirement — with its measured result). The FAI is performed on a representative unit from the first production run, and must be repeated, fully or partially, when the design, the manufacturing process, the source, the tooling or the production location changes, or after production has lapsed for longer than the standard allows.

For the protocol, the important point is that FAI belongs to the process, while the release certificate belongs to the unit. A WIA record for serial number EXS-00117 should therefore reference the FAI report that covers its part number and revision, not duplicate it. Changes that invalidate an FAI must be visible to the system: if the drawing revision in the record is newer than the revision the referenced FAI covers, the record is incomplete and the unit should not advance.

Certificate of conformity and authorised release certificate

Two documents accompany each unit. The certificate of conformity (CoC) is the supplier's statement that the shipment conforms to the purchase order and the applicable drawing. It is a commercial quality document and is required by most purchase orders from sub-tier suppliers. The authorised release certificate — FAA Form 8130-3 in the United States, EASA Form 1 in Europe — is a regulatory document. For a new part it is issued under a production approval and certifies conformity to approved design data and condition for safe operation. The same forms are later used by maintenance organisations to release parts after work, with a status field indicating what was done (for example new, overhauled, repaired, inspected/tested or modified).

In a WIA record, the release certificate appears in two places. The document itself, or a controlled reference to it, travels with the maintenanceEvent or release message; its identifying data (form type, tracking number, issuing organisation, status/work) should be stored in metadata, because the reference AircraftComponent type has no dedicated field for it. The Certification object, by contrast, describes the design-level approval — which standard, which authority, which certificate number — and is shared by every unit of the same design approval.

Status transitions for a new part

Chapter 1 introduced the six ComponentStatus values. Here they become protocol states, and every transition must name the message that justifies it. Table 6-2 lists the transitions this book treats as valid. The standard does not publish a transition table; the one below is derived from the lifecycle and should be adopted as an implementation rule and declared in the interoperability profile described in Chapter 8.

Two cautions apply. First, the enumeration mixes design-level and unit-level states: design, testing and certified describe the part number, while production, maintenance and retired describe a serial number. An implementation that keeps one record per serial number will typically create unit records directly in production and hold the earlier states on a design-level record. Second, there is no "installed" or "in stock" state. The book's convention, carried over from Chapter 1, is to treat production as "released and serviceable" and to record installation and removal as maintenance events.

6.3 Maintenance event flow

Most of a part's recorded life happens after the first release. A landing gear side-brace or a hydraulic pump can be removed, repaired and reinstalled on different aircraft many times, and every visit adds records that the next owner will depend on. The maintenanceEvent operation group — "record, retrieve, query maintenance actions" in PHASE 2 — carries this history.

The steps of a shop visit

1. Removal. The operator (or a line maintenance organisation acting for it) removes the part and records the reason — scheduled (hard time, on-condition finding) or unscheduled (failure, suspected damage) — together with the aircraft registration and the part's hours and cycles since new and since last shop visit. The removal record is what makes later reliability analysis possible, and it is the most frequently incomplete record in practice.
2. Induction. The MRO receives the part, checks that the identity on the data plate matches the paperwork, and queries the traceability group for its history and any open airworthiness directives.
3. Inspection and teardown. The work follows the component maintenance manual (CMM) or other approved data. Each non-destructive inspection produces an Inspection record with a method from the standard's enumeration (visual, ultrasonic, radiographic, magnetic-particle, eddy-current) and a result of pass, fail or conditional.
4. Repair, modification or replacement of sub-parts. Each action cites its approved data (CMM task, structural repair data, SB number). Replaced sub-parts that carry their own serial numbers generate their own events, which is how assembly-level traceability is kept intact.
5. Test and release. After functional testing, the MRO issues a maintenance release on 8130-3 or Form 1 with the appropriate status, and the record moves from maintenance back to production.
6. Installation. The operator installs the part on an aircraft and records it; the release to service of the aircraft itself remains a separate, aircraft-level act.

Conditional results and next inspection dates

The conditional result is the most informative value in the enumeration and the easiest to misuse. It means the part was found acceptable only with a condition attached: a finding within limits that must be re-checked, a repair with a reduced inspection interval, or a concession. A conditional result without findings text and without a nextInspectionDate (or an equivalent hours/cycles limit) is, for protocol purposes, incomplete and should be rejected by the receiving system. Because many repeat inspections are driven by cycles rather than calendar time, and the reference type has only a date field, this book stores cycle-based limits in the event payload alongside the date, as the example shows.

{
  "eventType": "shopVisit",
  "workOrder": "WO-2026-00418",
  "component": {
    "partNumber": "EX-4410-203",
    "serialNumber": "EXS-00117",
    "type": "landing-gear"
  },
  "removal": {
    "reason": "scheduled",
    "aircraftRegistration": "HL-EXMP",
    "removedAt": "2026-02-27",
    "hoursSinceNew": 18250,
    "cyclesSinceNew": 9410,
    "cyclesSinceLastShopVisit": 4620
  },
  "approvedData": ["CMM 32-11-41 rev 12 (example)"],
  "inspections": [
    {
      "id": "insp-0001",
      "inspectionDate": "2026-03-12",
      "inspector": "EX-INSP-203",
      "method": "magnetic-particle",
      "result": "pass"
    },
    {
      "id": "insp-0002",
      "inspectionDate": "2026-03-13",
      "inspector": "EX-INSP-203",
      "method": "eddy-current",
      "result": "conditional",
      "findings": "Corrosion pitting at lug bore, blended within CMM limits; repeat check required",
      "nextInspectionDate": "2027-03-13"
    }
  ],
  "repeatInspection": { "cyclesLimit": 2000, "whicheverFirst": true },
  "release": {
    "form": "EASA Form 1",
    "trackingNumber": "EX-F1-2026-0331",
    "statusWork": "repaired"
  },
  "statusTransition": { "from": "maintenance", "to": "production" }
}

Three details deserve attention. The inspector is identified by an authorisation code rather than a person's name, which keeps personal data out of records that will be shared across companies for decades. The hours and cycles live in the event, not in the component record, because they are facts about a moment in time; the current totals are derived by summing the event stream. And the inspection records use exactly the Inspection shape from the reference types, so an MRO system that already calls the SDK's addInspection can produce them without translation. A dye-penetrant inspection, however, cannot be expressed: the method enumeration has no penetrant value, a gap Chapter 7 discusses.

6.4 Airworthiness directives and service bulletins

PHASE 2 describes the serviceBulletin group as the place to "issue and acknowledge airworthiness directives". The wording merges two documents that aviation keeps carefully apart, and a protocol that merges them will produce wrong compliance records.

This book therefore gives every message in the group a directiveKind of AD or SB, and requires an AD message that mandates an SB to reference that SB by number and revision. The distinction is additive under the schema-evolution rule of Annex E and does not break a consumer that ignores it.

From issue to compliance

The flow has four steps, each a separate message. Issue: the originator publishes the directive with its applicability. Applicability resolution: each operator and MRO evaluates it against its fleet and stock. Acknowledgement: each recipient confirms receipt and states which of its serial numbers are affected — including an explicit statement when none are. Compliance: when the action is done, a compliance record is attached to each affected serial number.

Applicability is where the data model earns its keep. It is rarely a simple part number. A typical directive applies to a part number, but only to serial numbers in a stated range, and only to units that have not yet received a particular modification. Resolving that requires three things the record must hold: the part number with its revision or dash number, the serial number, and the modification status (the list of SBs already embodied). The reference AircraftComponent carries the first two; modification status belongs in metadata until a dedicated field is standardised. Without it, a query through the traceability group can only over-report — flagging units already modified — which erodes trust in the whole system.

Two pitfalls recur. A recurring AD is not complied with once; each accomplishment sets the next due point in hours, cycles or calendar time, and the record must carry that point forward. And a part moved from one operator to another carries its AD status with it; the receiving operator must be able to see, from the part's own history, which directives have been accomplished and when the next action is due, without relying on the previous owner's aircraft-level records.

6.5 Certification-package submission

The certificationPackage group is the most sensitive of the five. PHASE 2 describes it as submitting certification evidence to FAA, EASA or the Korean authority, and requires mutual TLS for type-certificate authority callers. The SDK exposes it through two methods:

• requestCertification(componentId, standard) sends POST /components/{id}/certify and is typed to return { requestId }.
• verifyCertification(certificateNumber) sends GET /certifications/{certificateNumber}/verify and is typed to return { valid, details }.

It is worth being precise about what these calls can represent. Certification authorities do not approve designs by API. A type certificate, TSO authorisation or PMA results from a project — certification plan, compliance demonstrations, conformity inspections, test witnessing, findings closure — conducted between the applicant and the authority, or with an organisation holding delegated approval. The protocol models the submission of evidence within that project and the verification of the outcome afterwards. The requestId is a tracking handle for the submission; a successful response means the package was received, not that anything was approved.

The submission sequence

1. The applicant assembles the package: the component record, structural analysis summaries, test reports, conformity records, and the development assurance evidence required by ARP4754A, DO-178C or DO-254 for the item's assurance level. How the package is signed and described is the subject of Chapter 7.
2. The applicant calls requestCertification over an mTLS channel and stores the returned requestId against the design-level record.
3. The authority reviews the package outside the protocol. Findings, requests for more data and resubmissions are exchanged under the same requestId, each as a new message.
4. When approval is granted, the applicant records a Certification object — standard, authority, certificateNumber, issueDate, expiryDate, compliance — and the design moves to certified.
5. Any party can later call verifyCertification with the certificate number, for instance at goods receipt, and must treat anything other than an explicit positive answer as "not verified".

Using the SDK honestly

The reference client does not send network requests. Its private makeRequest method emits a request event and returns { success: true, data: body }, echoing whatever was sent. For requestCertification, the "response" is therefore { standard: "WIA-SPACE-016" }, with no requestId; for verifyCertification, which sends no body, data is undefined. Code written against the SDK must be correct against a real server, and that means failing closed.

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

const client = new WIAAircraftComponentClient({
  apiKey: process.env.WIA_API_KEY ?? '',
  timeout: 60000,
});

client.on('error', (err) => console.error('[wia] request failed', err));

async function submitPackage(componentId: string): Promise<string> {
  const res = await client.requestCertification(componentId, 'WIA-SPACE-016');
  const requestId = res.data?.requestId;
  if (!res.success || !requestId) {
    // The reference SDK echoes the request body, so requestId is absent here.
    throw new Error('Submission not acknowledged; do not mark as submitted');
  }
  return requestId;
}

async function acceptAtGoodsReceipt(certificateNumber: string): Promise<boolean> {
  const res = await client.verifyCertification(certificateNumber);
  // Only an explicit true is acceptance. Undefined, errors and timeouts
  // all mean "not verified": quarantine the part.
  return res.success === true && res.data?.valid === true;
}

The same discipline applies to Certification.compliance. A boolean set by the party that benefits from it is a claim, not evidence. A receiving system should accept it only when the certificate number verifies against the issuing authority's source, and should re-check it when expiryDate passes. Some approvals, such as a type certificate, have no expiry. Because expiryDate is mandatory in the reference type, such an approval should not be forced into a Certification object with a placeholder date; as Chapter 4 recommends, record it in metadata.approvalBasis instead, so that consumers do not raise false expiry alarms.

6.6 Timing, ordering and retries

A part's history is written by several organisations, on several systems, sometimes offline, over decades. Without explicit rules for time and order, the same history will be told differently by each participant.

Two timestamps and a sequence number

Annex E of the standard notes that sub-second deadlines depend on synchronised clocks, that NTPv4 with stratum-2 servers is sufficient for most deadlines in the standard, and that PTP is recommended for sites that need deterministic interlocks. Record exchange between companies rarely needs sub-second precision, but it does need a clear meaning for each time value. The envelope in Section 6.1 therefore carries two. occurredAt is when the physical event happened — the inspection, the removal — as stated by the originator; recordedAt is when the originator's system committed the record. Both are ISO 8601 in UTC. A removal typed into the system two days late is then honest about both facts.

Wall-clock time, however synchronised, is not a reliable ordering key across organisations. The envelope adds subjectSequence: a counter per serial number, incremented by the system that holds the authoritative history for that part, so that consumers can detect gaps (message 41 is missing) and reorder late arrivals. Hours and cycles provide a second, physical check: a record claiming fewer cycles since new than an earlier record is either a typing error or a sign that two different parts are sharing one identity, and in either case must stop the process.

Delivery and idempotency

Networks between hangars, shops and head offices fail, and a retry that creates a second copy of an inspection is as harmful as a lost one. The protocol therefore assumes at-least-once delivery: a sender retries until it receives an acknowledgement, and every receiver de-duplicates. The idempotencyKey is chosen by the originator from its own business identifiers (for example organisation, work order, record type and sequence), so that a retry after a crash produces the same key even if the process lost its memory. A receiver that sees a known key returns the original result without applying the change again. When a request is refused because of load, the receiver answers with HTTP 429 and a Retry-After header, as PHASE 2 specifies with reference to RFC 6585, and the sender waits at least that long.

Updates to a shared record — the PUT /components/{id} of the SDK — need optimistic concurrency: the sender states the version it read, and the receiver rejects the update if the record has changed since. Appending events avoids most conflicts in the first place, which is one more reason to keep hours, cycles and status changes as events rather than as fields that several parties overwrite.

Offline hangars

Line stations and shops frequently work without a reliable connection. The recommended pattern is store and forward: the local system creates and signs the message at the moment of the work, queues it with its occurredAt time, and sends it when connectivity returns. Because the message is signed and carries its idempotency key, it can pass through intermediate systems without losing its origin, and the receiver can apply it in sequence order even if it arrives days later. What must not happen is re-keying from paper at a head office without the original originator identity; that turns an MRO record into an office record and breaks accountability.

One part's life as a sequence

Supplier              Operator              MRO                   Authority
   |                     |                    |                      |
   |-- package (req) ------------------------------------------------>|  [certificationPackage]
   |<------------------------------------------------ approval / cert-|
   |  FAI (AS9102), CoC, 8130-3 / Form 1                             |
   |-- identity + release ->|                  |                      |  [componentCatalog, traceability]
   |                     |-- verify cert --------------------------->|  [certificationPackage]
   |                     |-- install event    |                      |  [maintenanceEvent]
   |                     |<------------------------------------ AD --|  [serviceBulletin]
   |-- SB (for design holder) ->|               |                      |  [serviceBulletin]
   |                     |-- ack + applicability                     |
   |                     |-- removal event -->|                      |  [maintenanceEvent]
   |                     |                    |-- history query      |  [traceability]
   |                     |                    |-- inspections, repair|  [maintenanceEvent]
   |                     |<-- Form 1 release -|                      |
   |                     |-- install / AD compliance record          |  [maintenanceEvent]
   |                     |        ...  (repeat shop visits)  ...     |
   |                     |-- retirement + mutilation record         |  [maintenanceEvent]

The figure shows why the traceability group is central. Every arrow adds to the same subject, and every later participant — a new operator after a lease return, an MRO doing its tenth shop visit, an investigator after an occurrence — reconstructs the part from that stream. The standard's Annex E sets seven years as a retention floor that satisfies most audit expectations and requires deployments to extend it where regulators ask for more. For life-limited and serialised parts, back-to-birth records are commonly kept for the whole life of the part and beyond; the protocol should treat the seven-year figure as a minimum for message logs, not as a limit on part history.

6.7 Pitfalls

The failures below are not hypothetical categories invented for the book; they are the recurring ways parts-traceability systems let bad parts in or good parts out. Each has a protocol-level defence.

Suspected unapproved parts

An unapproved part is one not produced or maintained in accordance with approved procedures, or not conforming to approved design data — counterfeit parts, parts from unapproved sources, parts with falsified documents, and scrapped parts that re-entered the supply chain. The FAA publishes guidance on detecting and reporting suspected unapproved parts (SUPs) in Advisory Circular 21-29, and other authorities operate similar reporting schemes. A protocol helps in two ways: it makes the expected history of a genuine part queryable, so that a part arriving with no history or with a history that ends at a scrap record stands out; and it gives receiving inspection a machine check — verify the release certificate, compare the data plate triple with the record, confirm the status is production — before any human signs for the part. A SUP report should itself be a message, linked to the subject, so that every holder of that serial number sees the flag.

Broken back-to-birth trail

A gap in history — a missing shop visit, an unexplained jump in cycles, an operator change without transfer records — does not prove a part is bad, but it removes the evidence that it is good. For life-limited parts, a gap can make the part unusable because remaining life cannot be established. Defences: the per-subject sequence number makes gaps detectable; hours and cycles monotonicity makes inconsistent histories detectable; and a rule that transfer between operators is a message in its own right, carrying the accumulated history, prevents the most common gap.

Duplicate serial numbers after data migration

When two databases are merged, the same serial number often appears twice. Sometimes these are genuinely different parts from different manufacturers or with different part numbers, which is legitimate; sometimes they are one part recorded twice with slightly different spellings; occasionally they are two physical parts carrying the same identity, one of which is not what it claims to be. The protocol's rule that the subject is the full triple — manufacturer, part number, serial number — resolves the first case. The second and third cannot be resolved automatically. A migration should normalise formatting (case, leading zeros, separators) under documented rules, flag every remaining collision for human review, and never merge histories silently.

The last row deserves repeating. The simulator's Protocol tab prints a fixed log of successful calls, and the SDK echoes its inputs. Both are useful for learning the shape of the exchange; neither tells you whether your integration is correct. Chapter 8 describes the test vectors and conformance evidence that do.

Chapter summary

• PHASE 3 defines a protocol between supplier, operator, MRO and certification authority. It carries evidence produced under ARP4754A, ARP4761A, DO-178C and DO-254 without redefining it.
• Every message has one accountable originator, is append-only, and names its subject by manufacturer, part number and serial number. A proposed envelope adds an idempotency key, a per-subject sequence number, two timestamps and a signature.
• A new part is released on the strength of an AS9102 first article inspection for its process and a CoC plus 8130-3 or Form 1 for the unit. ComponentStatus transitions must each be justified by named evidence; retired is final.
• Maintenance events carry removal data, Inspection records, approved data references and a maintenance release. A conditional result needs findings and a next-inspection limit.
• ADs are mandatory and issued by authorities; SBs are issued by design holders and are optional unless mandated. Keep them apart, and model applicability with part number, serial range and modification status.
• Certification-package calls track evidence submission and verify outcomes; they do not approve anything. Verification must fail closed, which the echoing reference SDK makes easy to overlook.
• Use occurredAt and recordedAt, sequence numbers, at-least-once delivery with idempotency, and store-and-forward for offline sites. Seven-year retention is a floor for logs, not a limit on part history.