45 of 187 pages

AI Product Studio

Studio Getting Started

AI Product Studio

Guardrails, Evidence & Passport

Artefact Passport & Evidence Ledger

The Passport is the evidence record for one work package or one release: every check, every decision and every exception, with what each was based on. It is read from an append-only evidence ledger that the Studio writes as each thing happens, and it is read-only.

Where to find it

On a work package — the Passport tab. On the one-page view, choose Show the passport.

On a release — once the release has been approved, Show the passport on the Release plan.

Anyone in the studio can read a passport. Refresh reads it again; Download JSON saves it exactly as the server assembled it. Reading it changes nothing.

What you read this way is the live view: assembled afresh each time, and not itself signed. The signed passports — the same record frozen at one moment and signed — are listed in their own section, Signed passports and sharing. See Signed passports below.

Reading it at a glance

The reading at the top — one of Ready, Attention needed, Not ready or Unknown. It is a summary of what the record says, not a decision: Ready means every gate on the record has passed and nothing on it needs a look; Unknown means part of the record could not be read, and is never rounded up.

The identity page — the artefact, its version, the studio, the policy it answers to, whether a signed version has been issued, and the agents that built it. The strip of letters beneath it is decoration; every value in it is stated above it.

Stamps and counts — a stamp for each gate (passed, not passed, or passed with an exception in force) and counts of controls, exceptions, evidence entries and gaps. Each opens the section behind it.

Sections — the detail stays closed until you open it. Attention comes first and opens by itself when something is unmet, expired, unknown or missing. Expand all opens everything, and printing does the same.

The evidence ledger

Each work package and each release has its own ledger. An entry is added in the same moment as the thing it records — an agent’s assessment, a person’s decision, an exception, an invalidation, a release approval, a DPIA approval, the CI results read when a “reads the PR” item was assessed, the run that produced a pull request head. Nothing is filled in afterwards.

Entries cannot be edited or removed by the application. Each one carries a fingerprint of the record it came from and of the entry before it, so the entries form a chain: take one out, or change one, and the chain no longer joins up.

Reading the lines at the top

Under the identity page, a passport tells you how far to trust it.

Chain intact — every entry follows the one before it. The line adds not signed yet, and the words are chosen with care: an intact chain shows that no entry was dropped or altered on its own, but the live view is not signed, so on its own it is not proof to someone outside your studio. A signed version is.

Chain broken — an entry is missing or was changed after it was written. The line says where. Raise it with support.

Entries that no longer match their source — the record an entry was taken from now reads differently. Worth a question.

On the records but not yet in the ledger — something was saved and its evidence was not recorded at the time (see the notice below). The next change to that record adds it.

Recorded late — an entry was written well after its event. It is evidence that the event is on record, attested later rather than at the time. A work package older than the ledger shows its whole earlier history this way.

Lost — an event could not be recorded when it happened and the record has since moved on, so the ledger never will hold it. The passport keeps saying so; that is deliberate.

“Saved — but its evidence could not be recorded”

Very occasionally a save succeeds and the ledger cannot be written at that moment. You see a notice saying exactly that. Your change is saved — nothing was rolled back and nothing needs doing again. The gap itself is put on record, and the missing evidence is added the next time that record changes.

Do not repeat the action to “make sure”. A decision recorded twice is two decisions. If you want to check, open the Passport: it lists anything still waiting to be recorded.

The studio’s owner is also told, by a banner at the top of every Studio page. See When Evidence Is Not Recorded.

What a passport holds

Exceptions — every waived item and every override of the reviewer agents, as In force, Expired or Voided, with its expiry, who granted it and under which authority. See Gate Exceptions.

Policy — which organisation guardrail policy version the package was created under, or that none applies. If the organisation has since activated a newer version, the passport says so, and the studio owner can move the package onto it from here — which invalidates its gate evidence, because the rules changed.

Controls — each control the checklist items name, and where it stands. See below.

Gates — the Definition of Ready and the Definition of Done: every item, both sides, the evidence behind each, the verdicts.

Provenance — for each pull request head, the runner and model that produced it and who started the run, where the Studio published that head itself. It also names the agent the run ran as, the GitHub account the commit was made as, and the account GitHub names as the pull request’s author — each shown as unknown where it was not recorded. A head someone else pushed is shown as seen, with its producer unknown — the passport does not guess, and never credits a head to an agent because of a runner’s name.

CI — the check runs and commit statuses at the head that was assessed.

What this passport does not know — in words. That no deployment has been reported, a control no item names, a ledger that was only partly read.

A release’s passport adds its readiness check, who approved it, the DPIA it relied on, comms approvals and any rollback, and lists each work package with its approved head, CI and provenance.

Sample review — where your organisation samples completed work: whether this package was picked and what the reviewer found. Shown for information; it is never counted against the artefact.

Bills of materials — on a release: each one a pipeline reported, by commit, format and fingerprint. Where your organisation requires one, each package has a required row in the release gate that reads met, not met or unknown.

Legal hold — whether one is in force, who placed it and when, as it stood when the passport was made. Never the reason.

These three are described in Sample Reviews, Holds and SBOMs.

The words a passport uses

Where	Word	Meaning
Chain	Intact — not signed yet	No entry was dropped or altered. The live view is not signed
Chain	Broken	An entry is missing or was changed
Signed version	Signature verified	A published key signed exactly this record
Signed version	Signature not valid	It was not. Do not rely on it
Signed version	Not checked yet	Nobody has asked the verifier yet
Exception	In force	The item counts as waived
Exception	Expired	Its time ran out; the item is unmet
Exception	Voided	A change, a new decision or a renewal cut it short
Control	Satisfied, Waived, Not satisfied, Not needed, Unknown	See Controls in this article
Provenance	Produced by	The Studio published this head itself and knows what made it
Provenance	Seen	A head on the pull request the Studio did not publish
Anywhere	Unknown	The record does not say. It is never rounded up to a pass
Evidence	Recorded late; Lost	Written well after the event; or never recordable. See When Evidence Is Not Recorded

Controls

A Definition of Ready or Done item can name the controls it is evidence for. On Work Package Checklists, open an item and use Controls: choose a framework and then a control — ISO 27001:2022 (A.8.25 to A.8.32), SOC 2 (CC8.1 and the criteria around change), NIST SSDF, SLSA build levels — or choose Custom and give your own reference. An item can name up to ten. The seed checklists come mapped already. Owners and reviewers change them, and every change is in the studio audit.

The passport then shows each control once, at the worst of the items that cite it:

Satisfied — every item citing it is met, with evidence in the ledger for this version of the package.

Waived — an item citing it stands on an exception that is in force.

Not satisfied — an item is not met, or its exception has expired or been voided.

Not needed — every item citing it was found not needed for this change.

Unknown — an item is still pending, or was decided on an earlier version, or reads as met with no evidence in the ledger behind it.

Unknown is never shown as satisfied. A control with nothing in the ledger behind it stays Unknown however the item reads. And changing which controls an item names on a work package is a material change: the gate evidence taken under the old mapping is invalidated, because the passport would otherwise claim it proved something it was never judged against.

Signed passports

A signed passport is the Passport frozen at one moment and signed with the platform’s key, so that someone outside the Studio can check it with the published public key alone. Approving a release issues one, in the same step. A studio owner or admin can also issue one at any time with Issue a signed passport, for a release that has been approved or for a work package — a lone owner does it alone.

Each issue is a new version, and none is ever rewritten. Reopening a release and approving it again issues the next version; the earlier ones stay as issued and still verify. The version the current approval rests on is marked.

What the list tells you — who issued each version, and what the verifier says about its signature: Signature verified, Signature not valid, or Not checked yet until you ask.

A good signature is not a clean bill. The signature says the record is exactly as issued. What the record says — an item unmet, a control unknown, an exception that has run out since — is reported beside it, and is never hidden by a valid signature.

Downloads — .dsse, the signed file to verify; .json, the exact body that was signed; .html, the same record as a page to read.

Sharing — the studio owner can share one version with a link that works for 1 to 30 days and can be revoked. The link is shown once. Whoever holds it sees that passport, with the verifier’s answer at the moment they look.

If signing did not complete when a release was approved, the approval stands. The page says no signed passport was issued for it and offers to issue one.

Verifying one outside the Studio

An auditor needs the .dsse file and the public keys, which are published. Verify one outside the Studio on the list gives the command for a small offline script; the same check is available as a public endpoint, and the file is a standard signed in-toto statement, so standard tooling reads it too. The check uses only the file and the published keys — it never asks the Studio whether the passport is real.

An exception that was in force when a passport was issued carries its expiry inside the signed record, and every check judges it against the day it is run: once the expiry has passed, the passport no longer clears, with no new version needed.

Deployments

A deployment pipeline can tell the Studio where a release went. On Repositories, the studio owner creates a deploy token for a repository: it is shown once, the Studio keeps only a hash of it, and it can report deployments of that repository’s releases, and read the signed passport of a release that carries that repository’s commits, and do nothing else — it is not the repository’s access token and cannot read the repository or the rest of the studio. The panel gives the command to run after a deploy. Each report — environment, commit, workflow run, time, or a rollback — is listed on the release and recorded in its evidence ledger. A report for a commit the release’s signed passport does not cover is refused. Reports are evidence; they do not change the release’s status.

The passport check in a pipeline

Pipelines the Studio creates (Repositories → DevOps → Create, GitHub Actions) check the passport for you. Every deploy waits for a passport-check job: it finds the release that covers the commit being deployed, fetches its signed passport and verifies it on GitHub’s runner with the published keys — the signature, that the commit is one the passport covers, that nothing is unmet, and that no exception has run out. The verifier is written into the workflow and compared with its hash before it runs; nothing is downloaded.

Enforce or warn — the studio owner chooses for each environment before the pull request is opened. Enforce holds the deploy when the check does not pass; Warn only lets it continue and says what is wrong. The proposal is to enforce production and warn in dev, because a push to dev usually deploys before its release is approved. The pull request says which was chosen.

The secret — add the repository’s deploy token to GitHub as a repository secret named PW_DEPLOY_TOKEN (Settings → Secrets and variables → Actions). Without it an enforced deploy is held and a warn-only one says so.

After the deploy — the pipeline reports a successful deploy to the release itself. A deploy that fails is not reported.

Seeing it — DevOps → Pipelines shows, for each environment, whether its deploys are Passport enforced, Passport warn only, Passport check changed or have No passport check, as the Studio itself reads the workflow files. It finds a deploy by the job’s environment, its name, or its waiting for the check — a deploy done by any other job is not seen — and it lists a job that calls a workflow in another repository as one it cannot read. Pinning one of a deploy job’s actions to a commit reads as Passport check changed for now. DevOps → Runs shows what a check found for a run: what is unmet and which exceptions are no longer in force. That is what the job printed; the release’s passport is the record.

An agent override is retired as soon as the reviewer agents approve the same version themselves, and a retired override is never counted. One that has run out and is counted was what the gate stood on when the passport was issued: renew it on the gate, or reopen the gate and have the agents review again, then issue the passport again.

Setting the check up, every state the Pipelines page can show and what to do when a check does not pass are in Wire a Pipeline to the Passport.

The check sits beside branch protection, tag protection and required reviewers; it does not replace them. Whoever can change a workflow can remove the check, which is why the Studio shows where it is missing or changed.

What is not there yet

A pipeline you wrote yourself, or one outside GitHub Actions, is not held: a deployment from it is not refused because a passport is missing or does not clear, unless you add the same job. Security and dependency scan results are not recorded in a passport. Nothing deletes evidence when a retention period ends. Each agent does not act under credentials of its own: the passport names the agent and the GitHub account the commit was made as. The notice that evidence was not recorded is shown in the product and is not emailed, and there is no public log of issued passports.

All Guardrails, Evidence & Passport documentation

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