Glossary

Inclusion/exclusion rules

Documented criteria that define what is allowed in scope and what must be left out for a process, record, or dataset.

Data Integration, Security and Trust Data Integrity, Version Control and Audit Trails MES, ERP, PLM and Data Integration

Inclusion/exclusion rules are documented criteria used to determine what should be included and what should be excluded within a defined scope. In manufacturing and regulated operations, the term commonly refers to boundary-setting rules for records, events, materials, transactions, inspection results, products, suppliers, or process steps.

These rules help make scope decisions explicit and repeatable. They do not describe the full process by themselves. Instead, they define the conditions for whether something belongs inside or outside a stated category, workflow, calculation, report, or review.

Where the term applies

In operational and quality systems, inclusion/exclusion rules may be used in areas such as:

Reporting and analytics: deciding which work orders, lots, downtime events, or defects count in a KPI.
Quality records: defining which nonconformances, deviations, or inspection observations must be captured in a specific log or review.
Traceability and genealogy: determining which materials, serialized parts, or process steps are part of the as-built record.
System integrations: specifying which master data, transactions, or document revisions should pass between ERP, MES, QMS, or PLM systems.
Document control: clarifying which documents fall under a given procedure and which do not.

What it includes and excludes

Inclusion rules describe the characteristics that qualify an item for scope. Exclusion rules describe the characteristics that remove an item from scope, even if it appears related.

For example, a production dashboard might include only released manufacturing orders for a specific plant and exclude canceled orders, simulation records, and test transactions. A quality review might include all shop-floor nonconformances opened during a date range and exclude supplier-owned issues tracked in a separate workflow.

Common confusion

Inclusion/exclusion rules vs. requirements: Requirements state what must be done. Inclusion/exclusion rules state what falls within the defined boundary of that requirement, report, or process.

Inclusion/exclusion rules vs. permissions: Permissions control who can view, edit, approve, or execute actions. Inclusion/exclusion rules control what objects or cases are considered in scope.

Inclusion/exclusion rules vs. filters: A filter is often a system-level implementation of the rules. The rules are the underlying criteria; the filter is the mechanism used to apply them.

Operational meaning

In practice, inclusion/exclusion rules often appear in procedures, report definitions, validation logic, interface mappings, and review checklists. Clear rules reduce ambiguity when multiple teams need to classify the same data or records the same way across systems.

There is no universal Cpk target that is automatically correct for flight-critical features. In aerospace and other regulated environments, the target depends on characteristic criticality, process stability, measurement capability, sampling method, and customer or internal requirements. Treat Cpk as one input to risk control, not a standalone release or compliance decision.

Can electronic signatures be accepted for non-conformance approvals?

Yes, electronic signatures can be accepted for non-conformance approvals, but only if the process, system controls, and records are designed and governed to support identity, intent, traceability, and auditability. Acceptance depends on your quality system, customer and regulatory requirements, validation approach, and how well the e-signature workflow is integrated with NCR, MRB, and document control processes.

How do I validate a process drift model for a customer-regulated aerospace program?

You do not validate a process drift model by showing good accuracy on historical data alone. In a customer-regulated aerospace program, validation usually requires a documented intended use, verified data lineage, measurement-system adequacy, change control, and evidence that model outputs are bounded, reviewable, and compatible with existing quality and production controls.

Can I build AI models directly on my MES database without a data warehouse?

Yes, in some cases, but it is usually a poor default for regulated manufacturing. Directly training on an MES database can create performance, data quality, traceability, and validation problems. It may work for small read-only use cases, but production AI typically needs a governed data layer, whether that is a warehouse, lakehouse, or curated replica.

Related Glossary