Which AI Version Did You Approve? Track AI System Versions and Sign-Offs

Sooner or later an auditor, a regulator or your own board asks one question: which version of the AI system did you approve? A sign-off shows who approved it and what evidence they saw. It does not show what the system actually was that day: which model, which prompt, which settings. Meanwhile the model is upgraded, the prompt is reworded, a threshold moves, and the record still says "Approved". AI system versions close that gap. You record what the system is, every sign-off is tied to the version it approved, and you are told when the system moves on without a new approval.

What an AI system version is

A version is a list of the parts your AI system is made of, saved at a point in time. For each part you give a type, a name, and a version or value. KlaritiQ accepts seven types:

Versions are never overwritten. Recording a change adds a new version and keeps the old one, so you can always look back. Saving a list that is identical to the latest version records nothing, so there are no duplicates. The order of rows and capital letters in names do not matter, and notes are commentary, not part of what is compared.

Record your first version

1. Open the initiative that governs the AI system, go to the Governance tab and click Versions on the AI system card.
2. Click Record a new version. Admins and owners can do this.
3. Add one row per part: choose the type, then enter the name and the version or value.
4. Optionally add a short note on what changed and why, then click Save version.

Sign off on a specific version

On the Decisions page, the sign-off panel names the version you are approving, for example "AI system version you are approving: 2". Your sign-off is saved together with that version. Two safeguards follow:

• If a newer version is recorded while you are reviewing, the sign-off is refused and you are asked to review the new one. You can never approve a version you did not see.
• Once an initiative has any recorded version, a sign-off has to name one.

For an initiative with no recorded versions nothing changes, and sign-offs work as before.

Approve a part, or the whole system

A sign-off says exactly what it approves. When you are asked to sign off, the Decisions page shows You are approving with the parts of the AI system, each with its current version, and you confirm one sentence such as "I approve the Data part only." Nothing is ticked for you except what you were asked about, and approving The whole system is a separate choice you make on purpose.

• Asking someone. When you request a sign-off on the initiative's Governance tab, tick the parts you want them to approve, or the whole system. Parts nobody approves yet are ticked for you. The request names what it covers, and the person can answer it with that or less, never more. A request for the whole system can only be answered by approving the whole system. You can take an open request back with Withdraw.
• A change only touches what it changes. If the model changes after the data steward approved the data, the data approval still stands and the data steward is not asked again. Only the people who approved the model, and whoever signed off the whole system, are told.
• The whole system. Completing the initiative needs every part approved and one sign-off of the whole system as it is now. Any change to any part means the whole-system sign-off needs renewing, because the combination is new.
• On the cards. Each part card on the AI system card shows who approved it and when, or that it changed after it was approved, or that it is not approved yet. Under the meter you see how many parts are approved and whether the whole system is signed off.
• Part reviewers. You can ask any member, not only an admin, to approve named parts. Asking them about a part is what makes them its reviewer: there is no separate step. They can approve those parts and nothing else: not another part, and not the whole system, which stays with owners and admins. The record says whether a sign-off was given as an owner, an admin or a part reviewer.
• What the record says. Each sign-off keeps the parts it approved, the versions of those parts, who approved and which request it answered. A request that was declined stays on the record, and only that part is asked again.

What happens when the system changes

When a version is recorded that no longer matches what was approved, the initiative shows a yellow warning such as "The system has changed since it was approved (version 1, now version 2)", followed by the exact list of differences, for example "Model credit-risk: v4.2 to v4.3" or "Configuration credit threshold: 720 to 680". A notice also appears on your dashboard when the approval stops holding, once and not on every later update. If you return to exactly the approved configuration, the warning clears and the original approval holds again.

Does a changed system stop completion?

It depends on the initiative:

• The initiative requires sign-off and has recorded versions: only sign-offs on the current version count. If the system has changed, marking the initiative completed is refused, and the message says how many of the required sign-offs cover the current version. Review the change and sign off again.
• The initiative does not require sign-off: you see the warning, and nothing is blocked.
• No versions are recorded: the behavior is exactly what it was before.

See Governance Sign-Off for how required sign-offs work.

Record versions automatically from your deploy pipeline

If your team ships updates through a tool such as GitHub Actions, every deploy can record its version for you. On the initiative's Governance tab, click Sources on the AI system card. Under Add a source, choose the part the tool reports (for example Code), choose the tool (for example GitHub), name the key and click Create key. Copy the key straight away: it is shown once. The key can report only the part you chose. A key works for that one initiative only. It can record versions and ask whether the current version is signed off. It cannot read evidence, decisions or any other data, and you can revoke it from the same place at any time.

Store the key as a secret in your pipeline (in GitHub: Settings, Secrets and variables, Actions) and add a step after the release step:

- name: Tell KlaritiQ what was deployed
  run: |
    curl -sS -X POST https://klaritiq.in/api/v1/pipeline/system-states \
      -H "Authorization: Bearer ${{ secrets.KLARITIQ_PIPELINE_KEY }}" \
      -H "Content-Type: application/json" \
      -d '{"components":[{"kind":"model","name":"gpt-4o","version":"2026-03"},{"kind":"prompt","name":"underwriting prompt","version":"B"},{"kind":"config","name":"approval threshold","version":"720"}],"changeNote":"deploy"}'

Replace the example parts with what your system really uses. Because identical details record nothing, it is safe to run the step on every deploy. Versions recorded this way are labeled "pushed by the API", and your data export shows which key wrote each one.

Several tools, one version

Your AI system is not one thing. The code, the model, the data and the prompt often come from different tools, and each tool can report its own part. When a push names the types it replaces, KlaritiQ replaces only those and keeps everything else from the latest version, so a model registry can never erase the code that GitHub reported. Add replaceKinds to the call, and an origin to each part to say which tool reported it:

curl -sS -X POST https://klaritiq.in/api/v1/pipeline/system-states \
  -H "Authorization: Bearer $MODEL_KEY" \
  -H "Content-Type: application/json" \
  -d '{"replaceKinds":["model"],"components":[{"kind":"model","name":"credit-scorer","version":"5","origin":{"provider":"mlflow","reference":"models:/credit-scorer/5"}}]}'

• replaceKinds lists the types this push replaces: model, data, prompt, code, config, vendor or permissions. Every part you send must be one of them.
• origin names the tool and its own reference for that part. It appears in the AI system card and the version history, and it never counts as a change by itself.
• Limit a key to its tool. When you create a key on the Sources tab, tick the types its tool reports. A key limited to data can only replace data, so a leaked key cannot touch the model or the code.
• Nothing breaks for existing pipelines. A push without replaceKinds still replaces the whole state, exactly as before.
• Mistakes are refused, not guessed. A push is refused, and nothing is recorded, if it sends a part outside the types it names, names a type but sends none, or comes from a limited key asking for more than it may.

If two tools report at the same moment, KlaritiQ retries automatically so both parts are kept.

Link each version to its commit, and stop an unsigned release

Two optional additions make the GitHub step more useful. First, add a source to the same call and each version shows a link to the exact commit, pull request and workflow run that produced it, so anyone reviewing an approval can open the code. Add this inside the JSON, next to components:

"source": {"repository": "your-org/your-repo", "commit": "${{ github.sha }}", "pullRequest": "${{ github.event.pull_request.number }}", "runId": "${{ github.run_id }}"}

Second, ask KlaritiQ whether the current version has the sign-offs it needs, and fail the job if it does not:

- name: Block the release unless the version is signed off
  run: |
    curl -sS --fail https://klaritiq.in/api/v1/pipeline/release-check \
      -H "Authorization: Bearer ${{ secrets.KLARITIQ_PIPELINE_KEY }}" | tee result.json
    test "$(jq -r .ok result.json)" = "true"

The check uses the same rule as completing an initiative: only sign-offs on the current version count, so a changed system fails the check until someone reviews the change and signs again. It can only answer yes or no for the one initiative the key belongs to. If KlaritiQ cannot be reached, the step fails rather than passing.

Parts that report themselves

Some parts do not need a person or a pipeline script to type them. Each of these reports through the same rules as the pipeline above: it replaces only its own part and records nothing when nothing changed.

• The repository. A klaritiq.yml file in your repository can name the model, prompt files, datasets and vendors, and a step in your deploy workflow reports them with the commit. See Report your AI system from your build with klaritiq.yml.
• The vendor register. A vendor that an owner or admin has linked to the initiative in KlaritiQ's vendor register becomes a Vendor part, named after the vendor, with a version made of its status and its relationship to the initiative, for example active, supplier. The vendor's category is shown as a note on the part and is not part of the version, so correcting a category does not create a version or ask anyone to sign again. It shows with the vendor's next real change. This feed is switched on for your KlaritiQ workspace by KlaritiQ; once it is on, a sweep runs every hour, and a vendor edit, removal or link change also updates the system right after it. The first time it is switched on, vendors already linked are added in one new version, so sign-offs of the whole system on those AI systems need review. Unlinking or deleting a vendor takes its part out. On the AI system card, the Vendor part card has Manage vendors for owners and admins, or View vendors for members. It opens the vendor register for this initiative, where an admin picks a vendor with Link, adds one with Add and link, changes its status (Active, Inactive or Terminated) and its relationship (Supplier, Implementation partner, Risk source or Data processor), or chooses Unlink. Vendors that exist only in the DPDP engine are listed there read only. A deploy push from a pipeline, a manifest or a coding agent, partial or of the whole system, never removes the parts the vendor register or Microsoft Entra report. To drop a register vendor, unlink it in the register. To override one, the push must name the same vendor, and then the push's value is kept. When a system is close to the limit of 40 parts, a deploy may be recorded without some register or Entra parts, and its change note names what was left out, starting "Not carried forward (limit of 40 parts)". A person saving the AI system form records exactly what they sent. Vendor parts reported by another tool or typed by hand are kept exactly as they are, and a register vendor with the same name as one of them leaves it alone. The Vendor part card appears once the AI system has a recorded version, and a system with no recorded version yet is left alone: record a first version, and the register's vendors are added at the next sweep or edit. If adding them would take the system past 40 parts, the update is refused and nothing is recorded.
• Microsoft Entra. The Entra groups you pick for the system are recorded as Permissions parts: the group's name, with a version of the role, the member count and a short fingerprint of the members, about every 6 hours. A group waits until the system has a first version, and a group whose name matches a part another source already reports is left alone, with the reason shown under it. A deploy push never removes the Permissions parts Entra reports. See Report who has access with Microsoft Entra.
• A coding agent. An agent connected over MCP can read the system's status and record a part. See Connect coding agents with MCP.

Look back to any date

Under the version list, choose a date under What was running on to see the version that was current at the end of that day, in your own time zone. The full history, including which version each sign-off approved, is also in your organization data export.

What this does not do

• It does not detect changes by itself. KlaritiQ compares what is recorded, so a model upgrade nobody recorded is invisible. A pipeline step removes the dependence on someone remembering.
• It does not check that the details are true. "gpt-4o" is the text you or your pipeline entered.
• It does not replace the sign-off. A person still reviews the version and signs.

Common questions

Does KlaritiQ detect when my AI model changes?

No. KlaritiQ records the versions you or your pipeline report and compares them with each other. If a change is never reported, KlaritiQ cannot know about it. Connecting a deploy pipeline makes the reporting automatic.

Do I have to record every version by hand?

No. Create a pipeline key for the initiative and add one step to your deploy workflow, and each deploy records its version. You can still record a version by hand at any time.

What happens if a version is recorded while I am signing off?

The sign-off is refused with a message saying the system changed while you were reviewing. Nothing is saved. Review the new version, then sign off again, so your approval is tied to what you actually saw.

Can a changed system stop an initiative from being completed?

Yes, if the initiative requires sign-off and has recorded versions. Only sign-offs on the current version count, so you need to review the change and sign off again. Initiatives that do not require sign-off only show the warning.

Can my model registry and GitHub both report to the same system?

Yes. Each tool reports only its own part by naming the types it replaces, and KlaritiQ keeps the rest from the latest version. You can limit each key to its tool's types, so a data tool cannot overwrite the model. Pushes that do not name the types it replaces still replace the whole state, as before.

Can a pipeline key read my data?

No. A pipeline key works for one initiative and can only record versions and ask whether its current version is signed off. It cannot read evidence, decisions or any other data, it is shown only once when created, and you can revoke it at any time.

What counts as a change between two versions?

A difference in a part's type, name, or version or value, a part added, or a part removed. Notes and the order of rows do not count, and names are compared without regard to capital letters.

Related guides: Governance Sign-Off, Evidence, and how to track RBI's AI governance expectations.

Was this article helpful?

Community Questions (0)

Still have questions?