← All documentation

AI Approvals and Reviews

Every AI system is approved by people you name, through a review. A review keeps a signed record of who decided what, and why. That record is the system's approval history, and it exports as an approval dossier.

When a review opens

  • Submitting a proposal. A system's owner, whoever proposed it, or an organization administrator submits it for review.
  • Sending a live system back. An organization administrator sends an approved or deployed system back for review, for example after a significant change.
  • Re-review. Every approval carries a review date set by the system's risk tier (high: 6 months, moderate and low: 12 months, unclassified: 6 months). When that date arrives, a re-review opens automatically, and the system keeps its stage until the review decides. If no eligible approver is left to take it, no review opens: the organization's administrators are notified of what is blocking it, and reminded until that is fixed. Logging a material change to the system in the change log opens one early.

A re-review does not take a deployed system out of use while it runs.

Who approves, and by which rule

An organization administrator sets a policy for each risk tier in Settings → AI approvals. A policy names the approvers and a rule:

  • Any one approver: the first decision decides the review, whether it approves or rejects.
  • A majority: more than half of the approvers. A tie is not a majority: it sends the system back (or, on a re-review, the approval is not renewed).
  • Every approver: everyone must approve. One rejection ends the review.

A tier with no policy uses the built-in default: any one organization administrator.

A system can have its own policy:

  • A stricter one (a stronger rule and at least the same approvers) can be set by anyone who can edit the system.
  • A weaker one can only be set by an organization administrator, who must give a reason. The dossier shows the tier default, the system's policy and the reason.

The rule and the approvers are fixed when a review opens. Changing a policy later does not change a review that is already running. An organization administrator can still add an approver to an open review (for example when every named approver has left); anyone added is marked "added during the review". While a system holds an approval, its expiry date is set by the approval and cannot be edited on the system page — to review sooner, send it back for review or log a material change.

Separation of duties

Whoever proposed a system and its owners are left out of its approvers. If your organization is too small to separate those roles, an administrator can allow self-approval, with a reason. Every decision made under it is marked self-approved on the record and in the dossier, with the reason the organization gave. Someone made an owner while a review is open is left out of it in the same way.

If no one is left who can approve, the review does not open, and the page says who can fix it. If every approver on an open review leaves the organization, is suspended, or becomes an auditor, the review waits until an administrator adds an approver. It never approves by default.

Signing a decision

An approver chooses approve, approve with conditions, reject or send back, and gives a reason. They sign by typing their name, confirming the decision is theirs, and re-entering their password and a code from their authenticator app (or a backup code). The record shows which of those they used. An account with no password in Backsplice (one that signs in only with a passkey or single sign-on) cannot sign decisions yet.

A signed decision cannot be changed in Backsplice. Each one also carries a tamper-evidence check, shown as Intact in the history and the dossier: it shows the decision has not been altered without the application's signing key since it was signed. It covers the decision itself, not the review's outcome.

The signed decision is the approver's electronic signature on your organization's approval record, and the approval dossier presents it that way. Decisions in the demo data are marked Demo data (not signed by a person).

If an approver leaves the organization, is suspended or becomes an auditor before a review closes, their decision no longer counts, and the history marks it not counted.

  • Conditions: each condition becomes a remediation task. Marking one done does not complete it: it goes to an approver of the system's review (or, when none of them can still approve, to the approvers your current approval policy names), who confirms it or returns it with what is still missing. The system's proposer and owners never confirm its conditions. The system cannot be deployed, or marked as meeting its conditions, until an approver has confirmed every one.
  • Send back: returns the system to proposed so it can be revised. It is not offered on a re-review, which must be approved or rejected; a re-review that ends in a tie is treated as not approved.
  • Reject on a re-review: suspends a deployed system.

The approval dossier

Condition tasks cannot be deleted, and a confirmed one cannot be reopened: mark each done when the condition is met, and an approver confirms it.

The Approval page links to the dossier as a PDF or JSON (exports come with a plan; they are not in the demo). It contains:

  • the system's registry entry;
  • the policy in force, and how it compares with the tier default;
  • every review, with its rule, its approvers (including anyone who dropped out) and each signed decision;
  • the condition tasks, with who marked each done and which approver confirmed it;
  • the published system and model cards;
  • the system's assessments and their scores;
  • a record of the lifecycle events.