Training that is judged on what people do afterwards, not on what they sat through
Every enterprise can run an AI awareness session. Far fewer have people who can design an agent, tune a retrieval pipeline, read an evaluation report or explain a control to an auditor. This programme is built in layers for five different audiences, and it is assessed by demonstrated transfer — with the practical work done on your own workflow, not on a vendor's sample data.
Five audiences
Executives, business owners, product managers, engineers and data teams get different programmes, not one course with different slides.
Your data, your process
The practical project takes one of your real workflows and turns it into an evaluated agent, with your cases and your definitions.
Records in the LMS
Enrolment, assessment scores, competency records and certification renewals are held in the learning system of record.
Acceptance after go-live
We accept the programme on performance in the workflow weeks after training, not on completion certificates.
Five audiences, and what each one is accountable for
A single curriculum for everyone wastes the technical track on executives and leaves the engineers without the operational context. We design five programmes, and the shared material is deliberately small — the vocabulary and the operating rules — because the work is different for each group.
| Audience | What they are accountable for | Programme focus | How they are assessed |
|---|---|---|---|
| Executives and board | Capital allocation, risk appetite, and whether the organisation is actually becoming agentic | Authority allocation, operating model economics, what evidence a board should demand, and the questions to ask about a vendor's claims | A decision exercise: allocating authority and capital across a real portfolio, and defending the choice against the committee's criteria |
| Business owners and process leads | The delegated work itself, and the quality of what comes back | Decomposing a process into delegable units, writing acceptance tests, setting thresholds, reviewing exceptions, and redesigning a role | Assessed on their own process: a written unit specification and a set of acceptance tests, reviewed by a peer and by a supervisor |
| Product managers and designers | The design of the agent, its tools and its user experience | Tool contracts, orchestration patterns, human-in-the-loop design, failure states, and the design of the review and escalation experience | A designed agent specification with a failure-mode inventory, and a live walkthrough of the exception path |
| Engineers and platform teams | The runtime, the integrations, the evaluation and the operations | Retrieval parameters, context budgeting, tool integration, evaluation harnesses, trace and attribution, release and rollback discipline | Built and measured in a lab environment: a working agent, a regression set, and a written failure analysis from a real trace |
| Data teams | The corpus, the contracts, the identity and the provenance | Data contracts, entity resolution, permissions and classification, provenance, and the difference between a data problem and a context problem | A data contract and an identity rule set for a real entity type, reviewed against the semantic layer it must satisfy |
Why business owners are in the room at all. The most common failure we see is a technically excellent agent pointed at a process nobody owned, judged by a measure nobody defined. Business owners and process leads carry the half of the work that determines whether the agent is any use, and the programmes are designed to make that half explicit rather than implicit.
Data and context engineering training in numbers
Each with a different accountability
Each with a stated capability outcome, not a topic list
Only one of them is a certificate
One of yours, made testable by the end
Five audiences, and what each one is accountable for
Tell us which of these five is your bottleneck and we will build the programme around it. Training everyone equally is how training budgets get spent without changing anything.
| Audience | What they are accountable for | The capability gap that matters |
|---|---|---|
| Data engineers | Pipelines, lineage and the physical model | Entity identity and semantic modelling — the layer where most data work currently stops |
| Data analysts | Answering questions from the data | Asking whether the question is answerable, and knowing when a number is structurally misleading |
| Business owners | Defining what the data should mean | Participating in ontology work rather than receiving a finished model they cannot argue with |
| Technology architects | Where the platform sits and how it integrates | Context pipelines, evaluation harnesses, and the agent-specific failure modes |
| Risk and governance | Whether the answers can be relied on | Reading a decision log and an evaluation report well enough to challenge both |
Five layers, each with a stated capability outcome
The layers are sequenced so that each one can be delivered standalone or stacked. The outcomes are written as observable capabilities — what a participant can do afterwards — because a course description written in verbs about topics cannot be assessed.
Capability outcome: use an agent critically
A participant can describe what a model does and does not do, recognise the difference between a fluent answer and a supported one, and make an informed decision about when an agent should be used, when it should be supervised, and when it should be refused.
Deliberately not a technical module. It is where the shared vocabulary comes from, and where participants build the judgement that every later layer depends on — the recognition of a confidently wrong answer is the single most transferable skill in the whole programme.
- Format — facilitated workshop, half a day, with a live agent and deliberately seeded failures.
- Evidence — a short scenario assessment requiring the participant to identify what is wrong with a plausible answer and what evidence would settle it.
"We need everyone to have done this"
This layer is the one designed to be delivered to a large population, and it is the one where we are most careful about scope. A full-day version exists and it works; the half-day version with live examples is more honest, because it spends its time on judgement rather than on taxonomy.
Capability outcome: build and tune a context pipeline
A participant can build a labelled evaluation set, configure a retrieval pipeline with deliberate parameter choices, diagnose a failure from a trace, and explain why a given configuration was chosen for a given corpus.
The labs use the real parameters — chunk size, overlap, table retention, hybrid weighting, semantic boost, first-pass depth, rerank depth, score threshold and recall count — and the exercise is not to find a good value but to understand the trade-off each value represents and to measure the effect of moving it.
- Format — lab-based, over several sessions, working in a provided environment with a corpus the participant brings.
- Evidence — a tuned pipeline with a documented parameter rationale, a labelled set, and a measured before-and-after recall and faithfulness result.
Measure before you tune
The most expensive habit in this discipline is changing a prompt because the answer was wrong. The lab is structured so that participants learn to locate the failing layer first — because an engineer who does that is worth five who tune by instinct.
Capability outcome: design an agent and prove it is good enough
A participant can decompose a process into delegable units, write an acceptance test for a unit, design a tool contract, build a regression set, and interpret an evaluation result well enough to make a release decision.
This is where the two tracks meet. Business owners and engineers work on the same artefact — a unit specification and an evaluation set — from opposite sides, and the disagreements that emerge are the most valuable teaching moment in the programme.
- Format — a project lab with a business owner and an engineer paired, working on a real process from their own organisation.
- Evidence — a working agent with a regression set, an evaluation report, and a documented release recommendation including what it is not yet safe to do.
A release recommendation, not a demo
Participants do not present a working agent as a success. They present its evaluation results, the cases it still fails, the tier it has earned, and what it must not be allowed to do. It is a harder exercise and it produces a much better engineer.
Capability outcome: run the management system
A participant can maintain an agent inventory, classify an agent on impact and autonomy, design a control for a given class, test that the control is exercised, and assemble the evidence an assessor would ask for.
This layer is run with the participants' own inventory, from the real estate. The exercise is to answer a set of questions an assessor would actually ask — about one random agent — and to notice which answers are hard to produce.
- Format — workshop plus a live audit rehearsal against the organisation's own estate.
- Evidence — a completed inventory entry with classification and control mapping, and the rehearsal findings with remediation owners named.
One system, four views
ISO 42001 as the management system structure, with ISO/IEC 23894 risk treatment, the NIST AI RMF functions as the operating rhythm, and the EU AI Act's technical documentation as a template in the system. Participants see how one body of evidence answers four different frameworks.
Capability outcome: operate the estate and improve it
A participant can run an exception review, tune a threshold under supervision, read a monthly scorecard, conduct a control rehearsal, and manage a re-authorisation decision.
This layer is mostly about judgement under live conditions, so it is delivered closest to the work: as a working rhythm in the operating team rather than as a course. We join the existing review cycle, run it with the real exceptions, and coach the people who will keep running it after we leave.
- Format — embedded in the operating rhythm, with coaching on the job and a monthly clinic.
- Evidence — one full cycle of the review meeting observed, and the participant running the following cycle unaided.
The layer that decides whether it stuck
Everything else can be taught in a room. This layer is where capability is proven, because the standard is whether the operation continues to run at the same standard after the programme ends and after the coach leaves.
Five layers, each with a stated capability outcome
Each layer is defined by what someone can do afterwards, not by what was covered. That distinction is the difference between training that changes capability and training that produces certificates.
One of your workflows, made testable
The centre of the programme is a single piece of work: the participant takes a real process inside their own organisation and turns it into an agent that can be evaluated. Not a toy dataset, not a vendor scenario — a workflow with real cases, real exceptions and real constraints.
The project is scoped in the same session it is assessed. A process with no measurable outcome is not eligible, because there would be no way to tell afterwards whether the training was useful.
What the project produces. A unit specification with an acceptance test, a tool contract, a labelled evaluation set drawn from real cases, a working agent, an evaluation report with a pass rate and a list of known failures, and a written recommendation on the authority tier it has earned. Every one of those is a working artefact, and every one of them is reusable afterwards.
Why we insist on real cases. Real cases contain the awkward ones — the missing document, the ambiguous entitlement, the customer who disputes. Synthetic cases are cleaner, faster and much less informative, and they produce a cohort that believes it has solved a problem it has only rehearsed.
Six weeks, five checkpoints
Scope and eligibility
The process, the business owner, the outcome measure, the volume, and the reversibility test. If it fails, the participant picks another process.
Unit specification
The delegable unit written out with its input contract, action set, permission envelope, acceptance test and escalation path.
Evaluation set
Real cases labelled with expected outcomes by the business, including the difficult and the historically failed ones.
Build and measure
The agent, the tools, the context pipeline, and the first evaluation run. The first result is expected to be poor.
Diagnose and improve
Failure attribution from the traces, targeted fixes, and a re-run. The quality of the diagnosis is what is being assessed.
Recommend a tier
A written recommendation on the authority the agent has earned, what it must not do, and what has to be built before it can go further.
One of your workflows, made testable
This is the practical artefact of the whole programme, and it is deliberately narrow: one workflow, made testable by your own people. If they can do that once, they can do the next one without us.
You bring one workflow
A real one, from your own organisation, with the historical cases available.
We make it testable
The cases become a test set with expected outcomes, drawn from what people actually did rather than what the policy says should happen.
We build the semantic layer
Just enough ontology to make the workflow's entities and rules unambiguous — and a list of every ambiguity we found.
We design the context pipeline
Granularity, freshness and budget settings, with the failure attribution method defined up front.
You get the assessment
The programme is assessed by whether your people can make this workflow testable for the next one themselves.
Three kinds of evidence, and only one of them is a certificate
An assessment that can be passed by a well-rehearsed presentation is not an assessment. We use three kinds of evidence, and they are weighted differently by role — a business owner is judged on the quality of their specification and their judgement, not on their code.
Assessed artefact
A real deliverable produced under realistic constraints — a unit specification, a tuned pipeline, an evaluation report, a data contract. Assessed against the same criteria the organisation would use in production, by an assessor who works on real estates rather than by a peer who has just done the same exercise.
Observed performance
A structured session in which the participant does the work under pressure with a realistic constraint added — an incomplete case, a missing definition, a supervisor asking for a decision now. What is assessed is how they handle the constraint, not whether they get the right answer first time.
Post-deployment performance
The measure we actually accept the programme on: whether the participant is still performing in the workflow weeks later, and whether the workflow's business outcome improved. This is collected from the operating team, not from the participant.
Certification, and what it is for
A certificate of completion records that someone attended. A certification record states that a named individual is qualified to perform a specific activity, assessed against published criteria, valid for a defined period and revocable.
We issue the second kind, and we are careful about what it covers. The role-based certifications we offer map onto the roles we define with our clients: Agent Owner, Agent Engineer, AI Steward, and the assessment and supervisor competencies. Where an organisation needs a certification for a regulatory or contractual reason, we build the assessment to that requirement and the record is held in the learning system with the renewal cycle attached.
Renewal, and why it exists
Certification without renewal measures nothing after the first year, because the platform changes, the policies change and the workforce changes. Every certification we issue carries an expiry, a refresh requirement and a re-assessment, and the system tracks and enforces it. The renewal cycle is also what keeps the qualification list accurate for the partner-enablement use case.
Three kinds of evidence, and only one of them is a certificate
Certificates are the default because they are easy to count. Operating evidence is what a capability review actually needs, and it requires designing the programme for measurement from the start.
A certificate
Proves attendance. Useful for compliance training and almost nothing else. It is not evidence that anyone can do the job, and a regulator who asks will say so.
A capability demonstration
The person completes a real task from their own domain to a stated standard, with an assessor who knows the domain. This is what capability evidence means, and it is auditable.
Operating evidence
Six months later: are they still doing it, is quality holding, and did the failure rate fall? Only this one proves the capability transferred. Everything else is a leading indicator.
Where the learning data lives, and why it matters for the agents too
The programme runs on our learning platform, wizBank, which has more than twenty-five years of enterprise learning engineering behind it. The important property for this practice is not the LMS feature set — it is that the assessment records, competency decisions and certification renewals live in the same system, and can be joined to the agent evidence.
| Record | What it captures | What it is used for |
|---|---|---|
| Enrolment and attendance | Who took which layer, in which cohort, at which site | Coverage planning and completion reporting, with a defensible record for audits |
| Assessment and attempts | Scores against published criteria, assessor identity, dates, and the artefacts submitted | Competency decisions, and the evidence behind them when challenged |
| Competency records | A person's qualified status per role, with scope and expiry | Staffing decisions, and the answer to "is this person permitted to do this" without a spreadsheet |
| Certification and renewal | Issued certifications, expiry dates, refresh requirements and re-assessment outcomes | Partner enablement, supervisor coverage and regulatory or contractual qualifications |
| Agent capability records | For digital employees: knowledge pack version, evaluation set and results, mandate tier and expiry, owner | The compliance evidence pack, and the same register the human capability record lives in |
| On-the-job observations | Coaching notes, shadow-mode comparisons and post-deployment performance observations | The evidence that capability survived the programme — the measure we accept on |
People and agents, one register
When human competency records and agent capability records sit in the same system, the question "is this work being performed by someone qualified" has one answer, produced the same way for both populations.
Evidence that assembles itself
The compliance evidence for a digital employee is drawn from records that were generated as a by-product of normal operation, rather than assembled by hand when someone asks for it.
Certification for partners and suppliers
The same record structure supports qualifying external partners to work inside your process, with renewal cycles and audit trails, which is often the requirement nobody has a system for.
Where the learning data lives, and why it matters for the agents too
Where your learning data lives matters more than most training programmes realise. Course completions, assessment results and capability records sit in the LMS — and the LMS is exactly the kind of governed, permission-aware, versioned semantic store an agent needs to reason over. A well-run LMS is not a compliance system you have to justify to the technology team; it is an existing asset that answers a question most organisations are trying to build from scratch: who can do what, and how do we know that is still true?
What we do not promise
Training vendors are judged on their promises about capability. We are explicit about the limit of what any training can do, because overclaiming here damages the organisations that buy it.
- We do not promise that people will be capable after attending. A course creates the opportunity; competence is demonstrated by an assessed artefact and then by performance in the workflow. Our acceptance criterion is the latter, measured weeks after the programme, and we will not claim success on completion rates.
- We do not train people on a vendor's sample data and call it relevant. The practical work is on your workflow, your cases and your definitions. Where a participant cannot supply real cases, we will say that the project is not yet viable rather than substituting fictional ones.
- We do not certify a general capability. A certificate of "AI proficiency" is not something we issue, because it is not something that can be assessed or used. Certification is issued against a named role, a published criterion set and a defined scope.
- We do not deliver training as a substitute for an operating model. A cohort of trained people with no delegated work, no authority and no supervision will not produce an agentic business. If the organisation has not decided who owns the first agent, we will say that training is not the next step.
Training is the last step of a longer chain
Operating model
Decides who owns the work, so that training has a role to train people into.
Runtime and context
Provides the lab environment, the evaluation harness and the traces that the technical labs use.
Business semantics
Supplies the definitions that appear in the lab corpus and in the acceptance tests.
Capability programme
The organisational change programme that this curriculum is the technical half of.
What we do not promise
We do not run generic AI training and we will not sell you a curriculum because it is on a shelf. We do not certify people for things they cannot demonstrate, and we will not claim a capability level we cannot evidence six months later. If your bottleneck is not one of these five audiences, the honest answer is that this programme is not what you need yet.
What this page answers
Every topic below is covered in the sections above, and each links to the page that goes deeper on it.
Tell us which of your five audiences is the bottleneck
A 45-minute working session with a training lead. We will map your audience against the curriculum, identify the layer that is missing, and tell you what a cohort would produce — and how we would judge whether it worked. No course catalogue, no slide count.