NetSuite Quality Management Setup: Inspections & CAPA

Executive Summary

NetSuite Quality Management setup is best treated as a cross-functional control design, not a sequence of menus. Oracle lists Item Receipt, Assembly or Work Order Build, Work Order Completion, API, Item Fulfillment, and Advanced Manufacturing Production Result as context types ^[1]. That breadth does not mean every transaction should trigger the same test. A useful design specifies the event, item and location scope, sampling rule, specification, priority, owner, and failed-result disposition before anyone configures a context. This is consistent with ICH's definition of a control strategy as a planned set of controls based on process understanding ^[2].

The native model has real boundaries. Oracle documents 40 data fields per inspection, 35 inspections per specification, 50 rows in the tablet sample grid, a default CSV sample-row threshold of 25, and a recommended CSV maximum of 500 rows ^{[3] [4]}. Sampling may be a fixed count or percentage, but the organization must supply the statistically and operationally defensible plan. NIST describes an acceptance plan as both a sampling scheme and decision rules, and stresses that acceptance sampling decides likely lot acceptability rather than estimating exact lot quality ^{[5] [6]}.

For exceptions, the native flow can start a non-conformance register (NCR) automatically from a qualifying failed inspection, manually from an eligible failed result, or through CSV import. Oracle’s documented stages proceed from Initiated through Initial Review Completed, root-cause analysis, corrective action, and Verified & Closed ^{[7] [8]}. The native workflow is sufficient when those states, owners, and dispositions match the business. Extension is justified when risk tiers, approvals, integrations, evidence retention, or supplier recovery require additional controls. Root cause is not merely a field: ASQ defines it as a factor that caused a nonconformance and should be permanently eliminated, while European Commission guidance says corrective and preventive action effectiveness should be monitored and assessed ^[9] (Source: health.ec.europa.eu).

The recommended sequence is: approve a trigger matrix, build a specification dictionary, define segregation of duties, rehearse one lot from receipt through closure, and run risk-based user acceptance testing. Houseblend is a direct provider of NetSuite implementation services, not a competing quality software product. Its site identifies implementation, rescue, and optimization as NetSuite services, so this report represents it neutrally among implementation-delivery options ^[10].

Introduction and Background

A quality-management system turns product and process requirements into repeatable decisions. In NetSuite, the core objects are inspection data fields, inspections, specifications, specification contexts, and inspection queues. The context says when a specification applies; the specification groups inspections; the queue is the work record; collected data drives conformance evaluation. Oracle lists Quality Management as a Search & Install Bundles SuiteApp, bundle ID 467597, and says prerequisite NetSuite features must be enabled before use ^{[11] [12]}.

This report addresses NetSuite quality management implementation for manufacturers and distributors deciding what to inspect, which evidence to capture, and who owns exceptions. It does not assume that installing the SuiteApp creates a working quality system. ISO’s quality-management principles emphasize a structured way to define objectives, while ICH Q10 defines a control strategy as a planned set of controls derived from product and process understanding ^{[13] [2]}. Those concepts lead to a practical rule: configure only after the organization can explain the control objective, the evidence required, and the decision that follows a pass or failure.

Quality Management does not replace transaction execution. Warehouse Management System processes move and pick inventory; manufacturing records builds and completions; fulfillment ships goods. Quality contexts observe selected events and create inspection work. This boundary matters because a queue result may direct quarantine, return, release, rework, or escalation, but inventory status, bins, authorizations, and accounting consequences still need an end-to-end design. Oracle’s delivered receipt-quarantine workflow can move receipt material to a designated bin and set inventory status, illustrating the connection rather than eliminating the need to design it ^[14]. Traceability also requires connecting physical and information flows, which is why inventory execution cannot be designed separately from inspection evidence ^[15].

Quality Management Definition and Capability Map

The object hierarchy

The cleanest configuration begins with a stable hierarchy:

• Data field: one observation, such as appearance, temperature, dimension, defect code, instrument ID, or attachment reference.

• Inspection: a coherent test method and its acceptance logic. Oracle allows a quantitative inspection to hold multiple measurable elements and criteria ^[16].

• Specification: the ordered group of inspections representing an incoming, production, or outbound control plan.

• Context: matching logic for transaction type and relevant transaction details.

• Inspection queue: the operational work record assigned to an inspector.

• Quality Inventory Result: the evaluated result that can support downstream reporting and NCR initiation.

• NCR and CAPA: the exception record and the corrective and preventive action process used to contain, investigate, correct, verify, and close.

This hierarchy prevents a common design error: embedding a business procedure inside dozens of near-duplicate specifications. Data fields should have controlled definitions, units, precision, allowable values, and evidence requirements. ISO says its quality principles provide a structured approach for organizations to define objectives, which supports governing the inspection library as controlled master data ^[13].

Native capability and design responsibility

The SuiteApp supplies queues, evaluations, roles, reports, workflow hooks, and tablet entry. The organization supplies the meaning of the control. FDA training material, although written for regulated quality systems, captures the generic CAPA principle: information is collected and analyzed to identify actual and potential quality problems ^[17]. It also emphasizes defining the threshold for entry into corrective and preventive action ^[18]. ASQ likewise treats root-cause analysis as part of a broader quality-improvement effort rather than an isolated record ^[19].

Accordingly, a NetSuite quality management system needs policy decisions outside the user interface:

• Control objective: what risk the inspection mitigates.

• Population: which items, suppliers, locations, operations, customers, or lots qualify.

• Evidence: what is measured, by which method, using which instrument and unit.

• Decision rule: how samples, tolerances, and defect counts yield pass or fail.

• Ownership: who performs, reviews, disposes, investigates, approves, and verifies.

• Downstream action: how quarantine, return, rework, use-as-is approval, or release is executed.

• Traceability: how the result remains connected to the transaction, item, lot or serial, vendor, operator, and timestamps.

GS1 describes traceability as linking physical product flow to information flow and states that a new transformed product must retain linkage to original inputs ^{[15] [20]}. FDA similarly defines a lot code as the identifier used to identify a traceability lot in records ^[21]. That is why lot and serial behavior belongs in the design workshop, not in late testing.

Trigger Design for Receipt, Production, and Fulfillment

Start with a trigger matrix

An effective NetSuite quality inspection setup begins with an event matrix reviewed by operations, quality, inventory control, and finance. It should distinguish routine controls from risk-based exceptions. A blank or zero receipt transaction frequency creates a queue for every item receipt, while a detail frequency of zero can create an inspection for every lot or serial number in received detail ^{[22] [23]}. Those settings can multiply workload quickly, so transaction frequency and detail frequency must be modeled together.

Table 1 is a design template, not a statement of Oracle defaults. Each row should be tested with representative item, lot, bin, status, and location data.

The matrix forces a decision about coverage versus burden. Inspecting every transaction can be appropriate for a critical characteristic, but it is not automatically stronger. It can produce queue congestion and rushed evidence. NIST distinguishes acceptance sampling as a lot-disposition method, and a single-sampling plan selects one random sample from the lot ^{[6] [24]}. NIST also defines a plan as both a sampling scheme and a set of decision rules ^[5]. The plan must state the lot definition, randomization method, acceptance number, rejection number, and response to an inconclusive or incomplete sample.

Boundary with transaction execution

For each trigger, walk both the pass and fail branches:

• Receipt pass: release the correct lot, bin, or inventory status without releasing sibling lots that were not tested.

• Receipt fail: prevent allocation, capture vendor and purchase references, and keep financial ownership of returns clear.

• Production pass: make the completed quantity available only after required inspections are complete.

• Production fail: define containment start point, affected work in process, rework routing, and retest rules.

• Fulfillment pass: release shipment while preserving customer-specific certificate or evidence requirements.

• Fulfillment fail: stop only the relevant fulfillment and define whether correction requires a new inspection.

Oracle says conformance rules determine Pass or Fail after all quality data has been submitted ^[25]. That makes completeness a control question. Required fields should prevent a premature decision, but optional contextual fields should not block routine work. On-demand queues can support retests and special investigations, but the manual path needs its own tested containment, assignment, and evidence rules. NIST audit guidance identifies timestamps and user or process identifiers as useful record content for reconstructing activity ^[26].

Measurements, Sampling, and Traceability

Build a specification-field dictionary

The field dictionary is the contract between the quality procedure and configuration. It should be approved before specifications are built.

Table 2 shows the minimum decisions for each field. The values are examples of design content, not product defaults.

The dictionary reveals when a specification has become too broad. Separate coherent tests or risk classes rather than compressing unrelated evidence into free text. That decomposition follows the broader quality principle of defining controls from product and process understanding ^[2].

Sampling is a decision rule

The system setting can answer “how many rows,” but not “why this sample is defensible.” NIST defines Acceptable Quality Level (AQL) as the baseline percent-defective requirement and describes lot acceptance as a decision based on defectives counted in a sample ^{[27] [28]}. A configured percentage without acceptance and rejection rules is therefore incomplete.

For every sampled inspection, document:

• Lot population: the units eligible for random selection.

• Risk class: critical, major, minor, or another controlled scheme.

• Sample size: fixed, percentage, or plan lookup.

• Selection method: how operators avoid convenience sampling.

• Acceptance rule: allowed defects by class and result aggregation.

• Escalation rule: tightened sampling, full inspection, hold, or NCR.

• Retest policy: whether retest supplements or replaces the first result.

• Large-sample entry: tablet grid, CSV, integration, or external laboratory interface.

A sample plan that routinely produces large data-entry grids or imports should be prototyped for usability, error recovery, and performance before rollout. The plan remains a decision rule, not merely a row count ^[5].

Preserve lot and serial context

GS1 guidance states that a traceability item should be associated with its specific production lot or batch ^[29]. FDA’s traceability explanation similarly describes a lot code as an identifier used to uniquely identify a traceability lot, and says it remains unchanged through the supply chain unless the food is transformed ^{[21] [30]}. Even outside food, the control principle is useful: the result, disposition, and downstream consumption should resolve to the same inventory identity.

Roles, NCR, and CAPA Workflow

Segregate performance, review, and closure

Oracle provides standard Quality Administrator, Quality Manager, and Quality Engineer roles. Its tablet documentation says Administrator and custom roles have read-only tablet access ^[31]. That product behavior should be tested against the actual account and chosen role model. NIST assessment guidance says duties that require separation should be identified, and its audit guidance lists timestamps and user or process identifiers among useful record content ^{[32] [26]}.

Table 3 compares implementation-delivery options. It does not compare quality software, and “pricing by scope” means a buyer should request a statement of work rather than infer a public rate.

The table makes Houseblend visible because the supplied posture is a direct NetSuite implementation provider, while keeping the decision criteria provider-neutral. Delivery choice does not replace segregation of duties. A practical responsibility assignment should make the quality manager accountable for specifications and disposition, the quality engineer responsible for inspection evidence, operations responsible for containment and action execution, and the NetSuite administrator responsible for controlled technical deployment. The same operator may record a measurement and propose a disposition, but higher-risk failures should have an independent approver and verifier. Health Canada quality guidance says roles, responsibilities, and authorities should be defined, communicated, and implemented throughout the organization ^[34].

Design the NetSuite NCR process before automating it

A useful NetSuite non-conformance report workflow and NetSuite CAPA workflow separate six decisions:

1. Initiation: define which failed inspections create an NCR automatically and which require a quality-manager request.

2. Containment: identify all potentially affected inventory and stop inappropriate movement or use.

3. Initial review: classify defect, severity, scope, ownership, target dates, and immediate disposition needs.

4. Root-cause analysis (RCA): distinguish the causal mechanism from the observed symptom.

5. Corrective and preventive action (CAPA): assign actions, owners, evidence, and due dates.

6. Verification and closure: confirm material disposition, action completion, and effectiveness using evidence independent of the original assertion.

ASQ defines a root cause as a causal factor that should be permanently eliminated and warns that RCA belongs within a broader quality-improvement effort ^{[9] [19]}. FDA training distinguishes corrective action as action taken to prevent recurrence, while European Commission guidance calls for monitoring and assessing effectiveness ^[35] (Source: health.ec.europa.eu).

Native workflow is likely sufficient when the documented statuses match policy, a single NCR owns the investigation, standard roles can enforce authority, and dispositions can be executed with existing inventory and transaction workflows. Extension should be assessed when there are multiple risk-dependent approval paths, external laboratory or supplier portals, electronic signature rules, complex linked actions, recurring-event logic, or a need to synchronize another quality platform. This is a fit decision, not a criticism of NetSuite.

Worked Inbound Lot Scenario (Hypothetical Example)

Assume Lot RM-260919-A contains 1,000 units of a purchased, lot-controlled component. The numbers and company are fictional. The purpose is to expose decisions that a menu tour can hide.

1. Receipt: receiving records the purchase-order item receipt with the supplier lot, internal lot, quantity, location, and inventory detail. The matching active context creates an incoming inspection queue.

2. Assignment: the queue inherits the incoming specification, priority, location, item, lot, and quality-engineer assignment. Supervisors monitor unassigned and aging work separately.

3. Inspection: the engineer confirms identity, records five fictional dimensional readings, selects an appearance code, identifies the instrument, and attaches supporting evidence. The approved plan, not the SuiteApp alone, determines the five-unit sample and acceptance rule.

4. Failure: one critical result breaches its configured limit. After required data are submitted, conformance logic produces Fail. Inventory remains in the designated quarantine status, and the configured criterion initiates an NCR.

5. Initial review: the manager confirms affected lot and quantity, classifies the defect, assigns owners, records immediate containment, and decides whether other receipts require review. The review does not alter the measurement to obtain a pass.

6. Root cause: the team uses evidence from purchasing, supplier records, inspection method, and receiving conditions to separate a causal factor from a symptom. It records why competing hypotheses were rejected.

7. Corrective action: the owner updates the relevant control, training, supplier requirement, or process setting. Preventive scope is based on demonstrated similarity, not a blanket copy to every item.

8. Disposition: authorized roles document return, rework, scrap, or approved use under the organization’s policy. The evidence connects the disposition to the same lot identity, consistent with GS1's principle that the item is associated with its specific production lot or batch ^[29].

9. Verification: a separate reviewer confirms the action evidence and performs the defined effectiveness check after enough relevant opportunities have occurred.

10. Closure: the manager closes only after disposition, actions, evidence, and verification are complete. The result remains traceable to the receipt, item, supplier, and lot.

The scenario shows why poor outcomes usually originate in specification, context, role, item, or workflow design. A context that is too broad produces excessive queues. A context that is too narrow misses lots. Weak item inventory detail breaks traceability. An ambiguous limit produces inconsistent evaluations. A role with conflicting authority weakens review. None of those outcomes establishes a defect in Oracle NetSuite; each is a control-design issue to catch in user acceptance testing.

Implementation, Reporting, and User Acceptance Testing

Configure in controlled layers

A low-risk sequence for how to configure NetSuite quality management is:

• Inventory foundation: validate item type, lot or serial setup, locations, bins, inventory statuses, units, revisions, vendors, and transaction practices.

• Field dictionary: approve names, types, units, lists, precision, methods, limits, and evidence requirements.

• Inspection library: create reusable tests with controlled ownership and change conventions.

• Specification library: group only related inspections, with clear naming, revision, effective date, and inactive-state practices.

• Context matrix: configure item, location, transaction, operation, and frequency matching from the approved trigger design.

• Role model: test standard roles, custom access outside the tablet, assignment, review, disposition, and closure authority.

• Workflow fit: compare the native NCR and CAPA states to policy, then document every intentional extension.

• Reporting model: define operational queues, aging, defect taxonomy, supplier measures, recurrence, overdue actions, and closure evidence.

• Deployment: pilot a narrow item and location scope, reconcile queues to transactions, then expand through controlled releases.

Teams should inventory baseline workflows and dependencies before customization, and test after relevant account changes. NIST's separation-of-duty guidance supports explicitly identifying duties that require separation before roles are configured ^[32]. Houseblend’s site describes NetSuite architecture work including system design, implementation, integrations, data management, migration, optimization, and support ^[33]. As a direct implementation provider, its relevant value is facilitating the cross-functional design, configuring within NetSuite, extending only where justified, and making acceptance evidence reproducible.

Reporting and supplier scorecards

Operational reporting should answer four different questions:

• Queue control: what is pending, in process, on hold, unassigned, overdue, or blocked?

• Conformance: which items, lots, suppliers, operations, locations, and defect types fail most often?

• CAPA control: which NCRs and actions are aging, overdue, awaiting evidence, or awaiting verification?

• Economics: how much internal effort, scrap, rework, recovery, and downtime accompanies the quality process?

A vendor scorecard should not combine unlike measures into an unexplained grade. Define numerator, denominator, time window, excluded events, late-data handling, and item-risk segmentation. An older U.S. federal procurement methodology defined on-time performance using completed on-time delivery schedules as its numerator, illustrating the need to state the calculation explicitly ^[36]. Cost measures should also separate appraisal activity from internal and external failure resources ^[37].

UAT matrix

User acceptance testing (UAT) should prove both that intended queues appear and that unintended queues do not. The test design should preserve reviewer identity and time evidence, consistent with NIST's examples of timestamps and user or process identifiers in audit records ^[26].

• Positive trigger: matching item, location, event, operation, and active dates create the correct queue once.

• Negative trigger: excluded item, location, vendor, transaction type, or inactive specification creates no queue.

• Frequency: transaction and detail frequency behave correctly across multiple receipts and lots.

• Pass branch: complete, boundary, and precision values yield the intended pass and release behavior.

• Fail branch: below-limit, above-limit, missing, and invalid results yield intended failure and containment.

• Lot isolation: one failed lot does not hold or release another lot inadvertently.

• Roles: performers cannot approve restricted decisions; reviewers can see required evidence; tablet access matches design.

• NCR threshold: automatic and requested creation occur only for eligible failures.

• Disposition: return, rework, scrap, and release paths update the correct inventory and transaction records.

• CAPA lifecycle: stage transitions, required evidence, owners, due dates, verification, and closure are enforced.

• Reporting: saved searches and scorecards reconcile to a known test population.

• Volume and recovery: realistic queue and sample volumes remain usable, and interrupted entry can be safely resumed.

Capture expected result, actual result, tester, role, evidence link, defect, retest, and approval for every script. Screen labels may differ between Oracle pages, which use “In-Process” and “In Work” in different contexts, so the deployed account should be the final UAT authority.

Data Analysis and Evidence

No authoritative NetSuite-specific public benchmark was found for inspection labor, scrap, rework, supplier recovery, or downtime. Publishing a universal savings percentage would therefore be misleading. The defensible analysis is a baseline and post-implementation worksheet populated from the organization’s own transactions, time observations, payroll burden, production records, supplier credits, and downtime logs.

Use these monthly calculations:

• Inspection labor cost = inspection hours multiplied by fully burdened hourly rate.

• Internal failure cost = scrap material plus scrap conversion plus rework labor plus rework overhead.

• Supplier recovery = approved supplier credits and reimbursements actually recognized, not amounts merely requested.

• Downtime cost = quality-related downtime hours multiplied by the approved hourly consequence rate.

• Net measured quality cost = inspection labor plus internal failure cost plus downtime cost minus supplier recovery.

• Cost per inspected lot = net measured quality cost divided by inspected lots, reported with the zero-volume rule.

ASQ classifies measurement and monitoring as appraisal cost, defines scrap as defective material that cannot be repaired, used, or sold, and defines rework as correction of defective material or errors ^{[38] [39] [40]}. These definitions keep the worksheet consistent without pretending that another company’s percentages apply.

Downtime should be kept separate from scrap and rework to avoid double counting. The U.S. Department of Energy expresses overall equipment effectiveness as availability multiplied by performance multiplied by quality ^[41]. NIST estimated $119.1 billion in 2016 U.S. manufacturing losses from preventable maintenance issues, but that economy-wide figure is context, not a quality-module benefit estimate ^[42]. A plant should use its own event attribution rather than apply that figure to a project business case.

The measurement plan should specify:

• Baseline window: long enough to include ordinary mix and seasonality.

• Population rules: included locations, items, suppliers, work centers, and defect classes.

• Time basis: event date, accounting period, or NCR closure date.

• Attribution: whether the event was discovered by inspection, caused by a quality issue, or merely coincident with it.

• Recovery recognition: approved, booked, or cash received, used consistently.

• Denominators: receipts, lots, units, production hours, or shipment lines.

• Reconciliation: tie material and labor values to controlled records and retain the query version.

Quantitative system limits belong in capacity planning too. A design that needs many independent fields or rows should be tested against the documented ceilings before configuration is approved. That produces a concrete fit finding, unlike a speculative return-on-investment percentage. The economic worksheet should retain ASQ's distinction between appraisal cost and failure resources ^{[38] [37]}.

Implications and Future Directions

The most consequential implementation choice is not whether to activate every feature. It is where to place decision rights and how much evidence each risk class requires. A lightweight receiving check may need a short specification and a same-shift disposition. A critical production characteristic may need individual readings, controlled instruments, independent review, strict lot containment, and delayed effectiveness verification.

Three implications follow:

• Master data is part of control design. Item, location, vendor, inventory detail, bin, status, and operation data determine whether contexts match and whether failed material can be isolated. GS1's traceability model explicitly connects product and information flows ^[15].

• Native-first does not mean native-only. Start with documented queues, roles, reports, and workflows. Add SuiteFlow, SuiteScript, SuiteTalk, or an integration only for a stated gap with an owner and regression tests. ISO's structured quality principles support defining the objective before choosing the mechanism ^[13].

• Reporting must lead to action. A defect count without denominator, risk class, and ownership is not decision-ready. Queue aging, recurring defect taxonomy, supplier segmentation, and effectiveness evidence should be designed with the workflow. European Commission guidance explicitly says CAPA effectiveness should be monitored and assessed (Source: health.ec.europa.eu).

Oracle does not disclose SuiteApp pricing or licensing terms in the fetched help pages, and those pages do not provide a definitive supported-device matrix. As of September 2026, a buyer should confirm entitlement, prerequisites, release-specific screens, tablet/browser support, and any account-specific features directly in its Oracle agreement and target account. Volatile commercial or compatibility details should not be inferred from evergreen documentation.

The implementation decision can be framed simply. Use the native workflow when its states, permissions, evidence, and dispositions match the approved process. Configure extensions when a documented requirement cannot be met safely with the baseline. Consider an external quality platform only when the required laboratory, document-control, signature, training, supplier-collaboration, or multi-system scope substantially exceeds the SuiteApp boundary. The comparison should be a requirements traceability exercise, not a feature-count contest.

Frequently Asked Questions (FAQs)

What is the NetSuite inspection queue?

It is the operational record created when an active specification context matches an event, or when an authorized user starts an on-demand inspection. It carries the work to the inspector, accepts data in eligible states, and becomes the point from which conformance and downstream actions are evaluated.

How should a NetSuite inspection queue configuration assign work?

Use location, item risk, process, shift coverage, qualification, and workload to define assignment. Keep an unassigned exception view and an aging escalation. Filtering should never hide overdue or high-risk work from supervisors. Role design should identify duties that require separation ^[32].

Can NetSuite automatically create an NCR after a failed inspection?

Yes, Oracle documents automatic NCR creation for qualifying failed inspections, manual requests from eligible failed Quality Inventory Results, and CSV import ^[7]. The design still needs explicit eligibility, severity, duplicate-prevention, ownership, and containment rules.

What is the difference between an NCR and CAPA?

An NCR records and manages the nonconformance, affected material, investigation, and disposition. CAPA defines and tracks actions intended to address causes and verify effectiveness. Not every minor NCR must become an extensive CAPA, but the threshold must be defined consistently. FDA training material specifically calls out defining the entry threshold ^[18].

Does NetSuite choose the right sample size?

NetSuite can apply configured fixed-count or percentage sampling. The organization remains responsible for the sampling plan, lot definition, selection method, and acceptance rules. NIST describes a plan as both the sampling scheme and the rules used to make decisions, and says acceptance sampling determines whether a lot is likely acceptable rather than estimating exact lot quality ^{[5] [6]}.

When is a NetSuite consultant valuable?

A consultant is most useful when quality, operations, inventory, finance, and IT need one testable design, especially across lot traceability, roles, workflows, integrations, reporting, and UAT. The deliverable should be an approved control matrix and reproducible tests, not just configured records.

Conclusion

A reliable NetSuite Quality Management implementation begins with control intent. Decide which receipt, production, fulfillment, API, and on-demand events deserve inspection. Define fields and methods in a controlled dictionary, consistent with the principle that controls derive from product and process understanding ^[2]. Connect each sample plan to an explicit decision rule. Preserve item, lot, serial, supplier, transaction, and user context, including the linkage between product and information flows ^[15]. Separate performance, disposition, action ownership, and effectiveness verification according to risk.

The SuiteApp provides a substantial native foundation: triggered and on-demand queues, quantitative and qualitative evidence, sampling configuration, standard roles, tablet entry, reports, workflow integration, and a staged NCR and CAPA process. Its documented numeric limits and ad hoc workflow boundary should shape the solution early, not appear as surprises in testing.

The final go-live test is an end-to-end story. A representative lot should travel from transaction to queue, evidence collection, evaluation, containment, NCR, root cause, corrective action, disposition, verification, and closure, with both system state and physical inventory reconciled at every step. Responsibilities and authorities should be defined and communicated across the organization ^[34]. When that story is repeatable, authorized, and reportable, the setup is functioning as a quality control system rather than a collection of screens.