How the Catalog Relates
The hand-authored relationships between standards across the whole catalog — which practices are realized by which standards, and which standards build on, profile or supersede each other. A weaker claim than the specification map, deliberately kept separate from it.
What this page claims, and what it does not
Every edge here is a curator's assertion with a note. No property backs it.
That is a weaker claim than the one made on
the specification map, where twelve
published schemas are read side by side and every edge names the property that proves it —
go and look at sourceDescriptions, and the edge is there.
The two are different instruments pointed at different populations, and they share 0 edges — not one. Do not add the numbers together.
107
relationships
87
entries connected
24
practice → standard
83
standard → standard
A practice, and the standards that realize it
A practice is an argument about how to work; a standard is a way of actually doing it. These 24 edges are where the idea becomes an artifact someone can implement against.
API-First
| AsyncAPI | API-first for event-driven interfaces: the channels and messages agreed before anything publishes to them. |
| JSON Schema | The shapes the contract is written in, so the payloads are agreed as precisely as the operations. |
| OpenAPI | The contract written before the implementation — the artifact that makes API-first mean something a machine can check. |
BDD
| Gherkin | The Given/When/Then grammar BDD scenarios are written in, and the reason they are executable rather than prose. |
Event-driven Architecture
| AsyncAPI | Describes the channels, messages and participants an event-driven system is assembled from. |
| CloudEvents | A common envelope for events, so a consumer can read one without knowing which producer emitted it. |
| MQTT | A transport the pattern is frequently built on, particularly where the publishers are devices. |
Hypermedia
| Collection+JSON | A hypermedia type for collections, with templates describing how to add to them. |
| HAL | A minimal way to carry links in JSON, which is the whole of what hypermedia asks for. |
| JSON:API | A conventions layer that includes relationships and links as part of the document shape. |
| Siren | Carries actions as well as links, so a response describes what can be done next, not only what exists. |
OpenChain
| CycloneDX | An alternative SBOM format serving the same conformance need, common where security is the driver. |
| SPDX | The bill of materials an OpenChain-conformant program produces and exchanges. |
Schema Validation
| JSON Schema | The vocabulary most validation is actually expressed in. |
| Spectral | Lints the document itself against a ruleset, which is validation applied to the contract rather than the payload. |
Secure Software Development Lifecycle
| in-toto | Attests that each step of the supply chain was carried out by who was supposed to carry it out. |
| Sigstore | Signing and transparency for artifacts, so what was built can be shown to be what is deployed. |
| SLSA | A framework of levels for the integrity of the build, turning the practice into something assessable. |
Service Oriented Architecture
| SOAP | The messaging protocol most SOA implementations actually spoke. |
| WSDL | The interface contract SOA services were described with, and the basis for generated clients. |
Spec-Driven Development
| Kiro | AWS's agentic IDE, where the requirements/design/tasks trio that SDD converged on was popularized. |
| OpenSpec | A lightweight SDD convention: a change folder of proposal, design, tasks and requirement deltas. |
| Spec Kit | GitHub's SDD toolkit: a project constitution, then specify, plan, tasks, implement and converge. |
Versioning Protocols
| Semantic Versioning (SemVer) | The convention that gives a version number a meaning a consumer can depend on. |
Standards that build on each other
83 edges where one standard profiles, supersedes, extends or is commonly deployed beside another. Direction is as the curator wrote it, which is itself information: 23 of these pairs were written from both ends, and the rest point one way.
| From | To | How they relate |
|---|---|---|
| 3-D Secure | EMV ↔ | 3-D Secure is one of the EMV specification family maintained by EMVCo. |
| 3-D Secure | EMV Agentic Payments Framework ↔ | EMVCo names EMV 3DS as a candidate for enhancement to support card-based agentic payments. |
| 3-D Secure | EMV Secure Remote Commerce ↔ | SRC checkout is designed to work alongside EMV 3DS. |
| CARIN Blue Button | HL7 FHIR | CARIN Blue Button is a FHIR implementation guide for consumer-directed claims data. |
| CDS Hooks | HL7 FHIR | CDS Hooks cards reference and act on FHIR resources; the two standards are designed to compose. |
| CDS Hooks | SMART on FHIR | A CDS Hooks card can launch a SMART app to complete a decision, linking guidance to action. |
| Confirmation of Payee | UK Open Banking Standard | CoP is part of the UK's payments assurance layer alongside Open Banking payment initiation. |
| Confirmation of Payee | Variable Recurring Payments | Payee verification underpins safe account-to-account payments, including VRP. |
| Consolidated CDA | HL7 FHIR | Much clinical data still moves as C-CDA documents alongside or beneath FHIR APIs. |
| Consolidated CDA | HL7 v2 | C-CDA is the document-oriented HL7 standard that predates and complements FHIR's resource model. |
| CXL | PCI Express | The physical layer CXL builds cache-coherent memory semantics on top of. |
| Da Vinci | HL7 FHIR | Every Da Vinci implementation guide is a set of FHIR profiles and operations. |
| Da Vinci | US Core | Da Vinci IGs build on US Core as their base data layer. |
| Electronic Bill of Lading | DCSA | Publishes the container-shipping eBL standards the carriers implement. |
| EMV | 3-D Secure ↔ | Cardholder authentication for card-not-present payments. |
| EMV | EMV Agentic Payments Framework ↔ | Card-based payments made by AI agents (draft). |
| EMV | EMV Contact Chip ↔ | The original EMV specification — the chip in the card. |
| EMV | EMV Contactless Chip ↔ | Tap-to-pay for cards and NFC devices. |
| EMV | EMV Digital Payment Credential ↔ | A verifiable-credential schema for card authentication (draft). |
| EMV | EMV Mobile ↔ | Phones and wearables as cards, and as terminals. |
| EMV | EMV Payment Tokenisation ↔ | Tokens in place of card numbers. |
| EMV | EMV QR Codes ↔ | Merchant- and consumer-presented QR payments. |
| EMV | EMV Secure Remote Commerce ↔ | The specification behind Click to Pay. |
| EMV Agentic Payments Framework | 3-D Secure ↔ | Named for potential agentic enhancements. |
| EMV Agentic Payments Framework | EMV ↔ | The specification family this framework extends. |
| EMV Agentic Payments Framework | EMV Digital Payment Credential ↔ | Named for potential agentic enhancements. |
| EMV Agentic Payments Framework | EMV Payment Tokenisation ↔ | Named for potential agentic enhancements. |
| EMV Agentic Payments Framework | EMV Secure Remote Commerce ↔ | Named for potential agentic enhancements. |
| EMV Agentic Payments Framework | Verifiable Intent ↔ | The cryptographic intent record EMVCo says Intent Services complements. |
| EMV Contact Chip | EMV ↔ | The specification family. |
| EMV Contact Chip | EMV Contactless Chip ↔ | The tap counterpart, sharing the same chip specifications. |
| EMV Contact Chip | ISO 8583 | The card-network message standard chip transactions ride on. |
| EMV Contactless Chip | EMV ↔ | The specification family. |
| EMV Contactless Chip | EMV Contact Chip ↔ | The inserted-card original. |
| EMV Contactless Chip | EMV Mobile ↔ | Phones and wearables tapping as cards, or accepting taps as terminals. |
| EMV Digital Payment Credential | 3-D Secure | The existing authentication step for remote card payments. |
| EMV Digital Payment Credential | EMV ↔ | The specification family. |
| EMV Digital Payment Credential | EMV Agentic Payments Framework ↔ | Named for potential agentic enhancements. |
| EMV Mobile | EMV ↔ | The specification family. |
| EMV Mobile | EMV Contactless Chip ↔ | The contactless specifications mobile payments tap through. |
| EMV Mobile | EMV Payment Tokenisation | The tokens mobile wallets carry. |
| EMV Payment Tokenisation | EMV ↔ | The specification family. |
| EMV Payment Tokenisation | EMV Agentic Payments Framework ↔ | Named for potential agentic enhancements. |
| EMV Payment Tokenisation | EMV Secure Remote Commerce ↔ | SRC checkout is designed to work with tokens. |
| EMV QR Codes | EMV ↔ | The specification family. |
| EMV QR Codes | EMV Mobile | The other phone-at-checkout EMV technology. |
| EMV Secure Remote Commerce | 3-D Secure ↔ | Designed to work together at checkout. |
| EMV Secure Remote Commerce | EMV ↔ | The specification family. |
| EMV Secure Remote Commerce | EMV Agentic Payments Framework ↔ | Named for potential agentic enhancements. |
| EMV Secure Remote Commerce | EMV Payment Tokenisation ↔ | Designed to work together at checkout. |
| FAPI | FAPI 2.0 Security Profile ↔ | The current generation, Final since 22 February 2025 — PAR, PKCE and mTLS or DPoP required. |
| FAPI 2.0 Security Profile | DPoP (Demonstrating Proof of Possession) | One of the two permitted ways to sender-constrain access tokens (RFC 9449). |
| FAPI 2.0 Security Profile | FAPI ↔ | The FAPI family page — FAPI 1.0 Baseline/Advanced and FAPI 2.0 together. |
| FAPI 2.0 Security Profile | Mutual TLS (mTLS) for OAuth | The other sender-constraining method, and one of two client authentication methods (RFC 8705). |
| FAPI 2.0 Security Profile | OAuth 2.0 Security Best Current Practice | FAPI 2.0 is built on the Security BCP (RFC 9700) plus a formal attacker model. |
| FAPI 2.0 Security Profile | OpenID Connect | FAPI 2.0 references OIDC Core and Discovery; ID tokens travel back-channel only. |
| FAPI 2.0 Security Profile | PKCE (Proof Key for Code Exchange) | Mandatory with the S256 challenge method; it replaces state-based CSRF protection. |
| FAPI 2.0 Security Profile | private_key_jwt | The other permitted client authentication method. |
| FAPI 2.0 Security Profile | Pushed Authorization Requests | Mandatory — the authorization server rejects any request not sent through PAR (RFC 9126). |
| FHIR Bulk Data Access | HL7 FHIR | Bulk Data is a FHIR operation ($export) for population-scale access to the same resources. |
| FHIR Bulk Data Access | US Core | Exports are typically constrained to US Core profiles for regulated data-sharing. |
| HITRUST CSF | ISO/IEC 27001 | HITRUST CSF harmonizes and maps to ISO 27001 among many other frameworks. |
| HITRUST CSF | SOC 2 ↔ | HITRUST and SOC 2 are the two attestations healthcare and SaaS buyers most often ask for together. |
| IEEE 2030.5 | OpenADR | The two demand-response protocols this market names together, at 7 companies each. |
| ISO/IEC 27001 | NIST | ISO 27001 controls map closely to NIST frameworks widely used in the US. |
| ISO/IEC 27001 | SOC 2 ↔ | ISO 27001 (a certifiable standard) and SOC 2 (an attestation report) are the two most-requested security assurances. |
| ISO/IEC 42001 | ISO/IEC 27001 | ISO 42001 extends the same management-system pattern from information security to AI. |
| MTConnect | OPC UA | Frequently deployed alongside MTConnect, with a published companion mapping between the two. |
| Peppol | UBL | The document schemas Peppol's BIS profiles constrain. |
| ROS | DDS | ROS 2 runs on DDS, which supplies the real-time pub/sub and QoS model underneath it. |
| SMART on FHIR | HL7 FHIR | SMART is the authorization layer that makes FHIR safely usable by third-party and patient-facing apps. |
| SMART on FHIR | OAuth | SMART is a profile of OAuth 2.0 + OpenID Connect specialized for health-data scopes. |
| SMART on FHIR | US Core ↔ | The data profiles a SMART app reads once granted FHIR scopes. |
| SOC 2 | HITRUST CSF ↔ | In healthcare, SOC 2 and HITRUST are frequently held together. |
| SOC 2 | ISO/IEC 27001 ↔ | SOC 2 (an attestation report) and ISO 27001 (a certification) are the two most-requested security assurances. |
| Thread | Matter | The application layer that runs over Thread. |
| US Core | HL7 FHIR | US Core is the US-realm implementation guide that constrains base FHIR into required profiles. |
| US Core | SMART on FHIR ↔ | US Core defines the resources; SMART defines authorized access to them. |
| US Core | USCDI ↔ | US Core is the FHIR representation of the data elements USCDI mandates. |
| USCDI | HL7 FHIR | USCDI defines the data; FHIR + US Core define how it is exchanged. |
| USCDI | US Core ↔ | US Core is the FHIR implementation guide that operationalizes USCDI's data elements. |
| Verifiable Intent | EMV Agentic Payments Framework ↔ | EMVCo positions Intent Services as complementing Verifiable Intent's cryptographic assurance. |
| Verifiable Intent | JSON Web Token | The token format SD-JWT extends with selective disclosure. |
Sources and method
Hand-authored relations harvested from the _store entries themselves — the `realized_by` key a practice carries, and the `standards` key an entry carries. Each edge is a curator's assertion with a note, and no property backs it. This is deliberately a weaker claim than /relationships/, which reads twelve published schemas and names the property proving every edge. The two graphs share no edge at all and must never be summed. Harvested from the entries by scripts/build-catalog-edges.py, last run
2026-09-23. The practice edges are written in both directions by
PLANNING/wire-philosophy-edges.py from a single curated list, and counted once here.
An edge whose far end is not an entry in this catalog is dropped rather than shipped as a dead link.