Profile maturity

A profile states one bar, and a document either clears it or does not. That is the right shape for a conformance decision and the wrong shape for adoption: a producer that can enumerate its interfaces this quarter, and cannot attribute algorithms to them until it has instrumented its build, conforms to nothing at all. Maturity is the discipline of publishing a family of profiles ordered by depth, so that the first step is reachable, the last is demanding, and a consumer can tell which one a supplier has taken.

This is not new machinery

Everything a family of increasing depth needs is already decided and already checked. Profile defines extension and its two kinds, depth and coverage. Extension is monotonic: a derived profile adds rules and tightens inherited ones and may never relax them, which is what makes conformance to the derived profile carry conformance to the base. A rule id belongs to the profile that declares it and is cited against that profile's tag, so the same rule keeps its number as a family grows. An inherited group may be sharpened in place.

So a depth is not a new kind of object. A depth is a profile. There is no new field, no new artifact type and no new verdict. A conformance claim already names each profile it covers by identity and version, which means a claim already says which depth was met, and a report already lists the rules that were assessed to reach it. What is missing is not mechanism. It is that the family's shallowest profile has to actually exist, has to be reachable, and has to be published as part of a family rather than as a competing baseline.

Why these are not called maturity levels

"Maturity level" is already in use in this documentation, for the thing a profile deliberately is not. Related Work sets out the relationship with the consortium's PQC Maturity Model, whose subject is the same as this methodology's: a product assessed from the outside. A PQCMM level is a judgement, derived by an external versioned policy from the facts a document discloses, and Policy Evaluation is explicit that such judgements are computed at evaluation time and are not recorded as attributes, because the criteria change while the product does not.

A profile is the other half of that arrangement: it is what the judgement reads. Using one phrase for both would put two meanings of "maturity level" in one body of documentation, one of which is excluded on principle. This project has paid for a terminology clash once already, and the cheaper moment to settle it is before anyone cites the numbering.

The normative word used here is depth: a family ordered by depth, whose shallowest member is the entry profile. "Maturity" is kept as the title of this section because it is what a reader arrives looking for. The obvious alternatives are all spoken for:

The family as it stands

Two profiles, one branch, and a document between the two depths.

The entry profile declares each shared rule under the id the baseline uses for the same rule, so the gaps in its numbering — no P2, no I3 to I6, no I9 — are exactly where the next depth adds. That is legible rather than ambiguous only because an id is cited against a profile tag: the same rule appears in a report as interface-enumeration#I1 at one depth and interface-disclosure#I1 at the other, and a reader can see which bar was applied.

The demonstration that the entry depth is worth having is a document that was already in the repository. cbom-fail is named for the verdict the baseline gives it: it omits the management interface and fails product rule P2. It conforms to the entry profile. A producer in that position is not producing nothing, and before the entry profile existed there was nothing for it to conform to. At the other end, cbom-entry-fail — roughly what a scanner emits with no profile in mind, recording a TLS asset it found and nothing about what the interface is for — conforms to neither. That is where the entry depth is set: above untargeted output, below the full disclosure bar.

Depth and branch are different relations

Both are monotonic extension and the mechanism does not distinguish them, but a family is planned and read differently depending on which one is happening.

Depth asks more about the same decision. The entry profile and the baseline serve one consumer with one question — which interfaces does a published weakness reach — and differ in how much they demand before that question can be answered. Both declare orientation inventory. A producer moves between them by disclosing more about the same interfaces.

A branch changes the decision. The migration profile derives from the baseline, and its consumer is planning a migration rather than maintaining an inventory: it declares orientation both and asks for statements about a future state. Reaching it is not a matter of disclosing more of the same facts, and a supplier at the entry depth is not two steps from it. Presenting a branch as a rung would tell a producer to work in the wrong order and tell a buyer that one number ranks suppliers who are answering different questions.

The practical test: if the derived profile's objective states the same decision and its scope.orientation is the same, it is a depth. If either differs, it is a branch.

The test does not separate a third relation. A profile can state the same decision and the same orientation and differ only in the audience it is written for — the same rules, with the contested ones no longer withholdable, for a recipient under an agreement. Confidentiality sets out why that is published as a pair at one depth rather than as the rung above: a producer reaches it by signing an agreement rather than by learning something new about its own product, and presenting it as a rung ranks will not tell you against cannot tell you.

What makes a family one ladder

Publishing profiles in an order is not the same as publishing a ladder. The claim a family makes is that conformance at a depth carries conformance at every depth below it, and that claim holds only under the conditions below.

Where one profile declares extends on another, the validator enforces most of this already and refuses a relaxing profile before it evaluates any document. The two profiles here are siblings: the baseline was published first and does not name the entry profile as its base, because re-parenting it would move seven rule ids to another profile tag and change every citation of them in this documentation, in the test suite, and in any report already issued. Whether to pay that is the working group's call. Until it is taken, the ladder is an assertion about two independent profiles, and an assertion in this repository gets a check: tests/check-family.py requires every condition in the table above, and requires that every committed document conforming to the baseline conforms to the entry profile. It also reports the documents that sit between the two depths, because a family where every document conforms everywhere has one rung whatever it declares.

What a depth must not become

A ceiling. The obvious objection to an entry profile is that suppliers will stop there. Nothing in the artifact can prevent that, and it is not the artifact's job: a profile states a bar, and what bar to require is the consumer's decision. The control is in the ask. A buyer names the profile and version it requires, and a date by which the deeper one is required; the grace-window question in Versioning is the same question. A claim names the profile it met, so "conforms" is never ambiguous about which depth was reached — which is precisely what a family makes visible and a single baseline does not.

A floor. An entry depth set too high is the failure this section exists to correct. It is also the state this methodology was in: the shallowest thing to conform to required nine facts about every declared interface, the implementing library among them, and four about the product. A producer who could supply the first four of the nine had no way to say so and no verdict to show for it.

A relabelling of obligation levels. A depth is not the SHOULD rules of one profile renamed. The two answer different questions: a SHOULD is reported and does not decide a verdict, so a document satisfying only the MUSTs still conforms, and nothing says the rest was expected. A shallower profile's requirements are MUSTs, and a document that fails them does not conform. Moving a SHOULD to MUST inside one profile changes the verdict on documents already published without changing the documents, which is what version discipline exists to control; adding a depth does not, because the deeper profile is a new profile with its own version.

An enumeration of what comes later. A shallower profile cannot list what deeper profiles will require. Those profiles do not exist when it is published, and making it name them would mean re-releasing the entry profile every time the family grew — inverting the direction of extension, so that the base depended on its derivatives. The family therefore lives in the register described in Governance, not in the rules files. Each profile still says what it defers and why, in its exclusions, which is the honest half a profile can carry on its own.

One wrinkle follows from that. A rules file has a single exclusions list, and it is used both for what is excluded permanently — key material at every depth of every profile, derived judgements on principle — and for what is merely not asked at this depth. Those are different statements to a consumer, and nothing distinguishes them mechanically. The entry profile marks each of its own as "deferred, not excluded" or "permanently excluded" in prose, which a reader can follow and a tool cannot.

Climbing, and asking

The useful property of building the family this way is that the work list is generated rather than negotiated. A producer conforming at the entry depth runs the deeper profile against the same document, and the failing rule ids are the gap, named and countable:

cbom-fail.cyclonedx.json conforms to interface-enumeration,
  and interface-disclosure#P2 stands between it and interface-disclosure

That is a line from the test suite, not an illustration. The same holds for the document exercising the disclosure states, which sits one interface's worth of missing algorithms below the baseline.

The pattern already appears inside a single profile, one grain down. The migration profile takes three cryptographic purposes in depth and still requires a status for all seven, so a supplier cannot conform while behaving as though entity authentication does not exist, and a buyer sees the long-lead blockers in the first document rather than the third. A family ordered by depth is that same idea at the grain of a profile: the shallow depth is cheap to reach and says openly what it does not cover, and what it does not cover does not become invisible.

What is not settled