AI governance and workflow approvals

AIMS is Confluye's AI Management System: the governance layer that connects an AI-enabled workflow version with its intended use, impact classification, assessment, authorized approval, technical artifact, kill switch, and deployment authorization.

Human approval applies to a governed version or material governance change, not to every workflow execution. Once an approved version is active, Confluye checks it automatically whenever a run starts and again before a material external effect. Those automatic checks do not create a new approval task for each run.

Open AI Governance

In a workspace, go to Approvals in the main navigation. You need:

• an active AIMS role for the action you want to perform;
• MFA verification completed within the last 15 minutes; and
• write access to the workspace for changes.

The page has four permanent sections:

Section, selected workflow and approval filters are retained in the URL. Back to list or Back to workflows returns to browsing. Unsaved forms ask for confirmation before leaving; discarding a form does not revoke an approval. The organization page also offers Browse organization approvals, aggregating only workspaces allowed by your current ordinary access and AIMS assignments.

Organization approval policy: Owner or independent review

Open Approvals → Configuration → Organization approval policy. Only an Organization Owner can change this organization-wide setting. It is visible before AIMS setup, so a founder does not need to invite a second administrator just to enable it. A workspace Owner or organization Admin alone cannot enable the exception.

1. Complete recent MFA verification.
2. Enter a Reason (required) of at least ten characters; it is retained in the audit trail.
3. Check the required acknowledgement and select Enable owner authorization.
4. Prepare the governed draft and request review. In Decide, the eligible Owner selects Approve and enable for their own exact version, including choosing No scheduled renewal if appropriate.
5. For a previously approved version, select Enable approved version in the workflow detail, verify the exact workflow version shown, then confirm Authorize and enable. The server derives the technical manifest from the reviewed artifact and current authority, activates governance and publishes that exact workflow version. You do not copy manifest IDs or approve it again. Enabling the organization policy itself does not approve, bind, activate or execute a workflow.

This works with one member or a larger team. The enabling Owner receives active AIMS System Owner assignments for MFA and service-token operations. It does not issue an API token, grant anyone an administrator role, or automatically grant AIMS roles to the other members. Other Owners still need an active System Owner assignment. The audit record says owner authorization, with independent: false and the organization policy revision—not an independent review or certification.

To delegate, use Role assignments to propose an AIMS role for another member, then approve that proposal in Role assignment approvals. The Owner may do both while this mode is enabled. The beneficiary cannot propose or approve their own grant. Delegates use their scoped AIMS roles; they do not gain the Owner's self-approval exception. Emergency break-glass and recovery controls retain their independent safeguards.

Independent review remains the default for existing and new organizations. Its separate-person rules are described below. Selecting Require independent review increments the policy revision and stops executions that rely on owner approvals or owner-authorized manifests. Obtain new independent decisions and a current manifest to resume those workflows. Re-enabling Owner authorization does not revive old decisions. Removing an Owner's membership or revoking their assignment also removes their owner authorization. Decisions remain as historical evidence.

Neither mode bypasses MFA, exact-version checks, approved model configuration, data rights, expiry or kill switches. Claude Code and Codex CLI use a configured-model contract: the worker checks the CLI catalog and approved configuration before sending content, then records model metadata from the response when available. This does not certify the provider's internal model before inference. The in-app Help → AI governance guide includes this policy choice; subsequent descriptions of mandatory separate reviewers apply to Independent review mode.

Create a governed draft

Pending → Prepare lists each Production destination and named preview that needs preparation. The task keeps the selected destination when you open it. If the workflow already has a governed system profile, choose Prepare destination approval, then Prepare request from the system profile. This creates a separate draft for that destination's saved version and connections. Review the draft and request approval; existing approvals do not transfer to it.

A Prepare task offers Create governed draft (this replaces the older "Register in AIMS" flat-field form) when the workflow has no governed system profile yet. It opens a four-step assistant:

1. Purpose and owner — write the intended use and the distinct prohibited uses as separate narratives, and explicitly select the accountable System Owner from the eligible people. The owner is chosen, not inferred from who is filling in the form.

2. People and data — set the controlled affected people, data classes, and jurisdictions classifications, and the impact level.

3. Autonomy and runtime profile — choose exactly one canonical autonomy option:

   • Human makes the decision — a person makes each decision; the system only assists.
   • Human approves before effect — the system proposes; a person approves before it takes effect.
   • Human supervises with stop authority — the system acts under supervision; a person can stop it.
   • Autonomous operation — the system operates without a person in the loop for individual actions.

   Providers and models are derived on the server from the saved workflow version, not typed by hand. The read-only inventory shows each source node, requested model, and resolution status. Open node opens the editor in a new tab and leaves your governance entries in place. Save the workflow, then save the corrected governance draft to bind its updated inventory. Legacy autonomy values remain readable and are not rewritten.

4. Review — confirm the summary before submitting.

Independent review mode: standard, solo draft, and quorum upgrade

With roles already provisioned, workflow approval and enablement use two people:

A: prepare and submit → B: review → Approve and enable → new event → run
                            │
                            └─ publication blocked → approval retained → Retry enabling

B needs an active AIMS Reviewer or AIMS Manager assignment, recent MFA and ordinary workflow execute access. B must differ from the system creator, accountable owner, version creator and assessment submitter. B does not need a System Owner role or an additional manifest approver/activator. The server derives the manifest from B's retained decision and rechecks B's scoped authority at runtime. Revoking or expiring that assignment blocks executions relying on this combined authorization.

With explicit Owner authorization, an eligible Organization Owner with a current System Owner assignment can perform this workflow alone. This does not change role grants: in independent mode, proposer, grant approver and beneficiary remain distinct. Risk Owner handles risk/data responsibilities; Incident Commander handles emergency stops and recovery. Neither is an extra required workflow approver.

Standard setup is a two-person, two-step exchange:

1. A different Organization Owner/Admin who is also an explicit Workspace Owner/Admin opens AI Governance, verifies MFA, and selects Create manager approval code. The code expires after five minutes. The code grants nothing by itself.
2. The Organization Owner selects that same administrator as the initial AIMS Manager, enters the code, and selects Activate AIMS governance. This creates the initial MFA and service-token System Owner and AIMS Manager assignments; it does not review or activate a workflow.

A solo draft creates only a narrow MFA System Owner seed; it cannot approve, activate, issue production service tokens, or reach production. Its later quorum upgrade is also a two-person exchange:

1. A different Organization Owner/Admin who is also an explicit Workspace Owner/Admin selects Create manager approval code and shares the five-minute code with the original solo owner.
2. The original solo owner selects that administrator, enters the code, and selects Complete independent setup. The code never activates the quorum by itself.

Role proposals, review, and owner transfer

The three-account grant rule below applies to Independent review mode. In Owner authorization mode, the Organization Owner may be both proposer and approver, but never the beneficiary of that grant.

The role management panel handles AIMS roles in the browser as the normal path:

• Role assignments propose a scoped AIMS role for a specific person. The proposer/grantor, the approver, and the beneficiary are three distinct accounts: the beneficiary can be neither the proposer nor the approver. Only a current server-authorized AIMS role can propose or approve; a workspace or organization role never grants an AIMS role by itself.
• Role assignment approvals is where a different eligible person approves or lets a role proposal expire. Workflow review decisions are separate tasks in Your governance tasks. Revocation is deliberately different: a current MFA-authenticated System Owner uses Revoke to end an active assignment directly. It does not create a proposal and does not wait for a second approver. Before applying a revocation or recording an elapsed assignment as expired, Confluye requires at least one active, effective role-grant authority to remain for the affected scope. It blocks removing the last such authority so the organization keeps a recovery path. Do not try to self-revoke the sole solo seed; complete independent setup first.
• Accountable owner transfer moves the System Owner only while the system is an untouched draft: the lifecycle and all versions remain draft, and there are zero assessments, approvals, deployment manifests, or artifact snapshots. Once any assessment, review, or deployment evidence exists, authorship is immutable. A future successor-owner process would be required, but that process is not currently available in the browser or operator workflow; a normal change draft cannot change the owner.

The change-ticketed operator CLI remains a controlled fallback for role grants, not the normal route.

Material changes and governance-only updates

Saving a new workflow version does not stop the active version. AI Governance marks the workflow as Change detected and offers Start change draft. The active version keeps running under its existing approval while the candidate moves through review.

If the active version also needs renewal, Pending → Prepare offers both Start change draft and Request renewal review. Start the change draft to review the newly saved workflow; renewal continues to target the previous immutable active version.

When the workflow definition is unchanged, an authorized owner can still start a governance-only change from an active workflow. Select Start change draft, update the governance profile, and move the candidate through the same review path. Use this for intended-use, autonomy, data-class, affected-group, or jurisdiction updates without editing the workflow graph. Provider and model changes must be made in the source workflow nodes and saved before saving the governance draft; the inventory cannot be expanded by typing an allowlist.

active v1 ───────────────────────────────► superseded
             candidate v2: draft → review → approved → active

Only one candidate may be in review or approved at a time. Before the first activation, a returned first candidate may still correct impact in this screen together with the governance profile. After the first activation, the version-change form shows impact as read-only; this screen does not provide a post-activation impact-reclassification action. Prohibited uses are also not editable in change drafts.

Changes that normally need a new candidate include a saved workflow version, intended-use or autonomy changes, new providers or models, new data classes, new affected groups, or a different jurisdiction.

Correcting a review returned for changes

When a reviewer selects Request changes, the workflow moves to Changes requested and the reviewer's rationale appears at the top of the governance actions panel. If an active version already exists, it keeps running.

1. Read the Reviewer requested changes note to understand what must be corrected.
2. Update the governance profile fields the reviewer flagged. Before the first activation, impact may also be corrected here; after the first activation, impact stays read-only in this screen.
3. Select Save corrected draft.
4. Complete the assessment summary, findings, and treatments, then select Request review.

Assessment summary is required; findings and treatments are optional. Required fields are labeled and missing values have red validation messages. A disabled review or approval action lists the known blockers for its exact version. Decision not recorded means the approval failed: correct the listed cause and refresh readiness; your rationale and renewal choice stay in the form. A technically blocked approval does not prevent an eligible independent reviewer from choosing Request changes.

An outside the allowlist error means the reviewed inventory does not cover the node's provider or model. Correct and save a draft from the actual workflow; do not edit historical approvals. For Claude Code or Codex CLI, select a fixed model on the workflow node. An imported Claude node with no stored model shows an empty required field, not a pretend default selection. Saving another field does not invent a model. The server derives its CLI provider and configured model automatically. A governed worker checks that model against its catalog, uses controlled configuration, and rechecks AIMS authority under the workspace credential lease before sending content. A model name returned by session creation alone is not validation.

The configured model, catalog-selected model and response-reported model are separate evidence. If the CLI does not report a response model, the record says not reported; it never substitutes the configured name. An unexpected reported model fails the run before downstream publication, but the inference has already occurred. This is configuration governance, not immutable model certification. Old descriptor-v1 evidence is unchanged. Save and review a successor to use the configured-model contract; updating the worker does not rewrite or approve historical records.

Updating either CLI package is a platform deployment, not a request to type version numbers into AIMS. Both web and worker must use the tested image. Model availability or configuration errors still need correction, and approval does not connect a missing subscription session or enable imported n8n code.

The same returned candidate version stays open. Resubmitting supersedes the previous assessment. Request changes belongs to a pending review. To withdraw a completed approval, use its permanent detail in Approvals & history instead; it does not rewrite the old review as a rejection.

Find, modify or revoke an approval

Open Approvals & history and use My approvals, workflow search, authority/date filters or a decision-maker ID. Choose a decision to see the recorded outcome separately from current authority and execution readiness. A recorded approval can be expired, replaced, revoked or waiting for deployment. Evidence permission controls whether names, rationale and assessment details are visible.

Modify approval starts a linked assessment for the same immutable version. Enter the required reason and assessment, submit it, then open the new review task. The eligible decision-maker chooses the new rationale and either a date or No scheduled renewal, and confirms the before/after summary. Opening, cancelling or submitting this amendment does not withdraw the current approval. Approving the replacement withdraws the old authority and its dependent manifests atomically. Enable the exact version again using the new approval; previous decisions remain readable, not editable.

Revoke approval requires a reason, current permissions, recent MFA and explicit impact confirmation. An eligible original reviewer or an actor currently authorized to suspend may revoke; having approved in the past does not preserve permission after losing a role. Revocation retires that approval and its dependent manifests. New governed starts/effects cannot use them. It does not undo effects already performed or delete logs. There is no “unrevoke”: recovery requires a fresh authorized decision.

If renewal feedback only changes assessment evidence, correct the assessment and select Request renewal review. If it requires a material profile change, use Create governance change draft; the active version and its renewal remain immutable while the new candidate follows the normal review path.

Scheduled renewal and no scheduled renewal

Thirty days before an assessment or approval expires, the page shows Renewal required. The owner or risk owner submits a fresh assessment for the same immutable version, and a different reviewer approves or returns it.

The active version's renewal is tracked independently of any successor candidate. If a draft or in-review successor already exists, the row still reports that the active version needs renewal and the governance actions panel offers a separate Renew the active version section with its own assessment summary, findings, and treatments. That submission targets the active version, not the candidate, so production authority can be renewed without waiting for the successor review to finish.

The section stays in place for the whole renewal round trip. After submission it shows the renewal awaiting an independent decision; a reviewer with an approval role decides it there with Approve and enable or Request changes, against the active version and its own renewal assessment, with a rationale and either a dated expiry or No scheduled renewal. A viewer who cannot decide sees the awaiting-review state and no renewal evidence. If the reviewer requests changes, the separate renewal section shows that renewal's rationale (or a redacted notice when the viewer cannot read evidence) and returns to the submission form so the owner can resubmit. Candidate review is unaffected and continues to target the candidate. The section is hidden when the renewal is already the panel's primary action, and while an approved renewal is awaiting enablement. The existing unexpired assessment, approval, and manifest remain authoritative during review. The Reviewer or Manager who approved can enable the replacement, including retrying a partial failure; that atomic switch supersedes the old manifest while retaining the earlier assessment and approval as immutable history. A renewal does not ask users to approve each execution and does not change workflow content. If renewal starts only after expiry, production remains fail-closed until the refreshed manifest is ready.

If the reviewer selects No scheduled renewal, the approval stores that explicit policy and has no calendar expiry, so the date input disappears and the Renewal required window does not appear. An older null-expiry record without that policy does not count as permanent authority. Even without a scheduled renewal, authority can still end when a material workflow or governance change creates a new candidate, data rights expire, an artifact is revoked, evidence is superseded, or the kill switch is activated.

Current governance notices

Open Notifications → Current AI governance work to see work allowed by your current AIMS assignment and recent MFA. Open governance notice opens the exact task and rechecks its version before showing a form. Technical blockers appear with the selected task. Load more governance notices reaches additional tasks; a direct link does not depend on the first page.

These are current obligations, not archivable messages. Mark all read and archive actions apply only to ordinary notifications. A resolved or revised notice stops offering the old action and links to approval history. Recent approval activity lists retained decisions and withdrawals with View recorded decision links. A missing role or expired MFA does not reveal the task's title or evidence. Opening a notice never submits or approves anything automatically.

Roles and separation of duties

A workspace role such as Admin, and an organization Owner or Admin, do not automatically grant an AIMS role. The browser role management panel — or, as a controlled fallback, an operator — provisions the scoped AIMS assignment through the two-person proposal-and-approval process.

Activation and deployment authorization

Approval records a decision; enabling makes the exact approved workflow available to triggers. These are separate safety checks but do not require manually re-entering the technical inventory.

Save workflow → Review derived draft → Approve and enable → New event → Run

For an existing approval, open Workflows → Open governance → Enable approved version, or Pending → Blocked → Review production requirements. Recent MFA, a current System Owner assignment, ordinary workflow execute access and current organization Owner authority are checked for the Owner path. In independent mode, the Reviewer or Manager who made the decision uses their current scoped MFA assignment. The confirmation names both the workflow version and governance version (their numbers may differ), and the selected production or preview destination when the workflow uses Versions & previews. It builds a hash-bound manifest from retained evidence, activates governance and publishes only that approved workflow version through the normal deployment checks. It never turns on Owner authorization or clears an emergency stop automatically. Open approval policy leads to the actual configuration.

If authorization succeeds but deployment fails (for example, missing CLI login or Git review), the message says so and offers Retry enabling. Correct the displayed requirement first; do not approve again. If the saved workflow has changed since review, review the latest version first. Stale confirmation dialogs cannot authorize a different version after a refresh.

In Independent review, select Approve and enable in the review form after entering a rationale and choosing dated renewal or No scheduled renewal. This authorizes the workflow's approved external actions for new events. Approval is retained even if a later requirement prevents deployment. Use Workflows → Open governance to inspect the result and retry enabling, without requesting another review. Legacy operator CLI/API manifests retain their separate-person checks; they are not the normal browser enablement path and are not silently rewritten.

For GitHub review, a webhook returning 202 means the event was accepted, not that a review was posted. Enabling promotes the approved workflow instead of leaving an older version deployed. Previously failed deliveries are not automatically replayed. After enabling, send a new pull-request event and check its run and GitHub review. Approval, deployment, credentials, webhook configuration and worker availability must all be healthy; this screen does not claim that publication itself ran the review.

Workflow destinations and rollback

Each workflow destination has its own reviewed version, connection references and exact child activations. Approval of a preview never approves production, including when both use the same workflow version. A changed candidate or connection configuration needs matching review before publication; the already deployed activation retains its own authority while that review is pending. The Workflows registry and approval history show the destination name alongside the workflow. Opening a decision keeps its governed version and destination selected; approval history distinguishes a current decision from a destination that is actually deployed with that authority.

Preparing a promotion copies the deployed preview's version into production's candidate. It preserves production's connection choices and the selected choice to stop or keep the source preview. From the production review, Approve and enable uses those same publication checks and applies the source-stop choice only when publication succeeds. An approved decision remains available if publication is blocked.

When preparing production connections, Request approval for future reactivation of this production snapshot explicitly includes rollback in the reviewed scope. A later Restore deployment rechecks that snapshot's current grant, connections, child activations and Git evidence before creating a new production activation. Revocation, expiry or an unavailable connection blocks it. Approval never grants an unrestricted ability to restore arbitrary historical versions. Restoration preserves production's webhook URL and prevents the replaced generation's pending executions from resuming; effects already sent externally cannot be undone.

If the old snapshot needs a new grant, use Prepare rollback approval or Request new approval in production's deployment history. This prepares the old version and connection references in a separate rollback request without replacing the running version or editor candidate. The new scope follows the same roles, MFA and independent-review rules as any other production publication. It must be approved before publication can cut over production.

Legacy activation compatibility

For workflows using legacy manifests, activation makes the reviewed governance version current. If the previous workflow version is still deployed, it continues to pass runtime governance checks under its own unexpired manifest while the new workflow version is promoted. That predecessor is identified by exact manifest identity first: the approved, never-superseded production manifests for this system, environment, and the workflow's own active version. Several governance generations can have governed that same deployed version, each keeping its own manifest, so the authority is the last of them — the greatest supersession timestamp within that exact set. Supersession order is never consulted across workflow versions. Execution start and every external effect resolve it the same way. If no such manifest exists the runtime fails closed with approved_manifest_missing; if two of them tie for last it fails closed with superseded_manifest_ambiguous.

The overlap is closed in the same transaction that moves the workflow to the new version: the predecessor's approved manifest becomes superseded evidence at that moment. Pointing the workflow back at the older version later therefore does not restore the older governance — a rollback needs its own newly approved manifest, exactly like any other deployment. Once deployment switches the workflow, only the new current version qualifies. This ordering avoids an authorization gap during the cutover.

The Owner and independent-review browser actions share the same retained manifest and execution checks. See the AIMS operator API for the service-token flow.

If an action is blocked

• Recent authentication required — choose Verify MFA to authenticate in a dialog without leaving AI Governance. Your draft remains open when you cancel or verify. Invalid codes can be retried inside the dialog. Verification refreshes access but never submits or approves the draft automatically; review it and explicitly retry your action. First-time enrollment includes saving recovery codes. If enrollment requires a fresh primary sign-in, save your work before signing out.
• Role assignment required — ask an AIMS manager to provision the appropriate scoped role.
• Different authorized person required — separation of duties applies; another eligible person must perform the decision.
• Change already in review — resolve the current candidate's activation blockers and activate it, or finish the in-flight review before starting a new governance change.
• Profile changed before submission — the page refreshes the governance row and asks you to review the latest version before submitting; this prevents an assessment from being attributed to content you did not see.
• System suspended or retired — governance drafts and review decisions remain frozen until an authorized operator recovers a suspended system. Retired systems stay closed.
• Activation is disabled — open Review production requirements. The Reviewer or Manager who approved the version can enable it; an eligible Owner may do so under explicit Owner authorization. No extra operator is required.
• Production is blocked — verify the approved deployment manifest, current data rights, assessment expiry, approvals, and kill switch.