25 — As-built configuration and traceability

The released design describes what may be built. The production plan describes how it should be built. Neither proves what is installed in a particular vehicle. That requires records of material identity, installation, connection completion, software loading, inspection and authorised departures. As-built configuration is the recorded result of realisation, supported by evidence sufficient for the decisions that depend on it.

The practical question is often precise: does Vehicle 01 contain the affected fan, with the affected controller software and the earlier harness connector? A parts list for the vehicle type cannot answer it. A stores issue cannot establish installation. A passed test cannot identify every component present unless its configuration record supplies that context. Traceability connects these different facts without treating them as substitutes.

Identity before traceability

A part identity identifies a kind of item. A revision identifies a controlled version of its definition. An occurrence identifies a use within a structure: two uses of the same bracket have different positions and relationships. A physical instance is an actual manufactured item. A serial number distinguishes an individual instance within its identification scheme; a lot identifies a controlled group whose members share recorded provenance. A lot reference alone may not distinguish individual members.

Vehicle identity supplies the context in which these relationships become operational. Record that a particular item occupied a particular installation position on Vehicle 01 during a particular interval. If the item is removed and fitted elsewhere, its history follows the item while the position retains its own installation history. This permits both “where has this item been?” and “what has occupied this position?” queries.

Choose identification granularity according to consequence and intended use. A bought engine or transmission may require individual history; a consumable may need lot traceability; some ordinary items may need only conformity to an applicable definition and controlled issue record. Requiring a separate serial record for every object creates cost without necessarily improving confidence. Conversely, recording only a purchase description can prevent targeted containment when a supplier identifies a defective batch.

Record the identification scheme and issuer as well as the visible identifier. Supplier serial numbers need a namespace or equivalent context to avoid accidental collisions. Preserve supplier identity and its relationship to the internal part identity. Renaming an item internally must not erase the reference needed to interpret its supplier certificate or maintenance history.

Baselines and actual state

A baseline is an identified controlled set of information and relationships established for a purpose. The build-authorisation baseline defines the permitted target for work. The delivery configuration records what was actually accepted. They should be reconcilable, but an authorised departure may explain a difference. Treating both as one mutable bill of materials destroys the evidence of that difference.

NASA's configuration-management guidance describes identification, controlled change, status accounting and audits as connected activities, including preservation of configuration information through the lifecycle. This supports the general need to reconcile product and records; NASA-specific prescriptions are not requirements for these vehicles. NASA Systems Engineering Handbook, configuration management.

“As-built” must have a defined event boundary. A vehicle at initial assembly completion may differ from the same vehicle after acceptance-test rectification. Retain both the completion event and the later changes, and identify which accepted state forms the delivery baseline. After service intervention, the corresponding state is as-maintained. It is a continuation of controlled history rather than an overwrite of the delivery record.

Capture events where the work occurs

An installation record needs the vehicle, installation position, actual item identity at the required granularity, applicable instruction, event time, responsible performer and evidence of completion. It should distinguish the time work occurred from the time it was recorded. Late entry is sometimes unavoidable, but hiding it prevents reliable reconstruction.

Removal records identify what was removed, from where, why and its subsequent disposition. Replacement is therefore more than a new line in a current list: it links removal, installation and any required return-to-service checks. Correction of a recording error is a different event from physical replacement. Preserve the correction reason and original entry so that a corrected serial number does not falsely imply workshop activity.

Connection evidence is equally important. The cooling module can contain the correct radiator, hoses, fan and brackets while remaining incorrectly connected. Mechanical attachment, fluid connection and electrical mating each have contextual requirements. The record should identify the relevant connection or operation and its controlled acceptance evidence. It need not turn every connection into a purchased part. The actual representation must support the relationship between defined endpoints, performed work and inspection result.

Manufacturing engineering defines capture points in the work sequence. Quality defines evidence necessary for acceptance. Configuration management defines identity and reconciliation rules. Execution personnel record the actual work. The technical authority dispositions discrepancies; the person entering data cannot quietly decide that an unapproved substitute is equivalent.

Software and calibration are installed configuration

A controller's hardware serial number does not fully describe its behaviour. Record the installed software release and applicable calibration identity, the target hardware, loading event and evidence that the intended package was successfully established. Keep the approved release definition separate from the observed installed state. A package available in a repository has not thereby been loaded onto a vehicle.

Software identifiers should refer to controlled released content and its compatibility conditions. Where integrity checks are used, retain their results and method as appropriate; a matching checksum demonstrates a particular comparison, not that the content is suitable for the vehicle. Loading tools, permissions, verification and recovery procedures require their own control. These responsibilities remain necessary even when the selected core platforms do not determine the software lifecycle tool.

The bought engine and transmission may arrive with supplier-controlled software and calibrations. Define what identification and change notification the contract must provide and what the vehicle team is permitted to change. If internal content is inaccessible, record that evidence boundary and obtain sufficient supplier assurance for the intended integration. Do not invent detailed internal configuration from an equipment label.

Reconstructing the cooling-module change

Vehicle 01 is in build when the supplier proposes a new electrical connector. Vehicle 02 has equipment ordered; Vehicles 03–04 are still being planned. Start with the change's affected supplier identities and interface definition, then locate relevant stock, received equipment, open orders and installed instances. These are separate populations: an order proves exposure to supply, whereas an installation event proves physical applicability.

Suppose the earlier connector remains installed on Vehicle 01 while the revised connector is considered for later units. The technical assessment addresses both mating sides and compatibility with the supplier harness. The disposition specifies permitted combinations and any required rework or inspection. Purchasing separately resolves whether orders can be amended and on what terms. No new connector should enter use merely because its supplier description resembles the earlier item.

For Vehicle 01, reconcile the observed connector and harness identities against the permitted combination. If evidence is missing because access has already been closed, record an unresolved discrepancy. Decide whether inspection, controlled disassembly or another justified means can establish the fact. Copying the planned configuration into the actual record would conceal the uncertainty and could direct a maintainer to the wrong replacement later.

For Vehicle 02, amended order information must flow into receiving and the installation work package. Receipt records identify what arrived; installation records identify what was fitted. Vehicles 03–04 can plan against the revised permitted configuration once released. Closure of the supplier change requires evidence for each affected unit and disposition of residual stock, rather than a single approval against the revised definition.

Now consider the separate customer payload and hot-climate changes held in DOORS. Their disposition may require changed hardware, changed calibration, new inspection or further test evidence. The actual result is not predetermined. A requirement revision identifies the revised demand; the unit record identifies which implementation was authorised and completed. These links make it possible to distinguish a vehicle assessed and accepted without hardware change from one awaiting modification.

Provenance, discrepancies and acceptance

Evidence needs provenance: originator, issuing organisation, relevant identity and revision, applicable configuration, event context and review status. A supplier certificate may support material pedigree but does not establish that the material was installed in the stated location. A test report may establish a result but need a separate configuration snapshot to identify its subject. Link the records instead of stretching one document's meaning.

Reconciliation compares the permitted configuration, recorded events and observed product. Exceptions include unidentified items, incompatible combinations, missing certificates, incomplete operations, obsolete instructions and inconsistent software records. Classify each exception by what decision it prevents. Some require containment before further work; others need correction before acceptance. An unresolved information discrepancy should remain visible even if the vehicle appears to function.

An authorised concession or deviation must remain connected to the affected characteristic, units, conditions and approving authority. It does not silently revise the general design. Commercial acceptance and technical suitability may require different decisions. The delivery record should reveal both the departure and the supporting disposition so that service personnel can determine whether a standard repair instruction applies.

The configuration acceptance decision therefore consumes the actual configuration snapshot, reconciliation results, outstanding exceptions, relevant evidence and authorised departures. Its output identifies the accepted state and any restrictions. General verification strategy belongs in the verification chapter; this chapter's concern is that the strategy's evidence can be associated with the exact configuration being accepted.

Information architecture and scale

The reference architecture assigns controlled definition to the product-lifecycle environment and commercial transactions to the enterprise resource planning environment. NX and Capital contribute mechanical and electrical definition; Teamcenter provides the selected lifecycle platform; SAP provides the selected enterprise resource planning platform. Actual installation, inspection and service events may originate in execution, quality or service systems. SAP is not automatically the owner of every as-built record.

Assign authority by record class and attribute. Define stable identifiers, exchange acknowledgements, correction rules and reconciliation responsibilities. A material issue exchanged from SAP must retain its meaning as an issue, rather than becoming an installation simply because the receiving system has a convenient field. An engineering revision must not overwrite historical configuration snapshots. Exact product versions and integration mechanisms require separate validation.

At millions of occurrences and years of manufacture, history becomes too large for manual reconstruction. Queries must resolve applicability across supplier identities, lots, occurrences, vehicle instances and installation intervals. Indexing and retention need deliberate design. A fleet query should report uncertainty and missing coverage, rather than returning a reassuring empty list when source records are unavailable.

Thousands of people also make correction discipline essential. Preserve accountable changes, manage offline capture and duplicate submissions, and distinguish estimated history from observed fact during migration. Retention and access arrangements must outlive individual supplier contracts where support obligations require them. The test of traceability is whether a real decision can be made reliably: contain an affected population, justify a delivery, plan a compatible repair or reconstruct an incident. Through-life support carries this configuration history into service.