A specification whose job is to select from and constrain the standards that already exist, rather than to invent a new one or to crown an existing one as canonical.
⟨Per Martin Pompéry, 2026-11-06, during the ingest of the PACT Technical Specifications v2.2: “there are no canonical product IDs — there are only several, and the Tech Specs are in that sense an interoperability profile.” The term does not occur in the PACT documents; it is the frame, supplied orally, under which they were read.⟩
The page exists because the wiki kept producing the same wrong finding in different places: standard X does not define Y, therefore there is a gap. For a profile that inference is invalid. A profile’s substance is which existing pieces it picks, how tightly it constrains them, and what it deliberately leaves to the layer below.
The four moves
- Selection. Of the available standards for a layer, name one.
- Constraint. Of the named standard, allow a subset — usually a small one, because the full grammar is what makes independent implementation expensive.
- Obligation levels. Mark each element MUST / SHOULD / MAY, so that a mandatory floor is separable from the optional surface.
- Tolerance. Specify what a receiver does with input it did not expect. This is the move that is most often omitted from descriptions of profiles and is the one that decides whether a heterogeneous network actually interoperates.
The worked example
The PACT Technical Specifications for PCF Data Exchange
v2.2 invent almost nothing.
They profile HTTPS, OAuth2 Client Credentials (RFC 6749 §4.4), Bearer tokens
(RFC 6750), OpenID Connect discovery, a named subset of the OData v4
$filter grammar (six operators, one lambda, eight properties), RFC 8288
Link pagination, CloudEvents in Structured Content Mode, URN namespaces
for GTIN / CAS / IUPAC InChI / buyer- and vendor-assigned codes, UN CPC 2.1,
ISO 3166, SI units, IPCC AR versions, UUIDv4 and ISO 8601 — the full table
is on that page.
“The scope of the HTTP API is minimal by design” (§7.1).
It is also the worked example of move 4. Postel’s law — conservative in what you send, liberal in what you accept — governs the document: a host “should strive to accept an event”; filtering is best-effort and may be ignored; partial results (HTTP 202) are legal; a sender “should not rely on” the receiver responding. Against that stands a four-action mandatory floor over HTTPS. ⟨Per Martin Pompéry, 2026-11-06.⟩
⟨Inference: forty-odd independently built conformant implementations are what the floor-plus-tolerance construction bought. The known cost — tolerant receivers let divergent sender behaviour harden into de-facto permanence — is ⟨Background⟩; no PACT document discusses it.⟩
What a profile can fix, and what it cannot
The boundary established by checking the decision-grade criteria against PACT v2.2, and the most transferable thing on this page:
| Representation — units, boundaries, vocabularies, identifier schemes, envelopes, lineage fields | a profile fixes this well, and PACT does |
| Accountability — verification, conservation of quantities, audit trail, non-repudiation | a profile cannot reach this, and PACT declares it out of scope (§7.2.1) |
The asymmetry is structural, not an oversight. Representation is a question
about symbols, and agreement on symbols is exactly what selection and
constraint produce. Accountability is a question about state — who holds
what, who already claimed it, what happened before — and a document-moving
profile has no state to reason over. PACT moves ProductFootprint
documents; nothing in it could detect the same emissions being claimed
twice, because the
architectural exclusion
of 2022 ruled out persistent state before the protocol was written.
⟨Inference: where accountability was available as a standard to profile — JWS over the payload, for instance, as cheaply as OData was adopted — PACT did not pick it. So the profile frame defends the specification against the charge of incompleteness, and simultaneously sharpens the one charge it cannot dismiss: the omissions in §7.2.1 are choices, not gaps. See the confidentiality gap.⟩
Profiles stack — and that is where the n² count actually lives
- Catena-X CX-0136 is a profile of the PACT Pathfinder Framework, which is itself a profile. See Catena-X.
- iLEAP rode inside PACT as a data-model extension — PACT’s §5.5 extension mechanism being precisely the room a downstream profile needs — until v1.1.0 made a standalone API mandatory. See iLEAP.
- The PIIR claim on agent-protocol interoperability assumes an intermediate representation that is semantically complete; the escape hatch when it is not is a bilateral profile, and the n² mappings return inside “extensions”. The page already states the generalisation: an architecture’s real n² count is the count of its profiles, not of its protocols.
⟨Inference: stacking is how profiles succeed and also how they fail. Each layer narrows the one below, so a sector profile of a cross-sector profile is a genuinely cheaper thing to implement than a new standard — but two sector profiles of the same base are not interoperable with each other merely because they share a base. “Both conform to PACT” and “their data is exchangeable” are different statements.⟩
A profile is a frozen cut of moving standards
It inherits the version policy of everything it selected, and it has its own. The PACT v2 specification family was sunset on 1 April 2026; iLEAP’s response was to decouple — the PACT-based path is retained “for backward compatibility and fallback purposes” and is scheduled for removal in v2.0.0 (iLEAP Tech Specs, §1.2, §7.1). The stated cause is release management, not semantic failure.
⟨Inference: therefore the governance of a profile is a larger question than its content. Who re-cuts it when OData, CloudEvents or UN CPC move; what the sunset policy is; whether downstream profiles get notice. The agent-protocol page reaches the same conclusion from the other direction — “the intermediate representation is a governance object”.⟩
Conformance to a profile certifies the envelope, not the method
PACT conformance is certified separately from Framework (methodology) conformance; a host can be fully conformant while exchanging numbers computed any way at all, because §7.2.1 puts calculation out of scope. iLEAP says it outright in bold in its §8: conformance “ensures interoperability and syntactic correctness”. ⟨Inference: whenever an adoption figure is quoted — “40+ conformant solution providers” — the question to ask is which of the two conformances it counts.⟩
Consequence for the harmonisation debates
The DPP discussion, the identifier question, and the “76 competing projects” diagnosis all assume convergence on one format as the remedy. Profiling is the other available answer, and the one with a working precedent at scale. PACT states that a suitable product identifier “depends on the product, the conventions, contracts, and agreements between the Data Owner and a Data Recipient and is out of the scope of this specification” (§5.1) — and ships URN namespacing so that plural identifiers travel unambiguously. The identifiers stay plural; interoperability happens anyway.
⟨Inference: this is also the honest limit of what GS1 offers such a debate. GS1 Digital Link gives a resolvable, globally unique scheme and is the de-facto DPP carrier; what it does not give — and what no profile gives — is the binding of the symbol to the physical object, which is the half of the identifier problem that is not a standards problem.⟩
Cross-references
- PACT Technical Specifications for PCF Data Exchange v2.2 — the worked example
- PACT Pathfinder Network · PACT PCF calculation methodology
- iLEAP · iLEAP Technical Specifications (2026)
- Agent-protocol interoperability — profiles as the hidden n²
- Decision-grade carbon data criteria — the representation/accountability boundary
- Digital Product Passport · Catena-X · GS1
- Confidentiality gap in carbon accounting
- Coordination failure vs. bargaining failure
Sources
sources/standards/2026-10-29-pact-data-exchange-protocol-v2.2.mdsources/standards/2026-10-01-ileap-technical-specifications-v1.1.0-draft.2.md- ⟨Per Martin Pompéry, 2026-11-06 (Slack,
sine-strategy-works)⟩ — the term and the frame