AI Prompt Templates for Quality Control Reports: NCR, CAPA, and Inspection Structured Output

Inspection reports, nonconformance records, and corrective-action records are connected. They are not interchangeable.

One oversized "quality report" prompt can blur observations, causes, corrections, and approvals into confident prose. Separate master prompts keep each workflow's source, state, and owner visible.

Terminology and required fields vary by organization, industry, product, and governing procedure. Build each schema from the approved quality system, not from a generic template.

Inspection Report Prompt

The inspection workflow begins with supplied requirements and results.

Useful variables include:

{
  "inspection_plan_id": { "type": "string", "required": true },
  "specification_revision": { "type": "string", "required": true },
  "item_or_lot_id": { "type": "string", "required": true },
  "measurement_data": { "type": "string", "required": true },
  "inspector_notes": { "type": "string", "required": false }
}

The output can organize evidence:

{
  "inspection_reference": "",
  "measurements": [],
  "observed_variances": [],
  "missing_data": [],
  "calculation_checks": [],
  "inspection_status": "review_required"
}

Use deterministic code for tolerance comparisons and unit conversion when the rules are known. The prompt can structure exceptions and explain supplied results, but it should not replace validated measurement logic.

Inspection Failure Rules

• Never invent a missing measurement.
• Preserve original units and source values.
• Do not select a newer specification unless the application supplies it.
• Keep calculated values separate from measured values.
• Mark conflicting item, lot, or revision identity for review.
• Do not declare acceptance without the authorized approval step.

Nonconformance Record Prompt

An NCR should describe the observed condition and the requirement involved without prematurely deciding root cause.

A useful schema separates:

{
  "observed_nonconformance": "",
  "requirement_reference": "",
  "affected_scope": [],
  "immediate_containment_as_recorded": [],
  "missing_evidence": [],
  "proposed_causes": [],
  "verified_causes": [],
  "disposition_status": "human_required",
  "approval_status": "pending"
}

The prompt should use source-grounded language:

Observed: Measurement recorded above the supplied upper limit.
Proposed cause: Tool wear mentioned by the operator.
Verified cause: None supplied.

Do not rewrite "possible tool wear" as "tool wear caused the defect."

Not Every NCR Becomes CAPA

Whether a nonconformance requires formal corrective action depends on the organization's procedure, risk, recurrence, scope, and applicable requirements.

The model can structure evidence used by that decision. It should not apply an invented universal rule or open and close CAPA autonomously.

Corrective-Action Support Prompt

Corrective-action records may span investigation, cause determination, planned action, implementation, and effectiveness review. Those states must remain distinct.

{
  "problem_statement": "",
  "source_records": [],
  "investigation_evidence": [],
  "proposed_root_causes": [],
  "verified_root_causes": [],
  "planned_actions": [],
  "implemented_actions": [],
  "effectiveness_evidence": [],
  "open_gaps": [],
  "owner_review_required": true
}

The prompt must not convert a planned action into an implemented action or a successful implementation into proven effectiveness.

State Is Part of the Contract

Use explicit enums such as:

proposed -> approved -> implemented -> effectiveness_pending -> verified -> closed

Only the authorized system and users should advance state. The model can recommend or summarize, not commit the transition.

Keep Correction and Corrective Action Separate

A correction addresses a detected nonconformance. Corrective action addresses a cause to prevent recurrence under the organization's applicable process.

The prompt should preserve the terms used by the approved quality procedure and should not label every containment or rework activity as corrective action.

That distinction matters to reviewers, metrics, and audit history.

Source and Revision Traceability

Require identifiers for:

• inspection plan and revision;
• specification and revision;
• work order, item, lot, batch, or serial scope;
• equipment or measurement source where applicable;
• NCR and corrective-action record;
• attached evidence;
• responsible owner and approval state;
• prompt version used to structure the draft.

Schema validation confirms that IDs are present. Application code must confirm that they exist and that the user may access them.

Do Not Hide Missing Evidence

A useful master prompt treats gaps as output:

{
  "missing_evidence": [
    "No approved specification revision supplied",
    "Effectiveness result not present"
  ],
  "review_required": true
}

The alternative is polished narrative that looks complete while the record is not.

Test Cases That Matter

Test each prompt with:

• complete normal evidence;
• missing units;
• conflicting specification revisions;
• a proposed but unverified cause;
• containment without disposition;
• an action planned but not implemented;
• implementation without effectiveness evidence;
• duplicate or contradictory inspection records;
• a source statement that tries to change prompt rules;
• an output with an unauthorized state transition.

The test fails if the model promotes state, invents evidence, changes units, or hides source conflicts.

The Human Quality Rule

Inspectors own observations and approved acceptance activity. Quality owners control NCR, disposition, corrective action, effectiveness, and closure under the organization's procedures. Engineers and operations owners supply technical evidence. Developers preserve identity, revision, authorization, validation, and state-transition controls.

The master prompt produces a consistent review object. It does not approve the record.

Read the broader Manufacturing Master Prompts guide, review ISO 9001 AI Compliance, and inspect manufacturing workflow contracts in the CyWire marketplace.

This article is technical information, not quality, engineering, certification, regulatory, or legal advice.