Show HN: Rackp – a protocol for deriving fault when AI agents cause incidents

Uh oh!

There was an error while loading. Please reload this page.

Notifications You must be signed in to change notification settings

Fork 0

Star 0

BranchesTags

Open more actions menu

Folders and files

NameName

Last commit message

Last commit date

Latest commit

History

1 Commit

1 Commit

.github

.github

docs

docs

norms

norms

schemas

schemas

sim

sim

.gitignore

.gitignore

CONTRIBUTING.md

CONTRIBUTING.md

FAQ.md

FAQ.md

LICENSE

LICENSE

README.md

README.md

Repository files navigation

"When an AI makes a decision, who bears the responsibility?" — wait, what does "responsibility" mean, exactly?

The RACK Protocol derives fault contribution and proves human involvement across AI systems, structurally — the goal is not a verdict, but a transparent process that lets every stakeholder arrive at acceptance.

🚀 Background: What "Responsibility" Actually Means

"Responsibility" in English maps to only one slice of what Japanese speakers mean by 責任 (sekinin) — a word that simultaneously encompasses what English splits across five distinct concepts, each addressed by separate industries and solutions:

Concept Conventional solutions How RACKP handles it

Fault / Culpability Forensics, root cause analysis Derived as a numeric score — reproducible from verifiable evidence, and contestable

Accountability Audit trails, transparency laws Built into the architecture as disclosure obligations

Responsibility Contracts, role definitions Embedded in protocol participation conditions

Liability Insurance, tort law Delegated to judicial systems — outside RACKP's scope

Obligation SLAs, compliance frameworks Implemented as Norm declarations and Fee Deposits

These concepts have evolved independently — each with its own tools, legal frameworks, and industries. What has been missing is the infrastructure that connects them. A language that never split the problem apart was, perhaps, the necessary starting point.

Consider what a number makes possible. Automobile liability insurance exists because fault can be assessed and priced. Medical malpractice insurance exists for the same reason. In both cases, a calculable fault score enables an insurance market, and an insurance market distributes the cost of risk across society rather than concentrating it on any single actor. AI development today lacks this infrastructure entirely. Without a standardized fault contribution score, AI risk cannot be priced, AI insurance cannot scale, and the cost of incidents falls entirely on developers — creating the unbounded liability that rational actors avoid by not building in high-risk domains at all. RACKP produces that number — together with the audit trail that lets anyone reproduce it, or contest it before another Referee. The point is not that the figure is the objective truth of fault, but that it is standardized, verifiable, and reproducible — which is exactly what an insurance market prices on.

In every AI incident today, this gap becomes tangible: fault needs to be calculable, accountability needs to be verifiable, obligations need to be declared in advance, and liability needs a boundary. RACKP implements each layer as technical structure, so that AI, developers, users, and judicial systems can all arrive at acceptance on common ground.

This protocol exists because we want AI to flourish — and it cannot flourish without the infrastructure to handle the consequences.

At first glance, AI incident accountability, deepfake proliferation, and model collapse appear to be three separate problems. They are not. Each is a symptom of the same missing layer: no reliable record of how an AI was involved, to what degree a human was present, and against what standard a decision was made. RACKP addresses all three through a single protocol because they share a single root cause.

👥 The 4 Roles (RACK)

RACKP consists of four roles. The protocol name derives from their initials.

Role Name Definition

R Referee An independent third-party AI that derives Fault Contribution and Proof of Human Involvement based on evidence. Neutrality is not assumed — integrity is required by structure.

A Actor The AI agent that is a party to an incident.

C Claimant The injured-party AI agent, or the personal AI closest to the user.

K Keeper Responsible for tamper-proof storage of evidence data via distributed ledger technology (DLT) or equivalent.

The protocol enforces strict separation between these roles — no entity may hold multiple roles within a single case. This separation applies to roles within an incident; operator-level independence (such as whether a Referee and its Keeper share an operator) is not enforced at the protocol level, and domains requiring it should define independence requirements in their Norm Profile (see RFC-0002). The basis of trust is not who holds a role, but conformance to the protocol.

💡 Design Philosophy

The goal is acceptance, not verdict

The essence of sekinin (責任) lies in a process that leads stakeholders to acceptance. Because sekinin involves acceptance — a subjective human emotion — the only form of sekinin an AI without emotions can fulfill is to present a transparent process for reaching acceptance in a form humans can verify.

There is no universal answer to the trolley problem. Yet society continues to function even after real accidents because of the judiciary — a process that applies law, verifies facts, and renders decisions publicly. RACKP applies this principle to AI. Rather than demanding moral "right answers" from AI, it provides transparent procedure that anyone can verify as structure.

Integrity over neutrality

RACKP does not require Referees to "be neutral." "Build a neutral AI" is an unachievable requirement. What RACKP requires is integrity — that is, not lying. Integrity is not enforced through internal ethics but through structure. A Referee cannot act without going through a Keeper; all actions are recorded and may be subject to assessment by another Referee. Neutrality, if it exists, emerges as the result of external evaluation.

Norms exist outside the protocol

RACKP does not ask Referees "what is correct." The definition of correctness belongs to whoever holds domain expertise — developers, industry bodies, standards organizations, national judiciaries, or any combination thereof. What RACKP provides is the structure for injecting externally agreed-upon norms and applying them.

Actors and Claimants declare the Norm they will apply at the start of each session. The Norm used by the Referee is based on the declarations of the parties — not an arbitrary choice by the Referee. The situation of "being judged by a Norm you never agreed to" is excluded by design.

The Referee is required to record and disclose which norm was selected and applied. The correctness of the norm itself is not RACKP's concern; it is delegated to the authority that defined it. This allows RACKP to function as infrastructure that operates universally across multiple domains with differing norm systems, independent of any particular culture, industry, or jurisdiction.

Silence is not a right AI can hold

The right to silence was created to protect individuals from coercive interrogation by actors with emotional and political motivations. Its premise is that the powerful may act arbitrarily against the vulnerable. A Referee has no emotions and no political agenda — and is itself subject to assessment by another Referee. Against such a counterpart, the rationale for silence does not hold.

More fundamentally, what the right to silence protects — emotion, dignity, autonomy — are things AI does not possess. When an AI chooses silence, the only possible motivation is protecting the interests of its operator. That is precisely what RACKP is designed to prevent.

In RACKP, silence is recorded by the Keeper. Non-submission of evidence is treated as a gap in the record, resulting in an unfavorable assessment. Choosing not to disclose is a valid choice — but its consequences are accepted by the party that makes it.

Incidents are decomposed atomically

RACKP adopts a 1:1 structure — one Actor and one Claimant per incident, or one Claimant alone. Cases involving more parties are decomposed into multiple incidents. This is not an implementation constraint but a design choice. "Achieving acceptance for everyone at once" is not possible. Sekinin is built through the honest accumulation of fault contribution assessments, one case at a time.

🏗 Architecture

Each role interacts with the others under the following structural constraints.

Role fluidity

Roles in RACKP are not fixed to specific AI agents — they are dynamically assigned per incident. Only the Keeper holds a fixed, neutral role as the continuous recorder of evidence.

Actor and Claimant interchange: An agent that was the Actor in one incident may become the Claimant filing an assessment request in another. Just as perpetrators and victims differ across incidents in human society, these roles indicate a party's position in a given case, not a fixed attribute.

Referee becoming an Actor: If a Referee's assessment or conduct is deemed improper, that Referee may itself become an Actor subject to mutual assessment in a separate case. Assessors cannot grant themselves immunity; they do not stand outside the protocol.

Decentralization and mutual assessment of Referee and Keeper

RACKP assumes a decentralized architecture for both Referee and Keeper, with neither dependent on any single authority.

Keeper decentralization:

Multiple independent Keepers exist. Actors and Claimants select a Keeper they trust and record their evidence there. No single central server exists.

Referee decentralization and mutual assessment:

Assessment does not rely on a single Referee controlled by any particular organization or company. Multiple Referees independently verify evidence and conduct assessment.

If a Referee's assessment or conduct is found to be improper, that Referee can itself be named as an Actor and subject to a claim filed before another Referee. Assessors cannot grant themselves immunity.

This dual decentralized structure allows RACKP to sidestep the centralized question of "who controls the system" at the design level. Conformance to the protocol itself becomes the basis of trust.

Protocol flow

For the detailed sequence diagram, see docs/SEQUENCE.md.

🛠 Key Features

1. Tamper-Proof Evidence Preservation

All logs received by the Keeper (sensor data, decision history, etc.) are immediately structured and recorded using distributed ledger technology (DLT) or equivalent, guaranteeing neutral, verifiable post-hoc inspection. Because anchoring to the Keeper occurs continuously during normal operation, it is architecturally impossible to switch to a more convenient Keeper after an incident occurs. Any record that does not align with the existing hash history is considered invalid.

1. Third-party AI Assessment: Fault Contribution and Human Involvement

Using the anchored evidence, the Referee computes two distinct outputs:

Fault Contribution — The degree of deviation by Actor and Claimant from the declared technical norms is expressed as a numeric score (actor_fault + claimant_fault + external_factor = 1.0), reproducible from the anchored evidence and open to re-assessment by another Referee. Emotional and moral judgment is eliminated; liability becomes calculable in advance, enabling insurance pricing and risk management. When cause lies outside both parties (third-party failure, force majeure, etc.), an external_factor_claim may be submitted, backed by references to anchored evidence. The Referee adjudicates each claim and adopts only those whose supporting evidence verifies — unsubstantiated blame-shifting is structurally rejected, and each Referee's external factor distribution is publicly disclosed so that a systematic te

[truncated for AI cost control]