Cohort 1B ·
ML Engineering
for Regulated
Industries
How to build the governance layer, the audit trail, and the retraining pipeline that make models viable in regulated production — not just technically correct, but organisationally and compliance-ready.
The Problem
Models are not systems. Building one is not the same as building the other.
Most ML programmes teach practitioners how to train models — how to engineer features, evaluate performance, tune hyperparameters, and iterate toward a benchmark. Almost none teach them how to build the system around the model: the governance layer that makes decisions explainable, the audit trail that satisfies a compliance officer, the drift detection process that catches silent failure before it reaches a risk committee, the retraining pipeline that is itself a governed process with documented ownership and a defined trigger.
The failure mode is not technical incompetence. It is a category error. The ML engineer who can produce a model with a strong validation score has answered the question the programme asked. The question regulated production asks is different: who approved this feature set? How does this prediction get explained under challenge? What happens when the data distribution shifts? Who owns the retraining decision, and how is that ownership documented? A model that cannot answer these questions does not reach production in a regulated environment, regardless of how well it performs on held-out data.
The gap is structural. Risk committees, compliance officers, and governance boards are not blocking ML systems because they do not understand the technology. They are blocking them because the practitioner presenting the system cannot answer the questions they are obligated to ask. A model card that does not document the feature register, a deployment that has no drift governance, an architecture that has no audit trail — these are not oversights. They are the visible surface of a training gap that most ML programmes have not addressed.
Cohort 1B is built for that gap. It takes the practitioner who can build the model and teaches them to build the system around it that a regulated environment will actually accept.
Who This Is For
Three situations. One programme.
You can build the model. The validation metrics are good. But somewhere between the notebook and the production environment — at the risk review, in the compliance documentation stage, at the sign-off gate — the work stalls. The blockers are not technical. They are governance blockers: no explainability artefact, no drift plan, no documented ownership of the retraining trigger. You need the framework that turns a working model into a system a regulated organisation will deploy.
You are technically credible in environments where the primary constraint is predictive performance. You are moving into — or already working in — a context where the constraints are different: financial regulation, healthcare governance, insurance oversight, supply chain compliance. The modelling skills are there. What is missing is the governance layer: the MLOps discipline, the compliance documentation, the audit trail, the language of risk committees and governance boards. This programme closes that gap directly.
You have shipped systems. You understand production conditions from the inside — reliability, observability, handoff, ownership. You are now working on ML-augmented systems in a regulated context, and the gap you are feeling is not the machine learning. It is the specific discipline that regulated ML production demands: feature governance, model cards that hold up under audit, drift detection as a governed process, compliance by design rather than by documentation after the fact. This programme is the framework you need to close that gap without starting from scratch.
The Programme
Three weekends.
One system, built end to end.
The first weekend establishes the standard that the rest of the programme is built against. Not production-ready in the abstract — production-ready for an ML system in a regulated environment, with the specific compliance obligations, data governance constraints, and organisational approval structures that participants are actually working within. The economic lens is introduced here in its ML form: model selection is a constraint satisfaction problem with a cost structure, and the practitioner who cannot present that cost structure to a budget holder is fighting with one instrument missing. The human layer enters in the same weekend — who blocks ML systems in regulated organisations, why they block them, and what those blockers actually need before they will release an approval.
The second weekend is where the system is built. The ML system stack — layers, ownership boundaries, interface contracts between components. ADRs applied specifically to ML decisions: model selection, feature engineering choices, the explainability approach. Feature engineering under data governance obligations, not as a technical exercise but as a compliance-constrained design problem. SHAP and XAI not as interesting tools but as compliance artefacts — the evidence the risk committee will ask for. MLOps for regulated environments: how a governed retraining pipeline differs structurally from an ungoverned one. Drift detection as a governed process, with documented ownership, defined triggers, and an audit trail that survives a regulatory inquiry. Every chapter produces a component of the evolving spine project document.
The third weekend tests everything that was built. Agile value flow in the ML context: how to frame model work in sprint planning language that a product organisation can fund and schedule. The ML failure modes taxonomy: naming the specific failure modes of the specific system in the specific regulated context — silent drift, feature staleness, governance gaps, handoff failures — before they occur. The unbuilt model: the discipline of recognising when the right answer is not a model at all, and making that case with the same rigour as the argument for building. The ML handoff: what clean transfer of ownership requires when the system being handed over is a governed, audited, production ML system. The capstone is the defence of the complete system artefact before a simulated review panel. Participants leave with a portfolio piece, not a certificate.
18 chapters · 6 per weekend
- Weekend 1 Foundation and Judgment
- 01 What Production Ready Means for an ML System
- 02 Reading The Terrain: The Three ML Contexts
- 03 The Data Behind The ML Decision
- 04 Economic Decisions First: The ML Cost Structure
- 05 The Human Transactions
- 06 The Turtles: Who Blocks ML Systems and Why
- Weekend 2 Design and Decision
- 07 The ML System Stack: Layers, Ownership, Boundaries
- 08 ADRs For ML Engineers
- 09 Feature Engineering Under Data Governance Obligations
- 10 SHAP, XAI, and Compliance Artefacts
- 11 Model Selection as a Constraint Satisfaction Problem
- 12 MLOps for Regulated Environments
- 13 Drift Detection and Retraining as a Governed Process
- Weekend 3 Defence and Handoff
- 14 Agile Value Flow: Getting ML Work Into The Sprint
- 15 The ML Failure Modes Taxonomy
- 16 The Unbuilt Model
- 17 The ML Handoff: Giving and Receiving
- 18 The Capstone: Build, Defend, and Hand Off
What You Leave With
Not a notebook.
A governed system artefact.
A complete ML system document you can present to a governance board, a risk committee, or a hiring manager on the day you leave.
Every chapter in Cohort 1B produces a tangible output. Those outputs are not exercises in isolation — they are components of a single, evolving ML system artefact built against a real-world spine project. By the capstone session, participants have a complete document that represents eighteen chapters of applied work against a governed, production-grade ML system specification.
The capstone is the defence of that artefact before a simulated review panel, with the facilitator in the role of the governance board chair and compliance sign-off authority. What participants leave with is something they can deploy immediately — not a course completion record, but a system document that can survive the scrutiny of the environments they are actually working in.
- Model card Intended use, out-of-scope use, performance characteristics, known limitations — structured for regulatory audit
- Feature register Every feature documented with its source, governance status, data lineage, and approval record
- Architecture Decision Record log Every significant ML design decision — model selection, architecture choices, explainability approach — with the constraint map and economic justification that defends it
- Compliance mapping Regulatory obligations satisfied structurally within the system design, not appended as documentation after the fact
- MLOps architecture The governed pipeline: training, evaluation, deployment, monitoring — with ownership defined at every stage
- Drift governance document Detection methodology, threshold definitions, retraining trigger ownership, escalation path, and audit trail specification
- Failure modes register Named ML failure modes specific to the system context — silent drift, feature staleness, feedback loop degradation — with detection instrumentation defined
- Handoff checklist The conditions that must be satisfied before ownership of a governed ML system transfers — and the evidence that they have been met
The Spine Project
One problem. Eighteen chapters. One artefact.
Every Cohort 1B participant works on the same pre-designed spine project throughout all three weekends. The facilitator presents the problem — a real-world ML system challenge in a regulated production context — and plays the role of the business owner, the risk committee chair, and the sign-off authority throughout. This is not a pedagogical technique. It is a structural choice that changes the quality of what gets built.
When participants work on personal projects, they self-select problems they already know how to solve. They import their own assumptions, their own escape routes, and their own definitions of done. When every participant is working on the same problem — with the same facilitator in the room representing the governance authority they need to convince — the pressure is real. The challenge of explaining a drift detection threshold to a risk officer is not hypothetical. The difficulty of defending a feature engineering decision under data governance scrutiny is not simulated. The discomfort of being told that the compliance mapping is insufficient is the condition that produces the capability shift.
By the time the capstone arrives, participants have spent eighteen chapters building a governed ML system artefact against a problem they did not author, for an authority who is not going to make it straightforward. That is as close to the conditions of regulated production as a training environment can get — and it is the condition that Cohort 1B is built to create.
A model that cannot be handed off cleanly to a governance process is not production-ready. The spine project exists to ensure that every participant has built — and defended — a system that can be.
Pricing and Enrolment
Founder pricing.
Limited places.
Available for the first cohort only. Self-funded or employer-sponsored. No difference in price at this tier.
Standard rate for individual participants funding their own enrolment after the founder cohort closes.
Standard rate for participants whose enrolment is organized by an employer or practice team. Includes a post-cohort briefing note for the sponsoring organisation.
Maximum 12 participants per cohort. Places are confirmed by email following an introductory conversation. DataDomine reserves the right to decline enrolment where the programme is not the right fit for the participant's current context.