RSC Cluster: Data Integrity, Version Control and Audit Trails

The Data Integrity, Version Control and Audit Trails Cluster provides the governance foundation that makes operational data trustworthy. It explains permissions, approvals, revision control, and immutable audit trails across internal and supplier-facing workflows. The content makes responsibility and evidence preservation explicit. This cluster ensures credibility with auditors, customers, and internal stakeholders.

  • part number

    A part number is a structured identifier assigned to a specific part, component, or item so it can be uniquely referenced across engineering, manufacturing, quality, and supply chain systems. It usually follows a defined numbering scheme and is treated as the primary key for managing technical data, procurement, production, and traceability for that item.

    What a part number typically includes

    A part number commonly represents a specific combination of attributes such as:

    • Form, fit, and function of the part (geometry, interfaces, key features)
    • Intended use or assembly location
    • Material, finish, or key performance characteristics
    • Sometimes, configuration or variant information (e.g., left/right hand, size range)

    Companies define their own part numbering policies. Some use fully numeric sequences, while others embed meaning (for example, product family, material code, or commodity code). In regulated manufacturing, the numbering scheme is usually documented and controlled.

    How part numbers are used operationally

    In industrial and regulated environments, part numbers act as the common reference across multiple systems and workflows:

    • PLM / PDM: Links the part to controlled design data such as CAD models, drawings, and specifications.
    • ERP / MRP: Defines the item master used for purchasing, inventory, costing, and planning.
    • MES / shop floor systems: Ties work instructions, routings, and inspection plans to the specific item produced.
    • QMS / FAI tools: Identifies which part is being inspected, including in first article inspection records and certificates.
    • Supply chain documents: Appears on purchase orders, delivery notes, certificates of conformity, and invoices.

    Because the part number is used as a key across many systems, consistency and governance are critical. In integration scenarios, the part number (often combined with a revision) is used as the system-of-record identifier to synchronize drawings, BOMs, and inspection data.

    Part number vs. revision

    A part number usually identifies the item, while a revision identifies the version of its design or definition. In many environments:

    • The part number remains constant across design changes.
    • The revision is incremented when engineering changes are released.
    • Systems often use a part number + revision combination as a unique key for drawings, models, and inspection plans.

    In some organizations, a major design change may trigger a new part number instead of, or in addition to, a revision change. The chosen approach is defined in internal configuration management or document control procedures.

    Common confusion

    • Part number vs. serial number: A part number identifies the type of item; a serial number identifies an individual, traceable unit of that item.
    • Part number vs. drawing number: In some companies these are the same; in others, the drawing number is separate and may reference multiple part numbers or vice versa.
    • Part number vs. SKU: In manufacturing, the part number is the engineering/operations identifier. A SKU (stock keeping unit) is a commercial or logistics identifier; in many ERPs they are aligned but they are not always identical.

    Tie to PLM and FAI synchronization

    When synchronizing drawing revisions between PLM and first article inspection (FAI) tools, the part number often acts as the primary linkage. Reliable synchronization typically requires:

    • Consistent part numbers across PLM, ERP, MES, and FAI systems
    • Clear rules on how part number and revision are combined as a unique key
    • Governed change control so each new or updated part number and revision is propagated correctly

    In such integrations, the part number is the anchor for connecting design data, ballooned drawings, inspection characteristics, and FAI reports for the same item.

  • Content Governance

    Content governance is the structured framework of roles, rules, and processes that control how content is created, reviewed, approved, distributed, maintained, and retired. In industrial and regulated manufacturing environments, it typically applies to documents and data that guide or record operations, such as work instructions, SOPs, quality procedures, forms, checklists, training materials, and system master data.

    Content governance focuses on who can change what, how changes are requested and evaluated, and how the organization ensures that only current, approved content is used in production, maintenance, quality, and supply chain processes.

    Key elements in manufacturing and regulated operations

    • Ownership and roles: Defined content owners, authors, reviewers, and approvers for each content type (for example, engineering owns routings, quality owns inspection plans).
    • Standards and templates: Common structures, naming conventions, and templates so documents and records are consistent and understandable across sites and systems.
    • Change control: Clear workflows for drafting, reviewing, approving, releasing, revising, and retiring content, often integrated with document control or PLM/MES change processes.
    • Version governance: Rules ensuring that only the latest approved version is available at the point of use, with access to historical versions for traceability and audits.
    • Access control: Permissions that limit who can view, edit, or approve different content categories, aligned with job function and regulatory expectations.
    • Traceability and audit trail: Records showing who changed what, when, why, and under which approval, supporting internal investigations and external audits.
    • Lifecycle management: Criteria and processes for periodic review, re-approval, or deprecation of content that is obsolete or superseded.

    Operational examples

    • Digital work instructions in an MES or work-instruction system follow a defined approval workflow before release to operators, and line staff can only see the latest approved version.
    • Quality procedures, inspection plans, and checklists are managed under document control, with revision histories and effective dates linked to specific part numbers or work centers.
    • ERP/MES master data such as routings, BOMs, and inspection characteristics are updated through governed change workflows, preventing ad-hoc edits on the shop floor.
    • Training content is linked to specific controlled documents, so when a procedure changes, retraining requirements and acknowledgment records can be traced back to the new version.

    Common confusion

    • Content governance vs. document control: Document control typically focuses on managing documents and their revisions. Content governance is broader and can include digital content inside systems (for example, MES work instruction steps, forms, and data fields) and the processes and roles that oversee them.
    • Content governance vs. IT governance: IT governance addresses how technology decisions are made and controlled. Content governance focuses specifically on the information and instructions held within those systems, not the systems themselves.

    Relation to compliance and quality systems

    In regulated manufacturing sectors, content governance commonly supports quality management, audit readiness, and regulatory alignment. It helps demonstrate that operational content is controlled, that changes are authorized and traceable, and that operators and inspectors are using the correct, current information at the point of use.

  • Software Bill of Materials (SBOM)

    A Software Bill of Materials (SBOM) is a structured, machine-readable list of all software components that make up an application, firmware, or system. It typically includes proprietary code, open-source libraries, third-party components, and their dependencies, along with identifying information such as version, supplier, and known reference identifiers.

    What an SBOM includes

    In an industrial or manufacturing context, an SBOM commonly describes the software stack for:

    • Manufacturing execution systems (MES), ERP integrations, and plant-floor applications
    • OT equipment firmware (PLCs, HMIs, CNC controllers, test stands, industrial PCs)
    • Quality, traceability, and data collection tools deployed on the shop floor

    An SBOM usually contains:

    • A list of components (name, version, and supplier or origin)
    • Relationships between components (for example, dependency trees)
    • Identifiers for components (such as package URLs or other catalog IDs)
    • Document metadata (author, date, and tooling used to generate the SBOM)

    What an SBOM is not

    • It is not the same as a hardware Bill of Materials (BOM) used for physical parts.
    • It is not a complete cybersecurity program or vulnerability management system.
    • It is not a guarantee of compliance, security, or safety.

    Instead, an SBOM provides transparency about what software is present so that organizations can perform their own risk, vulnerability, and compliance assessments.

    Operational use in regulated manufacturing

    In regulated industrial environments, SBOMs are used to support:

    • Cybersecurity and regulatory alignment: mapping known vulnerabilities to specific software components in MES, QMS, and OT systems.
    • Change and configuration management: documenting software baselines for validated systems and tracking changes between releases.
    • Supplier management: requesting SBOMs from software vendors and OEMs to understand third-party and open-source content.
    • Incident response: rapidly identifying where a vulnerable library or component is deployed across plants, lines, or assets.
    • Compliance documentation: providing evidence of software transparency as part of broader quality, IT, or cybersecurity audits.

    SBOMs can be stored alongside other system documentation, referenced in configuration records, or integrated into automated tooling that checks components against vulnerability databases.

    Formats and standards context

    SBOMs are typically encoded in standardized formats that support automation and interoperability across tools. Common examples include formats that provide structured component lists, relationships, and metadata. In manufacturing, these formats are often integrated with IT service management, asset management, and OT configuration management databases.

    Common confusion

    • SBOM vs. hardware BOM: A hardware BOM lists physical parts and materials. An SBOM lists software components and dependencies. Many industrial systems require both.
    • SBOM vs. vulnerability report: An SBOM is an inventory. Vulnerability reports and security scans use the SBOM as input but are separate documents or tools.
    • SBOM vs. configuration specification: Configuration documents describe how a system is set up (parameters, options). An SBOM describes what software components are present.

    Relation to cybersecurity and compliance

    For organizations aligning with cybersecurity and defense-related requirements in manufacturing, SBOMs are increasingly referenced as part of secure software development, supply chain risk management, and asset inventory practices. They support internal controls around software provenance, patch management, and documentation expected in many regulated environments, without by themselves proving compliance.

  • design change

    A design change is a controlled modification to an approved product, component, software, or system design. It typically alters one or more design artifacts such as drawings, models, specifications, bills of material, software code, or interface definitions, and is managed through a formal engineering and configuration control process.

    Scope and characteristics

    In industrial and regulated manufacturing environments, a design change generally includes:

    • Updates to engineering drawings, 3D models, or CAD data
    • Revisions to requirements, specifications, or performance criteria
    • Changes to materials, components, or part geometry
    • Software or firmware updates that affect function, safety, or interfaces
    • Configuration changes to assemblies, systems, or product variants

    A design change is differentiated from routine process adjustments because it affects what the product is, not just how it is built. It is normally documented via engineering change requests (ECRs), engineering change orders (ECOs), deviation or concession processes, or similar mechanisms within PLM, PDM, or QMS systems.

    Operational meaning in manufacturing

    Operationally, design changes trigger coordinated updates across multiple systems and workflows, for example:

    • Revising controlled documents such as drawings, specifications, and work instructions
    • Updating BOMs and routing in ERP/MES to reflect new parts or operations
    • Adjusting inspection plans, FAI packages, and quality records
    • Assessing impact on tooling, fixtures, NC programs, and test equipment
    • Updating maintenance, overhaul, and repair instructions in MRO environments

    In standards such as AS9100 and similar quality frameworks, design changes are expected to be risk-assessed, reviewed, approved by authorized functions, and fully traceable. This includes clear identification of affected configurations, effective dates or serial/batch cut-ins, and linkage to verification and validation evidence.

    Design change and risk management

    In regulated sectors like aerospace and defense, design change is closely tied to risk management and configuration control. Typical practices include:

    • Evaluating potential impacts on safety, reliability, and compliance before approval
    • Reviewing downstream effects on suppliers, fielded assets, and MRO organizations
    • Ensuring alignment between design data in PLM and execution data in MES/ERP
    • Maintaining an audit trail of rationale, approvals, and implementation status

    For in-service products, design changes may drive service bulletins, retrofit campaigns, or updated maintenance instructions, and must be coordinated with continuing airworthiness and configuration management of fielded units.

    What a design change is not

    To avoid confusion, a design change usually does not include:

    • Minor shop-floor process tweaks that do not affect fit, form, function, or approved requirements
    • Temporary repair deviations or concessions applied to individual units without altering the baseline design
    • Administrative document edits that do not modify technical content

    However, if a process or repair change alters product requirements, interfaces, or performance, it often must be promoted and controlled as a formal design change.

    Common confusion

    • Design change vs. process change: A design change affects the product definition (what is built). A process change affects how the approved design is manufactured or inspected. In practice they interact, but they should be controlled and documented distinctly.
    • Design change vs. configuration change: A configuration change is any modification to the defined state of a product or system. A design change is one of the main mechanisms that drives configuration changes and updates the controlled baseline.
    • Design change vs. deviation/concession: A deviation or concession typically allows a one-time or limited departure from design requirements for specific units. A design change modifies the requirements themselves for future units or configurations.