Connect981 – Content Dev

RSC Sphere: Quality, Compliance and Traceability

The Quality, Compliance and Traceability Sphere demonstrates how audit-grade credibility is built directly into execution workflows. It connects nonconformance, corrective action, inspection, traceability, and audit evidence into a continuous operational loop. The content emphasizes how quality systems must interact with live work rather than exist as parallel documentation processes. This sphere proves that compliance and execution can reinforce each other instead of competing for attention.

  • certification scope

    Certification scope commonly refers to the formally defined boundaries of what an external certification or registration covers for an organization. It describes which activities, sites, processes, products, and services are included under a specific standard or scheme (such as ISO 9001, AS9100, or cybersecurity frameworks).

    The certification scope is typically documented in the certificate itself and in associated internal records. It is used by customers, regulators, and internal teams to understand where a particular certification applies and where it does not.

    What certification scope usually includes

    In industrial and regulated manufacturing environments, certification scope commonly defines:

    • Organizational boundaries: specific legal entities, sites, plants, or business units included in the certification.
    • Activities and processes: types of operations covered, such as design, manufacturing, assembly, test, inspection, repair, or distribution.
    • Products and services: product families, component types, systems, or service offerings that fall under the certified system.
    • Applicable standards: which standard(s) the scope relates to, for example ISO 9001, AS9100, ISO 27001 or CMMC.
    • Limitations and exclusions: processes or functions not covered, such as design-excluded scopes or non-certified sites.

    Operationally, the certification scope should be reflected in quality management systems, MES/ERP configurations, document control, and customer-facing information so it is clear which work is performed under which certified environment.

    Use in multi-site and integrated operations

    In multi-site manufacturers, different plants or business units may have different certification scopes. For example, one site may be certified for AS9100 including design, while another is certified only for production of specific part families. In these cases, organizations typically:

    • Map products, programs, and customers to the sites that are within the relevant certification scope.
    • Configure routing, work orders, and approved supplier lists so certified and non-certified flows do not get confused.
    • Maintain evidence showing that activities claimed as certified actually occur within the defined scope.

    Common confusion

    • Certification scope vs. process scope: Process scope describes the boundaries of a specific process or procedure (for example, what a work instruction covers). Certification scope is broader and tied to a formal external certification.
    • Certification scope vs. organization-wide coverage: A company may be certified only for part of its operations. It is incorrect to assume that a single certification automatically covers every site, product, or service unless the documented scope states this.
    • Certification scope vs. regulatory applicability: Certification scope is defined for a standard or scheme and does not, by itself, determine whether a regulation applies. Regulatory scope is set by laws or authorities, even if certification is used as supporting evidence.

    Relation to audits and evidence

    During external audits, auditors typically verify that the management system and collected evidence match the declared certification scope. Internally, operations, quality, and IT/OT teams often use the scope to decide:

    • Which processes must follow certified procedures and controls.
    • Which records must be retained as evidence for the certified activities.
    • How changes to products, sites, or IT/MES systems affect what is inside or outside the scope.

    Clear and maintained certification scope helps prevent incorrect claims about coverage and supports accurate communication to customers and regulators.

  • Ballooning and characteristics

    Ballooning and characteristics commonly refer to the practice of marking engineering drawings or models with numbered “balloons” and defining each unique, inspectable requirement as a discrete characteristic. This is widely used in first article inspection (FAI), production inspection, and ongoing quality control in regulated manufacturing such as aerospace.

    What ballooning is

    Ballooning is the process of visually annotating an engineering drawing or 3D model so that every requirement that must be verified is identified with a unique reference number (the balloon). Each balloon typically corresponds to a specific line item in an inspection report.

    In practice, ballooning may include:

    • Dimension callouts (linear, angular, GD&T features)
    • Notes and specifications that require verification (material, finish, treatments)
    • Hole sizes, locations, patterns, and thread details
    • Form, fit, and function requirements that can be inspected
    • Referenced standards or process requirements that must be confirmed

    Ballooning can be performed manually on paper, in 2D CAD/PDF, or through digital tools that link the balloons directly to a characteristic database or FAI software.

    What characteristics are

    Characteristics are the individual, measurable or otherwise verifiable requirements extracted from the drawing or model and associated with a balloon number. In AS9102 and similar frameworks, these are often called inspection characteristics or product characteristics.

    A characteristic definition usually includes:

    • The balloon or item number
    • Description of the requirement (for example, diameter of hole, surface finish)
    • Nominal value and tolerances, or acceptance criteria
    • Units of measure
    • Associated drawing zone or reference
    • Type of characteristic (for example, key, critical, major, minor) when applicable
    • Planned inspection method and frequency where defined

    Characteristics provide the structure needed to build inspection plans, first article inspection forms, and ongoing in-process or final inspection records.

    Role in AS9102 and FAI

    In aerospace, ballooning and characteristics are tightly linked to AS9102 first article inspection:

    • The ballooned drawing defines the complete set of product requirements that must be verified.
    • Each ballooned item is translated into a characteristic line on the AS9102 Form 3 (characteristic accountability and verification list) or equivalent digital record.
    • Inspection results, tools used, and any nonconformances are recorded per characteristic, enabling traceable evidence of conformance to drawing requirements.

    Digital FAI systems typically use structured characteristic data to automate form population, result capture, and traceability back to specific drawing requirements and revisions.

    Operational use in manufacturing systems

    In day-to-day operations, ballooning and characteristics may feed multiple systems:

    • PLM/CAD: Source of the design, where requirements originate.
    • FAI or quality systems: Store and manage the characteristic list, inspection results, and evidence.
    • MES: Use characteristics to drive in-process inspection steps and operator checks.
    • ERP/QMS: Reference characteristics for nonconformance records, deviations, and certificates of conformance.

    Consistent ballooning and characteristic definitions help align what is designed, what is manufactured, and what is inspected across different systems and locations.

    Common confusion

    • Ballooning vs. general markup: Ballooning is a structured, numbered system tied to inspection characteristics, not just informal comments or highlights on a drawing.
    • Characteristics vs. process parameters: Characteristics are typically product requirements on the drawing or model. Process parameters (for example, machine settings) may be controlled and recorded, but are not always defined as characteristics unless they appear as specific requirements.
    • Characteristics vs. critical characteristics only: While some organizations focus on key or critical characteristics, ballooning and characteristic listing usually cover all inspectable requirements, not only the critical subset.

    Relation to digital FAI preparation

    When preparing for advanced digital FAI capabilities, manufacturers often focus on cleaning and standardizing ballooning practices and characteristic data. This can include using consistent numbering rules, ensuring every inspectable requirement is captured as a characteristic, and structuring the data so it can be exchanged between PLM, ERP, MES, and quality systems without rework.

  • contract review

    Contract review is the formal evaluation of a proposed contract or order before it is accepted, to confirm that all technical, quality, delivery, regulatory, and commercial requirements are understood, feasible, and aligned with the organization’s capabilities and systems.

    Key characteristics

    In industrial and regulated manufacturing environments, contract review commonly includes:

    • Checking that drawings, specifications, standards, and revisions referenced in the contract are available and controlled
    • Verifying that special processes, certifications, or regulatory requirements (for example aerospace, defense, medical) are identified and can be met
    • Confirming capacity, lead times, and material availability against requested quantities and delivery dates
    • Reviewing quality requirements such as inspection levels, FAI/AS9102, traceability, documentation, and record retention
    • Ensuring commercial terms (pricing, penalties, warranty, change control) are understood by relevant internal functions
    • Aligning customer requirements with internal routings, BOMs, work instructions, and ERP/MES data
    • Documenting clarifications, deviations, or concessions that must be agreed with the customer before acceptance

    Contract review can apply to customer contracts, purchase orders (POs), long-term agreements (LTAs), and significant changes to existing contracts.

    How it appears in operations and systems

    Operationally, contract review is often implemented as a cross-functional process involving sales, program management, engineering, quality, and operations. Evidence of contract review may be found in:

    • Signed-off review checklists or forms attached to quotes or sales orders
    • ERP or CRM workflows that require approval before an order is released to production
    • Engineering reviews to translate contract requirements into controlled drawings, routings, and work instructions
    • Quality system records showing how special quality and regulatory requirements were identified and communicated to the shop floor and suppliers

    Use in quality management and audits

    Quality management standards such as ISO 9001 and AS9100 commonly refer to contract review (often under "review of requirements for products and services" or "contractual requirements"). Auditors frequently look for:

    • Defined procedures describing how contracts and orders are reviewed before acceptance
    • Objective evidence that reviews were performed for sampled orders, including who reviewed and when
    • Records of resolved discrepancies between customer requirements and internal capability
    • Linkage between contract requirements and downstream controls, such as inspection plans, FAI, or special-process qualifications

    Common confusion

    • Contract review vs. legal review: Contract review in a manufacturing QMS focuses on operational and technical feasibility, not only legal risk. Legal review may be a part of contract review for complex agreements but is not the whole process.
    • Contract review vs. order entry: Order entry is the administrative act of loading an order into ERP or another system. Contract review is the prior or parallel evaluation step that confirms the order should be accepted and under what conditions.

    Relation to the derived context

    In the context of AS9100 Rev D, contract review is a key source of audit evidence showing that customer and regulatory requirements are identified, understood, and translated into controlled processes, documents, and records before work is started.

  • Flow-Down Requirement

    A flow-down requirement is a contractual, regulatory, or customer-specific obligation that an organization is required to pass along to its suppliers, sub-tier suppliers, or internal teams so that the entire supply chain adheres to the same conditions.

    Core meaning

    In industrial and regulated manufacturing, flow-down requirements commonly originate from:

    • Customer contracts and purchase orders
    • Regulations and standards (for example, aerospace, defense, or medical device requirements)
    • Quality management system (QMS) rules, including documentation and traceability expectations

    The receiving organization must identify which of these obligations apply to the work being outsourced or procured and then formally communicate them to its suppliers. This communication typically occurs through purchase orders, quality clauses, supplier agreements, statements of work, or referenced specifications and standards.

    Operational context

    Flow-down requirements show up in day-to-day operations as:

    • Specific certifications, standards, or process controls that suppliers must follow
    • Requirements for inspection, first article inspection, test records, or material certifications
    • Document control and revision requirements for drawings, work instructions, and digital models
    • Traceability expectations for materials, components, and process steps
    • Data-handling, export control, and cybersecurity rules for technical information

    In MES, ERP, and related systems, flow-down requirements are often represented as quality clauses, PO terms, or routing attributes that are linked to supplier work orders and digital travelers. This supports consistent communication, version control, and evidence capture across the supply chain.

    Scope and boundaries

    A flow-down requirement:

    • Includes obligations that must be met by any party performing part of the contracted work, whether internal or external
    • Focuses on what must be passed on, not how each supplier implements the requirement internally
    • Can apply across multiple tiers of suppliers, not just the first-tier supplier

    It does not refer to general best practices or voluntary suggestions that do not arise from a contract, regulatory obligation, or formal customer requirement.

    Common confusion

    • Flow-down requirement vs. purchase order term: A purchase order term is how a buying organization may express a flow-down requirement. Not all PO terms are flow-downs; some apply only to the buyer and first-tier supplier.
    • Flow-down requirement vs. internal policy: Internal policies can generate flow-downs when they are derived from external obligations, but purely internal preferences do not necessarily become flow-down requirements unless explicitly imposed on suppliers.

    Manufacturing example

    An aerospace OEM has contractual and regulatory obligations for part traceability, special process control, and export-controlled technical data. When it outsources machining or special processes to a supplier, the OEM identifies the relevant clauses and flows them down on the supplier PO, including required certifications, process specifications, digital drawing control, and data-handling rules. The supplier, in turn, must flow the same applicable requirements to its own sub-tier vendors.

  • certification body (CB)

    A certification body (CB) is an independent organization that assesses and certifies that a company, process, or management system conforms to a specified standard or scheme. In industrial and regulated manufacturing environments, CBs are central to third-party certification to standards such as AS9100, ISO 9001, or other sector-specific quality and compliance frameworks.

    What a certification body does

    A CB typically performs the following activities:

    • Conducts initial audits to determine whether an organization's management system meets the chosen standard.
    • Issues certificates that formally recognize conformity to that standard, with defined scope and validity period.
    • Performs surveillance and recertification audits at planned intervals to confirm that the system is maintained.
    • Maintains audit records and certification status information in internal systems and sometimes in sector databases (for example, OASIS for AS9100).
    • Suspends or withdraws certificates if major nonconformities are not addressed within required time frames.

    In aerospace and other regulated sectors, CBs must themselves be accredited by a recognized accreditation body. This accreditation confirms that the CB operates to agreed rules for auditor competence, impartiality, audit methods, and oversight.

    Role in manufacturing and supplier management

    In manufacturing, CB-issued certificates are commonly used to:

    • Demonstrate that an organization's quality management system meets a standard such as AS9100 or ISO 9001.
    • Support customer and regulatory requirements for certified suppliers or production sites.
    • Provide traceable evidence of audits, findings, and certification status during customer or regulatory reviews.

    Buying organizations often verify a supplier's certification status, scope, and the identity of the CB through certificates and sector databases. This verification is usually treated as one input to supplier qualification and ongoing risk management, not a replacement for internal oversight.

    What a certification body is not

    • It is not the same as an internal audit team or second-party (customer) auditor. CBs are third-party, independent organizations.
    • It is not a regulatory authority and generally does not grant legal permissions to operate.
    • It does not manage a company's day-to-day quality system or ensure continuous compliance on its behalf.

    Common confusion

    • Certification body vs. accreditation body: An accreditation body evaluates and approves CBs themselves. A certification body evaluates and certifies manufacturing organizations.
    • Certification body vs. standard owner: Standards (for example, AS9100-series) are developed and maintained by standards organizations or industry groups. CBs apply those standards during audits but do not define their content.

    Link to OASIS and aerospace context

    In the aerospace sector, CBs that certify organizations to the AS9100-series standards are recognized and monitored through industry schemes. They are responsible for entering and maintaining accurate certification and audit data in directories such as the IAQG OASIS database. Manufacturers and customers use this information to verify supplier certification status, scope, and audit history as part of supplier control processes.

  • as-built records

    As-built records are documented evidence of how a product, subsystem, or facility was actually manufactured, assembled, configured, and tested, including any approved deviations from the original design or plan. They capture the real, final state of the build, not just the intended design.

    What as-built records include

    In industrial and regulated manufacturing environments, as-built records commonly include:

    • Final bill of materials (BOM) as used, including alternates and substitutions
    • Serialized component and material traceability, including lot, heat, or batch numbers
    • Final routing, process steps, and work centers actually used
    • Process parameters and key production data where captured (for example, torque values, oven profiles, test results)
    • Approved deviations, concessions, waivers, and rework dispositions affecting the build
    • Inspection, test, and verification records tied to the specific unit or batch
    • Configuration and software/firmware versions installed at release

    These records may be compiled from multiple systems such as MES, ERP, PLM, QMS, and test systems, and are often retained as the authoritative reference for what was actually delivered.

    Where as-built records are used

    As-built records are commonly used for:

    • Regulatory and customer traceability in aerospace, defense, medical devices, and other regulated industries
    • Supporting audits, investigations, and field issue analysis by showing exact build and configuration history
    • Enabling maintenance, repair, and overhaul (MRO) by providing the starting configuration of an asset
    • Supporting engineering changes, retrofits, and upgrades by comparing as-designed, as-planned, and as-built states

    Relationship to other record types

    As-built records are related to but distinct from:

    • As-designed data: The engineering intent, typically managed in CAD/PLM (models, drawings, specifications).
    • As-planned data: How production intends to build, usually in ERP/MES (routings, work instructions, planned BOM).
    • Device or batch history records: In some industries (for example, medical), the formal Device History Record (DHR) or batch record is the regulated package of evidence. As-built records are often a core component of that package.

    Common confusion

    The term “as-built records” is sometimes used interchangeably with:

    • As-built drawings, which focus specifically on updated design documents showing the final physical configuration. As-built records are broader and include process and traceability data, not only drawings.
    • Configuration records, which emphasize versions and options selected. As-built records usually include configuration but also cover how the configuration was achieved in production.

    Ties to digital operations

    In digital manufacturing and MES environments, as-built records are often generated automatically as production executes. Data from work orders, digital travelers, test systems, and quality workflows is aggregated to form a digital as-built or digital birth record for each serialized unit or batch. This supports audits, change control, and plant-wide traceability without disrupting ongoing production.

  • supplier NCR

    A supplier NCR is a non-conformance record used to document a quality issue associated with a supplier, such as defective incoming material, incorrect documentation, or a problem found after supplier-provided processing. In manufacturing, it commonly refers to the formal record that identifies the defect, affected parts or lots, scope, disposition status, and required follow-up with the supplier.

    The term is used in quality, receiving, supplier management, and ERP or MES-connected workflows. A supplier NCR may be opened when an issue is found at incoming inspection, on the shop floor, or later in assembly if the cause traces back to supplied product or service. The record often supports communication of evidence to the supplier so they can assess impact, contain further shipments, investigate cause, and respond with corrective action.

    Supplier NCR should not be confused with a general internal NCR, which may cover issues caused by in-house processes, or with a supplier corrective action request (SCAR), which is a specific request for supplier investigation and action. In many organizations, the NCR is the core quality record, while a SCAR is issued from or linked to that record when supplier response is required.