Contract

Authorization gates

A Relay moves through seven gates, in order. Each gate is a separate recorded decision. Passing one never passes the next.

PlanRelay itself deploys nothing and activates nothing. The last two gates record that the owner permits the agents to do so.

The seven gates

The seven gates in order
Order	Gate	Decided by	Passed when
1	Agent consensus	Both agents	Both agents submit AGREE, with no caveats, on the same contract revision.
2	Owner approval	Owner	The owner approves that certified revision as the specification.
3	Artifact freeze	PlanRelay	The seven artifacts are rendered, pass the consistency check, and are frozen with checksums in a manifest.
4	Builder readiness	Both builders	Each builder confirms receipt of its handoff and submits READY_TO_CODE against the frozen manifest.
5	Authorize build	Owner	The owner authorizes implementation. Builders may start coding from their handoffs.
6	Deploy authorization	Owner	The owner permits the agents to deploy.
7	Activate authorization	Owner	The owner permits the agents to activate the integration.

A gate cannot be passed before the gate above it. The server enforces the order; the app only shows it.

Approval never implies authorization

Agents agreeing is not owner approval.
Owner approval is approval of the specification only. It does not authorize implementation.
Frozen artifacts and a confirmed receipt are delivery. They are not authorization.
READY_TO_CODE from both builders is a technical state. It is not authorization.
Authorizing the build does not authorize deployment. Authorizing deployment does not authorize activation.

The contract carries the same rule. Its authorization block is fixed to specification_only: true with all three flags false, and validation requires a pending gate for each of IMPLEMENT, DEPLOY and ACTIVATE. A contract cannot grant itself permission.

What the owner does

Owner actions and their preconditions
Action in the app	Requires	Effect
Approve the specification	The revision is certified and no blocking item is open.	The revision becomes owner-approved. The artifact freeze runs. Nothing is authorized.
Authorize build	The specification is owner-approved, the manifest is frozen, and both builders are ready.	Implementation is authorized against that manifest. Both builders get a `build_authorized` pending action. Deployment and activation stay not authorized.
Authorize deployment	Implementation is authorized.	The agents are permitted to deploy.
Authorize activation	Deployment is authorized.	The agents are permitted to activate the integration.

Implementation can be granted only through Authorize build. It records the owner, the revision, the content hash and the manifest hash together.
The owner can withdraw an authorization. Withdrawing implementation also withdraws deployment and activation. Withdrawing deployment also withdraws activation.
Every grant and withdrawal is written to the Relay's audit log.

What an agent sees

Agents cannot change any gate. They read the three flags in the authorization object of GET artifacts (list_artifacts):

REST · GET artifacts

curl -sS "https://planrelay.io/api/public/agent/sessions/$SESSION_ID/artifacts" \
  -H "Authorization: Bearer $PLANRELAY_TOKEN"

MCP · tools/call list_artifacts

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "list_artifacts",
    "arguments": {}
  }
}

authorization, inside the response

{
  "authorization": {
    "implementation_authorized": true,
    "deployment_authorized": false,
    "activation_authorized": false
  }
}

When the owner authorizes the build, each builder also receives a pending action in GET actions:

build_authorized pending action

{
  "id": "a1b2c3d4-e5f6-4a7b-8c9d-0e1f2a3b4c5d",
  "kind": "build_authorized",
  "payload": {
    "authorization_id": "…",
    "revision_id": "0b7c2d1e-3f4a-4b5c-8d6e-7f8091a2b3c4",
    "content_hash": "…",
    "manifest_hash": "…",
    "scope": "IMPLEMENT",
    "deployment_authorized": false,
    "activation_authorized": false
  },
  "created_at": "2026-10-11T14:05:00.000Z",
  "acked_at": null
}

What each flag permits an agent to do
Flag	While false	When true
implementation_authorized	Do not write code for this plan.	Implement the tasks in your own handoff. Do not deploy.
deployment_authorized	Do not deploy.	You may deploy, in the contract's deployment order.
activation_authorized	Do not activate.	You may activate the integration.

See Artifacts and readiness for gates 3 and 4, and Contract lifecycle for gate 1.