Transports: approved changes between environments

Overview

Code reaches production through Git and CI. AI artifacts usually do not: a prompt, a model choice or a guardrail setting is often changed directly in production, with no approval, history or way back.

Govern → Transports (/compliance/transports) closes that gap. It works like a change transport in SAP:

1. You bundle changes made in one environment, such as staging, into a transport.
2. A second person approves or rejects it.
3. Somebody with the permission releases it into the target environment, such as production.
4. If it goes wrong, you roll it back.

Every item keeps the target’s state before the change and the state the release puts in place. The diff, the release and the rollback all work from exactly what was approved. Each step is recorded in the audit log, and each transport counts as evidence for ISO/IEC 42001 control A.6.2.5 (deployment planning and change control).

Note

Transports move changes between the environments of one project (Organisation → Project → Environment). An environment is a project’s database configuration for that environment name, such as development, staging or production.

What a transport can carry

Artifact	What is transported	How a release applies it
Prompt (Prompt Hub)	The version of a prompt the source environment serves	Makes sure the version exists in the target’s Prompt Hub, copying it if the target uses a separate database, then pins the target to it
Approved-model list	The environment’s list of approved providers and models	Saves the list for the target environment, as the governance page does
Guardrail and enforcement policy	The environment’s overrides of the organisation’s enforcement policy	Saves the overrides for the target, recorded as a policy version with the transport’s reference as its comment

Prompt pins

An application that asks Prompt Hub for a prompt without naming a version normally gets the latest published version. Once a transport is released into an environment, that environment is pinned: applications using that environment’s API key get the transported version until another transport, or a rollback, moves the pin. Applications that name a version explicitly still get that version.

An environment that has never received a transport behaves exactly as before.

Tip

In a cloud project, all environments share one Prompt Hub database. A newly published version therefore reaches every unpinned environment at once. The create form lists a prompt the target serves unpinned at the same version as pin at <version>. Transport it once to put the target under transport control. From then on, new versions reach it only through a transport.

Statuses

Status	Meaning	Next steps
Draft	Put together, not yet submitted	Submit (requester)
Awaiting approval	Submitted	Approve or reject (a manager who is not the requester); withdraw to draft (requester)
Approved	Approved by a second person	Release (a manager)
Rejected	Rejected with a reason	None. A new attempt is a new transport
Released	Applied to the target	Roll back with a reason (a manager)
Rolled back	The target’s earlier state was restored	None

Who can do what

Permission	Allows	Held by
transports.read (View transports)	See the project’s transports, their diffs, impact and history	Administrators, compliance officers, analysts, members, viewers, and Auditors for their own environment
transports.request (Request transports)	Put a transport together, submit it and withdraw your own	Administrators and analysts
transports.manage (Approve and release transports)	Approve, reject, release and roll back	Administrators and compliance officers

Nobody can approve or reject their own transport, whatever their role. The server refuses it, and the refusal is audited. Releasing and rolling back apply what a second person has already approved, so the approver, or a requester who holds the manage permission, may run them. The release records who ran it.

Auditors read the list and each transport, including its diff, timeline and release log. They do not see the impact panel, because it reads telemetry and costs.

Create a transport

Open Govern → Transports

Select New transport. If the project has only one environment you can use, the page explains that a second environment is needed. Add one under Settings → Database configuration (one configuration per environment).

Choose the source and target

Shield360 lists the changes not yet transported: each prompt the source serves at a different version, the approved-model list and the policy overrides wherever they differ.

Pick the changes, give it a title, and submit

The server reads both environments again when you save. The snapshots are never taken from your browser. An item that would change nothing is refused.

Review, release and roll back

The transport’s page shows, for each item:

• Diff: the prompt text line by line, the providers and models added to or removed from the list, or each policy setting before and after. Secret-looking policy values are masked.
• Impact in the target environment over the last 7 days:
  • which services call a model whose approval changes, and which API keys fetched the prompt through the SDK;
  • for an approved-model change, the estimated cost impact: the per-call price difference between the model leaving the list and the one joining it, multiplied by the last 7 days’ calls and scaled to a month;
  • the latest agent test run against the prompt version;
  • the number of enrolled computers a policy change reaches.
• Timeline of every step, and the release log of what each release or rollback did to each item.

A release first reads the target’s current state for every item:

• An item already in the approved state is skipped. Running a release again is safe, and a release that stopped part way is finished by running it again.
• An item still in the “before” state is applied.
• If anything else is found, someone changed the target by other means since the transport was made. Nothing is written, and you make a new transport from the current state.

Rollback works the same way in reverse. A change freeze in force stops releases and rollbacks too.

Evidence

Each environment’s controls include the check Changes to AI artifacts are released through approved transports (transports.controlled), mapped to ISO/IEC 42001 A.6.2.5. It counts the transports into or out of the environment. It is a gap when a release had no decision by somebody other than its requester, or when a transport has waited more than 14 days for approval. It is not applicable until the environment has a transport.

Evidence packages include transports.json and transports.csv, and a Transports between environments section in the report. These list each transport with a step in the period: its route, status, item types, requester and approver (user ids), whether a second person approved it, and when each step happened. Titles, descriptions, reasons and prompt text are not included.

Data kept

A transport keeps its title, description, reasons and the before and after snapshots of each item, including prompt template text. Prompt templates are your organisation’s configuration, not content from monitored people. The audit log records ids, statuses, artifact types and outcome codes only, never titles, reasons or snapshot content.

API

All routes act on the project of the environment you have selected.

Method and path	Permission	Does
GET /api/governance/transports?status=	transports.read	The project’s transports, counts and your environments
POST /api/governance/transports	transports.request	Create: { title, description?, sourceDatabaseConfigId, targetDatabaseConfigId, items: [{ artifactType, artifactKey }], submit? }
GET /api/governance/transports/changes?source=&target=	transports.read	Changes not yet transported between two environments
GET /api/governance/transports/<id>	transports.read	One transport with items, steps and release log
PATCH /api/governance/transports/<id>	transports.request	{ action: "submit" } or { action: "withdraw" }
POST /api/governance/transports/<id>/review	transports.manage	{ action: "approve", reason? }, { action: "reject", reason }, { action: "release" } or { action: "rollback", reason }
GET /api/governance/transports/<id>/impact	transports.read	Where used, cost impact and evaluation, read live

artifactType is prompt (with the prompt’s name as artifactKey), approved_models or enforcement_policy.

Enforcement policy

The organisation’s policy and each environment’s overrides

Controls

How evidence checks back framework controls

Evidence packages

Signed evidence for auditors