THE GUIDELINE · EDITION 1.0
A vendor-neutral operating guide for responsible AI in wind quality and APQP.
Start with the quality decision, not the technology. Establish evidence before intelligence. Keep a named human accountable wherever output affects conformity, safety, customer commitment or release.
PART 01
Foundations
What is AI for in quality?
§1.1 · 4 MIN
What AI is for in quality
AI improves the speed, coverage, consistency and preventive capability of an existing quality process. It does not replace that process or the person who owns its decision.
Read section →§1.2 · 5 MIN
Six guiding principles
Start from the quality problem, build on evidence, preserve human accountability, validate the task, control configuration and proportion control to consequence.
Read section →§1.3 · 4 MIN
Scope and preferred end state
The guidance applies across the wind lifecycle where AI supports quality and APQP work under normal records, decision rights and controls.
Read section →§2.1 · 6 MIN
AI fundamentals for quality professionals
Quality teams do not need to become data scientists. They need to recognise what a method is good at, how it fails and how to control the task.
Read section →§3.3 · 5 MIN
The quality information chain
The highest-value opportunities often sit between documents: requirements, risks, controls, instructions and inspection evidence need to remain connected through revision and lifecycle change.
Read section →§2.2 · 5 MIN
Why fluent is not the same as correct
A generated answer can be grammatically confident and factually wrong at the same time; fluency and accuracy are produced by different mechanisms.
Read section →§3.1 · 5 MIN
Human decision boundaries in quality work
Some quality decisions are not delegable to a tool regardless of measured performance: conformity release, safety judgement, contractual sign-off and disciplinary action stay with a named accountable person.
Read section →§3.2 · 4 MIN
Accountability does not transfer with automation
Automating a step does not automate the responsibility for its outcome; the named owner remains accountable for what the tool produces under their process.
Read section →§1.4 · 3 MIN
What this guideline does not cover
Data protection law, export control, cybersecurity engineering, contractual liability and certification schemes are specialist domains with their own owners; this guideline sets a quality-control model that sits alongside them, not in place of them.
Read section →§2.3 · 4 MIN
Debugging a wrong answer: retrieval or generation?
When an AI-supported output is wrong, the first diagnostic question is whether the system saw the right evidence at all, before asking whether it reasoned about that evidence correctly.
Read section →§3.4 · 4 MIN
Documenting the decision, not just the output
A quality record should capture what a human decided and why, with the AI output as supporting evidence — not the AI output alone, presented as if it were the decision.
Read section →PART 02
Deciding
Which problem deserves controlled AI first?
§4.1 · 5 MIN
Choose a use case that deserves AI
A good first use case produces a defensible number within a quarter. It has a real process complaint, a named owner, accessible evidence and a reviewable outcome.
Read section →§4.3 · 4 MIN
Measure the manual baseline first
A baseline sizes the opportunity, establishes acceptance criteria and creates the comparison for a validation report.
Read section →§5.1 · 5 MIN
Three levels of control
Level A is assistive, Level B is controlled decision support and Level C is high consequence. The level changes the depth of evidence, approval and operational protection.
Read section →§4.2 · 5 MIN
Desirability, feasibility and evidence readiness together
A use case needs all three to succeed: someone wants it, the evidence supports it, and it can be built and verified inside a reasonable cycle.
Read section →§5.2 · 6 MIN
The eight risk dimensions in practice
Consequence severity, reversibility, autonomy, scale, evidence quality, novelty, human oversight and regulatory exposure combine to set the control level.
Read section →§4.4 · 4 MIN
Sizing the first pilot
A pilot should be narrow enough to run to a real decision within one quarter, on real evidence, with a named owner who can act on the result.
Read section →§5.3 · 4 MIN
Approval evidence proportional to consequence
The depth of sign-off, testing and documentation should scale with the classified risk level, not with how interesting the technology is.
Read section →§4.5 · 4 MIN
Building support without overselling the technology
Durable sponsorship comes from a credible, bounded claim tested on real evidence — not from a demo that promises more than the validated capability can deliver.
Read section →§5.4 · 3 MIN
This guideline does not establish regulatory or certification compliance
Following this guideline's control model is not equivalent to meeting a specific regulatory requirement, customer specification, or certification scheme; those require their own assessment against their own criteria.
Read section →PART 03
Building
What has to be controlled before a tool can be trusted?
§6.1 · 5 MIN
Classify the evidence before choosing anything else
An AI-quality system is only as reliable as its evidence structure, source authority, metadata and access controls.
Read section →§7.1 · 5 MIN
Write the one-page specification first
A controlled AI solution starts with its intended use, inputs, outputs, limits, human boundary, acceptance criteria and record—not with a prompt.
Read section →§8.1 · 6 MIN
Software testing is not AI evaluation
A functioning interface does not demonstrate that an AI task is suitable for its intended quality use. Evaluate the real task on known, representative evidence.
Read section →§8.6 · 4 MIN
The release decision
A release record presents evidence for a controlled decision: stop, improve, restrict, pilot or release. It does not convert an evaluation score into automatic approval.
Read section →§9.5 · 4 MIN
Monitor the live process
Monitoring checks whether task performance, evidence coverage, user behaviour and configuration still support the intended use after deployment.
Read section →§6.2 · 4 MIN
Metadata that keeps evidence trustworthy
Revision, part, project, supplier, source location and lifecycle phase are the minimum fields that let a system and a reviewer tell current evidence from superseded evidence.
Read section →§6.3 · 4 MIN
Access control and permitted use
Evidence classification determines where it may be processed, which model or environment is permitted, and how long it is retained.
Read section →§7.2 · 4 MIN
Configuration as a controlled artefact
Model version, instructions, retrieval settings and rules should be versioned and change-controlled exactly like a work instruction.
Read section →§8.2 · 5 MIN
Building a golden reference set
A defensible reference set spans clean, difficult, borderline, incomplete-evidence and no-finding cases, each with an agreed ground truth.
Read section →§8.3 · 5 MIN
Coverage, missed findings and false findings
These three measures, read together, describe what a tool actually does on real evidence better than any single accuracy number.
Read section →§9.1 · 4 MIN
Deployment is not the end of validation
A qualified tool still needs a go-live checklist, a rollback plan and a defined first-week observation period.
Read section →§6.4 · 4 MIN
Multilingual and translated evidence
Supplier and field evidence often arrives in more than one language; a capability's performance should be evaluated separately for each language pair it will actually see.
Read section →§7.3 · 4 MIN
The reviewer interface is part of the control
A finding without an exact source location, without the option to reject, and without a record of the reviewer's decision is not a controlled interface regardless of the model behind it.
Read section →§8.4 · 5 MIN
Seeded difficult cases and safe failure
A capability should be tested deliberately against cases it is expected to struggle with, to confirm it fails safely rather than confidently wrong.
Read section →§8.5 · 4 MIN
Reporting results honestly
A qualification report should state the reference-set composition, the acceptance criteria agreed in advance, and every limitation found — not only the favourable numbers.
Read section →§9.2 · 4 MIN
The go-live checklist
Go-live is a controlled release, not a deployment event: it needs a named owner, a rollback path, a first-week review cadence and a communication to affected users.
Read section →§9.3 · 4 MIN
Handling an incident
A missed finding or a false finding discovered in production is an incident, not a footnote; it should be logged, investigated and used to decide whether the capability continues, is restricted, or stops.
Read section →§9.4 · 4 MIN
Change management for a live capability
A model update, a prompt change, a new data source or a scope expansion are all change events that deserve the same discipline as a work-instruction revision.
Read section →§6.5 · 4 MIN
When sources disagree: an authority hierarchy
Requirements, drawings, specifications, contracts and supplier submissions can conflict; a defined authority hierarchy — not the most recently retrieved document — should settle which evidence governs.
Read section →§7.4 · 4 MIN
Guardrails and rules as a control layer
Deterministic rules — required fields, prohibited terms, hard numeric limits — sit alongside model reasoning as a control layer that does not depend on the model behaving as expected.
Read section →§8.7 · 4 MIN
Evaluating consistency across suppliers and sites
A capability that performs well on one supplier's documentation style or one site's evidence format may not generalise; test across the actual diversity of sources it will face in production.
Read section →§6.6 · 4 MIN
Handling scanned and unstructured evidence
Scanned drawings, handwritten inspection sheets and unindexed PDF archives are common in wind quality work; treat OCR and layout-extraction quality as its own evaluated step, not an invisible preprocessing detail.
Read section →§9.6 · 3 MIN
Sunsetting a capability responsibly
Stopping a capability needs the same discipline as starting one: a decision record, a communication to affected users, a transition plan for the manual process it replaced, and retained evidence of why it was stopped.
Read section →PART 04
Applying
What does this look like in wind quality work?
§10.3 · 6 MIN
Supplier document verification
Supplier-package verification is a strong application when every finding identifies the rule, exact location, evidence and review action.
Read section →§10.1 · 5 MIN
Predictive quality on process and test data
Predictive-quality use cases forecast defect likelihood from process parameters; they support investigation priority, not automatic disposition.
Read section →§10.2 · 5 MIN
Root-cause and corrective-action support
Retrieval over closed investigations and field lessons can strengthen a root-cause investigation without replacing the investigator's judgement.
Read section →§10.4 · 5 MIN
Anomaly detection in production and test data
Statistical anomaly detection can flag unusual process or test signatures for human investigation; it should not itself decide disposition.
Read section →§10.5 · 5 MIN
Visual inspection assistance
Image-based assistance can pre-screen or highlight candidate defects on blade, weld or coating surfaces; a competent inspector confirms the finding against the physical part or a defined evidence standard.
Read section →§10.6 · 4 MIN
Cost-benefit realism for a wind quality use case
A defensible business case states the measured baseline cost, the verification cost of the new approach, and the net benefit — not just the time a machine appears to save on the easy cases.
Read section →PART 05
Capability
How does the organisation make this repeatable?
§11.1 · 5 MIN
Training curriculum and certification pathway
Competence develops from shared literacy to use-case design, validation and assessment. The outcome is better controlled work, not generic AI fluency.
Read section →§12.1 · 4 MIN
First thirty days
The first month establishes legitimacy and specificity: a data-use rule, baseline literacy, one measured use case and a visible human control boundary.
Read section →§11.2 · 5 MIN
Assessing an AI-supported quality process
An assessor reviews evidence, decision rights, and retained records to determine whether a control claim is actually supported.
Read section →§11.3 · 4 MIN
Facilitator and assessor separation
A person who teaches or facilitates a cohort should not also grade that cohort's assessment; the roles carry different incentives and mixing them undermines both.
Read section →§12.2 · 4 MIN
Sixty to ninety days: from pilot to decision
The second phase turns the first month's measured use case into a qualification decision: pilot, restrict, improve, or stop, each with a documented reason.
Read section →§12.3 · 4 MIN
Twelve months: repeatable capability, not a hero project
A one-year horizon should show at least one durable, monitored capability in production and a second use case moving through the same disciplined sequence — not a single project that depended on one person.
Read section →§11.4 · 3 MIN
Retaining competency records
A record of who completed which training, assessment or practical exercise should be retained on the same schedule as other quality-competency records, not left inside a learning platform no one else can query.
Read section →§12.4 · 4 MIN
Three years: a durable, self-sustaining capability
By the three-year horizon, AI-supported quality work should be a normal part of how the organisation runs its process — governed, monitored, staffed and funded like any other capability, not a standing project.
Read section →§13.1 · 3 MIN
Accessibility as a design commitment
A reviewer interface, a training exercise or a published section that is not usable with a screen reader, keyboard-only navigation, or under reduced motion has excluded part of its intended audience from the control it claims to support.
Read section →§13.2 · 4 MIN
Privacy posture for evidence containing personal data
Field reports, incident records and supplier communications can contain names, contact details or other personal data; evidence classification should account for this before that evidence reaches an AI-supported process.
Read section →§13.3 · 4 MIN
Dependency on an external AI service
Where a quality process depends on an externally hosted model or service, the organisation should know what happens to that process if the service changes, degrades or becomes unavailable — before it happens, not after.
Read section →