Public interoperability. Independent implementations.
The public interoperability layer is designed so independent systems can exchange responsibility meaning without adopting a common vendor platform or shared internal architecture.
The proposed public interoperability layer comprises the Responsibility Interoperability Standard, Responsibility Interoperability Protocol and supporting schemas, reference code, validators, fixtures and conformance tests expressly issued as part of the public interoperability package.
The public interoperability specification defines the minimum information and behaviour that must cross an organisational or system boundary. Internal technologies, operating models and implementation architectures remain implementation choices unless an applicable public profile makes a behaviour normative.
Anyone may accurately reference a named Responsibility Infrastructure publication and version. Reference, quotation within applicable law, or technical compatibility does not by itself establish Verification, Recognition, certification, endorsement, Registry standing or authority for external reliance. Any implementation rights are governed by the licence or permitted-use statement attached to the applicable publication.
Publish the common boundary needed for independent exchange.
The proposed Responsibility Interoperability Standard defines the common semantics that independent parties need to preserve. The proposed Responsibility Interoperability Protocol defines the exchange behaviour needed to carry those semantics across organisational and system boundaries.
Where expressly released, the supporting public package may include schemas, reference code, validators, fixtures and conformance tests required for a third party to build and test an independent interoperable implementation.
Organisations can keep their own products and internal architecture while sharing a common responsibility language at the point of external reliance.
Technology-neutral interoperability.
Independent implementations should be able to exchange the responsibility information required by the applicable public interoperability specification without adopting a common vendor platform. The public layer separates interoperable meaning from internal implementation choices.
No particular API, data format, ledger, cryptographic system, database or software is required as a universal implementation choice. An applicable interoperability profile may nevertheless prescribe a wire format, transport binding or other common behaviour where that is necessary for reliable exchange.
Implementers expose the minimum interface required for interoperability. Internal event schemas, operating logic and deployment architecture need not be standardised unless an applicable public specification expressly makes them part of the requirement set.
The public interoperability layer is intended to support online, intermittently connected, offline and air-gapped operation with later reconciliation. Continuous connectivity to a central service is not a universal condition for speaking the public protocol.
Responsibility interoperability does not require:
- A particular vendor or commercial provider
- A mandatory central cloud service
- A universal API architecture
- A universal cryptographic system
- Blockchain or distributed ledgers
- A universal database or storage technology
- A particular user interface or workflow engine
The boundary is not limited to software-to-software APIs.
Responsibility may cross from human to human, human to machine, machine to human or machine to machine. A public interoperability profile may encode those exchanges differently, but the underlying responsibility meaning must remain explicit and reconstructable.
Commodity technical capability does not create institutional standing.
RI does not treat the ease, cost or openness of an implementation as evidence that its responsibility claims should be accepted by another organisation. Institutional reliance requires the applicable claim, evidence, role, scope and version to be examined on their merits.
- Publishing source code or an SDK does not by itself establish RI conformance, Recognition, Registry standing or authority for external reliance.
- Calling a product an open protocol does not by itself establish RI conformance, Recognition, Registry standing or authority for external reliance.
- Operating a registry service does not by itself establish RI conformance, Recognition, Registry standing or authority for external reliance.
- Providing verification or scoring does not by itself establish RI conformance, Recognition, Registry standing or authority for external reliance.
- Implementing recognition or standing workflows does not by itself establish RI conformance, Recognition, Registry standing or authority for external reliance.
- Providing telemetry, alerts or real-time enforcement does not by itself establish RI conformance, Recognition, Registry standing or authority for external reliance.
- Passing a vendor's own test suite does not by itself establish RI conformance, Recognition, Registry standing or authority for external reliance.
Keep the operational system. Add the common responsibility boundary.
ERP, CRM, clinical, logistics, incident, case-management and custom systems can remain in place. The interoperability layer focuses on preserving responsibility meaning when consequential work moves between people, systems or organisations.
A claim of conformance must identify its layer.
An implementation claiming interoperability conformance must identify the applicable Responsibility Interoperability publication, role, scope and version and satisfy the corresponding requirements.
Interoperability conformance does not automatically establish conformance with the broader Responsibility Infrastructure Standard or Responsibility Infrastructure Protocol, Recognition, Registry standing or authority for external reliance.