SovAIHub

Reference Architecture · AI System Passport

One evidence record for every AI system.

The AI System Passport is a local-first, versioned evidence ledger connecting ownership, intended purpose, architecture, risk, artifact provenance, evaluation, agent authority, incidents, cost, and business value.

Why

Evidence is usually scattered across tickets, spreadsheets, wikis, dashboards, and repositories.

A passport does not replace those systems. It provides the stable identity, ownership, evidence index, current decision state, and traceable history that joins them together.

Before deployment

Prove who owns the system, what it is intended to do, which boundary it uses, and which evidence is required.

At every release

Pin the model, prompt, retrieval, tool policy, artifact BOM, evaluation result, approvals, and deploy record.

During operation

Connect incidents, changes, exceptions, cost, utilization, value, and periodic review to the approved system state.

Schema

Eight evidence domains form the passport.

The template stores summaries and references rather than copying every underlying log, document, or artifact into one database.

Identity and ownership

System ID, owner, accountable executive, operators, users, intended purpose, prohibited uses, environments, and lifecycle status.

Architecture and boundary

Data flows, deployment zones, models, retrieval, tools, stores, identities, external services, transfer paths, and diagrams.

Risk and obligations

EU AI Act orientation, operator roles, data-law flags, sector requirements, risk register, exceptions, approvals, and review date.

AI and artifact BOM

Model weights, datasets, prompts, tools, packages, images, licences, suppliers, checksums, signatures, vulnerabilities, and approval status.

Evaluation evidence

Dataset and evaluator versions, baseline/candidate results, security tests, thresholds, failures, human reviews, and release decision.

Agent authority

Tools, data scopes, credential flow, argument constraints, approvals, budgets, egress, side effects, audit events, and kill switch.

Change and incidents

Material changes, releases, migrations, exceptions, incidents, corrective actions, rollbacks, retirement, and evidence retention.

Cost and value

Allocated cost, utilization, quality-adjusted goodput, accepted outcomes, business value, budgets, anomalies, and optimization decisions.

Lifecycle

Treat the passport as an operating record, not a one-time compliance PDF.

01

Register

Create the passport before production data or users are introduced.

02

Assess

Classify purpose, roles, risk, data, suppliers, and required controls.

03

Approve

Record architecture, security, legal, product, and accountable-owner decisions.

04

Release

Attach versioned BOMs, evaluation evidence, deployment record, and release gate.

05

Operate

Link monitoring, tool decisions, incidents, cost, value, exceptions, and reviews.

06

Change

Trigger reassessment when purpose, model, data, tool authority, or boundary changes materially.

07

Retire

Record shutdown, data/artifact disposition, access removal, and evidence retention.

Evidence graph

Connect decisions to the evidence that justified them.

A useful ledger can answer why a release was approved, which test and policy versions were used, what changed, who accepted a residual risk, and whether the system still matches its approved purpose.

system private-policy-assistant
├─ purpose → approved-purpose-v3
├─ architecture → arch-2026-07
├─ ai_bom → release-1.8.0.spdx.json
├─ tool_policy → tools-policy-12
├─ eval_run → eval-2026-0718-0042
├─ risk_review → eu-aia-2026.07.22
├─ finops_snapshot → finops-2026-07
└─ approval → release-board-284

Design principles

  • Local-first and exportable
  • Human-readable plus machine-readable
  • Append-only decision history
  • References immutable evidence by digest
  • Role-based access to sensitive evidence
  • No claim of compliance from template completion alone