§ Publications/RI-CONF-001
RI-CONF-001 · RI-STD Series

Responsibility Infrastructure Protocol Conformance Requirements

Defines objective requirements and determinations for conformance with the Responsibility Infrastructure Protocol.

Draft
Version 0.1 · Working Draft
§ Status
DraftAn early draft released for review and subject to substantive change.
§ Related Files
  • RI-CONF-001-v0.1.htmlHTML ·
§ Related Publications
§ Abstract

This specification defines mandatory constitutional requirements, prohibited behaviours, evidence expectations, determination outcomes and declaration rules for implementation conformance. It does not confer Verification, Recognition, Registry standing or authority for reliance.

§ Publication

1. Scope

This specification defines the conditions under which an implementation may claim conformance with the Responsibility Infrastructure Protocol. It evaluates the implementation's exported responsibility information and observable protocol behaviour. It does not prescribe internal architecture, APIs, storage, databases, workflows, runtime engines or user interfaces.

2. Normative Language

The terms MUST, MUST NOT, SHOULD, SHOULD NOT and MAY indicate mandatory requirements, prohibitions, recommendations, discouraged practices and permissions respectively. A conforming implementation satisfies every applicable MUST and MUST NOT requirement.

3. Constitutional Boundary

Protocol conformance is a technical determination. It does not constitute independent Verification, Recognition, Registry publication, standing, certification, endorsement or authority for external reliance.

4. Mandatory Requirements

IDRequirement
CONF-01An implementation MUST represent a stable Responsibility Record identifier.
CONF-02It MUST explicitly represent the responsible party, assigning or proposing party, defined responsibility, intended outcome and applicable time.
CONF-03It MUST represent the authority under which responsibility is proposed or assigned.
CONF-04It MUST distinguish proposal from acceptance and MUST NOT infer acceptance from silence, access, action or system presence.
CONF-05It MUST distinguish acceptance, rejection, delegation, withdrawal and expiry where those events occur.
CONF-06It MUST preserve current state and the attributable events that produced that state.
CONF-07It MUST attach or reference evidence without requiring a proprietary storage format.
CONF-08It MUST preserve event identity, actor, timestamp, event type and relationship to the relevant record or prior event.
CONF-09It MUST prevent silent alteration or deletion of material event history.
CONF-10It MUST permit an independent relying party to reconstruct the record's material lifecycle from exported information.
CONF-11It MUST keep Recording, Verification, Recognition, Standing, Registry publication, Resolution and Reliance distinguishable.
CONF-12It MUST NOT represent self-declaration or protocol conformance as independent Verification or Recognition.
CONF-13Where standing is communicated, it MUST identify the authoritative Registry source, status and resolution time.
CONF-14It MUST disclose unsupported, unavailable or not-established claims rather than silently treating them as satisfied.
CONF-15It MUST export sufficient information for the applicable RI-TEST-001 tests without requiring access to proprietary internal mechanics.

5. Prohibited Behaviours

  • Implied acceptance.
  • Silent state replacement.
  • Self-verification represented as independence.
  • Registry standing created outside an authorised Registry publication.
  • A static badge or receipt represented as current standing without resolution.
  • Conformance conditioned on use of a named product, vendor, API, database or commercial model.

6. Determination

The only technical outcomes are Conformant, Non-conformant, or Indeterminate. Conformant means every applicable mandatory requirement passed. Non-conformant means at least one applicable mandatory requirement failed. Indeterminate means the evidence is insufficient to determine one or more applicable requirements. Requirements are not averaged and failures cannot be offset by strengths elsewhere.

7. Conformance Evidence

A determination MUST identify the implementation and version, Protocol version, test-suite version, evaluator, date, evidence examined, each requirement result, limitations and overall outcome.

8. Declaration

A self-declaration MUST use RI-DECL-001 or provide equivalent information. It MUST identify itself as self-declared, remain limited to the tested version and disclose exclusions and unresolved tests.

9. Future Profiles

Future domain profiles MAY add requirements but MUST NOT weaken the constitutional requirements in this specification. Assurance levels are governed separately by RI-LEVEL-001 and do not create degrees of technical conformance.

§ Document Metadata
§ Lifecycle History
  1. 2026-08-03
    Drafted · Version 0.1 Working Draft prepared
§ Normative References