Approval per version, per environment, with an expiry
Every organisation has a rule about which models may be used on which data. Usually it lives in a document, and the platform that runs the model has never read it. Here the rule is a row the runtime checks before it calls anything.
The trust states
A version occupies one of these, and only certain moves between them are permitted.
Discovered
The platform knows the version exists. Nothing has been decided about it.
Registered
Recorded deliberately, with its task, framework and licence filled in.
Under review
Someone is assessing it. This is a state, not a note in a ticket.
Approved
May run in this environment until the approval expires.
Restricted
May run, but under conditions the reviewer attached to it.
Blocked
Must not run. The refusal is specific to the environment it was recorded for.
Deprecated
Still permitted for now, with the intent recorded that it should stop being used.
Retired
Out of service. Kept, because the runs that used it still refer to it.
The four refusals
Each one is a distinct answer, because "it did not run" is not a useful thing to tell somebody.
No approval exists
There is no trust record for this version in this environment. The absence is the answer: nothing has to be recorded to say no.
The state blocks execution
A trust record exists and the state it names forbids running. Whether a state blocks is a property of the state, not a list hard-coded in the runtime.
The approval expired
The record still says approved and the expiry has passed, so it is treated as absent. An approval with a date on it that is honoured only until somebody notices is not an approval.
The trust store is unreadable
If the record cannot be read at all, the answer is no. An outage is the worst possible moment to widen access.
Why expiry is not a reminder
The usual pattern is an approval with a review date and an email that fires on it. That makes the expiry advisory: the model keeps running while the review sits in somebody's inbox, which is precisely the window the review was meant to cover.
Here the expiry is load-bearing. Past that instant the platform treats the record as though it were never written, and the version stops running until somebody approves it again. The state still reads as approved to anybody looking at the history, so the record of what was decided is intact - it is the permission that lapsed, not the history.
Every decision is kept
Trust changes are recorded as events, with who made the change and what it was. The review trail is the same record the runtime consults, so the audit and the enforcement cannot disagree with each other.
The permitted moves between states are themselves data. A transition that is not recorded as allowed cannot be made, which means the workflow is a property of the platform rather than a habit of whoever happens to be doing the reviewing.
Questions about approval
Can a model be approved everywhere at once?
No. Approval names an environment. Development, staging and production are separate decisions, which is the point - a version being safe to experiment with says nothing about it being safe for customers.
What happens to runs that were in flight when an approval expired?
The check happens before the call. An in-flight asynchronous run keeps its record and its result; the next invocation is refused.
Who can approve a model version?
Approval is a governance action inside a workspace, and it is separate from the capability to run a model. The two being the same person is a choice an organisation makes, not one the platform makes for it.
Is restricted different from approved in practice?
Both permit a run. Restricted records that conditions were attached, so the reason a version is usable is not lost the moment the reviewer moves on.
Where this is today
The machine learning layer is in build. What is described on this page is the data and governance model that is implemented in the platform: the tables that hold it, the rules that enforce it, and the refusals that happen when a rule is not satisfied.
The Data Science tab is in the application. It reads: the model registry and its versions, the approval held for each version in each environment, the integrations and whether each one may currently be called, the record of every run including the refused ones, the projects, and the egress rules. It does not invoke a model - running belongs to the execution provider, and the record of a run is audit evidence that a browser must not be able to write.
The rest of the ML layer
Model registry
Every model and model version recorded once, with its task, framework, licence and where it runs.
Feature store
Versioned features and feature sets, each carrying the sensitivity of the columns it was built from.
Training data and splits
Dataset snapshots and reproducible train, validation and test splits that can be rerun and compared.
ML projects and access
A project gathers datasets, features, models and integrations, and only granted data scientists can act.
Evaluation and runs
Model scores recorded against the same evaluation model as AI steps, and every invocation kept as a run.
Data egress controls
What leaves the platform when a model is called elsewhere, decided per field before the call is made.
Talk to us about the ML layer
DataLens is in private beta. If model governance is the reason you are here, say so when you request access - the ML layer is being built against real use rather than a roadmap.
Request beta access