System passports and release evidence

Purpose of a system passport

An AI system passport is a versioned index of decision-relevant facts and evidence for one specific release candidate. Its job is to let a reviewer understand the intended system and the exact version under consideration without re-deriving that understanding from scattered tickets and dashboards — and without becoming an unmaintainable duplicate of every source record it references.

Treat the passport as an index with links to authoritative evidence, not a copy of that evidence. A passport that duplicates content goes stale the moment the source changes.

Passport structure

Include:

• System identity, purpose, prohibited uses, owner, users, affected parties, and lifecycle state.
• Boundary, components, data and knowledge sources, models, prompts, tools, providers, and material dependencies.
• Deployment environments, identities, permission model, and administrative authority.
• Applicable obligations, threats, control objectives, implementations, and known limitations.
• Artifact identities, provenance, licenses, evaluations, security results, and operational readiness — see Artifact identity and provenance.
• Exceptions, residual risks, approvers, release decision, expiry, rollback target, and reassessment triggers.
• Links to authoritative evidence sources rather than copied, stale content.

Release recommendation

State approve, approve with conditions, hold, or reject for the exact candidate version — not for the product in general. Use the evaluation and release gates pattern to summarize which acceptance criteria passed, which failed, which exceptions and compensating controls apply, the monitoring window, rollback triggers, and the named decision authority.

A recommendation without a named accountable approver and an explicit rollback path is incomplete, regardless of how much evidence supports it.

Keeping the passport trustworthy

The passport must change whenever the system materially changes — see Controlled change and versioning for the triggers that should force a new version. Preserve every prior version rather than overwriting it, so an incident investigation or audit can reconstruct exactly what was approved, when, and why, even after later releases have shipped.

Operational signals from Observability and operational evidence feed back into the passport as continuous evidence that approved properties still hold — they extend the passport between releases; they do not replace the release decision itself.