Common requirements. Independent implementations.
Responsibility Infrastructure describes how responsibility information can be recorded and exchanged across organisations and systems, while each organisation retains its own duties and authority.
Common requirements across different systems.
Products, open-source projects, vendor protocols, sector systems, registries, verification services and workflow engines may all implement parts of Responsibility Infrastructure. They remain implementation choices.
Institutions can examine shared requirements and supporting evidence. A future standards process may set different requirements.
Similar technical features do not create equivalence of authority, conformance, Recognition, Registry standing or external reliance.
Use RI without adopting a particular supplier.
- Regulators and public authorities
- Use the published requirements, evidence status and conformance boundaries to assess responsibility claims without adopting a particular vendor implementation.
- Standards and assurance bodies
- Use RI publications, versioned test evidence and claims boundaries as a common reference when examining responsibility interoperability across otherwise independent systems.
- Procurement and assurance functions
- Reference the applicable RI version, role and scope in requirements and require testable evidence for any claim of conformance.
- Safety-critical and regulated operations
- Hospitals, defence and aerospace organisations, transport operators and other regulated enterprises can preserve their existing systems while specifying a common responsibility interface at cross-organisational boundaries.
- Insurers and relying institutions
- Treat resolved standing and supporting evidence as inputs to your own reliance decision. RI does not replace underwriting, legal judgement or sector authority.
- Vendors and open-source implementers
- Build any architecture you choose. Preserve the common responsibility meaning at the boundary and make conformance claims against the published requirements rather than against a vendor brand.
- Sector-specific systems
- Extend RI for clinical, financial, industrial, public-service or AI use cases without silently redefining the common semantics required for cross-boundary exchange.
Institutional claims should follow published evidence.
RI publishes versioned technical records. Contributor tests remain separate.
Do not confuse availability with standing.
- Public source code does not by itself establish RI conformance.
- A vendor protocol does not become the Responsibility Infrastructure Standard by implementing similar functions.
- A registry implementation does not by itself confer recognised standing.
- A verification service does not by itself create Recognition or authority for external reliance.
- Interoperability claims must identify the tested systems, conditions, version and limitations.
- Conformance claims must identify the applicable RI role, scope and version and be supported by testable evidence.
Information can support decisions without creating authority.
A regulator, insurer, purchaser, auditor, court, professional body or receiving organisation may use RI evidence or standing within its own process. RI does not replace that institution's statutory, contractual, professional or operational judgement.
This separation allows independent institutions to share a responsibility language while retaining their own decision rights.
Institutional engagement
Organisations considering RI for standards work, procurement, assurance, regulated operations, interoperability testing or implementation can request the appropriate materials and engagement route.
Contact Responsibility Infrastructure →