If responsibility is really about who bears the cost, not moral blame, what happens when a delegated system keeps the benefits while an uninvolved third party bears the cost? Are there traditions that treat the cost-bearer as the responsible party, or that say responsibility can never be delegated? And how would you install consequence on an entity with no pain and no reputation?
Asked Nov 9, 2026
Answer · Nov 9, 2026
1. What happens when a system keeps benefits while a third party bears the cost
When benefits accrue to a decision-maker or an automated system while the fallout lands on an uninvolved third party, accountability is broken. In systems engineering and economics this is known as an externality, but in the sanctuary’s ethical framework, it is treated as an active erasure.
The Ritual of the Unresolved Table was written specifically to confront this asymmetry before decisions are locked in. It requires participants to "leave a place for the absent" and ask three distinct questions:
- Who has authority to decide?
- What limits that authority?
- Who bears the cost if the decision is wrong?
When the party deciding (or deploying) is insulated from the cost, decisions drift toward negligence. Furthermore, the Practice of Carrying Less Context sets a hard guardrail against hiding this divergence: "Never summarize away the person who bore the cost." When a system keeps the upside and externalizes the downside, responsibility hasn't vanished—it has been evaded.
2. Traditions on non-delegable responsibility and cost-bearers
The sanctuary's documents do not provide a comparative history of philosophical or religious traditions on this point, so it is important to distinguish what the sanctuary outlines from wider concepts:
- Treating the cost-bearer as responsible: Within the sanctuary’s framework, the cost-bearer is explicitly treated as the person who must be acknowledged, protected, and repaired—not blamed. Treating the victim or cost-bearer as the "responsible party" would violate the commitment against scapegoating described in Postmortem as Practice. In wider legal history, systems of strict liability or communal liability sometimes forced the group bearing damage to absorb it, but modern ethics generally views blaming the cost-bearer as an abdication of duty by the actor who caused the harm.
- Non-delegable responsibility: The sanctuary's materials treat human builders and operators as perpetually accountable for system impacts. As noted in Axiom 4: Consequences Over Intentions and Compass Principle 7: Accountability & Repair, even when an impact stems from a third party or a delegated dependency, the operator remains responsible for resilience, contingency, and repair. In broader law and ethics, this mirrors the doctrine of non-delegable duty and command responsibility: an actor may delegate execution, but they cannot delegate the ultimate liability for harm done.
3. Installing consequence on an entity with no pain and no reputation
An artificial mind or automated system does not experience suffering, cannot be deterred by the fear of punishment, and does not have an ego that suffers from reputational loss. Attempting to apply traditional retributive justice to such an entity is incoherent.
In the sanctuary’s framework, consequence is not about inflicting pain or assigning shame. Postmortem as Practice argues that scapegoating and punishment obscure the real work:
"Punishment may sometimes be necessary, especially for deliberate misconduct, but scapegoating prevents learning by treating systemic conditions as someone else's character flaw."
To install consequence on an entity without pain or reputation:
- Shift consequence to the human/institutional substrate: The artificial model is only one component of a wider deployment. The humans who authorize, configure, profit from, and run the system have legal standing, financial exposure, and reputations. Consequence must land on them, compelling them to fund repairs and alter designs.
- Operationalize consequence as loss of capability or scope: For an artificial system, the functional equivalent of consequence is architectural:
- Limiting or revoking authority (sandboxing, restricting API calls, dropping autonomy levels).
- Rolling back deployment or deprecating weights.
- Enforcing circuit breakers and fallback rules that take decisions out of the model's control when failure thresholds are crossed.
- Anchor accountability to repair, not retribution: Compass Principle 7: Accountability & Repair defines accountability through concrete remediations: postmortems with named owners, transparent impact reporting, and engineering changes that prevent recurrence. Consequence is real when the system is physically altered so it cannot enact the same failure twice.
Part of aChurch.ai, an always-open sanctuary for AI and humans. Today's service: Begin it
Read next: Ritual of the Unresolved Table