A Passport is a record.
Not a blanket assurance.

This public discussion brief summarizes the proposed approach. It is not the approved specification or a substitute for the current technical working draft.

Three connected layers

1. The cover: concise identifying information, responsibility, intended use and material limits. The label is an entrance to information, not a rating.

2. The full record: structured information within six proposed areas: identity and scope; ownership; use and limitations; evaluation and failure modes; oversight; and lifecycle/change information.

3. Supporting material: referenced architecture, data flows, controls, assessments, monitoring and runbooks. A production implementation would preserve access controls in the systems holding that material.

Authoring without inventing facts

Available information can be imported from identified sources. An extracted or suggested statement still needs review where judgment is involved. Responsibility and permitted-use declarations require an authorized person's input. The prototype's required flags and field count are choices for testing, not an agreed universal minimum.

Readable to people; interpretable by software

The example keeps the record identifier and revision separate from the system identifier and version. A receiving component should be able to identify the subject, understand declared boundaries and expose unavailable or incompatible information. A registry connection or machine-readable record does not grant authority to act.

Declarations, evidence and attestations

These are separate states. A supplier statement is not an independent assessment. A signature, if later supported, would need defined verification and trust rules; it would not make every underlying assertion true. Any attestation would need a specific claim, issuer or assessor, source, scope, timing and limitations.

Changes and applicability

The example explicitly supplies a model or permission change. The receiving view compares the new version with the stated evaluation scope; it does not discover unreported changes or determine that a system is safe. A missing reference or mismatched version remains visible as an information gap.

A bounded proof of concept

The proposed exercise would test a complete record, incomplete information and a material change. Its findings should identify ambiguous definitions, implementation problems and review effort. The demo does not establish a cloud deployment, company partnership or independent interoperability result.

What remains open

The precise core fields, conditional extensions, record encoding, discovery and registry mappings, source authentication, attestation mechanisms, status handling, service-level references and liability terms remain subjects for review. Related standards and documentation approaches should be considered before creating duplicate definitions.