Documentation

14 of 187 pages

Organisation Portal

Guardrail Policies

A guardrail policy is the floor your organisation puts under every linked AI Product Studio: the Definition of Ready and Done items each work package must carry, the rules a release must meet, and whether two different people must decide. Studios can tighten it; they cannot loosen it.

Enterprise. Creating, editing and activating a policy needs an Enterprise contract. Everything else keeps working without one — reading policies, retiring one, the exceptions register, and the policy already applied to your studios’ work packages — so a lapsed contract never strands work in flight.

Draft, activate, version

Open Organisation → Guardrail Policies. A policy is a draft you can edit. Activate freezes it as the next numbered version, and from then on every new work package in every linked studio is created under that version. One policy is active at a time.

A version never changes. Editing an active policy edits its draft; activating again makes the next version.
Work packages keep the version they were created under. A new version does not rewrite existing packages. A studio’s owner can move one package onto the current version from its Passport, before it is dispatched; doing so invalidates its gate evidence.
Retiring removes the floor for new work packages and is the organisation owner’s. A retired policy cannot be activated again; its versions stay, because passports cite them.

Editing, activating and retiring ask you to sign in again, and every change is in the organisation audit log, item by item.

Write your first policy, step by step

  1. Create your reviewer roles first. Under Organisation reviewer roles on the Guardrail Policies page, add the roles your items will name — for example Security lead and Peer reviewer. An item’s human side names one of these, or any human in the loop.
  2. Start a draft and add a few items. Five to ten is a sensible first policy. For each: whether it belongs to the Definition of Ready or the Definition of Done, its agent reviewer, its human reviewer role, and the controls it is evidence for.
  3. Decide how much a studio may add.Tighten allowed lets a studio add a reviewer or a control to the item; Locked lets it add nothing. No studio can remove or weaken an item either way.
  4. Set the release rules you need, and leave the rest off.
  5. Set the exception rules: whether exceptions are allowed, the most days an item may stay under exception in all, and which roles may grant one.
  6. Leave separation of duties and four-eyes on change off unless you have the people for them. Both can be turned on later.
  7. Activate. You are asked to sign in again. The draft is frozen as version 1.
  8. Check Coverage. Each linked studio must say which of its own roles answers for each of yours, on its Human Roles page. Until it does, that role is held by nobody there and its items cannot be approved. Coverage shows which studios have not.
Nothing changes for work already under way. Work packages that exist keep the rules they were created under. Only work packages created after activation carry the new version.

How the items then behave in a studio — the gates, the evidence and the passport — is in the Studio guide, starting at Start Here: Guardrails to Passport.

Items

Each item is a Definition of Ready or Definition of Done check, always required, with an agent reviewer, a human reviewer, or both, and the controls it is evidence for. In a linked studio the organisation’s items appear first on every new work package, marked with a lock and the version they come from.

Tighten allowed — a studio may add a reviewer or a control to the item on a work package.
Locked — a studio may add nothing to it.
Never — a studio cannot remove an organisation item, reword it, make it optional, or take a reviewer or a control off it.

Organisation reviewer roles

An item’s human side names one of your organisation’s reviewer roles, or any human in the loop. Each studio maps your roles to its own on its Human Roles page. A role a studio has not mapped is held by nobody there, so its items cannot be approved until the studio maps it.

Must be a named role. A studio may answer one of your roles with “any human in the loop”, which lets every member there approve. Switch this on for a role to forbid that. It is off by default, it is the organisation owner’s to change, and it applies at once — a studio already answering the role that way cannot approve that role’s items or releases until it names a role.

Release rules

Require CI success — every work package’s pull request head must have passing CI, read from GitHub at approval and again at release. A failure, an unfinished check, no checks at all or a result that cannot be read all refuse.
Required reviewer roles — organisation roles the release approver must hold.
DPIA for AI-built releases — always required by the platform; a policy cannot relax it.

Separation of duties

By default a policy leaves this to each studio. It can instead require that two different people decide the two sides of a gate, or the two sides of each item as well. A policy can require separation; it can never switch off a studio’s own.

Four-eyes on changes to the policy itself is a separate option, off by default: with it on, a person who edited the policy since it was last activated cannot be the one to activate it. A lone owner who turns it on can only leave it by retiring the policy — the page says so next to the option.

Exceptions

A policy says whether a studio may take an exception to one of its items, how long an item may stay under exception, and which of your roles may grant one. An exception to an organisation item always has an expiry, and once it runs out the item is unmet again. Every exception appears in the Exceptions Register.

The limit is in all, from the first exception. The number of days is the item’s total time under exception on a work package, counted from the first exception to it. A renewal does not start it afresh, and nor does an exception granted again after the package changed. When it is used up the item must be met.
Named roles bind everyone in the studio, its owner included. With roles named, only someone who holds one may grant, renew or waive — or override the reviewer agents on a gate holding one of your items. A studio owner who holds none cannot. A role nobody holds refuses; it never falls back to the owner.
Two things to know. Each studio’s owner decides who holds a role in their studio, so an owner can hold the role themselves — the register says so when they grant. And activating a new version of the policy starts a new count for work packages moved onto it; the register marks an exception whose time limit was restarted that way.

Coverage

The Coverage table shows which linked studios apply which version, which of your roles each has not mapped, which it answers with any human in the loop, and any studio whose link is no longer sound. Who holds your roles here shows, for each studio, the studio role each of your roles is mapped to, how many people hold it, and whether the studio’s owner is one of them. You do not choose those people — each studio maps its own — but you can see who it chose.

Studios and the organisation link

A studio cannot unlink itself. Once a studio belongs to an organisation, nobody in the studio can remove or change that — whatever their role, and whether or not a policy is active.
Releasing a studio is done from the organisation, by its owner or any of its administrators, from the Coverage table, with a fresh sign-in and a written reason kept in the audit log of both the studio and the organisation. An administrator cannot release a studio they own themselves — another administrator, or the organisation’s owner, does. The studio leaves the organisation and its structure; new work packages there get no organisation items; work packages already created keep the version they were born under.
A studio whose owner has left the organisation is not sent the policy, and its new work packages are on hold rather than created without your items. Add the owner back, or release the studio.
Only the owner makes an administrator. Because any administrator can release a studio, only the organisation’s owner adds one, sends an invitation (and an invitation is accepted only if the current owner sent it), or issues the SCIM token whose OrgAdmin group may grant the role. Removing another administrator is the owner’s too; an administrator can remove themselves. Every way of becoming one is in the organisation audit log.

Studios with no organisation

Nothing here applies to them. A studio that belongs to no organisation keeps its own checklists, its evidence ledger, its passports and its exceptions, and nothing in it needs two people.

All Organisation Portal documentation

Build v0.3.2 · deployed 2026-10-19T23:52:31Z