The Responsibility Chain

1. Purpose

This standard defines the Responsibility Chain as the canonical operational lifecycle through which responsibility is captured, assigned, acknowledged, placed into a response state, acted upon, evidenced, verified, and receipted.

The Responsibility Chain preserves continuity between the creation of responsibility and its recorded outcome.

Its purpose is to prevent responsibility from becoming hidden, assumed, fragmented, silently transferred, self-declared, or impossible to reconstruct.

2. Scope

This standard applies wherever responsibility has operational significance and must remain identifiable, attributable, stateful, evidential, verifiable, and reconstructable.

It may be implemented through digital systems, physical records, organisational procedures, shared protocols, artificial intelligence systems, or mixed human and machine environments.

Conformance is determined by preservation of the required responsibility stages and records rather than by the technology used.

3. Normative Language

The terms shall, should, and may are used as follows:

• shall identifies a mandatory requirement;
• should identifies a recommended practice; and
• may identifies a permitted option.

4. Canonical Responsibility Chain

The canonical Responsibility Chain consists of eight stages:

Capture → Assign → Acknowledge → Response State → Act → Evidence → Verification → Receipt.

Each stage shall create or update an attributable part of the Responsibility Record.

The stages form a connected lifecycle. They shall not be treated as unrelated tasks, messages, approvals, documents, or system events.

5. Stage 1 — Capture

5.1 Purpose

Capture records responsibility as a defined and identifiable object.

Responsibility shall not remain solely within an informal conversation, assumption, general policy, vague instruction, or unrecorded expectation.

5.2 Minimum Capture Requirements

The captured responsibility shall identify, where applicable:

• the responsibility itself;
• the source or origin;
• the actor, role, system, organisation, or authority creating the record;
• the applicable scope;
• the date and time of capture;
• the relevant boundaries or conditions;
• the required outcome or expected state; and
• any applicable time requirement.

5.3 Capture Output

Capture shall produce an identifiable responsibility object capable of assignment, state tracking, evidence linkage, verification, and reconstruction.

6. Stage 2 — Assign

6.1 Purpose

Assignment places the captured responsibility upon an identifiable recipient.

6.2 Minimum Assignment Requirements

An assignment shall identify:

• the responsibility being assigned;
• the assigning actor or authority;
• the intended recipient;
• the scope of the assignment;
• the authority under which assignment occurs;
• the date and time of assignment;
• the required response or action;
• the applicable deadline or time boundary; and
• any conditions, limitations, or dependencies.

6.3 Valid Assignment

An assignment shall not be treated as valid merely because a name, email address, team, system, or job title appears within a message or task.

The connection between the responsibility and the recipient shall remain explicit.

7. Stage 3 — Acknowledge

7.1 Purpose

Acknowledgement records that the assignment has been received or brought to the recipient's attention.

7.2 Meaning of Acknowledgement

Acknowledgement does not by itself establish acceptance, agreement, authority, completion, or discharge.

It confirms receipt or awareness of the assignment.

7.3 Minimum Acknowledgement Requirements

The acknowledgement shall identify:

• the responsibility acknowledged;
• the acknowledging actor, role, system, organisation, or authority;
• the date and time of acknowledgement;
• the method through which acknowledgement occurred; and
• any immediate limitation, qualification, or notice recorded at acknowledgement.

7.4 Missing Acknowledgement

Where acknowledgement is not received within the applicable time boundary, the record shall preserve the missing acknowledgement as an explicit state.

Silence shall not automatically be treated as acceptance.

8. Stage 4 — Response State

8.1 Purpose

Response State records how the recipient responded to the assigned responsibility.

8.2 Permitted Response States

A Response State may include:

• accepted;
• refused;
• deferred;
• contested;
• partially accepted;
• acknowledged without acceptance;
• redirected;
• escalated;
• unable to act;
• no response; or
• another explicitly defined state.

8.3 Minimum Response-State Requirements

The record shall identify:

• the response state;
• who recorded or issued it;
• when it was recorded;
• any reason, limitation, or condition;
• any proposed variation or alternative; and
• the next required transition.

8.4 No Undefined Silence

Silence, delay, refusal, uncertainty, disagreement, or missing authority shall not disappear into an undefined operational condition.

9. Stage 5 — Act

9.1 Purpose

The Act stage records the operational response to the responsibility.

An action may include an intervention, decision, communication, transfer, escalation, correction, omission, refusal, or other material step.

9.2 Minimum Action Requirements

A material action shall identify:

• the responsibility to which it relates;
• the actor, role, system, organisation, or authority involved;
• the action taken or omitted;
• the date and time;
• the authority or basis for acting;
• the state before the action;
• the state after the action; and
• any resulting transfer, escalation, variation, or dependency.

9.3 Action Before Formal Response

Where urgent circumstances require action before acknowledgement or a formal Response State, the record shall preserve the actual order of events.

The history shall not be rewritten to suggest that earlier stages occurred when they did not.

9.4 Claimed Completion

An actor may claim that an action or responsibility has been completed.

A completion claim shall not become a verified outcome solely through self-declaration.

10. Stage 6 — Evidence

10.1 Purpose

The Evidence stage connects responsibility-related claims to supporting material.

10.2 Evidence Requirements

Evidence shall remain connected to:

• the relevant responsibility;
• the action, event, state, or outcome it supports;
• its source or creator;
• its date and time;
• the submitting actor or system;
• its relevant limitations;
• its integrity or preservation method; and
• the claim for which it is relied upon.

10.3 Evidence Timing

Evidence may be created or added before, during, or after an action.

Its actual date of creation, submission, amendment, or preservation shall remain distinguishable.

10.4 Evidence Is Not Verification

The presence of evidence does not automatically establish that the evidence is sufficient, reliable, complete, or supportive of the claim.

11. Stage 7 — Verification

11.1 Purpose

Verification examines whether the available Responsibility Record and evidence support a defined claim, state, action, or outcome.

11.2 Separation

Verification shall be performed by an appropriately authorised and sufficiently separated person, function, body, or system.

The person or system making the original claim shall not treat its own declaration as independent verification.

11.3 Minimum Verification Requirements

A verification record shall identify:

• the claim being examined;
• the verifier;
• the verifier's authority and role;
• the evidence examined;
• the criteria applied;
• the date and time of verification;
• any limitations, exclusions, or unresolved matters;
• the verification determination; and
• the reasons supporting that determination.

11.4 Verification Outcomes

Verification may:

• confirm the claim;
• reject the claim;
• qualify the claim;
• suspend determination;
• request further evidence; or
• leave the claim indeterminate.

11.5 Verification Is Not Accountability Judgment

Verification determines whether evidence supports a claim.

It does not automatically determine blame, fault, liability, sanction, compensation, or remedy.

12. Stage 8 — Receipt

12.1 Purpose

Receipt records the recognised status of the responsibility lifecycle at a defined point in time.

A Receipt provides a retrievable statement of the outcome without replacing the underlying Responsibility Record.

12.2 Minimum Receipt Requirements

A Receipt shall identify:

• the Responsibility Record or responsibility to which it relates;
• the recorded outcome or status;
• the verification determination relied upon;
• the date and time of issuance;
• the issuing actor, system, organisation, or authority;
• any applicable limitations or expiry conditions;
• any superseded Receipt; and
• a means of retrieving or referencing the underlying record.

12.3 Permitted Receipt Statuses

A Receipt may record:

• verified completion;
• verified transfer;
• verified discharge;
• closure;
• qualified outcome;
• rejected claim;
• suspended status;
• unresolved status;
• indeterminate outcome; or
• another defined result.

12.4 Receipt Integrity

A Receipt shall not erase contrary evidence, unresolved challenges, earlier states, rejected claims, or the history through which the outcome was reached.

13. Chain Continuity

The Responsibility Chain shall preserve the connection between all material stages.

An authorised examiner should be able to determine:

• what responsibility was captured;
• who assigned and received it;
• whether acknowledgement occurred;
• what Response State was recorded;
• what action occurred;
• what evidence supports the relevant claims;
• how verification was performed; and
• what Receipt or current status remains.

A collection of disconnected records does not satisfy chain continuity merely because each record exists somewhere within the same organisation or technical system.

14. Missing, Failed, and Exceptional States

A Responsibility Chain does not become invalid merely because responsibility was refused, contested, delayed, transferred, unsuccessful, unresolved, or left indeterminate.

The failure arises where the state or event is not preserved.

The record shall therefore preserve:

• missing acknowledgement;
• no response;
• refusal;
• insufficient authority;
• failed action;
• missing evidence;
• conflicting evidence;
• failed verification;
• unresolved challenge; and
• indeterminate outcome.

15. Transfer and Escalation

15.1 Transfer

A transfer shall preserve the identity of the previous holder, the receiving party, the authority for transfer, the time of transfer, the responsibility state, and any continuing obligations.

A transfer creates a new assignment event within the same Responsibility Record.

15.2 Escalation

An escalation shall identify the reason for escalation, the actor or authority receiving it, the date and time, the responsibility state, and the expected next response.

15.3 No Silent Transfer

Responsibility shall not be treated as transferred merely because another person, team, supplier, system, or organisation became involved.

16. Corrections and Amendments

Corrections, variations, challenges, transfers, reversals, and later determinations shall be added to the Responsibility Record.

Earlier material states shall not be silently replaced where doing so would prevent reconstruction of what was known, claimed, decided, or recorded at an earlier time.

17. Conformance Requirements

An implementation conforms with this standard only where it can demonstrate:

1. responsibility is captured as an identifiable object;
2. assignment is attributable and bounded;
3. acknowledgement or its absence is recorded;
4. a clear Response State is preserved;
5. material actions and omissions are time-sequenced;
6. claims remain connected to evidence;
7. verification is attributable and sufficiently separated;
8. a Receipt or explicit unresolved outcome can be produced;
9. transfers, escalations, corrections, and challenges remain visible; and
10. the complete responsibility history can be reconstructed.

The presence of isolated tasks, messages, logs, signatures, attachments, approvals, or dashboards does not establish conformance.

18. Relationship to Recognition and Registry Processes

This standard defines the operational Responsibility Chain.

It does not by itself grant Recognition, establish Registry standing, certify an implementation, or decide an accountability outcome.

Where Recognition or Registry publication is required, those functions shall occur through their separate authorised processes.

19. Relationship to Other Publications

This standard should be read alongside:

• RI-001 — Definition of the Responsibility Infrastructure Category.
• RI-002 — Principles of Provable Responsibility.
• RI-003 — Core Elements of Responsibility Infrastructure.
• RI-004 — The Responsibility Record Specification.
• RI-005 — Characteristics of Responsibility Infrastructure.
• RI-GLOSS-01 — Responsibility Infrastructure Glossary.
• RI-STD-02 — Responsibility Evidence Requirements.
• RI-STD-03 — Responsibility Verification Requirements.

20. Normative Statement

Responsibility shall remain connected from Capture through Receipt.

Where a stage is missing, failed, refused, disputed, or unresolved, that condition shall be recorded rather than concealed.

21. Keywords

Responsibility Infrastructure, Responsibility Chain, Capture, Assignment, Acknowledgement, Response State, Action, Responsibility Evidence, Verification, Responsibility Receipt, Responsibility Record, Transfer, Escalation, Conformance, Reconstruction