Objects
The methodology has about a dozen nouns, each introduced on the page where it became necessary. This page collects them, says what writes each one and how each is identified, and names what is deliberately not modelled. Nothing here is new. It is the material the other pages assume you have already assembled.
Model covers the subject matter, meaning the cryptography a document describes. This page covers the documents themselves and the things that check them.
What there is
| Object | What it is | Written by |
|---|---|---|
| Subject | The product, service or component a document describes. A profile declares which kind it accepts as its subjectType. | nobody; it is the thing being described |
| Interface | A cryptographic relationship the subject exposes at its boundary. The unit most rules apply to. See Model. | producer, as part of a document |
| CBOM revision | One revision of the record for one subject, in one carrier format. An extract from an inventory rather than a thing that exists on its own. See Inventory. | producer |
| Variant | The public or restricted form of a revision, distinguished by who may hold it. The public one carries markers where the restricted one carries values. See Confidentiality. | producer |
| Profile | The minimum reporting requirements serving one stated consumer and one stated decision. A rules file, not a schema. | profile author |
| Profile family | A set of profiles related by extension and ordered by depth, each containing the one below it. The shallowest is the entry profile. A profile that changes the consumer decision is a branch rather than a rung. | nobody declares it; it follows from extends |
| Rule | One requirement. P is evaluated per product, I per interface, G per entry in a group. Local to its profile and cited as tag#id. | profile author |
| Vocabulary | A controlled list a rule constrains values against, such as the cryptographic purposes. | profile author, or inherited |
| Conformance report | The full result of evaluating one document against one profile, rule by rule, with the disclosure state of each. | a validator, where the evaluation ran |
| Conformance claim | The portable record of one or more evaluations, bound to a document by digest. The artifact that crosses an organisational boundary. | whoever ran the evaluation |
| Policy | External and versioned. Holds the judgements a CBOM deliberately does not carry, such as whether an algorithm is still acceptable. See Policy Evaluation. | the consuming organisation |
| Vulnerability statement | External, and joined to a document rather than contained in one. It cites the document a claim already binds by digest. Conformance asserts nothing about it. See Vulnerabilities. | whoever issues it, usually not the producer |
How they connect
How each one is identified
This is the question that recurs, and the answers were spread across five pages. Identity matters because a conformance claim has to be reproducible years later by somebody who was not there.
| Object | Identified by | Stable across |
|---|---|---|
| Subject | An identifier in the form the profile names, usually a purl | revisions of the document |
| Interface | interfaceId, chosen by the producer. No profile constrains it. | nothing; it is a label |
| CBOM revision | Content revision, and a digest when a claim or a vulnerability statement cites it | nothing; a new revision is a new document |
| Profile | profileId and version, cited together | a published version is never altered |
| Profile, in a citation | profileTag, the short handle | the life of the profile |
| Rule | tag#id, such as interface-disclosure#I9. The id belongs to the profile that introduced it, not to one that later tightened it. | every version after it appears; a released id is never reused |
| Claim | The digest of the document it is about | nothing; a new revision needs a new claim |
| Policy | Its own version, recorded alongside any judgement it produced | whatever the consuming organisation decides |
Two axes that get confused
Both were one word until decision 0021, and the distinction is worth holding on to.
Capture phase belongs to a fact. lifecycleStage says whether a value was intended, implemented, configured or observed, which is how much weight the value carries. It can differ between two attributes in the same document. See Lifecycle Data.
Revision state belongs to a document. Created, signed, published, superseded. It is the same for every attribute in the document, and governance controls the transitions. See Governance.
What is deliberately not an object here
A judgement. Whether an interface is adequate, or how mature a supplier's disclosure is, is produced by policy at evaluation time and carries the policy version and the date applied. Storing it in a document would freeze an answer whose criteria move. A depth is a profile; a maturity level is a judgement read off one.
An attestation. Nothing here establishes that a disclosed value is true. A signature covers origin and integrity, and a claim covers what was evaluated. A producer who states the wrong protocol version produces a document that signs, validates and verifies.
A registry. Profiles, documents and claims all have to be stored and served somewhere, and the model says nothing about where. That is left to whoever operates the inventory, with the archive obligation in Governance as the one requirement placed on them.