P43 · Cross-Discipline Capstones
apply the engineering discipline end-to-end to another discipline's artefact
The discipline's flagship transfer task: take an artefact from another discipline - a P5 tabular model - and engineer it to production standard end-to-end (package, CI-gate, observe), all in Pyodide with the production simulators inlined and the model given.
A data scientist hands you a notebook. It trains a model, the model is good, and that is the end of their involvement — from here it is your problem, and none of what makes it your problem is machine learning. Can it be installed? Does it build the same way twice? What stops a change from silently degrading it? When a prediction is slow or wrong at two in the morning, can anyone find out why? This pillar is that handover, run properly.
It is deliberately constructed so the modelling is not the work. The artefact comes from Data Science & AI — a trained tabular model — and it is given to you, so every decision you make is an engineering decision. You package it with the P35 discipline: a real project layout, declared and pinned dependencies, an installable artefact rather than a folder of scripts. You gate it with the P36 discipline, and the gate has a quality floor rather than a green tick, so a change that degrades the model's measured performance fails the build the same way a broken test would. You instrument it with the P37 discipline, so its serving emits structured logs with a correlation id, metrics you could alert on, and spans that show where a slow prediction spent its time.
The whole thing runs in Pyodide with the production simulators inlined, which means you actually do it rather than describe it. That is the point of a capstone in this position: every earlier pillar was assessed on material chosen to suit it, and this one is not. If the discipline transfers, it transfers here.