Responsibility Infrastructure
Responsibility Infrastructure
Standards for Provable Responsibility
Public interoperability layer · Version 0.1

Responsibility Interoperability Protocol.

The proposed public protocol for preserving responsibility meaning when information crosses independent organisational and system boundaries.

Version
0.1
Scope
Interoperable responsibility exchange
Technology model
Implementation-neutral
Status
Proposed public interoperability protocol
Public boundary

This page presents the interoperability scope, core functions, minimum record, representative MUST and MUST NOT requirements and operating conditions that independent implementations need to understand.

The Protocol states the common exchange behaviour needed for interoperability. Internal implementation choices remain outside its scope unless an applicable interoperability publication makes a particular behaviour normative.

§ Scope

Technology-independent, not technology-free.

The Protocol defines the minimum information, states and behaviours required for responsibility to move between independent organisations and systems without losing its meaning.

Implementations may use APIs, files, event streams, databases, cryptographic methods or other technologies, provided the required responsibility meaning is preserved.

The Protocol does not mandate a universal database, ledger, workflow engine, user interface, cryptographic method or runtime architecture. An interoperability profile may prescribe a wire format, transport binding or other common behaviour where necessary for reliable exchange.

§ Core functions

Identify → Define → Authorise → Propose → Respond → Record → Prove

  1. 01IdentifyDistinguish the parties, organisations and systems participating in a responsibility event.
  2. 02DefineState the responsibility, scope, intended outcome, conditions and relevant time or closure condition.
  3. 03AuthoriseRepresent the source, holder, scope, limits and validity of the authority under which responsibility is proposed.
  4. 04ProposePresent a defined responsibility explicitly to an identified intended responsible party.
  5. 05RespondRecord an explicit acceptance, rejection or other permitted response by the intended responsible party.
  6. 06RecordPreserve every material event with identity, time, actor, provenance and relationship to the prior state.
  7. 07ProveAttach attributable evidence to the event or claim it supports.
§ Minimum record

Enough information to reconstruct responsibility.

A conforming exchange must preserve enough information for an independent party to understand the responsibility without access to the originating system's source code, database or undocumented internal knowledge.

  • Record identifier and Protocol version
  • Proposing and intended responsible parties
  • Authority source, holder, scope and limits
  • Responsibility, scope and intended outcome
  • Conditions, relevant time and closure condition
  • Proposal, response and response time
  • Current state and state-transition event
  • Complete material event history
  • Evidence references and provenance
  • Corrections, challenges and superseding events
§ Operating conditions

Interoperability cannot depend on permanent connectivity.

The public interoperability model is intended to support responsibility exchange where continuous connection to a central service is unavailable, prohibited or undesirable. Later reconciliation must preserve provenance and must not silently rewrite the event history.

Online exchange
Intermittently connected exchange
Offline exchange with later reconciliation
Air-gapped exchange with controlled later reconciliation

Interaction directions

Human → Human
Human → Machine
Machine → Human
Machine → Machine
§ Requirements

Interoperability conformance requires the applicable requirements to be satisfied.

  • MUST — Represent the responsible party, authority, defined responsibility, intended outcome and relevant time.
  • MUST — Record an explicit acceptance, rejection or other permitted response before responsibility changes state.
  • MUST — Preserve attributable evidence throughout the responsibility lifecycle.
  • MUST — Preserve a complete and independently reconstructable material event history with provenance.
  • MUST — Distinguish Recording, Verification, Recognition, Standing, Registry publication, Resolution and Reliance as separate functions.
  • MUST — Export the minimum Responsibility Record without changing its meaning.
  • MUST NOT — Infer acceptance where no explicit response has been recorded.
  • MUST NOT — Silently overwrite, remove or rewrite historical material events.
  • MUST NOT — Treat recorded evidence as Verification or Recognition.
  • MUST NOT — Treat historical Recognition as equivalent to current Standing.
§ Relationship to RI

The interoperability protocol is not the whole RI Protocol.

The Responsibility Interoperability Protocol defines the public exchange boundary used by independent parties. The Responsibility Infrastructure Protocol addresses the wider protocol architecture and its relationship to the broader Responsibility Infrastructure Standard.