SovAIHub
ModulesSAI-250
SAI-250 table of contents
Reference2 min readPrototype

Controlled change and versioning

Version complete AI behavior, assess change impact, approve promotion, support rollback, and retire superseded assets.

Last content review 2026-08-03Included in SAI-200, SAI-210, SAI-220, SAI-230, SAI-240, SAI-250, SAI-260, SAI-270, SAI-280

Before you start

Module prerequisites: SAI-100, SAI-120. Check the exercise-specific tools and environment before running commands.

Module outcomes: Map controls to technical evidence; Define audit events and evidence retention; Verify model, container, configuration, and decision provenance. This lesson contributes to that sequence.

Version the behavior, not only the model

An AI system's behavior depends on a configuration set: model and tokenizer, prompt and templates, retrieval corpus and index, policy, tools and schemas, runtime, dependencies, hardware profile, feature flags, and application code. A release identifier should resolve to that complete set.

Classify change

Define change classes based on possible impact, not file size. A one-line policy or prompt update can be material. For each class, specify required review, evaluation, approval, deployment, monitoring, rollback, and evidence.

Common reassessment triggers include:

  • Model, quantization, tokenizer, runtime, or hardware changes.
  • Prompt, tool, retrieval, corpus, permission, or policy changes.
  • New users, purpose, data class, geography, provider, or deployment boundary.
  • Security findings, incidents, drift, quality regression, license changes, or expired exceptions.

Controlled promotion

Identify the immutable candidate and its parents. Evaluate in a representative environment, record results and exceptions, obtain authorized approval, promote without rebuilding, verify deployment identity, monitor the defined window, and preserve rollback.

Separate content movement from authorization. The ability to copy an artifact must not imply permission to promote or execute it.

Rollback and forward recovery

Rollback must consider data schemas, indexes, caches, state, secrets, and evidence compatibility as well as binaries. Some changes are not safely reversible; document forward-recovery steps and the point of no return.

Retirement

Remove superseded artifacts from active selection, revoke credentials and approvals where appropriate, preserve required evidence, update dependencies, and verify that hidden routes cannot still invoke the retired version.

Record architecture consequences and reversal triggers in an architecture decision record. Tool-specific deployment syntax belongs in separately tested adapters; the change contract remains stable across platforms.

Module worked example

A release has passing functional tests but no evidence for a required access-control objective.

Apply the control
Link the missing objective to an owner and hold the release pending evidence or a valid scoped exception.
Expected result
The gate records the unresolved finding and the specific condition needed to reconsider it.
Troubleshooting
Check evidence scope, revision and expiry. A high average coverage score cannot satisfy a missing critical control.

Practice and completion check

Choose one control from this lesson. Identify its actor, target, enforcement point and expected result. Describe an allowed case and a denied or failed case. For a runnable exercise, retain observed output and separate it from expected output. Record unresolved limitations before marking the lesson complete.

Your lesson progress

Completion is self-reported learning progress; it does not certify practical competence.

Status: Not marked

My learning

Loading your learning record…