TEMPLATES · WORKED EXAMPLES

See a filled record before you fill your own.

A blank template is hard to fill in without a reference. Each of these three cases carries all ten appendices — Use-Case Charter through Assessment Questions and Glossary — to completion, end to end, on real wind-sector situations from the Case Atlas. Read one before opening the blank appendix — then adapt, don't copy, the specifics to your own use case.

WORKED EXAMPLE 01 · Blade-bonding void-rate anomaly signal

A candidate-correlation flag, never a stated cause

A blade-bonding line has an intermittent void rate that inspection has not yet linked to a specific cure parameter. Process engineering wants a preventive signal before the next non-conformity, not a retrospective root-cause report.

APPENDIX A · USE-CASE CHARTER — FILLED

Quality problem / recurring decision

Void-rate excursions on the blade-bonding line are caught after cure, not predicted before it; root cause is not yet linked to a cure parameter.

Process owner

Amara Solis, Process Engineering Lead, Bonding Line 2

Manual baseline

Process engineers review cure-cycle trend charts weekly by hand; correlation to void rate has taken up to six weeks to establish per prior incident

Intended use

Flag cure-cycle windows whose temperature/pressure/dwell pattern statistically correlates with elevated void rate, ranked by strength of association, as an investigation input only

Evidence sources and revisions

Cure-cycle logs (temperature, pressure, dwell time) and void-rate inspection records, joined by lot and station, cure-log schema v2.1 since 2025-11-01

Output destination

Automated report

Human decision boundary

Human reviews flagged cases only

Acceptance measure

False-flag rate below 15% against process engineering's independent judgement on a held-out set of 40 prior lots

APPENDIX B · DATA CLASSIFICATION RULE — FILLED

Evidence class

Internal process data — cure-cycle logs and void-rate inspection records, not customer or personal data

Permitted use

Statistical correlation analysis for investigation triage only; not permitted as input to any automated process-parameter change

Retention

Retained for 3 years alongside the source cure-log and inspection records it was joined from, per existing quality-record retention policy

Access

Process Engineering and Bonding Line 2 quality staff only; no supplier or external access

Source authority

Cure-log schema v2.1 (MES export) and inspection record system are the systems of record; the tool holds no independent copy of authority

APPENDIX C · AI RISK ASSESSMENT — FILLED

consequence

medium — a missed or false preventive signal delays a real fix but does not itself release a defect

influence

medium — output opens or declines an investigation, not a disposition

criticality

medium — void rate affects a structural bonding characteristic

sensitivity

low — internal process data only, no restricted evidence

traceability

low — flagged windows link directly to the source cure-log rows and lot IDs

propagation

medium — an undetected recipe drift could affect multiple lots before caught manually

volatility

low — the statistical model is refit quarterly, not per-run

dependency

low — runs on internally held process data, no external provider

CONTROLS AND SAFEGUARDS

Output is labelled explicitly as a candidate-correlation list, never a stated cause. The tool's output destination is fixed as an investigation input; it cannot trigger a process-parameter change directly.

RESIDUAL RISK AND ACCEPTANCE

Residual risk of a missed preventive signal is accepted by the Process Engineering Lead given the existing weekly manual trend review remains in place as a backstop.

Result: Level B

APPENDIX D · ONE-PAGE TOOL SPECIFICATION — FILLED

Inputs

Cure-cycle logs (temperature, pressure, dwell time) and void-rate inspection records, joined by lot and station

Outputs

Ranked list of cure-window candidate correlations with association strength, lot IDs and source rows

Limits

Requires at least 20 logged cure cycles per lot; does not run on lots below that threshold

Configuration

Anomaly-correlation model v1.4, quarterly refit, cure-log schema v2.1

Acceptance

False-flag rate below 15% on a held-out set of 40 prior lots

Human review

Process engineer investigates every flagged window before any parameter change is proposed

APPENDIX E · GOLDEN SET AND EVALUATION REGISTER — FILLED

Known-correct cases

12 prior lots with a process-engineer-confirmed cure-parameter root cause, used to check the model surfaces the true correlation

Hard cases

6 lots with two overlapping candidate parameters, where the true cause was only resolved after supplemental testing

Borderline cases

5 lots just above the 20-cycle minimum, to check the low-confidence flag behaves correctly near the threshold

No-finding cases

9 lots with normal void rate and no known cure-parameter issue, used to check the false-flag rate on clean data

APPENDIX F · QUALIFICATION FILE — FILLED

Intended use and limits

Assistive triage only; surfaces candidate cure-window correlations for engineer investigation, never states a confirmed cause

Evidence and configuration

Cure-log schema v2.1, void-rate inspection record, anomaly-correlation model v1.4, quarterly refit

Evaluation results

83% of investigator-confirmed correlations from the prior 12 months were also surfaced by the model on a held-out set; false-flag rate 12%

Known limitations and controls

Degrades when a lot has fewer than 20 cure cycles logged; flagged low-confidence windows are marked, not suppressed

Approval and monitoring

Approved by A. Solis, 2026-02-14; false-flag rate reviewed monthly against the acceptance measure in the charter

APPENDIX G · PRODUCTION GO-LIVE CHECKLIST — FILLED

Operational controls

Tool output feeds the weekly cure-trend review meeting only; no direct write access to MES or cure-cycle set points

User training

Process engineers briefed on reading association-strength scores and the low-confidence flag before first live use

Monitoring

Monthly false-flag rate tracked against the 15% acceptance measure; refit schedule logged

Incident handling

Any missed preventive signal later confirmed by a non-conformity is logged and reviewed at the next quarterly refit

APPENDIX H · CHANGE AND REVALIDATION LOG — FILLED

Change

Quarterly refit of anomaly-correlation model v1.4 on the latest 12 months of cure-log and inspection data

Retested

False-flag rate re-measured on the current 40-lot held-out set after each refit

Accepted by

A. Solis, Process Engineering Lead

Why

Keeps the correlation model current as bonding-line process drift occurs, without changing the intended use or output destination

APPENDIX I · SUPPLIER AND THIRD-PARTY AI QUESTIONNAIRE — FILLED

Provider

Internally built and hosted; no third-party AI service in this use case

Source

Cure-log and inspection data originate entirely from in-house MES and inspection systems

Access

No external party has access to cure-log or inspection data used by the model

Change control

Model refits are internal changes, logged in the change and revalidation log, not a supplier-issued update

Incident and evidence responsibilities

Not applicable — no supplier relationship to notify or audit for this tool

APPENDIX J · ASSESSMENT QUESTIONS AND GLOSSARY — FILLED

Practical question

Would a process engineer trust this flag enough to open an investigation without first checking the raw trend chart?

Practical question

What happens on a lot with exactly 19 logged cure cycles — is the exclusion boundary obvious to a new engineer?

Glossary term

Candidate correlation — a statistical association surfaced for investigation, explicitly not a stated or confirmed cause

Glossary term

False-flag rate — the proportion of surfaced correlations that an investigator's independent judgement does not confirm

WHAT TO NOTICE

Notice the risk assessment lands at B, not A — a statistical tool touching a structural characteristic still needs a written specification, an evaluation on known cases and a named approver, even though nothing here is a language model and nothing here makes an automatic decision.

WORKED EXAMPLE 02 · Structural weld-package completeness check

Report what was checked, not just what passed

A structural welding package for a tower section arrives from a new supplier with a large document set: weld procedure qualifications, NDT reports and material certificates. The reviewer has a fixed window before the next assembly gate.

APPENDIX A · USE-CASE CHARTER — FILLED

Quality problem / recurring decision

Manual completeness review of large weld-package submissions is slow and inconsistent across reviewers, especially under assembly-gate deadlines

Process owner

Tomas Nkemelu, Supplier Quality Engineer, Tower Structures

Manual baseline

One reviewer manually checks each package against a 34-item checklist, approximately 3 hours per package

Intended use

Confirm every required document type and field is present, and flag where a submitted value appears inconsistent with the applicable specification revision, as a structured findings list

Evidence sources and revisions

Supplier's submitted document package, specification revision D (effective 2025-09), required-document checklist v3

Output destination

Operator dashboard

Human decision boundary

Human reviews flagged cases only

Acceptance measure

Every flagged finding must be verifiable by the reviewer in under 30 seconds against the cited document location (Thirty-Second Lab test)

APPENDIX B · DATA CLASSIFICATION RULE — FILLED

Evidence class

Supplier-submitted technical documents — weld procedure qualifications, NDT reports, material certificates

Permitted use

Completeness and consistency checking against specification revision D only; not permitted as a standalone accept/reject basis

Retention

Retained for the life of the tower structure record, matching existing supplier-document retention policy

Access

Supplier Quality Engineering and the assembly-gate review board; not shared outside the reviewing organisation

Source authority

Specification revision D and required-document checklist v3 are authoritative; the tool never overrides either

APPENDIX C · AI RISK ASSESSMENT — FILLED

consequence

high — an undetected missing NDT report or misread material certificate could allow a non-conforming weld package to pass the gate

influence

high — directly informs a gate-pass/hold decision

criticality

high — structural tower weld is a safety-critical characteristic

sensitivity

medium — supplier-submitted commercial and technical documents

traceability

medium — every flag names the document and field, but illegible scans may be silently unreadable if not explicitly reported

propagation

medium — a systematic misread could affect every package from one supplier

volatility

low — specification revisions change a few times a year, not per-run

dependency

low — runs on internally held documents, no external provider

CONTROLS AND SAFEGUARDS

The tool states explicitly what it checked and what it could not check (illegible scans, missing pages) rather than reporting silence as a pass. Every flagged inconsistency names the exact document and field. A named reviewer accepts, rejects or escalates every flag.

RESIDUAL RISK AND ACCEPTANCE

Residual risk of a missed inconsistency is accepted by the Supplier Quality Engineer on the condition that unreadable or unchecked items are always recorded as open gaps, never as passes, and every package retains a named human sign-off.

Result: Level C

APPENDIX D · ONE-PAGE TOOL SPECIFICATION — FILLED

Inputs

Supplier's submitted document package against specification revision D and required-document checklist v3

Outputs

Structured findings list: present/missing per checklist item, and any field value inconsistent with the specification, each naming its document and location

Limits

Cannot assess illegible or handwritten scans; does not issue an accept/reject disposition

Configuration

Checklist v3, specification revision D, document-parsing configuration v1.2

Acceptance

Every flagged finding verifiable by the reviewer in under 30 seconds (Thirty-Second Lab test)

Human review

Named reviewer accepts, rejects or escalates every flag before the package proceeds to the assembly gate

APPENDIX E · GOLDEN SET AND EVALUATION REGISTER — FILLED

Known-correct cases

8 fully complete, historically accepted weld packages, used to confirm the tool reports zero false findings on clean submissions

Hard cases

5 packages with a field value that is inconsistent with specification revision D only in a subtle unit or rounding difference

Borderline cases

4 packages containing at least one illegible or handwritten scan, to confirm these are reported as unchecked gaps, not passes

No-finding cases

8 packages missing no required document, used to verify the tool does not manufacture findings where none exist

APPENDIX F · QUALIFICATION FILE — FILLED

Intended use and limits

Completeness and consistency checking only; does not issue an accept/reject disposition on the weld package

Evidence and configuration

Checklist v3, specification revision D, document-parsing configuration v1.2

Evaluation results

Thirty-Second Lab run on 25 flagged findings: reviewers verified 24 of 25 within 30 seconds against the cited location

Known limitations and controls

Cannot assess illegible or handwritten scans; these are reported as unchecked gaps, never silently skipped

Approval and monitoring

Approved by T. Nkemelu, 2026-01-20; escalation path to Quality Director for any unresolved flagged inconsistency before gate release

APPENDIX G · PRODUCTION GO-LIVE CHECKLIST — FILLED

Operational controls

Findings list feeds the reviewer's existing sign-off workflow; the tool cannot itself pass a package through the assembly gate

User training

Reviewers trained on the unchecked-gap category before relying on the tool for a live gate decision

Monitoring

Rate of reviewer-overturned findings tracked monthly; any illegible-scan gap left unresolved at gate time is logged

Incident handling

A non-conformity that passed the gate despite an available document is investigated as a tool-and-process failure, not tool-only

APPENDIX H · CHANGE AND REVALIDATION LOG — FILLED

Change

Specification revision D superseded a prior revision; document-parsing configuration updated to v1.2 to match new field layout

Retested

Golden set re-run against the updated configuration before go-live on revision D packages

Accepted by

T. Nkemelu, Supplier Quality Engineer

Why

A specification revision changes which field values count as consistent, so the tool's configuration must be revalidated, not assumed compatible

APPENDIX I · SUPPLIER AND THIRD-PARTY AI QUESTIONNAIRE — FILLED

Provider

Internally operated document-parsing tool; documents originate from an external supplier but the tool itself is not third-party AI

Source

Supplier submits the weld package directly through the existing document intake channel

Access

Supplier has no access to the tool's findings list before the internal reviewer has assessed it

Change control

Supplier-side document template changes are tracked against checklist v3 and trigger a configuration review

Incident and evidence responsibilities

Supplier remains responsible for submitting complete, legible documentation; the tool's role is limited to checking, not correcting, submissions

APPENDIX J · ASSESSMENT QUESTIONS AND GLOSSARY — FILLED

Practical question

If a required document is present but the tool cannot parse it, does the reviewer see that as 'missing' or as 'unchecked'? The record must say which.

Practical question

How does a new reviewer learn to distinguish a flagged inconsistency from an illegible-scan gap without opening every source document?

Glossary term

Unchecked gap — an item the tool could not assess (e.g. an illegible scan), recorded as an open item, never reported as a pass

Glossary term

Thirty-Second Lab test — an acceptance measure requiring a competent reviewer to verify any flagged finding within thirty seconds against its cited source

WHAT TO NOTICE

This one lands at C — the highest posture — because the consequence of a missed finding is high and the characteristic is safety-critical, even though the check itself is deterministic, not a language model making judgement calls. Risk level tracks consequence, not which technology is used.

WORKED EXAMPLE 03 · Cross-site corrective-action recurrence retrieval

A candidate match still needs the investigator's own verification

The same bolted-joint torque non-conformity keeps recurring on a tower platform across multiple sites. Each site has opened its own corrective action, but no one has compared them, so investigations restart from zero each time.

APPENDIX A · USE-CASE CHARTER — FILLED

Quality problem / recurring decision

Recurring bolted-joint torque non-conformities are investigated independently per site with no cross-site comparison, so root cause is never resolved systemically

Process owner

Priya Adeyemi, Corrective Action Board Chair

Manual baseline

Investigators manually search a shared drive of prior corrective actions by keyword, when they think to search at all; no baseline search time is currently tracked

Intended use

Cluster prior corrective actions by symptom similarity to the current investigation, surfacing candidate matches with their stated root cause and containment, for the investigator to judge relevance

Evidence sources and revisions

Closed and open corrective-action records across all sites, CAPA register export dated 2026-01-05

Output destination

Operator dashboard

Human decision boundary

Human reviews flagged cases only

Acceptance measure

Retrieval must surface at least the same matches a manual cross-site search finds on a 10-case test set, with a false-lead rate the investigator can characterize

APPENDIX B · DATA CLASSIFICATION RULE — FILLED

Evidence class

Closed and open corrective-action records across all sites — internal quality records, some naming individuals as investigators

Permitted use

Similarity clustering for investigation input only; not permitted to auto-close, merge or reclassify any corrective action

Retention

Retained per each site's existing CAPA retention policy; the retrieval index is derivative and rebuilt from the register, not a separate record of authority

Access

Corrective Action Board members and investigators across sites; no access outside the CAPA governance group

Source authority

The site-level CAPA register export dated 2026-01-05 is authoritative; the similarity index holds no independent facts about any case

APPENDIX C · AI RISK ASSESSMENT — FILLED

consequence

high — a missed systemic recurrence could leave a safety-relevant torque non-conformity uncorrected across sites

influence

medium — informs whether to escalate to a systemic investigation, not a final disposition

criticality

high — bolted-joint torque on a tower platform is a safety-critical characteristic

sensitivity

low — internal CAPA records only

traceability

medium — clusters link to source CAPA records, but similarity scoring itself is not directly inspectable

propagation

high — the failure mode is already known to recur across sites

volatility

low — the retrieval index is rebuilt on each CAPA register export, not per query

dependency

low — runs on internally held CAPA records, no external provider

CONTROLS AND SAFEGUARDS

Clustering is presented as candidate similarity, never confirmed recurrence. The investigator must independently verify that a retrieved prior case shares the actual failure mechanism, not just similar wording, before treating it as a true match.

RESIDUAL RISK AND ACCEPTANCE

Residual risk of an unsurfaced true match is accepted by the CAPA Board Chair given the tool is additive to, not a replacement for, the investigator's own judgement and existing escalation process.

Result: Level C

APPENDIX D · ONE-PAGE TOOL SPECIFICATION — FILLED

Inputs

Current investigation's symptom description plus the full cross-site CAPA register export

Outputs

Ranked list of candidate prior corrective actions with stated root cause, containment and similarity score

Limits

Similarity is on symptom wording, not confirmed mechanism; cannot itself confirm a true recurrence

Configuration

CAPA register export 2026-01-05, similarity model v1.0

Acceptance

Surfaces at least the same matches a manual cross-site search finds on a 10-case test set

Human review

Investigator independently verifies shared failure mechanism before treating any retrieved case as a true match

APPENDIX E · GOLDEN SET AND EVALUATION REGISTER — FILLED

Known-correct cases

10 known cross-site recurrences with a confirmed shared mechanism, used as the retrieval test set

Hard cases

4 cases with similar symptom wording but a different underlying mechanism, to check the false-lead rate on near-miss wording

Borderline cases

3 cases where the CAPA record's symptom description is sparse, testing retrieval quality on thin source text

No-finding cases

6 investigations with no true prior match anywhere in the register, used to verify the tool does not force a match where none exists

APPENDIX F · QUALIFICATION FILE — FILLED

Intended use and limits

Candidate-match surfacing only; the tool never confirms a recurrence or assigns root cause

Evidence and configuration

CAPA register export 2026-01-05, similarity model v1.0, rebuilt per register export

Evaluation results

On a 10-case test set of known cross-site recurrences, retrieval surfaced 9 of 10 manually-found matches; 3 additional false leads per case on average

Known limitations and controls

False-lead rate is high enough that every surfaced match is explicitly labelled 'candidate — verify mechanism', not 'match'

Approval and monitoring

Approved by P. Adeyemi, 2026-01-22; quarterly re-evaluation as the CAPA register grows

APPENDIX G · PRODUCTION GO-LIVE CHECKLIST — FILLED

Operational controls

Retrieval results appear only inside the investigator's existing CAPA workflow; the tool cannot close or merge any record

User training

Investigators briefed on the 'candidate — verify mechanism' label and the known 9-of-10 recall rate before first live use

Monitoring

Missed true matches later discovered manually are logged and counted against the retrieval recall rate

Incident handling

A missed systemic recurrence found after the fact triggers a review of the similarity model, not just the individual case

APPENDIX H · CHANGE AND REVALIDATION LOG — FILLED

Change

CAPA register export refreshed and similarity index rebuilt to include the latest closed and open cases across all sites

Retested

10-case known-recurrence test set re-run against the rebuilt index to confirm recall has not regressed

Accepted by

P. Adeyemi, Corrective Action Board Chair

Why

The register grows continuously as new CAPAs close; the index must be rebuilt and recall reverified on a known cadence rather than assumed stable

APPENDIX I · SUPPLIER AND THIRD-PARTY AI QUESTIONNAIRE — FILLED

Provider

Internally built retrieval tool operating on internally held CAPA records; no third-party AI provider

Source

Corrective-action records originate from each site's own CAPA system, exported into a shared register

Access

No party outside the CAPA governance group can query the similarity index

Change control

Index rebuilds are logged in the change and revalidation log against each register export date

Incident and evidence responsibilities

Not applicable — no external supplier is involved in this use case

APPENDIX J · ASSESSMENT QUESTIONS AND GLOSSARY — FILLED

Practical question

Would an investigator know to keep searching manually even after the tool returns zero candidates, given it is not proven to have perfect recall?

Practical question

How is a 'candidate — verify mechanism' label distinguished in the UI from a confirmed recurrence, so a rushed investigator cannot mistake one for the other?

Glossary term

False-lead rate — the number of retrieved candidates per case that the investigator's own review does not confirm as a true mechanism match

Glossary term

Recall (retrieval)— the proportion of manually-findable true matches that the tool also surfaces, measured against a known test set