UCIe Compliance Testing

Module 20's first six chapters built a complete internal verification methodology. Every one of them answers to the team that wrote it. A green regression against your own reference models, your own coverage plan and your own peer is evidence about your interpretation of the specification — and interoperability is a claim about somebody else's.

1. The One-Sentence Model

Verification proves your design matches your understanding. Conformance proves your understanding matches the specification. Interoperability proves it matches somebody else's understanding of the same specification. Compliance testing is the mechanism by which the second and third stop being assumptions — and no amount of the first substitutes for either.

Three distinct claims, three distinct evidence types, and the failure this chapter exists to prevent is stating one and having demonstrated another.

2. What This Chapter Owns

This chapter owns four things and refuses a fifth.

The distinction between four claims (§6–§8) — verification, conformance, interoperability, and certification — which are routinely spoken as if they were one.

What the Consortium's published material actually establishes (§4), quoted, with the source named — and it establishes more than most engineers realise and far less than a compliance claim needs.

A conformance matrix and an interoperability matrix (§14–§18, §29–§33), which are different artefacts from a coverage report and answer different questions.

An evidence discipline (§36–§44) — what a package must contain for a claim to be checkable by somebody who was not there.

And it refuses to invent the fifth: the specifics. §5 is an explicit list of everything a real compliance programme has that this chapter cannot establish from public sources. That list is the chapter's most important content, because a tutorial that fabricated those specifics would be worse than no tutorial at all.

3. Sourcing — the Strictest in This Module

4. What the Consortium's Published Material Establishes

Five statements, quoted, with the revision they belong to. These are the load-bearing facts of the chapter.

On UCIe 1.0, the Consortium's specifications page describes "compliance testing that will enable end users to easily mix and match chiplet components" — so compliance testing has been part of the standard's stated purpose from the first revision, and its purpose is stated as mixing and matching components, which is interoperability.

On UCIe 1.1, the same page describes "Architectural Specification Enhancements enable compliance testing", and states that the specification "details architectural specification attributes to define system setups and registers that will be used in test plans and compliance testing to ensure device interoperability." Three things follow: compliance testing requires architectural attributes to be defined; it requires registers; and those exist to support test plans. §13 develops what that implies for a testbench.

On UCIe 2.0, the Consortium's release announcement states that UCIe 2.0 "establishes an initial framework for physical, adapter, and protocol compliance testing." That is the sourced three-layer structure — §10 — and the word "initial" is doing real work.

Also on UCIe 2.0, and this is the single most useful sentence for a verification engineer: "The goal of compliance testing is to validate the main-band supported features of a Device Under Test (DUT) against a known-good reference UCIe implementation." Three sourced facts in one sentence — the scope is main-band supported features, the subject is a Device Under Test, and the oracle is a known-good reference UCIe implementation. §11 and §12 develop both.

And the specifications page lists "Optimized package designs for interoperability and compliance testing" among UCIe 2.0's contents, which places package design inside the compliance concern rather than adjacent to it.

Additionally, and separately from Consortium publications, public industry material describes an Intel and Cadence live UCIe-S interoperability demonstration using a test chip, and Cadence and Siemens work on verification IP intended to enable compliance and interoperability testing in simulation. Those are vendor and event reports, not Consortium specification statements — they are cited here as evidence that pre-silicon compliance-shaped testing and silicon interoperability demonstration are both real industry activities (§22, §23), and for nothing more.

5. What This Chapter Cannot Establish

The most important section in the chapter. Everything below is something a real compliance programme has, that a competent engineer would want, and that the official material I could reach does not publish.

This chapter cannot establish any of the following as an official UCIe compliance requirement from the sources inspected.

Three consequences, and they shape everything after this section.

Every criterion in this chapter is explicitly internal. §47's gate, §48's sign-off, §45's selection — all of them are engineering constructs, and each says so at the point of use.

The chapter teaches the framework, not the specifics. A conformance matrix, an evidence package, a version discipline and an interoperability matrix are all constructible without knowing the official test list — and they are exactly what a team needs before it obtains that list.

And the honest position is stated in the artefacts themselves. §36's evidence package has a field for "basis of criterion", and an internal criterion is recorded as internal. A package that silently presents an internal pass criterion as a conformance criterion is the failure this chapter is written to prevent.

6. Three Words That Are Not Synonyms

Four properties of this table.

Row 1's evidence cannot support rows 2 or 3. Our models encode our reading; a regression is a consistency check between the design and that reading (20.4 §16's mirroring argument, one level up). Where the reading is wrong, the design and the regression are wrong together.

Row 2 is the row that needs an external oracle, which is exactly what the Consortium's sourced statement provides: "against a known-good reference UCIe implementation" (§4). §21 is why our own model cannot be that oracle.

Row 3 is the narrowest and the most concrete. It makes no claim beyond the pair tested — and that narrowness is a feature, because it is the only one of the three that is a direct observation rather than an inference.

And "compliant" is deliberately absent from the table. It is used loosely to mean any of the three, which is why this chapter uses the specific word each time.

7. Certification Is a Fourth Thing

Conformance is an engineering property. Certification is an institutional one — a recognised body, a defined procedure, a defined result, and usually a public record.

8. The Confidence Boundary

Every verification programme has a boundary beyond which its evidence says nothing. Naming it is a deliverable.

Three notes.

Row 1 is the boundary this chapter is about. Everything in 20.1 to 20.6 is inside it, and the specification is outside it — which is why conformance needs an external oracle rather than a better internal one.

Row 3 is the boundary 20.6 §59 crossed deliberately. An adversarial peer covers more of the legal range than a friendly one; it still covers the range we believe is legal.

And the boundary must appear in the sign-off (§48). A sign-off that states what was demonstrated and stops there is honest; one that states a conclusion the evidence does not reach is the failure mode.

9. Why an Internal Regression Cannot Demonstrate Conformance

Four independent reasons, and each survives making the regression better.

The oracle is ours. 20.4's models encode our reading of the specification. A design that matches them matches our reading — and if the reading is wrong, the regression confirms the error. This is precisely 20.4 §16's mirroring failure with the specification in the place of the RTL, and it is why §4's sourced "known-good reference UCIe implementation" is architecturally necessary rather than merely convenient.

The coverage plan is ours. 20.5 §7's requirement table is built from our enumeration of requirements. A requirement we did not extract from the specification has no row, no checker, and no coverage item — and its absence is invisible, because the table is complete with respect to itself.

The peer is ours. 20.6 §59: even an adversarial peer varies within the ranges we believe legal. A real peer does whatever it does, including things we did not model as legal and things the specification permits that we read as forbidden.

And the interpretation of ambiguity is ours. Every specification has passages that admit more than one reading. We chose one for the design and the same one for the models — so the regression cannot detect that we chose, let alone that we chose differently from a partner. §34 is what to do about it.

A green regression is strong evidence for exactly one claim: the design is self-consistent with our interpretation. That is genuinely valuable, it is a prerequisite for everything else, and it is not conformance.

10. The Three Compliance Layers

Sourced. UCIe 2.0 "establishes an initial framework for physical, adapter, and protocol compliance testing" (§4).

Three layers, and they need different evidence, different equipment and different expertise.

Three observations.

The word "initial" in the sourced quote matters. A framework described as initial is one whose scope is expected to grow. A plan that treats one revision's framework as the permanent shape of compliance will be wrong, and §40's version discipline is the response.

The three layers map onto the stack this curriculum has used throughout — Protocol Layer / D2D Adapter / Physical Layer (4.2) — which is why 20.1 §7's four-monitor architecture is directly reusable for compliance-shaped observation. The monitor at each boundary is the observation point for that layer's compliance questions.

And the Adapter layer's compliance scope is configuration-dependent. 20.1 §3's sourced fact: the Adapter optionally guarantees reliable delivery through CRC and link-level retry. So "Adapter compliance" for a device that implements reliability and one that does not are different scopes — which is §15's feature-declaration problem.

11. The Reference-Implementation Oracle

Sourced, and it is the sentence that shapes the whole activity: the goal "is to validate the main-band supported features of a Device Under Test (DUT) against a known-good reference UCIe implementation."

Four things that sentence establishes.

There is a DUT and a reference, and they are asymmetric. The reference is the authority; the DUT is being measured against it.

The reference is "known-good", which is a claim about the reference that somebody else established. A team's own model is not known-good in this sense — §21.

It is a "reference UCIe implementation", not a reference model or a reference document. An implementation behaves; a document is interpreted. That distinction is the whole reason this approach resolves interpretation disputes that a document cannot.

And validation is of "supported features", which presupposes that the DUT has declared which features it supports. §15.

The architectural consequence for a testbench. 20.6 §57's peer levels end at "a second instance or VIP" — and this is that level, with an external authority attached. The environment shape does not change; what changes is whose implementation sits on the far side and who vouches for it.

12. "Main-Band Supported Features" — What It Implies for Scope

Two words in the sourced sentence carry scope information: main-band, and supported.

On main-band. The sourced goal statement names the main band specifically. This chapter does not infer from that what the compliance status of sideband or management paths is — that is a specification question, and §5's list includes revision scope. What a plan can safely conclude is that the main-band data path is definitely in scope, and that anything else must be confirmed against the specification.

On supported. Compliance validates the features the DUT claims. Three consequences:

A narrow claim is easier to substantiate and less useful commercially. A device declaring one protocol, one width and no reliability has a small conformance surface — and a customer needing two protocols cannot use it.

A broad claim is a larger obligation. Every declared feature is a feature the evidence must cover (§17).

And an undeclared feature that is implemented is a hazard rather than a bonus. A device that happens to accept traffic in a mode it never declared has behaviour nobody tested, and a partner may discover and depend on it — which is §16.

13. Architectural Attributes and Registers

Sourced: the specification "details architectural specification attributes to define system setups and registers that will be used in test plans and compliance testing to ensure device interoperability" (§4, UCIe 1.1).

What that tells a verification engineer, and it is more actionable than it first appears.

Compliance testing is register-mediated. There are defined registers whose purpose includes supporting test plans. So a conformance harness reads and writes defined state rather than inferring everything from traffic — which is a fundamentally more tractable activity than black-box behavioural inference.

"System setups" are defined. The configuration a test runs in is not left to the tester's discretion; the specification defines setups. A plan that invents its own configurations for conformance purposes is doing internal verification, not conformance testing (§45).

And this connects directly to 19.6 §20's capability structure. A design that exposes its built capabilities as readable state is a design whose declared feature set (§15) can be checked against the silicon rather than taken from a datasheet. That is a design decision with a compliance payoff, and it is worth making for that reason alone.

The architectural consequence, as a harness step. A conformance step is establish, verify, then test — three phases where a verification testbench has one.

ILLUSTRATIVE conformance harness step. Register names and setup identifiers are
NOT claimed (§5); `SETUP_ID` and `attr_*` stand for whatever the specification
defines for the target revision.
 
  ESTABLISH
    1. read the device's capability state          -> capability_reported
    2. compare against the declaration (§15)       -> mismatch is a DECLARATION
                                                      ERROR, before any test
    3. write the specified setup's attributes      -> attr_write(SETUP_ID)
    4. wait for the setup to become active
 
  VERIFY THE SETUP  -- the phase a verification testbench skips
    5. read back what is ACTIVE                    -> configuration_active
    6. if configuration_active != SETUP_ID's definition:
         RESULT = INCONCLUSIVE, reason "setup not established"   (§48)
         STOP.  Do not run the test.
    7. record configuration provenance             -> §38's five fields
 
  TEST
    8. run the procedure
    9. decide against the ORACLE, and record which oracle    (§20)
   10. record: result, oracle class, basis of criterion      (§14, §18)

Three properties of that shape.

Step 6 stops the test rather than running it. A verification testbench that cannot reach a configuration usually proceeds and reports whatever happens; a conformance harness that runs in an unestablished setup has produced an invalid result that will be filed as evidence. 19.6 §21's requested-versus-active distinction, with a compliance consequence.

Step 2 catches a declaration error before any test runs, which is the cheapest possible time to catch it (§15).

And steps 9 and 10 are inseparable. Recording a result without recording which oracle decided it produces §39's unusable package — so the harness records them together or not at all.

14. The Conformance Matrix

A conformance matrix is not a coverage report. It maps declared features to evidence, and its rows are claims rather than bins.

Three properties.

The specification basis column is what separates conformance from verification. A row with an empty basis is an internal requirement in a conformance matrix — useful, and it must be labelled (§5's third consequence).

The basis of criterion column is the chapter's honesty mechanism. Three values, and only the first two support a conformance claim. A matrix where every row reads "internal" is a verification report with conformance headings.

And inconclusive is a first-class result. 20.4 §30's rule that a model must be able to say it does not know, applied to conformance: a test whose oracle could not decide is not a pass, and recording it as one is how a matrix stops being evidence.

A worked excerpt, illustrative throughout, showing what the columns look like when they are filled honestly:

ILLUSTRATIVE conformance matrix excerpt. Specification bases are shown as
placeholders because no clause reference is available to this chapter (§5).
 
F  FEATURE / ROW KIND         DECL  SPEC BASIS   ORACLE          CLASS  RESULT       BASIS OF CRITERION
-- --------------------------- ----- ------------ --------------- ------ ------------ -------------------
1  link state mgmt / positive  yes   <clause>     ref impl        E1     PASS         reference impl
2  link state mgmt / negative   -    <clause>     ref impl        E1     PASS         reference impl
3  param negotiation / pair A  yes   <clause>     independent rule E2    PASS         spec-derived (indep)
4  param negotiation / pair B  yes   <clause>     independent rule E2    FAIL         spec-derived  -> D2
5  param negotiation / refusal  -    <clause>     independent rule E2    PASS         spec-derived
6  reliability / positive      cond  <clause>     internal model  E4     PASS         INTERNAL ONLY
7  reliability / negative      cond  <clause>     internal model  E4     NOT RUN      -
8  reliability / inertness     n/a   <clause>     elaboration     E6     PASS         review + elab check
9  multi-protocol / positive   yes   <clause>     ref impl        E1     PASS         reference impl
10 multi-protocol × reliability yes  <clause>     internal model  E4     INCONCLUSIVE INTERNAL ONLY
11 degraded width / nominal    yes   <clause>     ref impl        E1     PASS         reference impl
12 degraded width / from max   yes   <clause>     ref impl        E1     NOT RUN      -   (§16's gap)
13 physical / electrical       yes   <clause>     measurement     --     NOT RUN      -   (no instruments)
 
GAPS RECORDED:
  rows 6,7,10 : no E1/E2 evidence -> requires a reference implementation or an
                independently constructed oracle before any conformance claim
  row  12     : declared configuration untested -> §16's failure shape
  row  13     : physical layer entirely unevidenced -> §24, §25
DEVIATIONS:   D2 (row 4) -> §43's record required, with disclosure status

Five readings, and each is a decision the matrix format forces.

Row 4 is a failure that produced a deviation record, not a suppressed result. §43.

Rows 6, 7 and 10 all read INTERNAL ONLY in the last column. They are genuine verification results and they support no conformance claim — and because the column exists, a reader can see that without reading the test code.

Row 10 is inconclusive, not pass. An interaction test whose internal oracle could not decide. The pressure to record it as a pass is exactly why §48 makes the value first-class.

Row 12 is the §16 shape caught before integration. Degraded width is declared and tested from the nominal width only; the from max row exists precisely so its absence is visible rather than hidden inside a single "degraded width: pass".

And row 13's blank class column is honest. No measurement was made, so there is no class to assign — and §25 is why this chapter does not fill it with a number.

15. Feature Declaration

The DUT declares; the matrix tests the declaration. Getting the declaration right is prior to all testing.

What a declaration must state, per feature:

Three rules.

The declaration comes from the design, not from marketing. 19.6 §20's capability structure is the authoritative statement of what was built; a declaration that exceeds it is wrong in silicon, and §16 is what that costs.

Conditional support must state the condition. "Reliability supported" when it is present only in one configuration is a declaration that will be read as unconditional — and 20.1 §51's Raw Mode case is exactly where the condition bites.

And a feature declared as not supported still needs evidence. Not that it works — that it is inert. 19.6 §47's inertness property: a disabled feature that occasionally activates is a declaration violation, and §17's matrix row for a not-supported feature tests exactly that.

The cross-check that runs before any test, and it is the cheapest check in the whole programme:

// ILLUSTRATIVE, VERIFICATION-ONLY. The declaration is checked against what the
// silicon reports (§13) before a single conformance test runs. A mismatch is a
// DECLARATION error, and it is found in seconds rather than at integration.
function automatic bit check_declaration(ucie_declaration_t decl,
                                         ucie_capabilities_t reported);
  bit ok = 1'b1;
 
  // 1. Nothing declared that the device does not report as built.
  foreach (decl.features[f]) begin
    if (decl.features[f].supported && !reported.has_feature(f)) begin
      report_error(ERR_DECL_EXCEEDS_SILICON, f,
                   "declared supported; capability state does not report it");
      ok = 1'b0;
    end
  end
 
  // 2. Nothing reported as built that the declaration is silent about.
  //    NOT an error — a HAZARD (§16's mirror case). An undeclared but
  //    implemented feature is behaviour nobody tested and a partner may find.
  foreach (reported.features[f]) begin
    if (reported.has_feature(f) && !decl.mentions(f))
      report_warning(WARN_UNDECLARED_CAPABILITY, f,
                     "reported as built and not declared: declare it as "
                     "supported-and-tested, or as not-supported-and-inert");
  end
 
  // 3. Every declared bounded parameter is inside what was built.
  foreach (decl.params[p]) begin
    if (decl.params[p].max > reported.param_max(p)) begin
      report_error(ERR_DECL_PARAM_EXCEEDS, p,
                   $sformatf("declared max %0d, built max %0d",
                             decl.params[p].max, reported.param_max(p)));
      ok = 1'b0;
    end
  end
 
  // 4. Every conditional declaration names its condition (§15's second rule).
  foreach (decl.features[f])
    if (decl.features[f].conditional && (decl.features[f].condition == ""))
      report_error(ERR_DECL_CONDITION_MISSING, f,
                   "conditional support with no stated condition");
 
  return ok;
endfunction

Three notes.

Check 2 is a warning rather than an error, and it is the one that prevents §16's mirror failure. An implemented-but-undeclared feature is not wrong; it is untested behaviour a partner can discover and depend on, and a later revision removing it becomes 19.6 §54's compatibility break.

Check 4 catches the declaration that will be misread. "Reliability supported" on a device where it is present only in Adapter-managed mode will be read as unconditional — and 20.1 §51's Raw Mode case is where that reading fails.

And the whole function depends on the capability state being readable, which is 19.6 §20's design decision. A device that does not expose what it was built with cannot have its declaration checked against anything but a datasheet — which is a document, not evidence.

16. Wrong Declaration — Claiming an Untested Feature

Worked, on the most common shape.

A device's capability structure says degraded-width operation is built. The declaration says "degraded width supported." The internal regression covered degradation from the nominal width only; 20.5 §18's width-before-after cross has one cell hit.

A partner integrates it and their link degrades from the maximum width instead.

Four properties.

The declaration was true about the hardware and false about the evidence. The feature exists; the claim a declaration makes is that it works, and that was demonstrated for one of several cases.

The failure surfaces at integration, where it is most expensive. Not in a lab, not in a regression — in somebody else's system, where the debug loop involves two companies.

The conformance matrix would have caught it if its rows were per configuration rather than per feature (§14's configuration column). One row reading "degraded width: pass" hides which degradations were tested; several rows, one per configuration, do not.

And the mirror error is a claim of non-support for an implemented feature. The device accepts something it never declared; a partner discovers it, depends on it, and a later revision removes it — which is 19.6 §54's version-compatibility failure arriving through a declaration rather than a register.

17. Mapping a Claim to Evidence

Every declared feature gets at least three matrix rows, and most teams write only the first.

Two notes.

The negative row is the one that matters at integration. A device that accepts an illegal request from a partner rather than refusing it produces a failure in the partner's system with the partner's name on it — and the refusal path is the least-exercised logic in most designs (20.5 §16's refusal bin).

And the interaction rows grow quadratically, which is why §28 bounds them. Declaring six features means fifteen pairs; declaring them without testing the pairs is 20.5 §31's cross-justification question asked about a product claim rather than a coverage bin.

18. Evidence Classes

Not all evidence is equal, and a matrix that does not distinguish classes cannot be assessed.

Three rules.

E4 and E5 do not support conformance, however extensive. That is §9, restated as a taxonomy — and a matrix whose evidence column is all E5 is a regression report.

E2 is achievable without a reference implementation, and it is what most internal conformance programmes actually have. Its credibility rests entirely on the independence of the construction — a specification-derived oracle built by the same engineer who wrote the RTL from the same reading is E4 with a different label.

And E6 is legitimate for some claims and not others. "This feature is inert because it is not instantiated" is a review argument backed by elaboration evidence (19.6 §10); "this timing is met" is not.

19. Wrong Evidence — the Regression as Conformance

WRONG conformance matrix row:
 
  Feature:               reliability (CRC + retry)
  Declared:              yes
  Specification basis:   —
  Test:                  nightly regression, ucie_reliability_suite
  Oracle:                our transport reference model
  Evidence:              regression report 2026-07-14, 4,812 tests, 0 failures
  Result:                PASS
  Basis of criterion:    —

Four things wrong with that row, in increasing severity.

The specification basis is empty, so the row does not identify what specification requirement it claims to demonstrate. It is an internal requirement in a conformance matrix.

The oracle is E4. Our model. §9: the design matching our model means the design is self-consistent with our reading.

The basis of criterion is empty, so a reader cannot tell that the pass criterion was ours. This is the field that makes the row's limits visible, and its absence is what turns an honest verification result into an overstated conformance claim.

And "4,812 tests, 0 failures" is quantity presented as authority. 20.5 §5's argument: a number summarises a plan whose quality it cannot express. Four thousand tests against our own oracle is four thousand instances of one claim.

The honest version of the same row:

Feature:               reliability (CRC + retry)
Declared:              yes, conditional on Adapter-managed mode
Specification basis:   <clause reference — TO BE FILLED FROM THE SPECIFICATION>
Test:                  internal reliability suite + fault-injection matrix
Oracle:                internal transport reference model (E4)
Evidence:              regression report <ref>; fault-injection coverage <ref>
Result:                PASS against the internal criterion
Basis of criterion:    INTERNAL — not a conformance criterion (§5)
Gap:                   no E1 or E2 evidence; requires a reference
                       implementation or an independently constructed oracle

The Gap field is the addition that matters. It states what would be needed to upgrade the row, so the matrix becomes a plan rather than a verdict.

20. The Oracle Question

For every conformance row, one question: what decided pass or fail, and why should anybody believe it?

Two notes.

The last row is not a straw man. A conformance test whose expected result is computed by a function shared with the RTL is f(x) == f(x) — 20.6 §56's predictor failure. In a compliance context it is worse, because the output is a claim made to third parties.

And E2's independence must be demonstrable. Written by a different engineer, from the specification text, without reading the RTL, and structurally unlike it (20.2 §20's set-intersection-versus-priority-chain argument). A note in the evidence package stating who built it and from what is part of the evidence (§36).

21. Wrong Oracle — Our Own Model

Worked, on a specification ambiguity.

A passage admits two readings of when a particular obligation may be considered discharged. The design team read it one way. The verification team, reading the same passage, read it the same way — naturally, because they discussed it.

The models encode reading A. The design implements reading A. Every test passes.

A partner implemented reading B.

Four properties.

No amount of internal testing detects this. Not more tests, not more coverage, not formal proof — because every artefact in the programme encodes the same reading. 20.4 §16's mirroring failure, with the specification in the RTL's place.

The regression's silence was read as confirmation. The team concluded the reading was correct because nothing failed — and nothing could have.

This is the precise reason §4's sourced approach uses an implementation as the oracle. A reference implementation embodies one reading and behaves; testing against it surfaces a divergent reading as a behavioural mismatch, which a document comparison cannot do.

And the mitigation available without a reference implementation is §34's: treat ambiguity as a finding, record it, and resolve it externally — rather than resolving it internally and forgetting that a choice was made.

22. Pre-Silicon Compliance-Shaped Testing

Compliance-shaped work can begin long before silicon, and public industry material describes exactly this activity — verification IP intended to enable compliance and interoperability testing in simulation (§4, cited as a vendor/industry report rather than a Consortium statement).

What pre-silicon work can establish:

What it cannot establish: anything measured — the physical layer's electrical behaviour (§24), and any timing that depends on real silicon.

Two properties.

Pre-silicon is where negative testing is cheap. Injecting a malformed request or an illegal configuration is a few lines in simulation and a fixture problem in a lab. 20.1 §42's four negative-test categories are largely a pre-silicon activity.

And it is where an ambiguity is cheapest to discover. Running against a third party's model surfaces a divergent reading (§21) before either party has committed it to silicon, which is the difference between an errata discussion and a respin.

23. What VIP-Based Testing Can and Cannot Establish

The engineering question a team must answer about any external model, commercial or otherwise:

The last row is the one to press on. "Known-good" in §4's sourced sentence is a property somebody established. A model that is merely careful is E2; a model whose correctness has been established by an external process is E1 — and the difference is the difference between a documented internal claim and a citable one.

24. The Physical Layer's Compliance Questions

The physical layer's questions are measurements, and this chapter can name them without answering them.

Three notes.

Every row needs a specified limit, and §25 is why none is given here.

Package design being inside the concern is sourced — UCIe 2.0's contents include "Optimized package designs for interoperability and compliance testing" (§4). That means a compliance plan has a package dependency, which is unusual and worth planning for: the fixture is part of the evidence.

And the physical layer is where pre-silicon work runs out (§22). A plan that treats simulation results as physical-layer evidence has crossed §8's boundary, and it is the crossing least likely to be noticed because the simulation is so much easier to run.

25. Why This Chapter Gives No Electrical Numbers

No electrical threshold, eye mask, jitter budget, voltage limit, margin, data rate or timing number is given in this chapter, because none was established from the sources inspected (§3, §5).

Three reasons this is the right choice rather than a limitation.

A wrong electrical number is uniquely harmful. A wrong protocol claim produces a bug; a wrong electrical limit produces a design that either fails compliance or is over-designed at real cost, and the engineer who used it has no way to know which.

These numbers are revision- and variant-dependent. 8.6 §2's caveat applies with more force here: a number from one revision or one package variant is actively misleading in another.

And they are exactly the numbers most often quoted third-hand. Vendor material, conference slides and aggregators all carry electrical figures. A tutorial reproducing them lends them an authority they do not have — which is 13.1 §3's patents-are-not-normative position applied to measurement.

What a plan should do instead: take every limit from the specification revision it targets, record the clause in the matrix's specification-basis column (§14), and record the instrument and fixture in the evidence package (§36).

26. The Adapter Layer's Compliance Questions

Sourced context: the Adapter owns link state management and parameter negotiation, provides Arb/Mux when multiple protocols are supported, and optionally guarantees reliable delivery through CRC and link-level retry (20.1 §3).

The questions that follow, and each maps to a declared feature (§15):

Two notes.

Four of seven rows are configuration-dependent, which is why §14's matrix has a configuration column and §28 exists. A single "Adapter compliance: pass" row is meaningless for a device with a conditional feature set.

And negotiation is the row with the largest hidden scope. "Does negotiation reach the specified result" is a question about a pair of capability sets — so it is one row per pair the device must handle, and 20.2 §20's independent negotiation rule is what makes it checkable without asking the design.

27. The Protocol Layer's Compliance Questions

Sourced context: UCIe maps PCIe and CXL natively; UCIe 1.0 supported Streaming Protocols only in Raw Mode and 1.1 allowed them to use the Adapter on FDI (20.1 §3).

Two distinct question sets, and conflating them is the layer's characteristic error.

Three consequences.

A UCIe compliance plan should not reimplement PCIe's or CXL's rule sets. 20.1 §52's protocol-specific/protocol-independent split: those rules are extensive, subtle and specified elsewhere, with their own compliance ecosystems. Where a protocol VIP exists, it belongs at the protocol boundary.

But the transport questions are genuinely UCIe's, and they are the ones a UCIe plan owns: was the object conveyed intact, exactly once, in the required order, under the declared configuration.

And Raw Mode changes which layer owns which question (20.1 §51). A Streaming Protocol in Raw Mode has no Adapter in the path, so the reliability questions of §26 do not apply and the protocol layer's own mechanisms take their place. A matrix that does not record the mode cannot express that.

28. Interaction Coverage of the Claim

Every pair of declared features is a potential interaction, and §17's fifth row grows quadratically. Bound it the way 20.5 §31's cross rule bounds coverage.

The question, per pair:

If these two declared features interact incorrectly, what would a partner observe?

Worked, on four pairs of a plausible declaration:

Two notes.

Three of four pairs earn a test, which is a much higher hit rate than a coverage cross — because a declared feature is already a claim somebody chose to make, so its interactions are all plausible.

And the fourth row's reasoning must be recorded. 20.5 §52's waiver discipline: an untested pair with a written reason is a decision; an untested pair with no record is an omission, and at integration nobody can tell which it was.

29. The Interoperability Matrix

A different artefact from the conformance matrix, answering a different question.

A row's columns:

Two notes.

The negotiated result column is the one that carries the most information. Two devices' capability sets intersect to a specific configuration — and that configuration may not be one either party tested alone. 20.2 §20's independent negotiation rule predicts it; the matrix records what actually happened.

And features exercised is usually a subset of features declared. A pairing where the partner does not support reliability exercises none of the reliability rows — so an interoperability pass says nothing about them, and a matrix that does not record which features were in play invites exactly that over-reading.

A worked excerpt, illustrative, with partners anonymised:

ILLUSTRATIVE interoperability matrix excerpt.
 
  PARTNER  THEIR   OUR    CONFIGS      NEGOTIATED     FEATURES      RESULT   ISSUES
           REV     REV    OFFERED      RESULT         EXERCISED
  -------- ------- ------ ------------ -------------- ------------- -------- ---------------
  X        R(n)    R(n)   nominal,max  nominal, 1 pr  F1 F2 F3 F9   PASS     --
  X        R(n)    R(n)   max only     max,     1 pr  F1 F2 F3 F9   PASS     --
  Y        R(n-1)  R(n)   nominal      nominal, 1 pr  F1 F2 F3      PARTIAL  I-1 (ambiguity A2)
  Y        R(n-1)  R(n)   max          NO AGREEMENT   --            PASS *   * correct refusal
  Z        R(n)    R(n)   nominal,max  nominal, 2 pr  F1 F2 F3 F9   FAIL     I-2 (attributed: Z)
  Z        R(n)    R(n)   reliability  nominal, 2 pr  + F6 F7       FAIL     I-3 (UNATTRIBUTED)
 
READINGS:
  X, both rows    : two configurations, same partner -> two independent cells (§30)
  Y row 1         : PARTIAL — worked, with a known ambiguity in play (A2, §34)
  Y row 2         : capability sets had no common configuration; BOTH refused
                    cleanly -> this is a PASS, not a failure (§32 row 4)
  Z row 1         : attributed to Z via §33's procedure -> Z outside its envelope
  Z row 2         : UNATTRIBUTED -> both sides inside their envelopes ->
                    candidate specification ambiguity, escalate (§32 row 3, §35)
 
WHAT THIS MATRIX DOES NOT SUPPORT:
  - any claim about a partner not listed                      (§30)
  - any claim about F4, F5, F8 — never exercised by any pair
  - any claim about R(n+1), or about Y at R(n)                 (§40)
  - transitivity: X-works and Z-fails says nothing about X-Z   (§30)

Four readings.

The two X rows are two independent cells, not one result with two configurations. Same partner, same revisions, different negotiated configuration — and each is its own observation (§30).

The Y second row is a pass, and it is the row most teams file as a failure. No common configuration, both sides refused cleanly — which is 20.2 §24's refusal path working exactly as it should (§32 row 4).

The Z second row is the valuable finding in the whole matrix. Both sides inside their own conformance envelopes, and the pairing fails — which is a candidate specification ambiguity, and it is only reachable as a finding because both parties have conformance matrices to check against (§32 row 3).

And the what this does not support block is part of the artefact. Three declared features were never exercised by any pairing; their absence from the matrix is the claim's boundary (§8), and stating it is what stops the matrix being read as "interoperable".

30. Interoperability Is Pairwise

An interoperability result is an observation about one pair, at named revisions, in named configurations. It does not generalise — not to another partner, not to another configuration, and not to another revision of either party.

Three reasons, and the third is the one people resist.

Each implementation makes its own interpretive choices (§21). Working with partner A says both of you resolved the ambiguities compatibly; it says nothing about partner B, who may have resolved them differently — and both may be conformant.

Each pairing negotiates to its own configuration (§29). A pair that lands on a narrow common configuration exercised that one, and the wide configuration remains untested by that pairing.

And a pass is not transitive. A works with B, and B works with C, does not imply A works with C. Each pair resolved a different set of ambiguities and negotiated a different configuration; there is no argument that composes them. This is why an interoperability programme is a matrix rather than a list — the cells are independent.

31. Wrong Interoperability Claim — One Successful Pair

Worked. A device interoperates successfully with one partner, at one revision, in the configuration their capability sets happened to negotiate. The claim made is "interoperable."

Four things that claim overstates.

One pair became "any partner." §30. The next partner resolves a different ambiguity and the claim fails, publicly, in their system.

One configuration became "all configurations." The pairing negotiated, say, a narrow width with a single protocol. Every declared feature the pairing did not exercise is untested by this evidence (§29's features-exercised column).

One revision became "the standard." Both parties implemented one revision. A partner on a different revision is a different experiment (§40).

And a successful pairing hides the asymmetry of failure (§32). The pairing worked, so nobody had to determine who would have been at fault — and that determination is where the real interoperability work is.

The honest claim: "demonstrated interoperability with implementation X, revision R, in configurations C1 and C2, exercising features F1–F4." Long, specific, and defensible — and a customer can tell whether it covers their case.

32. The Asymmetry of an Interoperability Failure

When two devices do not interoperate, exactly one of four things is true — and they have completely different owners.

Three notes.

Row 4 is the one most often misdiagnosed as a bug. Two conformant devices with no common configuration should fail to establish a link, cleanly and explicitly — which is 20.2 §24's refusal path. A "failure" that is a correct refusal is a success, and a plan that treats every non-working pairing as a defect will chase it.

Row 3 is the valuable finding and the hardest to reach. It requires both parties to demonstrate conformance independently, which is exactly the evidence §14's matrix produces — and without both matrices, row 3 is indistinguishable from rows 1 and 2.

And the default assumption in the absence of evidence is mutual suspicion, which is expensive. Two teams each convinced the other is at fault, with no shared oracle, is the failure mode the reference-implementation approach of §11 exists to break.

33. Who Is Wrong — Determining It

A procedure, and it is the practical core of interoperability work.

1 — Establish the negotiated configuration, independently, from both sides' observations. 20.2 §20's independent rule predicts what the two capability sets should have agreed; a mismatch between prediction and outcome localises to whichever side's negotiation is wrong, before any traffic is examined.

2 — Determine whether the pairing should have worked at all. §32 row 4: if the capability sets have no common configuration, the correct outcome is an explicit refusal. Check whether both sides refused.

3 — Find the first divergence, per side. 20.1 §60's engine, run on each side's own observations. Two first-divergence reports, at two boundaries, on the same event — and the earlier one is where to look.

4 — Compare each side's behaviour against its own conformance matrix. A device behaving outside its own declared and demonstrated envelope is the candidate (§14).

5 — If both sides are inside their envelopes, the specification is ambiguous (§32 row 3). Escalate rather than negotiate a private workaround (§35).

And the enabling condition for all five steps: both sides must be able to observe their own boundaries and produce a first-divergence report. 20.1 §7's four-monitor architecture is what makes a device a cooperative interoperability partner rather than a black box — and it is worth building for that reason alone.

The procedure as an attribution function, so the outcome is a category rather than an argument:

ILLUSTRATIVE attribution procedure. Inputs are each side's OWN observations
plus each side's OWN conformance matrix. No shared oracle is assumed.
 
INPUT   ours   = { negotiated_observed, first_divergence, conformance_matrix }
        theirs = { negotiated_observed, first_divergence, conformance_matrix }
        rule   = independent negotiation rule (20.2 §20)
 
STEP 1  predicted = rule(our_capabilities, their_capabilities)
        if ours.negotiated_observed   != predicted -> ATTRIBUTE: US   (negotiation)
        if theirs.negotiated_observed != predicted -> ATTRIBUTE: THEM (negotiation)
        if predicted == NO_AGREEMENT:
            if both sides refused cleanly          -> RESULT: CORRECT REFUSAL
            else                                   -> ATTRIBUTE: whichever did not
 
STEP 2  earlier = min_by_event(ours.first_divergence, theirs.first_divergence)
        -- NOT by cycle; the two sides have unrelated clocks (20.4 §46)
 
STEP 3  side = owner_of(earlier)
        if behaviour_at(earlier) outside side.conformance_matrix.envelope:
            ATTRIBUTE: side                        -- outside its own claim
 
STEP 4  if both sides' behaviour is INSIDE their envelopes:
            RESULT: CANDIDATE SPECIFICATION AMBIGUITY
            -> record in the ambiguity register (§34)
            -> escalate (§35 path 1), bilateral stopgap optional (§35 path 2)
 
STEP 5  if neither side can produce a first_divergence:
            RESULT: UNATTRIBUTABLE — an OBSERVABILITY gap, not a protocol one
            -> the fix is instrumentation (19.6 §43), on whichever side lacks it

Three notes.

Step 2 orders by event, not by cycle. The two devices have unrelated clocks and unrelated cycle counts; the ordering must come from the causal chain — request, transmit, arrival, response — which both sides can agree on (20.4 §46's argument applied across a die boundary rather than across a clock domain.)

Step 4 is the outcome worth reaching, and it is only reachable when both parties have matrices. Without them, step 4's condition cannot be evaluated and the investigation stalls at mutual suspicion (§32's last note).

And step 5 is the outcome nobody plans for. Two black boxes that disagree, with no divergence report on either side — and the finding is that the observability is inadequate, which is a design gap rather than a protocol one, and it is the one gap no amount of further testing closes.

34. Specification Ambiguity as a Finding

An ambiguity is a finding, with the same status as a bug, and it must be recorded when it is encountered rather than resolved silently.

The record, per ambiguity:

Three properties.

The observable difference field is what makes the record actionable. Two readings that produce identical behaviour are a documentation nuisance; two that differ observably are an interoperability risk with a specific test that would expose it.

Recording that our models assume the same reading as our design is the point (§21). It makes the mirroring explicit, so nobody later mistakes the regression's silence for confirmation.

And an ambiguity register is a product of a verification programme. 20.5 §7's requirement extraction is where they are found — every requirement whose extraction required a judgement call is a candidate, and the ones that took a meeting to settle are almost certainly ambiguities.

35. Escalating an Ambiguity

Two paths, and choosing the wrong one is a commercial decision disguised as an engineering one.

Path 1 — escalate to the Consortium. Produces a clarification or an errata that applies to everybody. Slow, and it is the only path that resolves the ambiguity rather than working around it.

Path 2 — agree bilaterally with the partner. Fast, produces a working pair, and creates a private interpretation that neither party's conformance evidence covers. The next partner meets the ambiguity again.

Three rules.

Path 2 is legitimate as a stopgap and must be recorded as one. §34's status field, plus §43's deviation record. A bilateral agreement that is not recorded becomes an undocumented interpretation that outlives the people who made it.

Path 1 should be taken in parallel, not instead. The bilateral fix unblocks the pair; the escalation fixes the standard, and only the second prevents the third partner from hitting it.

And a bilateral agreement must never be described as conformance. §14's basis-of-criterion column: an interpretation agreed between two vendors is neither specification-based nor reference-based.

36. The Evidence Package

A claim is only as good as somebody else's ability to check it. An evidence package is what makes a conformance or interoperability claim checkable by a reader who was not there.

Three notes.

The reproduction procedure is the test of the whole package. A result nobody can re-run is an assertion. Writing the procedure frequently reveals that a result depended on an undocumented setup — which is §39.

The confidence-boundary section is the one that distinguishes a professional package from a marketing document. Stating what the evidence does not reach is what makes the rest of it credible.

And the ambiguity register belongs in the package rather than in an internal wiki. A partner reading it can say "we chose B for that one" — which converts a latent interoperability failure into a conversation before integration.

The package as a concrete structure, because a package whose shape is left to whoever assembles it will omit whatever was inconvenient:

ILLUSTRATIVE evidence-package structure.
 
  00_CLAIM.md
       the claim, in §49's block form: claim / evidence / class / not-run /
       deviations / ambiguity / boundary
 
  01_DECLARATION/
       declaration.yaml            features, conditions, parameter ranges, revision
       capability_readback.log     what the silicon reported (§15's check 2)
       declaration_check.log       the cross-check result
 
  02_MATRICES/
       conformance_matrix.csv      §14's ten columns, one row per §17 row kind
       interop_matrix.csv          §29's eight columns, one row per pairing
       gaps.md                     every NOT RUN and INCONCLUSIVE, with why
 
  03_ORACLES/
       oracle_<n>_description.md   what it is, WHO built it, FROM WHAT,
                                   which revision, evidence class (§18, §20)
 
  04_CONFIGURATIONS/
       setup_<id>/requested.yaml   what was asked for
       setup_<id>/active.log       what was READ BACK as active (§38)
       setup_<id>/provenance.md    how it was established
 
  05_RESULTS/
       <test>/result.yaml          result, oracle ref, basis of criterion
       <test>/raw/                 logs, traces, measurement records
       <test>/repro.sh             the reproduction procedure (§37)
       <test>/versions.yaml        design, env, tools, seeds
 
  06_REGISTERS/
       ambiguity_register.csv      §34's eight fields
       deviation_register.csv      §43's seven fields, INCLUDING disclosure
 
  07_BOUNDARY.md
       §8's table, filled: what this package does NOT claim
 
CHECKABLE BY A READER WHO WAS NOT THERE:
  - can they re-run any result?           -> 05/*/repro.sh + versions.yaml
  - can they tell what decided it?        -> 03/ + result.yaml's oracle ref
  - can they tell if it is conformance?   -> result.yaml's basis of criterion
  - can they tell what is NOT claimed?    -> 02/gaps.md + 07_BOUNDARY.md

Three properties of that structure.

Directory 03 exists separately from 05 deliberately. An oracle is referenced by many results; describing it once, with who built it and from what, is what makes the evidence class assignable — and it is the section most often missing entirely (§39).

Directory 04 keeps requested and active configuration in separate files. 19.6 §21's distinction: a result whose active configuration was never read back cannot be known to have run in the intended setup.

And the four questions at the bottom are the package's acceptance test. A package that cannot answer all four is not evidence — and reviewing it against those four questions takes minutes, which is the point of fixing the structure in advance.

37. Reproducibility

Every result must be re-runnable by somebody else. Five things that must be recorded, and the last two are the ones omitted.

Two notes.

A randomised result without its seed is not evidence. 20.5 §54's point that seeds explore rather than prove applies here differently: a conformance result from a randomised run must be re-runnable to the same outcome, and only the seed makes it so.

And "anything a script defaulted" is the killer. A harness with an unset parameter that fell back to a default ran a configuration nobody chose — and if the default changes, the result changes and nobody knows why. §39.

38. Configuration Provenance

Sourced context: the specification "details architectural specification attributes to define system setups" (§4, §13). So a conformance configuration is a specified thing, and the package must record which one was used and how it was established.

Two notes.

The third and fourth rows are different quantities, and recording both is what catches a configuration that was requested and not achieved. 19.6 §21's requested/validated/active distinction: a test that ran in a configuration different from the one it intended is an invalid result, and only reading back the active configuration detects it.

And reading the device's own report closes the loop between the declaration and the silicon (§13). A declared capability that the capability structure does not report is a declaration error, findable before any test runs.

39. Wrong Evidence Package — Results Without Configuration

WRONG package excerpt:
 
  Test:     protocol conformance suite
  Result:   PASS, 312/312
  Date:     2026-07-22
  Notes:    run on the standard bench

Five things a reader cannot do with that.

Cannot re-run it. No design version, no environment version, no tool versions, no seeds (§37).

Cannot tell what configuration it ran in. "The standard bench" is a local convention; its defaults change and nobody records when. So the result may not even be reproducible by the same team six months later.

Cannot tell which features it covers. 312 tests against an unnamed feature set — so it cannot be mapped to the declaration (§15), and a feature the suite happens not to cover is silently unevidenced.

Cannot tell what the oracle was (§20), so cannot assign an evidence class (§18). This is the failure that matters most, because the whole distinction between E1 and E5 is invisible.

And cannot tell what revision it was against (§40), so cannot tell whether it is still valid.

The result is not wrong. It is unusable as evidence — and the difference between a usable and an unusable package is a few structured fields recorded at run time rather than reconstructed afterwards.

40. Version and Revision Discipline

Every claim is against a revision. Four things a package must pin, and a claim that pins none has no expiry.

Three notes.

Rows 1 and 2 differing is common and must be visible. A test suite written against one revision, run on a design implementing a later one, produces failures that are revision differences rather than defects — and reporting them as either without checking is wrong in both directions.

UCIe 2.0's compliance framework is described as "initial" (§4, §10). A framework that grows means a package's coverage of it is revision-relative, so a claim's validity does not survive a revision change automatically.

And this is 19.6 §54's version-compatibility discipline applied to a claim rather than to a register. The same three rules hold: never change what an existing claim means, add rather than reinterpret, and version the claim rather than the implementation.

41. Wrong Claim — Compliance Without a Revision

Worked. A device is described as "UCIe compliant" with no revision named.

Three ways that is read, all of them by somebody who matters.

A customer reads it as the revision they implement. If that is later than the device's, features they expect are absent and the claim looks false.

A partner reads it as the revision they implement. §40's rows 1 and 2 — the interoperability attempt fails and both parties believe the other overstated.

And an auditor reads it as the current revision, which it almost certainly is not, because revisions arrive faster than compliance programmes.

The correction is one clause and it costs nothing: name the revision, name the features, name the configurations. A specific claim is defensible and a general one is not — and the specific one is also more useful, because a reader can determine whether it covers their case.

42. A Regression Is Not a Compliance Run

Same tests, sometimes the same environment, and a different activity.

Two consequences.

A compliance run is frozen. Re-running it after a design change produces a new result, not a confirmation of the old one — and a package that mixes results from several design versions is not evidence about any of them.

And the two must not share a report. A dashboard showing regression and compliance results together invites the substitution §19 makes: the regression's large green number lends authority to the compliance rows beside it.

43. Deviations and Errata

A known non-conformance is manageable. An undocumented one is not.

The record, per deviation:

Three rules.

A deviation belongs in the evidence package (§36), not only in an internal tracker. A package that omits a known deviation is not incomplete; it is misleading.

The disclosure field is the one with consequences beyond engineering. A known deviation not disclosed to a partner who then integrates against it is a commercial and possibly contractual matter, and it is not one an engineering team should decide alone.

And a bilateral interpretation (§35 path 2) is recorded here as well as in the ambiguity register. From the standard's point of view it may be a deviation; from the pair's point of view it works. Both facts belong in the record.

44. Wrong Waiver — an Undocumented Deviation

Worked. A device does not implement a required refusal behaviour: it accepts a request it should reject. The team knows, judges it low-risk because no partner has exercised it, and does not record it.

Four consequences.

The conformance matrix has a row that reads pass, because the test that would have caught it was not written — and 20.5 §50's classification never happened because there was no coverage item.

The next engineer does not know. The judgement was made once, by people who have moved on; the behaviour is now simply how the device works.

A partner exercises it and gets accepted traffic that should have been refused. The failure appears in their system, downstream of the acceptance, as data corruption or a protocol violation they cannot attribute.

And the disclosure question was never asked (§43). By the time it matters, the answer is that a partner integrated against undisclosed non-conformant behaviour — which is a much worse position than having disclosed a known deviation.

45. Test Selection

Four inputs, in priority order:

1 — the feature declaration (§15). Every declared feature needs §17's five row kinds. This is the mandatory core and it is fully determined by the declaration.

2 — the specification's own defined setups (§13, §38). Where the specification defines configurations, those are the configurations to test in — a plan that invents its own is doing verification.

3 — the interaction pairs that pass §28's question. Bounded, justified, recorded.

4 — the ambiguity register (§34). Every ambiguity with an observable difference is a test worth running against any external oracle available, because it is the highest-value information per test in the whole plan.

And the input that is deliberately last: internal coverage gaps. 20.5's uncovered bins are a verification concern. Some map to conformance rows and most do not — and letting the coverage report drive the conformance plan inverts §14's structure, which is organised by claim rather than by bin.

The selection as a procedure, so the plan is derived rather than assembled:

ILLUSTRATIVE selection procedure. Output is a matrix, not a test list — the
rows exist before the tests do, and a row with no test is a NOT RUN (§48).
 
INPUT   decl        = the feature declaration (§15)
        setups      = the specification's defined setups (§13)
        ambiguities = the ambiguity register (§34)
        pairs       = declared feature pairs passing §28's question
 
STEP 1  for each declared feature f in decl:
            for each row_kind in { positive, negative, inertness, boundary }:
                for each setup s in setups where f applies:
                    emit_row(f, row_kind, s)
        -- MANDATORY CORE. Fully determined by the declaration. No judgement.
 
STEP 2  for each non-declared feature f that the silicon reports (§15 check 2):
            emit_row(f, inertness, all_setups)
        -- an implemented-but-undeclared feature must be shown inert
 
STEP 3  for each pair (a,b) in pairs:
            emit_row(pair(a,b), interaction, nominal_setup)
        -- BOUNDED by §28's question; the REJECTED pairs are recorded too
 
STEP 4  for each ambiguity A in ambiguities where A.observable_difference != none:
            emit_row(A, ambiguity_probe, setup_that_exposes_it)
        -- highest information per test in the plan; run against ANY external
           oracle available (§45)
 
STEP 5  annotate every row with: oracle available? -> class (§18)
        rows with no external oracle          -> basis of criterion = INTERNAL
        rows with no oracle at all            -> RESULT = NOT RUN, with a gap
 
STEP 6  record what was NOT emitted and why:
            rejected feature pairs (§28's second note)
            setups excluded, and on what basis
            ambiguities with no observable difference
 
OUTPUT  the conformance matrix, pre-populated, every row with a result value
        drawn from { pass, fail, not run, inconclusive }  (§48)

Four notes.

Step 1 requires no judgement, which is why it is the mandatory core: the declaration determines it entirely, so it cannot be truncated by schedule pressure without the truncation being visible as NOT RUN rows.

Step 4 is the highest-value step and the one no coverage report would produce. An ambiguity with an observable difference is a test whose result tells you whether your reading matches an external one — which is the single thing internal verification cannot establish (§9).

Step 5 is what prevents §19's overstated row. Assigning the class before running the test means a row with no external oracle is labelled internal from the start, rather than being labelled after somebody notices.

And step 6 is what makes the plan finishable and honest (§46). A plan that records what it excluded can be reviewed; one that implies completeness cannot.

46. Wrong Selection — Everything, or the Happy Path

Two failure modes, opposite in shape and identical in outcome.

"Test everything." Every feature, every configuration, every pair, every corner. The plan does not finish, so it is truncated under schedule pressure — and what gets cut is chosen by whatever is left when time runs out rather than by importance. The result is an arbitrary subset with no stated rationale.

"Test the happy path." The positive rows of §17 and none of the others. Every refusal path, every inertness property and every boundary is unevidenced — and those are precisely the rows that fail at integration, because a partner exercises them and the device has never been asked to.

The bounded middle: §45's four inputs, with the untested pairs recorded (§28's second note). A plan that states what it did not test is finishable and honest; one that implies completeness is neither.

47. The Internal Conformance Gate

Seven conditions. All must hold.

1 — The feature declaration is complete and matches the capability structure (§15, §38). No declared feature the silicon does not report; no reported capability left undeclared.

2 — Every declared feature has all five row kinds in the matrix (§17), each with a result — including not run, explicitly.

3 — Every row's evidence class is recorded (§18), and every row whose basis of criterion is internal is marked as such (§14).

4 — Every configuration's provenance is recorded, including the read-back active configuration (§38).

5 — Every result is reproducible — versions, tools, seeds, full configuration (§37).

6 — The ambiguity register and the deviation register are current, with disclosure status on each deviation (§34, §43).

7 — The confidence boundary is written down (§8), and the claim being made does not exceed it.

And the gate's most important property: none of the seven is "all tests pass." §49.

48. Honest Sign-Off Criteria

Four result values, not two, and the two extra ones are what make a sign-off honest.

Three notes.

"Not run" is acceptable and "silently absent" is not. A feature with no matrix row is indistinguishable from a feature that passed. An explicit not run narrows the claim, which is the correct response to having not tested something.

"Inconclusive" is the value most often collapsed into pass. 20.4 §30's rule: a model must be able to say it does not know. A test whose oracle was ambiguous, whose measurement was marginal, or whose configuration could not be established did not pass — and the pressure to record it as a pass is exactly why the value must exist.

And the sign-off states the claim, not a verdict. "We claim X, evidenced by Y, bounded by Z" is signable. "Compliant" is not, because §7 has already established that the word carries an institutional meaning the evidence does not reach.

49. Wrong Sign-Off — "All Tests Pass"

Four things that statement does not establish, each of which somebody will assume it does.

That the tests covered the declaration. A suite passing says nothing about which features it exercised. §39's 312-of-312 is the canonical form.

That the oracle was external. All tests passing against our own models is §9's claim — a strong verification result and not a conformance one.

That the configurations were the specified ones (§38). Passing in a configuration nobody specified is a verification result in an arbitrary setup.

And that nothing is known to be wrong. A team may hold a deviation register (§43) while every test in the suite passes, because the suite does not test the deviation. "All tests pass" and "we know of a non-conformance" are simultaneously true, and only a sign-off structured as §48's claim-plus-boundary exposes it.

The honest replacement, and it is shorter than it looks:

CLAIM:      Features F1–F6, revision R, configurations C1–C3.
EVIDENCE:   Conformance matrix <ref>; evidence package <ref>.
CLASS:      F1–F4: E2 (independently constructed oracle, <who/from what>).
            F5–F6: E4 — INTERNAL ONLY, no conformance claim made.
NOT RUN:    F7 (declared, untested — claim excludes it).
DEVIATIONS: D1 (disclosed to partners <list>), D2 (open, undisclosed).
AMBIGUITY:  A1, A2 open; A3 escalated <ref>.
BOUNDARY:   No physical-layer measurement evidence. No E1 evidence.
            No interoperability evidence beyond partner X, revision R.

That block is a claim somebody can check, dispute, or rely on — which is the entire purpose of the activity.

50. Post-Silicon and the Lab

Silicon changes what can be established, in both directions.

Three notes.

Rows 5 and 6 are why 19.6 §43's observability contract has a compliance payoff. A device whose stall reasons, first-fault record, active configuration and resource state are readable can participate in §33's who-is-wrong procedure in a lab. One that cannot is a black box in exactly the situation where attribution matters most.

Row 4 is why negative testing is a pre-silicon obligation (§22). A refusal path not tested before tape-out is likely never tested, because inducing an illegal stimulus in a lab requires equipment that may not exist.

And row 7 makes lab evidence harder to package (§37). A silicon result's "seed" is a set of environmental conditions, and recording them precisely enough for reproduction is a discipline in itself.

51. What Each Side Uniquely Adds

Two lists, and a plan needs both.

Silicon uniquely adds: all physical-layer evidence; behaviour across real process, voltage and temperature; interaction with real packages and real fixtures (§24's package dependency); and interaction with real partner implementations, which is the only source of E3 evidence.

Simulation uniquely adds: complete internal observability, so 20.1 §60's first-divergence analysis is available for every failure; arbitrary and precise fault injection (20.2 §43's seven points); cheap negative testing; exact reproducibility; and the ability to test a configuration before it exists in silicon.

The consequence for sequencing. Everything simulation can establish should be established before tape-out — not because silicon is expensive, but because silicon is less observable. A protocol ambiguity found in simulation is a discussion; found in a lab, against a partner, it is a discussion conducted through two black boxes.

52. Debug When a Conformance Test Fails

A conformance failure has one extra hypothesis that a regression failure does not: the test may be wrong about the specification.

Five hypotheses, in the order to eliminate them:

1 — The configuration was not what the test intended (§38). Read back the active configuration. A test that ran in the wrong setup produced an invalid result, not a failure.

2 — The revision differs (§40). The test derived from one revision, the design implements another. Check both pins before anything else technical.

3 — The oracle is wrong. For E2, this is a real and common outcome: the independently constructed model made an error, or resolved an ambiguity differently than the design. §34 — and this hypothesis is the reason E2 evidence must record who built the oracle and from what (§20).

4 — The specification is ambiguous (§32 row 3). Both readings defensible. Record it and escalate (§35).

5 — The design is non-conformant. The remaining hypothesis, and the one to act on after the first four are eliminated.

And the ordering matters commercially. Acting on hypothesis 5 first produces a design change; if the actual cause was hypothesis 3, the design has been changed to match a wrong oracle — which is a defect introduced by the conformance process itself.

53. Debug Checklist

A conformance or interoperability result is being investigated. In order:

1. Which revision does the design implement, and which did the test derive from (§40)?
2. What configuration was requested, and what did the read-back say was active (§38)?
3. Is the configuration one the specification defines, or one the plan invented (§13, §45)?
4. What was the oracle, and what is its evidence class (§18, §20)?
5. Who built the oracle, from what, and is it independent of our reading (§20)?
6. Does the failure appear against a different oracle, or only this one?
7. Is the requirement clearly stated in the specification, or does it admit two readings (§34)?
8. If two readings: what does each predict observably, and which did we implement?
9. Is this feature declared (§15), and does the capability structure report it?
10. Was this configuration inside the declared envelope, or outside it (§16)?
11. For an interoperability failure: what did each side's negotiation predict (§33 step 1)?
12. Should the pairing have worked at all, or is the correct outcome a refusal (§32 row 4)?
13. What is each side's first divergence, from its own observations (§33 step 3)?
14. Is either side outside its own conformance envelope (§33 step 4)?
15. Is the result reproducible — versions, tools, seeds, configuration (§37)?
16. Is there an existing deviation record covering this (§43)?
17. Is there an existing ambiguity record covering this (§34)?
18. Is the result a pass, a fail, or inconclusive (§48)?
19. If inconclusive: was it the oracle, the measurement, or the configuration?
20. Does the claim being made still hold given this result, and if not, has the claim been narrowed (§31)?
21. Has the disclosure question been asked (§43)?
22. Would this failure have been found pre-silicon, and if so why was it not (§51)?

54. Common Misconceptions

"Our regression passes, so we are compliant." The regression demonstrates that the design is self-consistent with our reading of the specification. Four independent reasons it cannot demonstrate more — our oracle, our coverage plan, our peer, and our resolution of every ambiguity (§9).

"Compliant, conformant and interoperable mean roughly the same thing." Three different claims with three different evidence types and three different sets of people who can dispute them (§6) — and "certified" is a fourth, institutional, thing (§7).

"We interoperate — we tested against a partner." With one partner, at one revision, in one negotiated configuration, exercising some of the declared features. The result does not generalise and is not transitive (§30, §31).

"If two compliant devices do not interoperate, one of them is lying." One of four things is true, and two of them involve nobody being wrong: the specification may be ambiguous, or the capability sets may simply have no common configuration — in which case a clean refusal is the correct behaviour (§32).

"A specification-derived model is an external oracle." Only if its construction was genuinely independent. A model written by the same person from the same reading is our model with a different label (§18's E2 caveat).

"More tests means stronger evidence." 312 of 312 against an unnamed oracle in an unnamed configuration is unusable as evidence (§39) — and quantity against our own model is many instances of one claim (§19).

"All tests pass" is a sign-off. It establishes nothing about coverage of the declaration, the oracle's class, the configurations, or whether the team already knows about a non-conformance (§49).

"A known issue nobody has hit is not worth recording." Then the matrix reads pass, the next engineer does not know, a partner hits it, and the disclosure question is answered for the first time after they integrated (§44).

"Simulation results cover the physical layer." Nothing measured can come from simulation, and this is the boundary crossing least likely to be noticed because the simulation is so much easier to run (§24, §50).

"We can settle an ambiguity with the partner and move on." That is a legitimate stopgap and it creates a private interpretation neither party's conformance evidence covers — and the third partner meets the same ambiguity (§35).

"A conformance test failure means the design is wrong." It is the fifth hypothesis, not the first. Configuration, revision, a wrong oracle and specification ambiguity all come before it — and acting on the design first can introduce a defect to match a wrong oracle (§52).

"UCIe compliant" is a claim you can make about a product. Name the revision, the features and the configurations, and do not use certification language for a programme whose existence and terms you have not confirmed with the Consortium (§7, §41).

55. Understanding Check

56. Summary and What Comes Next

Verification proves the design matches our understanding. Conformance proves our understanding matches the specification. Interoperability proves it matches somebody else's. No amount of the first substitutes for either of the others.

What the Consortium's published material establishes: compliance testing has been part of the standard's purpose since 1.0 and its purpose is interoperability; 1.1 added architectural attributes and registers for test plans; 2.0 establishes an initial framework for physical, adapter and protocol compliance testing; and the goal is validating a DUT's main-band supported features against a known-good reference implementation.

What it does not establish, and this chapter therefore does not invent: any suite name, test identifier, test count, pass criterion, instrument, electrical threshold, workshop procedure, certification programme, logo programme, certified-products list or certification authority. Every criterion here is labelled internal.

A green regression cannot demonstrate conformance for four independent reasons — our oracle, our coverage plan, our peer, and our resolution of every ambiguity — and each survives making the regression better.

The reference-implementation oracle is architecturally necessary, because it is the only thing that surfaces a divergent interpretation as a behavioural mismatch.

An interoperability result is one pair, one revision, one negotiated configuration, some features — and it is neither general nor transitive.

When two conformant devices do not interoperate, two of the four possible causes involve nobody being wrong, and a clean refusal on incompatible capability sets is correct behaviour rather than a defect.

Record ambiguities and deviations as findings, with disclosure status, because the alternative is a partner integrating against undisclosed non-conformant behaviour.

And sign off on a claim, not a verdict. "All tests pass" establishes nothing about the declaration's coverage, the oracle's class, the configurations, or what the team already knows is wrong.

Module 20 is complete. The link has been contracted, composed, asserted, modelled, measured, exercised and — as honestly as public sources permit — positioned against conformance. What remains is the part no methodology prevents: a link that does not come up, a training sequence that never converges, a credit counter that drifts, a throughput number that is inexplicably low, and a trace with ten thousand cycles in it and no obvious cause. The next module works those failures from the evidence backwards — the seven families that account for almost every UCIe bug, each approached as a real trace with a real root cause rather than as a checklist.

• 21.1 — Link Bring-Up Failures — bring-up that hangs, and the debug methodology for it.

Browse the full path on the UCIe tutorials index.

Sources for the Consortium statements quoted in §4: UCIe Consortium — Specifications · UCIe Consortium Releases 2.0 Specification