Capture and Assignment
Records responsibility as an identifiable object and connects it to an attributable, bounded recipient and authority.
Example evidence: Captured responsibility record · Assignment event · Authority reference
§ Implementation
Implementation and conformance.
Reference materials for translating issued Responsibility Infrastructure publications into testable operational systems without turning a vendor, tool, or self-declaration into institutional standing.
Current status
These materials are non-normative reference resources. They do not certify an implementation, grant Recognition, establish Registry standing, or replace the requirements in an issued Responsibility Infrastructure publication.
External conformance assessment, accreditation, Recognition, and Registry intake are not presently open. The pathway below defines the intended separation of functions and the language that future implementation claims should use.
§ 1 · Reference artefacts
Minimum testable reference package
These files illustrate one possible implementation of issued requirements. They are deliberately limited to the minimum material needed for mapping, testing, and independent examination. The publications remain the normative source.
- JSON Schema
Responsibility Record reference schema
A non-normative JSON Schema illustrating the four mandatory sections defined by RI-004: Identity, State, Proof, and Outcome.
Open artefact → - JSON
Responsibility Record example
A machine-readable example showing how the public proof lifecycle may be represented as a connected Responsibility Record.
Open artefact → - YAML
Implementation mapping template
A YAML template for mapping an implementation to named publications, clauses, functions, evidence, and limitations.
Open artefact → - JSON
R-Receipt example
A non-normative JSON representation of the portable proof fields used by the existing RR-0001 public proof artefact.
Open artefact → - Markdown
Implementation-claim language guide
Permitted and prohibited wording for Mapped, Evidence Submitted, Independently Verified, Recognised, and Registered claims.
Open artefact →
§ 2 · Functional mapping
Execution layers map to functions, not endorsements
An independent tool may implement one or more functions below. A functional mapping does not make that tool an official Responsibility Infrastructure module, prove conformance, or create Registry standing.
Acknowledgement and Response State
Records receipt or awareness and preserves the recipient's explicit response, including refusal, delay, contest, or no response.
Example evidence: Acknowledgement event · Response-state record · Time-bound escalation
Boundary Control
Applies defined limits, stop conditions, release conditions, escalation rules, or authority boundaries and records whether they were respected.
Example evidence: Boundary definition · Control event · Exception or override record
Action and State Transition
Records material actions or omissions and preserves the state before and after each transition.
Example evidence: Action event · Actor and authority · Before-and-after state
Evidence
Connects responsibility-related claims to attributable evidence, preservation methods, limitations, and sources.
Example evidence: Evidence item · Integrity method · Claim-to-evidence link
Verification
Examines whether the available record and evidence support a defined claim through an attributable and sufficiently separated process.
Example evidence: Verification criteria · Verifier authority · Verification determination
Receipt
Produces a retrievable statement of a verified or unresolved outcome without replacing the underlying Responsibility Record.
Example evidence: Receipt identifier · Outcome status · Underlying record reference
Registry Interface
Publishes or retrieves recognised standing after a valid Recognition Decision, without deciding the substantive outcome itself.
Example evidence: Recognition Decision reference · Registry Entry · Current standing
§ 3 · Claim pathway
Five distinct claim states
Marketing language must not collapse mapping, evidence submission, verification, Recognition, and Registry publication into a single claim of “RI compliance.”
- 01
Mapped
Permitted wording: “Mapped to [named publication and clauses].”
The implementation identifies the named Responsibility Infrastructure publications and requirements it claims to support.
- — Named implementation and version
- — Named publication and clauses
- — Declared functional mapping
- — No claim of independent verification or Recognition
- 02
Evidence Submitted
Permitted wording: “Evidence submitted against [named publication and clauses].”
The implementation has supplied evidence against its declared mapping, but no independent determination has been made.
- — Completed implementation mapping
- — Evidence references
- — Declared limitations
- — Identified submitting organisation
- 03
Independently Verified
Permitted wording: “Independently verified against [named publication and clauses] by [evaluator].”
A sufficiently separated evaluator has examined the evidence against defined criteria and issued a Verification Report.
- — Independent evaluator
- — Defined verification criteria
- — Verification Report
- — Recorded limitations and unresolved matters
- 04
Recognised
Permitted wording: “Recognised for [defined scope] under [Recognition Decision].”
A properly constituted recognition authority has accepted the verified claim through a Recognition Decision.
- — Valid Verification Report
- — Recognition Decision
- — Defined scope and conditions
- — Conflict-of-interest controls
- 05
Registered
Permitted wording: “Registered standing: [Registry Entry identifier].”
The recognised standing has been published as a current Registry Entry and may be referenced through its public record.
- — Valid Recognition Decision
- — Registry publication
- — Current status
- — Publicly retrievable record
§ 4 · Institutional separation
The rule-maker does not mark its own exam
Trust depends on separating publication, implementation, evidence submission, verification, Recognition, and Registry publication.
| Role | Function | Current position |
|---|---|---|
| Requirements publisher | Publishes and maintains Responsibility Infrastructure publications and reference materials. | La Touche Academy Ltd publishes the current publication set. |
| Implementation operator | Builds or operates systems that claim mapping to named requirements. | Independent organisations and technology providers may implement the requirements. |
| Evidence submitter | Supplies evidence supporting a defined implementation claim. | The applicant or operator remains responsible for its submitted evidence and disclosures. |
| Independent evaluator | Assesses evidence against defined criteria with sufficient separation from the original claim. | No general external evaluator authorisation programme is presently open. |
| Recognition authority | Accepts, rejects, or qualifies a verified claim through a Recognition Decision. | No general external Recognition programme is presently open. |
| Responsibility Infrastructure Registry | Publishes recognised standing after procedural requirements are satisfied. | External Registry intake is not presently open. |
La Touche defines the conditions. Independent evidence determines whether they have been met. The Registry preserves the recognised result.