Registration and Stage Rules
Policy is where registries earn their trust
Registering is not enough — you need rules for what evidence a version needs, who may move stages, and how stages map to actual deployments. Stage rules are the policy that keeps the registry honest.
What you will learn
- Write registration requirements (evidence prerequisites)
- Define stage-entry rules and approval flows
- Map registry stages to actual serving behavior
What is this?
Registration and stage rules are the policy layer of the registry: what a version must carry to be registered, who can transition it between stages, what evidence each transition requires, and how serving interprets stages. Rules turn the registry from a database into a control.
Why do you need it?
- A registry without rules lets anyone promote anything — the same as no registry.
- Consumers rely on stage meaning; rules make 'Staging' and 'Production' trustworthy words.
- Approvals and audit trails become enforceable only when the tool enforces them.
- Clear entry criteria keep garbage versions from polluting the source of truth.
Mental model
Airport security checkpoints
Registry stage rules
You can't board (enter Production) without a boarding pass (evidence) and checks (approvals). Skip the checkpoint and the whole flight is at risk; the checkpoint is policy, not paperwork.
How it works
- The team defines minimum registration metadata: metrics, run ID, owner, data version.
- Stage entry rules state the evidence for each stage (e.g., Staging = offline eval passed; Production = shadow agreement + review).
- Permissions assign who may transition; some transitions require an approver.
- Serving maps stages to behavior: Production routes traffic, Archived is unservable.
- Every transition is logged for audit regardless of how it was done (UI/API/CI).
A policy-ruled path from registration to production.
In production
- A healthcare platform requires an approver role for every Production transition and no direct client-delete of versions.
- A fintech blocks Staging entry unless the version carries a data-version hash — CI validates instead of humans.
- Servers read only Production/Archived state, so a rogue Staging version never receives traffic.
Best practices
- Write the stage policy as code in the repo and review it like code.
- Enforce required metadata at registration with automated validation.
- Make Production transitions approval-required in regulated domains.
- Define what serving does with each stage and audit that mapping quarterly.
Common mistakes
- Rules documented only, never enforced by the tool.
- Production transitions without evidence fields — the 'trust me' promotion.
- Everyone banned from transitions so the platform ossifies — balance with approvals.
- Stages names copied from defaults without defining what they mean for serving.
Debugging tips
- Promote blocked — read the stage policy: which evidence gate is failing?
- Serving ignoring a Staging model — that may be correct policy; check the serving stage mapping.
- Audit flagged a transition — re-run the transition log for that version to see approver and evidence.
Interview checkpoint
Hands-on lab
- Validate required metadata at registration time
- Reject incomplete versions and log the reason
- Let a reviewer approve a Production transition
Enforce Registration Rules
25 min · intermediate
Quick quiz
A version passes CI but has no data-version hash recorded. Under a strict policy what happens at registration?
Stage rules should only ever be a human process, never tool-enforced.