AboutCurrent statusParticipationContact
Responsibility Infrastructure
Responsibility Infrastructure
Standards for Provable Responsibility
Working proposal · v0.1

Responsibility exchange working proposal.

A working proposal describing how responsibility information can be exchanged and interpreted across independent systems.

Version
0.1
Scope
Interoperable responsibility exchange
Technology model
Implementation-neutral
Status
Founder-authored proposal; not consensus-approved
Original working title
Responsibility Interoperability Protocol
Public boundary

This working draft uses MUST and MUST NOT to express candidate technical requirements. Its publication record identifies the applicable version and status.

The technical questions concern what meaning must survive exchange. No particular vendor implementation, private service or wider RI publication is a prerequisite for a future agreed shared boundary.

§ Scope

Technology-independent, not technology-free.

This proposal examines information, states and exchange behaviours that may be needed to preserve responsibility meaning between independent organisations and systems.

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

Draft requirements for independent technical consideration.

  • 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.