ACADEMY · AI BASICS PRIMER
What these tools are, before what they're for. A short, self-contained literacy primer, built as four stages from zero to working knowledge: foundations, practical choices, a map of eight AI capability patterns, and applying it. Read it start to finish; nothing here assumes prior technical background.
NOT ONE OF THE FOUR ACCREDITED LEVELS
The Academy's four competence levels — Foundation, Practitioner, Implementer/Validator, Assessor — teach AI governance inside wind-sector quality work. This primer is prerequisite orientation for anyone who wants the underlying AI literacy first. Completing it is not a course level and earns no separate record.
← Back to the four-level Academy STAGE 1 · FOUNDATIONS
SECTION 01
Foundations of AI, ML, DL and generative AI Four terms get used almost interchangeably in casual conversation. They are not interchangeable — each one is a narrower slice of the one before it, and mixing them up is how vague claims about "AI" survive contact with a real decision.
Name the problem before the tool The most common failure in any AI adoption effort is reaching for a capability before naming what decision or task it should change, and who owns that decision today. State the problem first — the tool choice follows from it, not the other way round. Try it: Write one sentence naming a real, recurring task from your own work and the person who currently owns it — before naming any AI capability that might help with it.Four nested terms, not four interchangeable ones Artificial intelligence is the whole field: computers and data producing intelligent behaviour — reasoning, decisions, predictions. Machine learning is a subset of it: historical data plus algorithms producing learned patterns and predictions. Deep learning is a subset of machine learning: data plus multi-layer neural networks with feedback. Generative AI sits mostly inside deep learning: a trained model plus a prompt produces new content — text, images, audio or code — rather than a prediction about existing data. · AI — computers + data → intelligent behaviour. Scope: the whole field. · ML (subset of AI) — historical data + algorithms → learned patterns and predictions. Example: predicting which crane is likeliest to need unplanned maintenance next month. · DL (subset of ML) — data + multi-layer neural networks + feedback → learned patterns and predictions. Example: recognising a suspect weld in an end-of-line inspection photo. · Generative AI (mostly within DL) — model + training data + prompt → new content, not a prediction about existing data. Example: drafting a first-pass investigation narrative for a named human to edit. A kitchen you already recognise A restaurant is the whole operation — menus, staff, tools — the AI layer. A chef who improves recipes from customer feedback is machine learning. The individual stations — grill, sauce, pastry — learning from the head chef's corrections is deep learning. The creative chef inventing an entirely new dish from what the kitchen already knows is generative AI. The same nesting applies to a quality function: automatically logging sensor data is not the same as a model that classifies a defect, which is not the same as a system that drafts a first-pass investigation narrative. SECTION 02
How a generative language model actually produces text Once you can see how these models produce their output, most of the mystery — and most of the overconfidence — goes away.
Tokens, context window and temperature A model reads and writes in tokens — small chunks of text, not always whole words. The context window is how many tokens it can hold in view at once, like the size of a table you're building on. Temperature is the setting that controls how much randomness goes into picking the next token: low temperature produces steadier, more repeatable output; high temperature produces more varied, more surprising output. · Token = the smallest unit the model reads and writes — closer to a syllable than a word. Example: "inspection" is commonly split into two or three tokens, not one. · Context window = how much prior text (prompt plus its own output so far) the model can hold in view at once. Example: paste a 40-page supplier report in and the model may start losing track of the first pages once the window fills. · Temperature = the creativity dial — low for steady and repeatable, high for varied and surprising. Example: a low, fixed temperature for a repeatable draft-report generator; a higher one for brainstorming candidate root causes. Try it: For anything feeding a controlled document, treat the generation setting as a test condition: fix it, disclose it, and expect the same input to produce comparable output — not identical output, comparable output.The output is a computed guess, not a lookup At each step, the model predicts a probability distribution over what token comes next, then samples from it. That is why the same prompt can produce different wording each time, and why a fluent, confident-sounding answer can still be wrong — fluency and correctness come from two different things. Treat generated text as a calculated output that needs the same verification any other calculated output gets, never as a retrieval of a stored fact. Try it: Ask the same factual question twice in separate sessions and compare the two answers word for word — noticing what changed is a faster way to internalise this than reading about it.STAGE 2 · PRACTICAL CHOICES
SECTION 03
Where the model actually runs Every generative model runs somewhere, and where matters as much as which model.
SECTION 04
Prompt engineering The same underlying model can be prompted well or badly, and the gap between the two is large. These patterns cover most of the useful ground, in roughly increasing order of how much structure you give the model.
STAGE 3 · CAPABILITY MAP
SECTION 05
Eight AI capability patterns for a quality function Almost every real request — "can AI help with X?" — turns out to be one of these eight patterns underneath. Naming the right pattern before building anything saves most of the wasted effort: a pattern chosen for the wrong reason costs far more to unwind than it costs to choose carefully up front.
Automation tools The simplest pattern, and often confused with AI even though no model or judgement is involved: rule-based triggers connecting existing systems together, running the same fixed step every time a condition is met. BEST FOR
Connecting apps and automating repetitive steps in a workflow.
EXAMPLE USE CASE
Sending an automatic reminder for an overdue APQP deliverable or action.
Data engineering (readiness pipelines) The unglamorous foundation the other seven patterns quietly depend on: taking raw, inconsistent source data and structuring it — cleaned, validated, consistently labelled — into a state any model or report can actually use. No model, however capable, produces a trustworthy result from untraceable or inconsistent source data; this is foundation work, not a step to skip. BEST FOR
Getting data into a state where any of the other patterns can be trusted to use it.
EXAMPLE USE CASE
Structuring a legacy parts database with inconsistent part numbers into clean, analysis-ready tables.
OPEN INSTRUMENT → Data analytics and reporting Descriptive analysis over data that already exists — counting, ranking, charting what already happened. No prediction, no generation — often the right first step before reaching for any model, since a surprising number of "AI problems" turn out to be reporting problems once the data is organised. BEST FOR
Descriptive analysis and reporting over existing data — Pareto charts, trends, dashboards.
EXAMPLE USE CASE
Surfacing the top five recurring defect types across production lines this quarter.
Machine learning A model trained on your own structured historical data to predict or classify a numeric or categorical outcome — not a language model, and not generating any new text. The prediction is only as good as how representative that historical data is of what it now has to predict. BEST FOR
Predictive tasks built on structured historical data.
EXAMPLE USE CASE
Predicting which crane is likeliest to have unplanned downtime next month, from usage and repair history.
Deep learning — computer vision Trained to recognise patterns in images or video rather than in text — a different branch of deep learning from the language models the rest of this primer focuses on. A flagged image still needs the same verification discipline as any other automated finding: a suspect result, not a verdict. BEST FOR
Automated visual inspection from images or video.
EXAMPLE USE CASE
Flagging a suspect end-of-line weld for a qualified inspector to review.
Retrieval-augmented generation and semantic search Connecting a model to a specific set of documents at query time, so it finds and answers from that material by meaning — not just exact keyword match — instead of only from whatever it absorbed during training. The same principle — cite the actual controlled document rather than reciting from memory — is what separates a defensible answer from a plausible-sounding one, in a model or in a person. BEST FOR
Finding relevant material across a large body of existing documents by meaning, not keyword.
EXAMPLE USE CASE
Finding past 8D reports relevant to a new defect, even when the old reports use different wording.
Fine-tuning Updates a general model's weights on a smaller set of your own examples, so it performs a narrow task closer to a trained specialist than a generalist working from a one-off prompt. It costs more to build and re-run than prompting or retrieval, and once a fine-tuned model is in use, that exact version — model, training data and configuration — has to be tracked with the same discipline as any other change to a validated process. BEST FOR
Building a company-specific AI model that already matches your own format and terminology.
EXAMPLE USE CASE
Generating a first-pass FMEA entry that already follows your organisation's own template.
OPEN INSTRUMENT → Agentic flow Breaks a task into steps and calls tools — search, calculations, other models — in sequence toward a goal, with an orchestrating layer deciding what happens next. An agent completing more of a workflow on its own does not move the boundary of what a human has to do: if the last step is approving, releasing, closing or signing something, a named human still performs that step, however many of the earlier steps the agent handled. BEST FOR
Guided, multi-step problem solving across several tools or sub-tasks.
EXAMPLE USE CASE
Walking a team through formulating candidate root causes for a recurring failure.
OPEN INSTRUMENT → TEST YOURSELF · MATCH THE SCENARIO
Which pattern does this scenario actually need? Eight short scenarios, one per pattern above. Pick an answer to see immediate feedback — change it any time.
Q1. A team wants a model to draft failure-mode entries that already follow the exact format and terminology used in this organisation's own FMEA template.
Fine-tuning Machine learning Retrieval-augmented generation and semantic search Automation tools
Q2. A quality engineer needs the system to automatically message an action owner three days before an APQP deliverable is due.
Agentic flow Machine learning Automation tools Data engineering (readiness pipelines)
Q3. Maintenance wants to predict which crane is most likely to have unplanned downtime next month, from years of usage and repair logs.
Deep learning — computer vision Machine learning Data analytics and reporting Fine-tuning
Q4. Leadership wants a monthly chart of the five most frequent defect categories across every production line.
Machine learning Data engineering (readiness pipelines) Data analytics and reporting Retrieval-augmented generation and semantic search
Q5. Before any of the above can run reliably, a legacy parts database with inconsistent part numbers and missing fields needs cleaning and structuring.
Data analytics and reporting Machine learning Data engineering (readiness pipelines) Retrieval-augmented generation and semantic search
Q6. A camera at the end of the production line should flag a suspect weld for a qualified inspector to look at.
Machine learning Deep learning — computer vision Agentic flow Automation tools
Q7. An investigator wants to find every past 8D report dealing with a similar bearing failure, even if it used completely different wording.
Data analytics and reporting Data engineering (readiness pipelines) Machine learning Retrieval-augmented generation and semantic search
Q8. A team wants guided, multi-step help walking through candidate root causes for a recurring failure, pulling in several sources along the way.
Retrieval-augmented generation and semantic search Automation tools Fine-tuning Agentic flow
STAGE 4 · APPLYING IT
SECTION 06
Building software with AI assistance A faster style of building software has emerged around these models: describe what you want in plain language and get a working prototype back in minutes rather than days. It is genuinely useful for the right job, and genuinely risky for the wrong one.
What it's for, and what it isn't This style of AI-assisted prototyping is strong for fast idea validation, throwaway internal tools and early-stage prototypes — it is not a substitute for controlled software development on anything a quality or safety decision will depend on. Treat a prototype built this way as a prototype, whatever it looks like once it's running. Discipline that keeps the practice honest A small set of habits separates AI-assisted prototyping that stays maintainable from a pile-up of code nobody understands: define the task clearly before generating anything, look for existing code to extend before writing new code, keep files small and refactor once they grow past a couple of hundred lines, and write tests for anything that matters. · Do — state the task clearly first, prefer extending existing code over new code, keep functions and files small, write tests for what matters, re-check the result after every real change. · Avoid — duplicating functionality that already exists, leaving throwaway scripts as permanent files, faking or stubbing data outside of tests, overwriting a configuration file without explicit sign-off, adopting a new pattern or dependency casually. Working documents that make the practice repeatable Three short documents do most of the work of keeping an AI-assisted build honest: a requirements document stating what is being built and why, a short usage document covering setup and how to run it, and a specifications document giving exact expected behaviour and inputs and outputs. Written before the building starts, each one turns a vague request into something that can actually be checked against afterwards — the same relationship a controlled specification has to the part it describes. SECTION 07
Responsible AI: principles before deployment Choosing the right capability pattern gets a use case working. It says nothing about whether the use case is safe to rely on, fair to the people it affects, or defensible after the fact. That is a separate layer of judgement, and it applies whether the model is hosted or local, generic or fine-tuned, a one-off prompt or a multi-step agent.
A model trained on the past will reproduce the past Any model — machine learning, deep learning or generative — learns from historical data, and historical data carries whatever gaps, imbalances or past decisions produced it. A model is not neutral just because it is mathematical; it is only as representative as the data it learned from, and a skewed training set produces a skewed model with no warning label attached. · Representativeness — check who and what is under-represented in the training or reference data before trusting an output about them. Example: a defect-classification model trained mostly on one production line may perform worse on a newer line it rarely saw. · Silent failure — a biased model does not announce itself; it produces confident output that looks the same as any other output. Example: a resourcing recommendation that quietly favours the shift pattern best represented in last year's logs. Try it: For a candidate use case, name the population or scenario least represented in the data the model would learn from or search over — before asking whether the output can be trusted for that population.Explainability has limits — plan around them, not past them A classical rule-based system can usually show its exact reasoning step by step. A deep learning or generative model generally cannot — it can produce a plausible-sounding explanation of its own output, but that explanation is itself a generated guess, not a trace of the actual computation. Design the surrounding process to compensate for this gap rather than assuming a fluent explanation is a true one. Try it: Ask a model to explain its own answer to a question you already know the correct reasoning for, and compare the two — a fluent explanation and a correct one are not the same claim.Privacy and what actually leaves your boundary Every prompt, upload or query sent to a hosted platform is data leaving your organisation's boundary unless a contract specifically restricts what happens to it next — retention, use in further training, and who can access it. Before sending anything to any model, hosted or local, apply the same minimisation habit you would apply to any external system: send only what the task actually needs, never more. · Ask before sending — does this input contain personal data, unreleased results or anything a supplier or customer would not expect to leave the building? · Contract, not assumption — a hosted platform's data-handling terms are a specific, checkable document, not a default you can assume in the tool's favour. Accountability stays with a named human None of the eight capability patterns changes who is accountable for the decision the output feeds into. An agent completing more of a workflow, a fine-tuned model matching your house format, or a computer-vision model flagging a defect are all still producing a suspect finding for a named, qualified person to accept, reject or escalate — never a verdict that closes itself. Try it: For a candidate use case, name the specific person — by role, not by "the team" — who signs off the final decision, before deciding which capability pattern to build.OPEN INSTRUMENT → Robustness: tested for the case that actually breaks it A model that performs well on typical inputs can still fail badly on an edge case, an adversarial input, or simply a case it rarely saw in training — and it will usually fail with the same fluent confidence as a correct answer. Trusting a use case means testing it against its hardest realistic cases, not just its average ones. OPEN INSTRUMENT → Proportionality: matching model size to the task Training and running larger models consumes real computing resources and energy, and that cost is easy to ignore because it happens somewhere else. Reaching for the largest available model out of habit, when a smaller model or a non-AI pattern like automation or reporting would do the job, is not a neutral default — it is an avoidable cost with no corresponding benefit to the decision it's meant to support. SECTION 08
Build vs. buy, and a deployment roadmap Naming the right capability pattern and checking it against responsible-AI principles still leaves a commercial question open: build it, buy it, or wait. And once that's answered, a use case needs an actual sequence of gated phases to get from idea to relied-upon capability — not a single leap from pilot to production.
Four build-or-buy archetypes, not one answer Plot a candidate use case on two axes: how much it differentiates the business if done well, and how mature the external market already is for that exact need. The quadrant this lands in — not habit, not whichever option was pitched most recently — should drive the call. · Low differentiation, mature market → buy off-the-shelf. Example: a general drafting assistant for routine correspondence — many adequate options exist and none of them is a competitive advantage. · Low differentiation, immature market → wait or run a small, time-boxed pilot rather than committing budget. Example: an emerging category with no track record yet in this industry. · High differentiation, mature market → buy the base capability and adapt it (fine-tune, configure, integrate) rather than building from scratch. Example: a defect-classification model built on a general computer-vision platform but adapted on your own labelled images. · High differentiation, immature market → build in-house, because no outside vendor has an incentive to build your specific advantage for you. Example: a proprietary scoring model on a manufacturing process unique to your own product line. Try it: Place one real candidate use case on this two-axis grid before comparing a single vendor quote or build estimate — the quadrant usually settles the question faster than the numbers do.Price the whole cost, not the licence line A build-or-buy comparison that stops at licence fee versus developer-day rate is comparing the wrong numbers. The real total cost of ownership includes data preparation and integration, ongoing maintenance, staff training, and — on the buy side specifically — what it costs to leave if the vendor relationship ends. · Integration and data readiness — connecting either option to clean, structured source data is real cost that belongs to neither the licence fee nor the build estimate on its own. · Maintenance and revalidation — a hosted vendor can update or retrain the underlying model with no notice, silently invalidating whatever evidence justified the original decision; an in-house build only changes when you change it, but then you own every fix. · Exit cost — data export, staff retraining and the gap while a replacement is qualified are real costs of a vendor relationship ending, and belong in the comparison before signing, not after. OPEN INSTRUMENT → A five-phase deployment roadmap Every instrument on this site sits in one of five phases, and together they are the deployment roadmap: Deciding, whether a use case is worth pursuing and how it should be controlled; Building, whether the evidence foundation underneath it is actually ready; Validation, proving it works on reference, seeded and difficult cases before anyone relies on it; Applying, connecting the decision to its evidence and controlling its exact configuration as it runs; and Capability, turning one proven use case into an organisation that can repeat the process. Skipping a phase to move faster is exactly where deployments fail expensively later. · Deciding — Verification Ratio, Portfolio Map, Thirty-Second Lab, Risk Classifier: is this worth doing, and at what level of control? · Building — Data & Evidence Readiness: is the underlying data foundation actually trustworthy? · Validation — Attribute Agreement Study, Correlated Error Simulator, Seeded-Case Protocol, Golden Set Builder, Qualification File & Release: does it work on the cases that matter, including the hard ones? · Applying — Quality Evidence Graph, APQP Lifecycle Explorer, Configuration Attestation & Gate Pack, Survivability Test: does it stay controlled once it's running and things change? · Capability — Maturity Ladder, Roadmap Generator, Prohibited List & Signature Test: what's built next, and what never gets automated? OPEN INSTRUMENT → The gate that separates a pilot from a rollout A pilot proves a use case can work once, on a favourable case, with someone watching closely. Scaling that same pilot to routine, less-supervised use is a different claim, and it needs its own evidence — not a good pilot demo stretched further than it was tested. The Qualification File is the explicit gate between the two: restrict, pilot further, release, or stop, each with a stated reason. Try it: For a use case currently running as a pilot, write down the specific evidence that would justify calling it ready for routine use — before assuming a successful demo already counts as that evidence.OPEN INSTRUMENT → Revisit the build-or-buy call at every gate, not just once The market matures, a vendor's terms change, and your own team's capability grows — any of which can flip yesterday's build-or-buy answer. Treat it as a decision to revisit at each phase gate against your current Maturity Ladder position, not a choice made once at the start and left alone. OPEN INSTRUMENT → SECTION 09
Where this primer connects This primer teaches how these tools work. It does not, on its own, authorise using any of them inside a quality decision.
From literacy to governed use Understanding tokens, prompting patterns, the eight capability patterns, the responsible-AI principles and the build-or-buy roadmap above is the literacy this primer set out to build. Deciding whether a specific use case is allowed, how confident it needs to be before anyone relies on it, and who is accountable if it's wrong is a separate, harder question — covered by the guideline itself, not by this primer.
PRIMER COMPLETE?
Save your progress to the Playbook, then continue to the four-level Academy to apply this literacy inside a governed wind-sector quality process.
Save to Playbook Copy share link
Continue to the four-level Academy →