Agent-built software outpaces review
An agent can open more pull requests in a day than a team can read in a week. Review either becomes a rubber stamp or becomes the bottleneck, and neither is a control.
The methodRelease evidence
Artefact Passport
Evidence that the right things were checked, by the right people, against the right policy.
When agents write the change, the question a release has to answer is no longer “did the build pass?” It is “what was checked, who decided it, under which rules — and can you prove it?” The Artefact Passport is that proof: one record per work package and per release, gathered as the work moves through its gates, frozen and signed when the release is approved, and checkable by anyone who holds the file.
This page explains the problem, the approach and the process, and states plainly what the AI Product Studio does today and what it does not.
The problem
Delivery tooling was built for a world where a person wrote each change and another person read it. Agents break that assumption in four ways.
CI proves a build ran, not that the right things were checked
A green pipeline says the tests passed at a commit. It does not say which rules applied to this change, who decided each one, or whether the person who approved it was entitled to.
The evidence is scattered
A review comment here, a CI run there, an approval in a chat thread, a waiver nobody wrote down. Assembling it for one release is a week of archaeology, and the result is a reconstruction.
Auditors and customers ask "show me"
Not "do you have a process" but "show me that this release followed it". The answer has to be a record made at the time, that an outsider can check without taking your word for it.
The approach
Do not ask people to read more. Decide, once, what must be true before work moves; check it at the work; and keep a record of each check that stands on its own.
Put the control at the work
Every work package passes a Definition of Ready before it is built and a Definition of Done before it completes. Each checklist item has an agent side, a human side, or both, and names who may decide it.
Record evidence as it happens
Each assessment, decision, exception, CI result and approval is written to an append-only ledger in the same request as the event. Entries are chained, so one that is dropped or altered shows.
Say what is not known
A control with no recorded decision behind it reads Unknown, never Satisfied. A pull request head the Studio did not publish is shown as seen, with its producer unknown. Nothing is inferred to a pass.
Make exceptions visible and temporary
A waived item or an override of the reviewer agents records who took it, on what authority, why and until when. Once it expires or is voided, the item is unmet again.
Trust the signature, not the screen
At release approval the record is frozen and signed. Anyone holding the file and the published public key can check it, offline, without asking the Studio whether it is real.
The process, step by step
One change, from the rules it is built under to the environment it reaches. Each step says who acts and what is left on the record.
Step 1: Set the guardrails Enterprise organisations
Write a guardrail policy once: the Ready and Done items every linked studio must carry, the rules a release must meet, and who may take an exception. Activating it freezes a numbered version.
- Who
- Organisation owner or administrator
- On the record
- The policy version, and every change to it, item by item.
Step 2: Gate the work
Each work package is checked against its Definition of Ready and Definition of Done. The reviewer agents assess; a person decides. A studio may add items of its own and may never remove or weaken the organisation's.
- Who
- Reviewer agents and a person
- On the record
- Every assessment, every decision and every exception, each with what it was based on.
Step 3: Gather the evidence
As each thing happens, the server adds an entry to that artefact's ledger: the gate decisions, the CI results at the head that was assessed, which agent produced a pull request head, the DPIA a release relied on.
- Who
- The server
- On the record
- One append-only, hash-chained ledger per work package and per release.
Step 4: Read the passport
The passport presents the ledger for one artefact: exceptions first, then the policy it was judged against, the controls its items are evidence for, the gates, provenance and CI, and a list of what it does not know.
- Who
- Anyone in the studio
- On the record
- Nothing. Reading a passport changes nothing.
Step 5: Approve and issue
Approving a release issues a signed passport in the same step: the record frozen at that moment and signed with the platform's key for that environment. Each issue is a new version; none is ever rewritten.
- Who
- Release approver
- On the record
- An immutable, signed version, and a ledger entry pointing at it.
Step 6: Verify from outside
The signed file is checked against the published public keys with a small offline script, a public endpoint or standard in-toto tooling. The answer is the signature, plus what the record says is unmet or has run out since.
- Who
- An auditor, a customer, a pipeline
- On the record
- Nothing. The verifier never reads the Studio's database.
Step 7: Hold the deploy
In a GitHub Actions pipeline the Studio generates, every deploy waits for a passport check that verifies the release's signed passport on the runner. The studio owner chooses, for each environment, whether a failed check holds the deploy or only warns.
- Who
- The pipeline
- On the record
- The check's result in the job log; the signed passport stays the record.
Step 8: Report where it went
After a successful deploy the pipeline reports the environment, the commit and the workflow run, with a token that can do that and nothing else. A report for a commit the signed passport does not cover is refused.
- Who
- The pipeline
- On the record
- A deployment entry on the release and in its ledger.
Step 1 needs an organisation on an Enterprise contract. A studio with no organisation starts at step 2 with its own checklists, and every later step works the same way.
What you get from it
Agents can go fast without review going blind
People decide the items that need a person, on a record that shows what the agents found. The rest is evidenced rather than re-read.
An answer to "show me" in minutes
One record per release, made at the time, mapped to the controls your framework names. Hand over the signed file, or share one version by a link that expires.
One set of rules across every team
An organisation states its floor once. Every linked studio builds under it, and every passport names the version it was judged against.
Exceptions you can see
Where a control was set aside, the passport says so first, and an organisation has one register of every exception across its studios.
It starts with one developer
A studio of one gets the ledger, the passport, exceptions, a signed passport and the pipeline check. Nothing needs a second person unless a studio or an organisation chooses that.
What the AI Product Studio does today
Each of these is in the product now, at the place named under it. Each is labelled with who it is for.
Evidence ledger
An append-only, hash-chained ledger for each work package and each release, written in the same request as the event it records. The application cannot edit or delete an entry.
Every Studio plan
/studio/work-packagesThe passport
A page per work package and per approved release, assembled from the ledger on every read: exceptions, policy, controls, gates, provenance, CI and what is not known. It can be downloaded as JSON.
Every Studio plan
/studio/work-packagesControls
Checklist items name the controls they are evidence for — ISO 27001:2022 A.8.25 to A.8.32, SOC 2, NIST SSDF, SLSA build levels, or your own. The passport shows each control as satisfied, waived, not satisfied, not needed or unknown.
Every Studio plan
/studio/settings/work-package-checklistsExceptions with expiry
One record for a waived item and for an override of the reviewer agents: who, on what authority, why and until when. Expired or voided is unmet. Renewal is recorded as a new exception that names the one it replaces.
Every Studio plan
/studio/work-packagesSigned passports
Issued at release approval and on demand: an in-toto statement in a DSSE envelope, signed with one platform key per environment. Each version is stored once and never overwritten. The public keys are published.
Every Studio plan
/studio/releaseVerification outside the Studio
A standalone script that needs only Node.js, a public endpoint, and standard tooling all give the same answer from the file and the published keys alone. The studio owner can share one version by a link that lasts 1 to 30 days and can be revoked.
Every Studio plan
/studio/releaseA passport check before a deploy
In a GitHub Actions pipeline the Studio generates, each deploy waits for a job that verifies the release's signed passport on the runner. The verifier is written into the workflow and pinned by its hash. Enforce or warn only is the studio owner's choice for each environment.
Every Studio plan
/studio/repositoriesDeployment reports
A pipeline reports where a release went with a deploy token that is minted per repository, shown once and stored only as a hash. Each report is listed on the release and recorded in its ledger.
Every Studio plan
/studio/repositoriesThe agent is named
Evidence an agent recorded carries one identity for that agent in that studio. For each pull request head the Studio published, the passport names the agent and the GitHub account the commit was made as, and shows unknown where neither was recorded.
Every Studio plan
/studio/work-packagesThe owner is told when evidence was not recorded
If a save succeeds and its evidence cannot be written at that moment, the change is kept, the gap is put on record, and the studio's owner sees a notice at the top of every Studio page naming the artefacts affected.
Every Studio plan
/studioLegal hold
A studio owner can place a hold on a work package or a release, with a written reason. While it is in force the records it depends on cannot be deleted. Work on the artefact carries on as usual.
Every Studio plan
/studio/work-packagesBill of materials as evidence
A pipeline reports a software bill of materials for a commit with the deploy token. The Studio records its SHA-256, its format and the commit it describes; the document stays with the pipeline.
Every Studio plan
/studio/releaseGuardrail policies
An organisation writes the Ready and Done items, release rules, separation of duties and exception rules its studios must follow. Versions are frozen once active, and a work package keeps the version it was created under.
Enterprise organisations
/organisation/guardrailsExceptions register
Every waived item and every override across the organisation's studios, as in force, expired or voided, with who granted it and why.
Enterprise organisations
/organisation/exceptionsSample review and release rules
A policy can require passing CI and a bill of materials for each package before a release is approved. It can also name a share of completed work packages for a second look by a named role: the reviewer's verdict is evidence, and it never holds a release.
Enterprise organisations
/organisation/assuranceDeclared retention
An organisation's owner declares the minimum time the organisation keeps evidence for. It is a declaration, recorded and audited. The evidence ledger has no expiry with or without one.
Enterprise organisations
/organisation/assurancePlans and what each includes are on AI Product Studio plans. An Enterprise contract that lapses stops new guardrail policies being written; it never stops the reading of one, a policy already applied to work in flight, the exceptions register or a legal hold.
What is not built
A page about evidence should be exact about its own limits. None of the following is available.
A check in pipelines the Studio did not generate Not built
The passport check is in the GitHub Actions pipelines the Studio generates. A pipeline written by hand is not held unless you add the same job, and there is no passport check for GitLab or Bitbucket pipelines.
Scan results as evidence Not built
Security and dependency scan results are not recorded in the ledger or shown in a passport. CI check runs and a bill of materials' digest are.
The bill of materials step in generated pipelines Not built
A pipeline reports a bill of materials with a script a team adds to its own build. The pipelines the Studio generates do not carry that step.
An automated evidence purge Not built
Nothing deletes evidence when a declared retention period ends. The ledger and issued passports are kept, including after a studio is deleted.
A credential of its own for every agent Not built
The passport names the agent, but the Studio's own runner commits with the publishing person's GitHub account, and the passport says so.
Email when evidence was not recorded Not built
The owner's notice is shown in the product. No email is sent.
A hosted transparency log Not built
The record is the hash chain, the append-only table and the signed versions. There is no public log of issued passports.
The passport check sits beside branch protection, tag protection and required reviewers on an environment. 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 has been changed.
Start by reading one passport
Nothing has to change in how a team works to begin. Open a work package, read its passport, and see what the record already says. Map controls when you are ready; add an organisation’s guardrails and the pipeline check when the risk warrants it.
Read the guide: guardrails to passportWhy pipelines change: Agent PipelinesExplore AI Product Studio
How the Studio’s compliance controls map to ISO 27001 and SOC 2 is on Compliance & Controls.