Outcome · Deployment readiness
The model works. It has sat in staging for months because nobody is able to sign for it.
The blocker is rarely the science. It is that promotion needs an owner willing to put a name to it, an evaluation somebody else can re-run, and a record of what was compared against what — all assembled afterwards, by the team with the least appetite for assembling it.
The one metric
No inventory has been measured yet, so the slot is empty. It will be calibrated on the first pilot’s own registered inventory, and the starting figure will be published beside the finishing one — an improvement quoted without its baseline is not a result.
The one mechanism: a model that cannot be registered cannot deploy
The chain runs preparation, tuning, evaluation gate, registration and deployment as governed steps, each streamed and each recorded — so the evidence for a promotion is produced by the promotion rather than about it (UC068).
The evaluation gate is joined by a cross-model check: heterogeneous models re-derive the result and a computed agreement predicate must pass before promotion releases (UC064).
A named owner signs at a durable waitpoint, and the signature is part of the model’s record rather than an email attached to it. An unregistrable model has nowhere to go, which is the point.
[O]NX/services/nexus-workflows/src/services/tool-executors/model-{factory,eval,register,deploy}-executor.ts
[O]NCT/services/nexus-workflows/src/services/tool-executors/sentinel-executors.ts
Validation-Evidence Autopilot
The annual validation dossier compiles itself, out of runs that were reproducible on the day they happened — rather than being reconstructed once a year from memory and spreadsheets.
shipped(shipped)Cross-Model Computed Gate → Sealed Certificate
Two or more heterogeneous models re-derive the answer. A computed — not learned — agreement predicate must pass before anything is released, and the inputs and model versions are sealed into the record.
shipped(shipped)The one honest bound
WHAT THIS DOES NOT DO YET
- Drift-detection logic. The alert taxonomy and stores exist; the detection does not.
- Automated model search and hyper-parameter optimisation. The chain governs the steps you configure; it does not search the space for you.
Read plainly: getting a model approved and keeping it approved are different problems, and this path answers the first one. The alert taxonomy and the stores for drift exist; the detection that would fire them does not. Until it does, the question “is this model still the model we validated?” is answered by a person on a calendar.
REFUSED
GATE_DISAGREEMENT
When the heterogeneous models disagree at the promotion gate, nothing promotes. The effect is held and the disagreement is named on screen.
The alternative is a promotion that proceeded because one model was confident, which is precisely the event your model-risk committee exists to catch. A held promotion is a bad afternoon; an unheld one is a finding.
Start with the model that has waited longest
Register one model, run one evaluation through the gate, and have one named owner sign it. What you learn in an afternoon is which parts of your approval record already exist and which parts your team has been re-creating from memory every time.