An AI Release Decision Needs an Exact Revision

An AI workflow can have a green build, a passing evaluation run, an approved model, a reviewed prompt, a security checklist, and a deployment plan without anyone being able to answer the release question clearly.

Which exact revision are we approving?

That question is smaller than AI governance and more consequential than it looks. A release decision is not about a model in isolation. It is about a working combination of code, configuration, model, prompt, tools, skills, data, policies, evaluation cases, permissions, and operating conditions. Change one of those pieces and the evidence may no longer apply.

The practical unit of review is therefore an exact AI workflow revision.

Start with the decision, not the dashboard#

The release question should fit in one sentence:

Is this exact AI workflow revision ready to release, under what conditions, and what evidence supports that decision?

The answer does not have to be yes. A defensible record can conclude:

• Release.
• Release with conditions.
• Block.
• Defer until named evidence exists.
• Expire a prior approval because its assumptions no longer hold.

This framing prevents a common failure: collecting a large amount of governance material without connecting it to an accountable engineering decision. An inventory can tell you that a model exists. A control map can tell you which policy topics were considered. An evaluation platform can tell you how cases scored. None of those artifacts, alone, says whether this implementation should enter this environment under these conditions.

Bind the subject before reviewing the evidence#

The first section of the release record should identify the subject precisely enough that two reviewers cannot unknowingly discuss different systems.

At minimum, record the applicable versions of:

• Source code and configuration.
• Model and model-serving settings.
• System and task prompts.
• Agent skills, plugins, tools, hooks, and permissions.
• Retrieval sources, data snapshots, and transformation logic.
• Policies and human-review thresholds.
• Evaluation cases, expected results, and evaluation implementation.
• Target environment and release mechanism.

Not every workflow has every field. That is fine. The goal is not to force one universal schema onto every system. The goal is to make omitted and inapplicable fields explicit instead of allowing the subject to drift during review.

A Git commit is useful, but it is rarely enough. Model aliases can move. Prompts can live outside the repository. Tool permissions can differ by environment. Data can change without a code revision. The subject record should point to the authority for each part and state how its identity was established.

Separate evidence from interpretation#

The evidence register should preserve what was actually observed and what remains an assertion.

Useful states include:

• Available.
• Missing.
• Stale.
• Disputed.
• Pending.
• Inapplicable.

That vocabulary is more honest than forcing every control into pass or fail. A rollback document may be available while a rollback test is missing. A tool may be described as read-only while the runtime permission record is disputed. An evaluation may have passed against an older prompt revision and therefore be stale for the proposed release.

For each material artifact, record:

• Evidence owner and source authority.
• Collection or observation time.
• Exact revision or digest when useful.
• What claim the artifact supports.
• Which environment, population, route, or operating condition it covers.
• Known limits and unresolved questions.

This is provenance work, but provenance alone does not prove correctness. A hash can establish that two files are byte-identical. It cannot establish that the file is safe, current, meaningful, or appropriate for the release decision.

Known failures belong in the decision#

Release packets often become weakest where they need to be strongest: the known failures are summarized away.

Averages and aggregate scores can hide the cases that should determine the release conditions. The record should preserve representative cases, boundary cases, refusal behavior, ambiguous inputs, unsafe requests, tool failures, partial completion, and recovery behavior separately when their consequences differ.

For each known failure, ask:

1. Is it reachable in the proposed release scope?
2. Who or what could be affected?
3. Is the failure detected?
4. Does the system stop, escalate, contain, retry, or continue silently?
5. Who owns the exception?
6. What evidence would justify accepting, narrowing, or blocking the risk?
7. What change would force re-review?

The objective is not to produce a system with no known failures. That standard is usually impossible and encourages concealment. The objective is to ensure that the decision owner sees the applicable failures and explicitly accepts, conditions, or rejects the release scope.

Approval needs scope and expiration#

"Approved" is incomplete.

A useful approval identifies:

• The named human decision owner and role.
• The exact subject being approved.
• The target environment and allowed population.
• Conditions and exceptions.
• The evidence basis and unresolved gaps.
• The rollback or containment reference.
• The approval time and expiration.
• Re-review triggers.

Expiration matters because AI workflow evidence ages in several ways. A model provider can change behavior. A prompt can be edited outside the code release. A retrieval source can change meaning. A tool can gain permission. A policy can be revised. An evaluation set can stop representing the traffic the system now receives.

An approval that never expires and has no re-review triggers is not durable governance. It is a historical statement that can be misapplied indefinitely.

Re-review should be event driven#

The release record should say which changes invalidate or narrow the decision. Common triggers include:

• Code or configuration changes.
• Model, prompt, tool, skill, or permission changes.
• Retrieval or data-source changes.
• Policy or reviewer-threshold changes.
• Evaluation-case or scoring changes.
• New failure classes or incidents.
• Expansion to a new user population, route, jurisdiction, or environment.
• Expiration of a time-bounded condition.

The trigger should connect to an owner and an observable change. "Review periodically" is too vague if nobody knows which event starts the review or who must act.

What the record does not prove#

An exact-revision release record can improve clarity, accountability, and reproducibility. It cannot prove that the released system is safe, correct, compliant, effective, secure, or free of unknown failures.

It is not a legal opinion or certification. It does not replace accessibility testing, security testing, operational readiness, privacy review, or domain-specific approval. It does not make a weak evaluation representative. It does not turn a simulated result into customer evidence. It does not prove that a documented rollback works in production.

The claim should stay narrow:

For this exact subject, under these stated conditions, the named owner made this decision using this evidence, with these known limits and re-review triggers.

That is less dramatic than "responsible AI platform." It is also much easier to inspect and challenge.

Validate the service before the software#

The tempting next step is to build a multi-tenant evidence dashboard. I think that is backward.

The first version should be a bounded service for one workflow and one proposed release. The delivery team should discover which artifacts buyers actually have, which fields are repeatedly disputed, which evidence is expensive to produce, who owns the decision, and whether anyone will pay to repeat the work.

Only after comparable paid engagements produce the same evidence structure should the reusable software boundary be designed. Otherwise, the platform will encode assumptions from a synthetic example or one organization's process and call them a universal domain model.

The evidence threshold I would use before product development is deliberately strict:

1. Three comparable paid release-evidence engagements.
2. Two separate buyers asking for continuation, maintenance, or another workflow review.
3. A repeated evidence structure that survives without erasing the differences between the engagements.

Until then, repository activity, templates, internal examples, interviews, proposals, and free reviews are learning evidence. They are not customer validation or recurring revenue.

The smallest useful release packet#

A first packet can remain compact:

1. Decision question and accountable owner.
2. Exact subject and target environment.
3. Evidence register with applicability and limitations.
4. Evaluation results and known failures.
5. Exceptions and unresolved gaps.
6. Release, conditional release, block, defer, or expire decision.
7. Conditions, rollback reference, and expiration.
8. Re-review triggers.

The structure is intentionally plain. The value is not a prettier report. The value is making the release decision reviewable without pretending that the evidence says more than it does.

This article follows the public evidence standard: implementation artifacts, live behavior, customer outcomes, and commercial validation remain separate facts.