Responsibility Infrastructure Protocol™.
The minimum constitutional requirements for representing and exchanging provable responsibility between independent organisations and systems.
- Status
- Proposed public draft
- Version
- 0.1
- Publisher
- La Touche Holdings Ltd
- Independent approval
- None
- Independent implementation
- Not yet demonstrated
- Recognition or Registry standing
- None
The Responsibility Infrastructure Protocol™ defines the minimum requirements for representing, proposing, accepting, recording, reconstructing and exchanging responsibility information between independent organisations and systems.
The Protocol standardises constitutional meaning and interoperability rather than implementations. It defines the minimum requirements for exchanging responsibility information between independent organisations. It does not prescribe internal architectures, databases, user interfaces, storage mechanisms, APIs, workflows, commercial models or runtime designs.
Responsibility must be explicitly represented.
A name, job title, task, signature, approval, system log or evidence file does not by itself establish responsibility. A conforming record must represent the responsible party, authority, defined responsibility, intended outcome, relevant time and explicit response.
Identify → Define → Authorise → Propose → Respond → Record → Prove
These are constitutional functions, not mandatory interface stages. Implementations may organise their internal workflow differently provided every function is satisfied and remains independently reconstructable.
- 01IdentifyDistinguish the parties, organisations and systems participating in a responsibility event.
- 02DefineState the responsibility, scope, intended outcome, conditions and relevant time or closure condition.
- 03AuthoriseRepresent the source, holder, scope, limits and validity of the authority under which responsibility is proposed.
- 04ProposePresent a defined responsibility explicitly to an identified intended responsible party.
- 05RespondRecord an explicit acceptance, rejection or other permitted response by the intended responsible party.
- 06RecordPreserve every material event with identity, time, actor, provenance and relationship to the prior state.
- 07ProveAttach attributable evidence to the event or claim it supports without treating evidence as Verification or Recognition.
Minimum Responsibility Record
Every conforming record 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.
A Responsibility Record is the minimum interoperable representation required for independent reconstruction. Implementations may preserve additional information provided the constitutional meaning of the minimum record remains unchanged.
- 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, provenance and submitter
- Corrections, challenges and superseding events
Lifecycle states
Implementations may add states, but extensions must not silently redefine the meaning of the minimum states or remove the requirement for explicit acceptance.
Evidence must remain attributable and reconstructable.
Every material event must be preserved with an event identifier, time, actor, type, relationship to the preceding state and relevant evidence references. Historical events must not be silently overwritten. Corrections must be recorded as later events.
Evidence must identify its submitter, submission time, supported event or claim, provenance and applicable access restrictions. Recording evidence does not verify the claim and does not create Recognition or standing.
Preserve meaning across systems.
A conforming implementation must be able to export the minimum Responsibility Record in a form another independent implementation can interpret. The export must identify the Protocol version, preserve event order and party relationships, distinguish current from historical state and expose missing required information rather than inventing it.
All mandatory requirements are satisfied.
One or more mandatory requirements are violated.
Required information is missing, inaccessible or ambiguous.
Normative Conformance Requirements
Conformance is determined against the mandatory requirements of this Protocol. A conforming implementation must satisfy each applicable requirement without altering its constitutional meaning.
A conforming implementation MUST
- Represent the responsible party, authority, defined responsibility, intended outcome and relevant time.
- Record an explicit acceptance, rejection or other permitted response before responsibility changes state.
- Preserve attributable evidence throughout the responsibility lifecycle.
- Preserve a complete and independently reconstructable material event history with provenance.
- Distinguish Recording, Verification, Recognition, Standing, Registry publication, Resolution and Reliance as constitutionally distinct functions.
- Export the minimum Responsibility Record without changing its constitutional meaning.
A conforming implementation MUST NOT
- Infer acceptance where no explicit response has been recorded.
- Silently overwrite, remove or rewrite historical material events.
- Treat recorded evidence as Verification or Recognition.
- Treat historical Recognition as equivalent to current Standing.
Conformance is not Verification, certification, Recognition, Registry standing or permission for external reliance.
Detailed conformance criteria, test cases and implementation examples may be published in companion conformance specifications without altering the constitutional requirements of this Protocol.
Recording, Verification, Recognition and reliance are distinct.
The Protocol standardises interoperability, not implementations.
Relational databases, document stores, event stores, distributed ledgers, manual records and hybrid systems may conform. No technology becomes the Protocol merely by using responsibility-related terminology. Conformance depends on preserving the required constitutional meaning and supporting independent reconstruction.
- Independent implementation testing has not yet been completed.
- Cross-system interoperability has not yet been demonstrated.
- The Protocol defines constitutional functions rather than implementation workflows. Implementations, including LROS®, may realise those functions through different operational workflows provided the constitutional requirements of this Protocol remain satisfied.
- This draft does not establish a Recognition authority or Registry standing.
- This draft does not authorise external reliance.