Connect981 – Content Dev

RSC Cluster: Traceability and Digital As-Built

The Traceability and Digital As-Built Cluster defines how aerospace manufacturers create trustworthy, auditable product histories directly from execution. It explains unit versus batch genealogy, minimum data sets, and how lot and serial tracking must work across manufacturing, inspection, and suppliers. The content shows how traceability becomes a living operational artifact rather than a reconstructed report. This cluster anchors compliance, trust, and customer confidence.

  • characteristic number

    A characteristic number is a unique identifier assigned to a specific requirement, feature, or attribute on an engineering drawing or specification. In regulated manufacturing environments, it is commonly used to link each requirement to inspection records, data entry fields, or quality documentation for traceability.

    How characteristic numbers are used

    In practice, characteristic numbers typically:

    • Appear on ballooned or numbered engineering drawings next to dimensions, notes, tolerances, and other requirements
    • Map directly to line items in inspection forms, electronic inspection plans, or FAI (First Article Inspection) reports
    • Provide a stable reference for recording measured values, results (pass/fail), and any associated nonconformances
    • Support traceability between design requirements, shop floor inspection activities, and quality records in MES, QMS, or FAI software

    Each characteristic number should be unique within the scope of the drawing or inspection plan so that a reviewer can unambiguously connect the documented result back to the original requirement.

    What a characteristic number is not

    • It is not the measured value itself; it is a reference that points to the requirement being measured.
    • It is not inherently a risk or criticality rating, although systems may separately flag some characteristic numbers as key, critical, or safety-related.
    • It is not limited to dimensional data; it can also identify notes, material requirements, finishes, processes, or documentation checks.

    Common context in aerospace and AS9102

    In aerospace first article inspection (AS9102), each requirement on the ballooned drawing is assigned a characteristic number. That number is then used in the AS9102 Form 3 (characteristic accountability and verification details) to:

    • Identify the requirement being verified (dimension, note, specification, etc.)
    • Record measured results and inspection methods
    • Document any nonconformances related to that requirement

    This linkage helps auditors and customers confirm that every identified requirement on the drawing has a corresponding inspection record, without implying approval or compliance on its own.

    Common confusion

    • Characteristic number vs. balloon number: On many drawings these are effectively the same, because each balloon on the drawing contains the characteristic number. Some organizations use the terms interchangeably.
    • Characteristic number vs. characteristic ID in software: Digital systems may generate internal IDs that differ from the visible drawing number. In that case, the system should still preserve the original characteristic number as a reference back to the drawing.
    • Characteristic number vs. critical characteristic: A critical or key characteristic is a classification of importance or risk. The characteristic number is simply the identifier; separate attributes or flags usually indicate criticality.

  • Labeling

    Labeling commonly refers to the process of creating, approving, printing, and applying identifiers or required information to materials, components, finished goods, samples, containers, and shipping units. In manufacturing and regulated operations, a label is not just a sticker or printed tag. It is a controlled carrier of information used to identify an item, communicate status, support handling, and maintain traceability.

    Depending on the operation, labeling can include human-readable text, barcodes, 2D codes, serial numbers, lot or batch numbers, part numbers, revision levels, dates, storage conditions, quality status, and shipping data. The term can apply to both physical labels and directly marked identifiers when they serve the same operational purpose.

    What it includes

    • Item, material, lot, batch, or serial identification
    • Status labels such as quarantine, accepted, rejected, or in-process
    • Packaging and shipping labels
    • Work-in-process and kitting labels
    • Labels generated from ERP, MES, WMS, LIMS, or quality systems
    • Controlled templates, approval logic, and print records where used

    What it does not mean

    Labeling does not usually mean product branding, marketing design, or consumer-facing package artwork unless the discussion is specifically about commercial packaging operations. In industrial settings, the term usually refers to operational identification and traceability rather than promotional labeling.

    Operational meaning

    In day-to-day workflows, labeling appears at receiving, inventory moves, production issue, kitting, work order execution, inspection, nonconformance handling, packaging, and shipment. A labeling process may pull master and transaction data from business or shop-floor systems so that the label reflects the current item identity and status. Because labels often drive scanning and downstream decisions, errors in labeling can affect traceability, inventory accuracy, routing, and release controls.

    For example, a lot label on raw material may link the received material to supplier data and inspection status, while a finished-goods label may carry serial, revision, and shipment information needed by downstream systems.

    Common confusion

    Labeling is often confused with marking, identification, and packaging.

    • Labeling usually means applying a separate information carrier such as a printed label or tag.
    • Marking often refers to direct identification placed on the item itself, such as laser etching or ink marking.
    • Identification is broader and includes any method used to distinguish an item, whether by label, mark, record, or system reference.
    • Packaging refers to the physical containment or protection of goods, while labeling communicates information on or with that package.

    Why it matters in regulated manufacturing

    In regulated and quality-controlled environments, labeling is commonly tied to document control, revision management, approved data sources, and traceability records. The exact content and control level vary by industry, process, and product risk, but the general purpose remains consistent: to ensure the right item carries the right information at the right point in the workflow.

  • Formula versioning

    Formula versioning is the controlled tracking and management of changes to a manufacturing formula over time. A formula version identifies a specific approved or recorded state of a recipe, blend, bill of ingredients, or process formula so the organization can distinguish one definition from another.

    In manufacturing, this commonly includes changes to ingredient or material quantities, units of measure, processing parameters, yield assumptions, substitutions, specifications, effective dates, and approval status. It may also include links to related records such as work instructions, quality documents, ERP or MES master data, and change control records.

    Formula versioning is not the same as simply overwriting a formula master record. The key distinction is that prior states remain identifiable, and each version can be tied to when it was created, who changed it, why it changed, and where it was used. In regulated or traceability-sensitive environments, this supports consistent execution, review, and historical reconstruction.

    How it appears in operations

    Formula versioning often appears in ERP, MES, LIMS, PLM, or quality systems as version numbers, revisions, effective dates, status labels, and approval workflows. For example, a plant may release a new formula version for a coating mix with an updated solvent ratio while keeping the prior version available for historical batch records and investigation.

    • Current version: the formula presently released for use
    • Pending version: a change under review or not yet effective
    • Obsolete or retired version: no longer released for execution but retained for history
    • Effective dating: controls when a version may be used in production

    What it includes and excludes

    Formula versioning commonly refers to the version control of product formulations or process formulas used to manufacture a material or product. It may apply to discrete, batch, and process manufacturing, especially where composition matters.

    It does not usually mean versioning of every related document or every production instruction, although those items may be governed alongside the formula. A formula version can be linked to document revisions, but it is not identical to document control in general.

    Common confusion

    Formula versioning vs. recipe versioning: These terms are sometimes used interchangeably, but they are not always identical. A formula usually focuses on composition or material relationships, while a recipe may also include sequence, timing, equipment steps, and execution logic.

    Formula versioning vs. BOM revision: A bill of materials revision is usually associated with product structure in discrete manufacturing. A formula version is more often used where proportions, yields, or batch scaling are central.

    Formula versioning vs. document revision control: Document revision control manages files such as SOPs or specifications. Formula versioning manages the manufacturing definition itself, even when related documents are attached.

  • How do we trace a KPI value back to individual work orders and defects?

    You do that by designing the KPI as a traceable calculation, not just a dashboard number.

    In practice, a KPI must retain lineage from the displayed value back to the underlying production, quality, and transaction records that contributed to it. That usually means every KPI point can be decomposed into the specific work orders, operations, lots, serials, NCRs, defect events, rework events, and timestamps used in the calculation.

    If that lineage does not exist, the honest answer is no: you do not truly have traceability to individual work orders and defects. You have an aggregate metric that may be useful for monitoring, but it is not reliably auditable or explainable.

    What has to be in place

    • Stable record keys: work order numbers, operation IDs, part or serial identifiers, defect or NCR IDs, and equipment or line references must be consistently captured across systems.

    • A defined KPI formula: numerator, denominator, exclusions, time window, and treatment of rework, scrap, split lots, and late quality dispositions must be explicitly governed.

    • System lineage: you need to know which system is the source for each data element. For example, ERP may own work order status, MES may own operation completions, and QMS may own defect classification and disposition.

    • Event-level history: corrections, overrides, reopened defects, backdated transactions, and master data changes must be retained, not silently overwritten.

    • Time alignment: KPI values often fail traceability because systems post events at different times. A defect recorded after shift close may still belong to an earlier production period depending on your business rule.

    • Change control: if the KPI logic, mappings, or source system behavior changes, the effective date and impact on historical reporting need to be documented.

    How the drill-back usually works

    A defensible drill-back path typically looks like this:

    1. The KPI dashboard shows a value for a defined period, line, program, part family, or cell.

    2. That value links to the exact filtered dataset used in the calculation.

    3. The dataset links each contributing record to its source transaction, such as work order completion, inspection result, defect log, rework order, or scrap entry.

    4. Each source transaction links back to the original operational object, such as the work order, operation step, serial number, or NCR.

    5. The user can see why each record was included, excluded, or weighted in the KPI.

    For example, if a first-pass yield KPI drops, the drill-back should show which work orders contributed failures, which operation steps failed, which defect codes were recorded, whether failures were reworked, and whether the KPI counts rework as recovered yield or not.

    Brownfield reality

    In most regulated manufacturing environments, this is not handled by a single system.

    Traceability usually spans MES, ERP, QMS, historian, and sometimes spreadsheets or custom databases. That creates common failure modes:

    • work order IDs differ across systems or are reformatted

    • defect codes are not standardized

    • ERP completion timing does not match MES execution timing

    • QMS dispositions arrive days after production events

    • rework loops are inconsistently recorded

    • manual adjustments appear in reports without source evidence

    Because of that, full replacement is often not the practical answer. In long lifecycle, regulated operations, replacing MES, ERP, or QMS platforms just to improve KPI lineage often fails on qualification burden, validation cost, downtime risk, integration complexity, and the need to preserve historical traceability. A federated approach is usually more realistic: govern identifiers, map source ownership, and build drill-back across existing systems.

    What makes the traceability trustworthy

    A KPI trace-back is more trustworthy when you can answer these questions clearly:

    • Which source systems contributed to this KPI?

    • Which exact records were used?

    • What business rules transformed those records into the KPI?

    • What was excluded and why?

    • Can the same result be reproduced later from retained data and versioned logic?

    • Can a quality or operations reviewer inspect the underlying work orders and defects without manual reconciliation?

    If the answer to several of those is no, the KPI may still help with directional management, but it should not be treated as fully traceable evidence.

    Tradeoffs to expect

    • More detail improves traceability but increases integration and governance effort.

    • Near-real-time KPI updates can conflict with data completeness. Early values may change as inspections close, defects are dispositioned, or transactions are corrected.

    • Strict standardization improves comparability but may hide local process realities.

    • Historical reproducibility requires versioning. If definitions change, organizations must decide whether to restate history or preserve prior KPI logic.

    Practical answer

    Yes, but only if the KPI is built with record-level lineage, governed definitions, and cross-system identifier discipline. In most plants, that depends less on the dashboard tool and more on data model quality, integration reliability, and change control across MES, ERP, and QMS. Without those controls, you can view the KPI, but you cannot reliably defend how it was formed.

  • electronic device history record

    An electronic device history record (often abbreviated eDHR) is a digitally maintained, unit-specific record that documents how a particular product or serialized device was manufactured, inspected, tested, and released. It is the electronic counterpart of a paper device history record and is commonly used in regulated manufacturing environments such as medical devices, pharmaceuticals, and other life sciences and high-reliability industries.

    What an electronic device history record includes

    An electronic device history record commonly includes:

    • Identification of the specific unit or lot (serial numbers, batch/lot numbers)
    • The bill of materials actually used, including component and material lot numbers
    • Manufacturing steps performed, including dates, times, equipment, and locations
    • Operator or system IDs associated with each executed step
    • Process parameters and key production data captured from MES, PLCs, and other OT/IT systems
    • In-process and final inspection results, test data, and pass/fail decisions
    • Recorded deviations, nonconformances, rework, and associated approvals
    • Electronic signatures and approvals for production, quality review, and release

    The focus is on the actual history of a specific unit or lot, not the intended instructions or specifications.

    How it appears in manufacturing systems

    In practice, an electronic device history record is assembled from multiple systems:

    • MES and electronic batch record systems capture execution data for each operation and associate it to the relevant unit or lot.
    • PLCs and automation systems provide time-stamped process data and equipment status that may be linked into the record.
    • LIMS, quality, and test systems contribute test results, inspections, and quality decisions.
    • ERP and inventory systems provide material genealogy, work orders, and lot/serial assignments.

    The eDHR is often presented as a consolidated view or report that can be queried by serial number, lot, work order, or date range for traceability and audit purposes.

    What an electronic device history record is not

    • It is not a device master record or master recipe. Those define how a product should be built; the eDHR documents how it was actually built.
    • It is not limited to a single system log. It typically aggregates data across MES, PLCs, ERP, quality, and laboratory systems.
    • It is not a generic production report. It is specific to an individual serialized unit or a defined lot/batch.

    Relationship to MES and PLCs

    Electronic device history records rely on data captured at different layers of the manufacturing stack:

    • PLCs and other control devices collect real-time machine and process values but do not, by themselves, structure these into a complete device history.
    • MES and related execution systems orchestrate work orders, enforce workflows, collect operator input, and link equipment and material data, forming the core of the eDHR.

    The eDHR is therefore an outcome of integrated OT and IT systems, rather than a single standalone application.

    Common confusion

    • Electronic device history record vs. electronic batch record (eBR): An eDHR is usually associated with discrete or serialized units (for example, medical devices), while an eBR often refers to batch or process manufacturing records. In practice, organizations may use the terms differently, but both serve a similar purpose of documenting actual production history electronically.
    • Electronic device history record vs. device master record (DMR) or product specification: The DMR or specification defines requirements, procedures, and materials. The eDHR documents actual execution against those requirements.

  • as-built record

    Core meaning

    An **as-built record** is a documented description of the actual configuration, materials, and construction of a product, system, or facility at the time it is completed or released.

    It captures what was **actually built and installed**, which may differ from the original design or engineering intent. In regulated manufacturing, as-built records are typically retained as part of product history or device history documentation.

    Typical contents in manufacturing

    In industrial and regulated environments, an as-built record commonly includes:

    – Final bill of material (BOM) with actual part numbers and revisions used
    – Lot, batch, or serial numbers of critical materials and components
    – Configuration details (options, software versions, parameter sets)
    – Records of deviations, nonconformances, or waivers that changed the design or process
    – Approved engineering changes applied during build (e.g., ECNs, ECRs)
    – Key process data that define the built state (e.g., torque values, calibration data, test results)
    – Identification of the specific unit(s) to which the record applies (serial number, unit ID, tail number, etc.)

    The level of detail depends on the product, risk classification, and regulatory expectations.

    Use in MES, ERP, and traceability

    In integrated manufacturing IT/OT landscapes:

    – **MES (Manufacturing Execution System)** typically holds or generates the as-built record at the unit, serial, or batch level. It may include:
    – Material genealogy (which material lots and components went into each finished unit)
    – Route and operation history
    – Operator IDs, timestamps, and equipment used
    – Test, inspection, and release decisions

    – **ERP (Enterprise Resource Planning)** usually contains the **as-planned** and **as-designed** structures (standard BOMs, routings, costing), and may store high-level as-built information (e.g., shipped configuration, top-level serials) but not full process detail.

    For high-traceability industries such as aerospace, medical devices, and pharmaceuticals, the combination of MES data and supporting quality records commonly constitutes the authoritative as-built record for a product or batch.

    Boundaries and what it is not

    – **As-built vs. as-designed:**
    – *As-designed* describes the intended configuration from engineering.
    – *As-built* documents the configuration that was actually produced.

    – **As-built vs. as-planned/as-intended process:**
    – *As-planned* describes the standard process route or work instructions.
    – *As-built* includes the actual route followed, including rework, holds, or alternative operations.

    – **As-built vs. real-time monitoring data:**
    – Real-time OT/SCADA data streams support the record but are not, by themselves, the as-built. The as-built record is the curated, contextualized, and retained representation of the final state.

    An as-built record is typically not a marketing datasheet or general product specification; it is a formal, traceable record tied to specific manufactured units or installations.

    Common confusion and related terms

    – **As-built drawing:** A drawing or model updated to reflect the final constructed state. It is often one element of the broader as-built record but does not, by itself, capture full material genealogy or process history.
    – **Device history record (DHR) / batch record:** In some regulated sectors, these formal record types include or essentially are the as-built record, augmented with quality and release documentation.
    – **Configuration record:** Focuses on the configuration of a unit (options, software, parameters). An as-built record usually includes the configuration record plus the underlying materials and process evidence.

    Site context: aerospace material usage and genealogy

    In aerospace manufacturing, an as-built record typically links:

    – Each aircraft or major assembly serial number
    – The exact material lots, components, and subassemblies installed
    – The manufacturing and inspection operations performed (with dates, equipment, and personnel)
    – Any concessions, deviations, or repairs accepted during build

    MES is commonly used to capture this unit-level genealogy and operation history, while ERP maintains higher-level inventory and costing views. Together, they support the as-built record required for long-term traceability and investigations.

  • as-built configuration

    An as-built configuration is the documented record of how a product, system, or asset was actually built and configured at the time of manufacture or release. It captures the real components, revisions, parameter settings, and approved deviations that were used, rather than the ideal or planned configuration from design or planning systems.

    Core meaning in manufacturing and regulated environments

    In industrial and especially regulated manufacturing (such as aerospace, medical devices, and defense), an as-built configuration commonly refers to:

    • The complete list of parts, materials, and subassemblies used, with serial/lot numbers and revisions
    • The routing actually followed, including operations performed and the resources used (machines, tools, fixtures)
    • Process parameters and key settings as executed, where these are required for traceability
    • Approved deviations, concessions, rework, and substitutions that differ from the original design or work order
    • Links to inspection, test results, and nonconformance records associated with that specific build

    The as-built configuration is typically captured and maintained by execution-layer systems such as MES, electronic travelers, or maintenance/asset systems, sometimes in coordination with ERP and PLM. It is a core element of traceability, genealogy, and digital thread initiatives.

    As-built vs. other configuration views

    Different lifecycle stages often maintain different views of configuration:

    • As-designed configuration: The engineering intent managed in PLM or CAD systems (design BOM, design configuration). It describes what should be built.
    • As-planned configuration: The manufacturable plan, usually in ERP/MRP and MES (manufacturing BOM, routing, planned work orders).
    • As-built configuration: The factual record of what was actually built on the shop floor, including any approved departures from design or plan.
    • As-maintained configuration: For in-service assets, the configuration after repairs, retrofits, and field modifications.

    The as-built configuration is the authoritative reference when questions arise about which specific part revisions, lots, or processes were used on a particular unit or batch.

    Operational use

    In day-to-day operations, an as-built configuration typically appears as:

    • A serial-level build record that ties finished units back to component serials/lots and process history
    • Evidence for audits and investigations (for example, which aircraft or devices contain a given suspect lot)
    • The basis for MRO and service decisions, where maintenance teams need to know exactly what is installed
    • An anchor point for digital thread, linking design data, process data, quality data, and field performance

    ERP, MES, and PLM integrations often revolve around keeping design and planning configurations aligned while ensuring the as-built configuration remains stable, traceable, and queryable over time.

    Common confusion

    • As-built vs. BOM: A bill of materials defines a structure of required parts. The as-built configuration is a historical, instance-specific record of which actual parts and revisions were used, plus execution details.
    • As-built vs. as-designed: As-designed is the engineering specification. As-built is the realized outcome of manufacturing, including controlled differences.
    • As-built configuration vs. documentation package: An as-built configuration is the structured configuration record. An as-built documentation package may include drawings, reports, and certificates, which reference or support the configuration record.

    Context: ERP and aerospace MES

    In aerospace ERP–MES integrations, ERP commonly owns planning data (as-planned BOMs, routings, and cost structures), while the MES or execution layer owns the detailed as-built configuration. Work orders, inventory, and completions are exchanged between systems, but the serial-level as-built configuration, including traceability and genealogy, is typically maintained within the MES and exposed back to ERP, PLM, and quality systems as needed.