What leaders approve

Most of a migration job runs without ceremony: assessments record, conversions start, transfers checkpoint, and validation runs execute as ordinary work. A small number of moments are different. They change what the organization is committed to, and Airlift requires a named human being — never an agent, never a script — to make each one through a governed Platform action.

This page covers the common leader decisions. For the canonical action and permission catalog, full role model, principal types, and tenant configuration, see roles and separation of duties.

Common human-only decisions

One adjacent moment is deliberately not a human decision: certificate minting. A migration certificate is system-minted from independently admitted evidence once policy thresholds are met. No person authors or edits a certificate payload — a leader cannot mint one by hand, and neither can an agent. The leader's job is the business acceptance and cutover decisions around the certificate, not the certificate itself.

How a decision appears in the App

A decision card renders only when policy actually requires a human, and it answers the same four questions as every other guidance surface: what this decision commits to, why it is required now, who may make it, and what evidence it is based on. There is one primary action per card. The App never shows a leader a form asking for a digest, an idempotency key, or a raw action name — the button on the card invokes the same governed Platform action the CLI invokes.

View full size

Separation of duties is enforced, not suggested

Approval authority is checked again at execution time, and it is independent of submission authority:

• Distinct approvers. Waivers and go-live approvals require a second, distinct natural person. The requester cannot approve their own waiver; the person who submits a cutover cannot be its only approver.
• A resolver cannot review the same case. The person who repaired a residue case never reviews it; review belongs to a different authorized person.
• No inherited approval. An agent, converter, worker, or submitter cannot manufacture or inherit a natural person's approval from a workflow signal, a form field, or a CLI flag. Approval exists only as governed Platform state recorded by that person.
• Automation is bounded operationally. The automation role may record or execute explicitly cataloged assessment, inventory, planning, transfer, validation, discrepancy, observation, and evidence work. It never carries approval, waiver, certificate, policy, membership, or cutover-execution authority. The exact list is machine-checked in organization membership.

Agents never decide

The agent boundary is absolute and worth stating plainly: a bounded Harness agent may record assessments and objects, propose dependency graphs and plans, and start and record conversions. It cannot approve, certify, waive, execute cutover, and it cannot deploy. Agents also never accept assessment or dependency truth, select or freeze plans, submit readiness evidence, accept on behalf of the business, mint or invalidate certificates, roll back a cutover, or configure policy — and nothing in the App, the CLI, or an AI assistant gives an agent an alternative mutation path around these rules.

When an assistant explains a decision card to you, it reads the same deterministic guidance you do. It may summarize and link; it may never invent a different next action or make the decision for you.

Use the CLI with the same truth

Leaders who prefer the terminal exercise the exact same governed actions — there is no lighter-weight approval path in the CLI:

fa plan freeze <plan-id> --idempotency-key plan-freeze-<plan-id> --json
fa cutover approve <wave-id> --idempotency-key cutover-approval-<wave-id> --json
fa cutover start <wave-id> \
  --window 2030-01-15T02:00:00Z/2030-01-15T04:00:00Z \
  --reason "Approved production change window" \
  --json

Scope acceptance, wave approval, waivers, and business acceptance are exercised from the decision cards in the App; every one of them records the same governed Platform action with the same actor and evidence. The App and fa read the same projections, so an approval made in one surface is immediately visible in the other, with the same actor, evidence, and audit record.

Where to go deeper

• Roles and separation of duties — the five tenant roles, worker and agent principal lanes, and independent approval checks.
• Waivers and staleness — waiver expiry, evidence freshness, and what a waiver can never cover.
• Cutover control room — the go-live ceremony, the cutover gate, and rollback.
• When something fails — the Fix list work that precedes most waiver requests.

Trust & certificates

Two reference pages close the loop on what these approvals protect:

• Parity and migration certificates — what a signed certificate actually claims, the evidence depth it was minted from, and how to verify it offline.
• Security model — the identity, tenancy, evidence, and external-effect boundaries every approval on this page is enforced through.