ivyxivyx
← All skills
IVYXSTUDIO · SKILL
M

Model promotion review

model-promotion-review · v1.0.0

ivyx

Use before promoting a model version, moving the champion alias or putting a new version into production (modeli terfi ettirmek, production'a almak, champion), and whenever someone asks to compare a new version with the champion or to promote it if it is better; reads both versions' training runs first and promotes only after the person has seen the comparison and said yes.

Who is asked

Risk high: you are asked on every call to it.

Tools it may call

While this skill is active, a call to any other tool is refused. These still meet every policy rule; the list narrows, it approves nothing.

mlops.model.listmlops.model.getmlops.model.versionTraceexperiments.getmlops.metric.historyevidence.buildmlops.model.promote

What it tells the agent

The published SKILL.md, as written.

---
name: model-promotion-review
description: Use before promoting a model version, moving the champion alias or putting a new version into production (modeli terfi ettirmek, production'a almak, champion), and whenever someone asks to compare a new version with the champion or to promote it if it is better; reads both versions' training runs first and promotes only after the person has seen the comparison and said yes.
allowed-tools: mlops.model.list mlops.model.get mlops.model.versionTrace experiments.get mlops.metric.history evidence.build mlops.model.promote
metadata:
  risk: high
---

Reviewing a model promotion

A promotion moves an alias in the registry; it is the one write in this procedure and it happens only through mlops.model.promote, after the person has read your comparison and said yes. Everything before it reads.

1. Find the candidate and the champion

  1. mlops.model.list: the registered models with their alias map. Take the model the person named; if they named none and there is one, take it and say so.
  2. mlops.model.get with its name: every version with its status and run id. The champion is the version the alias (champion unless the person uses another) points at; the candidate is the version they named, or the newest one that is not the champion. Say which two you are comparing, by version number.

2. Compare them by their training runs

For each of the two versions:

  1. mlops.model.versionTrace with name and version: the run that trained it (runId, traceId).
  2. experiments.get with that runId: its params and its metrics.

Put the two side by side: every metric both have, with the candidate's value, the champion's, and the difference; the params that differ; the data the run names, when it does. A metric only one of them has is listed as not comparable. If versionTrace cannot find a run for a version, say that version has no training record here and do not compare it from memory.

mlops.metric.history when the project has a pipeline with gates: whether the newest run passed its quality gate.

3. Say what you recommend, and wait

  • Promote when the candidate is better on the metric the person cares about and not worse on the others by more than noise, and its run is on record.
  • Do not promote when it is worse, when it has no training record, or when the metrics are not comparable. Say which.
  • Either way, end with the question: do they want the alias moved to the candidate? Do not call mlops.model.promote in the same turn as the comparison.

4. Promote, when they said yes

  1. evidence.build with model and version for the candidate first: the package records what the decision was made on. Report its path.
  2. mlops.model.promote with name, version (as a string) and alias. The project may ask the person once more; that is expected.
  3. Report previousVersion, version and changed from the answer.

Never promote a version that is not the one you compared, and never promote on a comparison the person has not seen.