Here is a question worth asking over coffee this week: when your platform “shipped” last Tuesday, did anything actually change for users, and could you undo it before lunch if the answer turned ugly? Most AI teams we meet answer the first half confidently and mumble through the second. ReleaseOps is the informal name The Ops Atlas gives to the release-strategy layer between release engineering and release management, and its centre of gravity is one distinction: deploying installs a version, releasing exposes behaviour to users. The ten checks below test whether that split genuinely exists in your platform. Score a point for every honest yes.

What the audit is really testing

When installation, exposure and announcement travel as one atomic event, every release becomes all-or-nothing: nobody can try a change on a slice of traffic, nobody can measure it before the whole user base feels it, and backing out means moving the entire system at once. Split the acts and a release stops being a leap and becomes a decision you can stage, watch and reverse. Announcement belongs in that split too — telling users is a choice with its own timing, not a side effect of copying files onto a machine.

The practical test is whether you own two independent dials: one that decides which version runs where, another that decides who sees which behaviour. Flags move only the second dial. Canary analysis and blue-green switches move both together. And a warning about the default most teams start with: a plain rolling update mixes old and new versions across the fleet with no traffic control at all, and undoing one takes minutes rather than seconds. That is survivable for a dashboard, dicey for a scoring endpoint that trading partners poll every few seconds.

The ReleaseOps checklist: ten checks, one point each

1. Independent dials. Your team can change who sees a behaviour without re-deploying code, and can install a version invisibly. If exposure always waits on a deploy, the dials are ganged together.
2. Configuration travels like code. Prompt templates, thresholds, routing tables and policy records go through review, staging and the same pipeline as binaries — every one of them alters behaviour, which makes each one a release in its own right.
3. A flag registry with expiry dates. Every release flag carries an owner and a removal date, and release flags should retire within weeks. Each live flag multiplies the states your tests must cover; untested combinations are where defects hide.
4. Canaries sized to the traffic they actually get. Five minutes at one percent on a quiet service will only confirm what you already believe — it catches failures at roughly ten times your normal rate and little else. Honest sizing starts from the change you want to detect, then works backwards to the sample it needs.
5. An undo order everyone can recite. Flag off first, because it takes seconds and fails only when the defect sits outside the flagged path. Then rollback. Roll forward last, through the same staged route — never a side door that skips scrutiny.
6. No re-used flags on stale machines. Knight Capital in 2012 re-used a flag on a server that never received the new code; the money was gone in forty-five minutes. Walk your fleet and ask whether every box runs the version you think it does.
7. Merge rights understood as release rights. If merges to main trigger automatic tagging and rollout, then everyone with merge access is effectively on the release team, whether or not the word appears on their badge.
8. Numbers on the wall. How early does a bad build get caught? How many user-minutes did the last bad release touch? How long did safe state take? Release lead time — merge to full exposure — belongs beside them. If nobody can answer, the practice is vibes.
9. On-call holds a real abort button. Titles do not matter; the engineer staring at the graphs at two in the morning can halt exposure without convening a committee.
10. A 30/60/90 on paper. First month: a written release policy plus a flag inventory. Second: dark deploys and one rollback actually rehearsed. Third: automated canary analysis live on three services.

Reading your ReleaseOps score

Eight or more, and the strategy layer is doing real work — polish the gaps and re-audit twice a year. Five to seven means the split exists on paper but leaks under pressure, usually at items two, six or nine. Below five, resist fixing everything at once; the 30/60/90 in check ten orders the work deliberately, and the Atlas maturity sketch — ad hoc, repeatable, decoupled, progressive, adaptive — suggests most stuck teams sit somewhere between repeatable and decoupled. Tiny teams and quiet internal tools can legitimately keep this light; the discipline earns its cost where software is operated, deployments are frequent and traffic can be compared. One caution while you measure: watch the false-abort rate, because an abort nobody trusts gets ignored by the second incident. The Ops Atlas entry on ReleaseOps expands each check into mechanisms, worked maths and maturity stages, and it is the document we hand teams who want the complete picture before their first re-run.

Where AI platforms trip over themselves

Machine-learning estates accumulate exposure decisions faster than most: a model version swap here, a threshold nudge there, a routing rule tuned by someone who left last quarter. Each behaves exactly like a release whether or not anybody called it that, which is why item two earns its place near the top.

The pattern we see most: the pipeline for code is immaculate, while the file that actually decides what users experience was last touched by hand, on a Friday, by a contractor.

The remedy is boring and effective — one inventory, one expiry habit, one pipeline for anything that changes behaviour. When alert quality sags because too many small changes land at once, the walkthrough on quieting noisy IT alerts pairs naturally with flag hygiene. If the audit exposed ownership gaps rather than tooling gaps, the field notes on adopting AIOps inside an existing team cover the human half of the work, and newcomers can warm up with the primer on handling IT problems as they happen.

Run the audit, write the score on the whiteboard, and date it. Teams that improve fastest are rarely the ones with the cleverest tooling — they are the ones that measure themselves the same way twice, quarter after quarter, until the numbers move.