Responsibility Engineering: Design Theory for Irreversibility—— From Ethical Norms to Physical Constraints

1. Introduction: Why Responsibility Evaporates in "Responsible AI"

Current global discussions surrounding "Responsible AI" and "Ethical AI" face a critical structural limitation. They rely primarily on "Norms" and "Soft Law," leaving implementation to the "willingness to comply" of designers and operators [1][2]. Even with recent legislative and standardization movements such as the EU AI Act [3] and ISO/IEC 42001 [4], the focus remains largely on risk-based management processes, which exist on a different layer from physical enforcement.

Norms can be violated. Post-hoc accountability is consistently fraught with the risk of distortion through "Post-hoc Rationalization," as shown in cognitive psychology. Research by Nisbett and Wilson [5] and Haidt’s models [6] suggests that humans do not have direct access to their own judgment processes and tend to construct consistent narratives after the fact.

In complex system operations, the basis for decision-making becomes dispersed and ambiguous over time, leading to a phenomenon where the locus of responsibility eventually becomes unidentifiable—a phenomenon defined in this paper as "Responsibility Evaporation." Existing ethical guideline approaches possess no effective deterrent against this.

In this paper, we define "Responsibility Engineering" as an independent engineering discipline, distinct from the existing "Responsible X" trends. This is not an implementation of ethics. It is a rigid design theory that fixes the judgment structure itself as a "Pre-decision constraint" so that responsibility cannot be transformed ex-post.

2. Separation of Coordinate Systems: The Unintegrated Fourth Quadrant

To define Responsibility Engineering, "coordinate separation" from existing research fields is essential. Based on a literature review, we have organized current technological trends along the following two axes:

• X-Axis (Timing of Constraint): Ex-post (Audit/Explanation) ⇔ Ex-ante (Fixation/Constraint)

• Y-Axis (Nature of Constraint): Normative (Ethics/Guidelines) ⇔ Structural (Math/Physics/Cryptography)

Configuration and Limitations of Current Trends

1. Responsible AI / Ethical AI (Bottom-Right: Ex-ante × Normative)

   • Overview: Approaches that consider principles such as fairness, transparency, and privacy at the design stage.

   • Representative Literature: NIST AI RMF [7], IEEE Ethically Aligned Design [8].

   • Limitation: Guidelines indicate "what should be done" but lack the physical mechanisms to enforce it.

2. Algorithmic Accountability / AI Governance (Bottom-Left: Ex-post × Normative)

   • Overview: Stipulates accountability for algorithm results and audit processes when issues arise.

   • Representative Literature: Wieringa (2020) [9], Busuioc (2021) [10].

   • Limitation: Accountability is fulfilled ex-post, and the risk that the responsible entity itself is redefined (plasticized) ex-post cannot be eliminated.

3. Safety Engineering / Assurance Case (Top-Right: Ex-ante × Structural [Partial])

   • Overview: Guarantees beforehand that a system meets safety requirements using argumentation structures (e.g., GSN).

   • Representative Literature: Kelly & Weaver (2004) [11], ISO/IEC/IEEE 15026 [12].

   • Limitation: Safety assurance concerns the "state of the system" and resides on a different layer from the fixation of the responsible entity regarding "who assumed the risk of that judgment."

The Domain of Responsibility Engineering (Top-Left: Ex-ante × Structural)

In existing discussions, the domain of "making the change of the responsible entity physically and mathematically impossible through ex-ante structural constraints" remains fragmented. Individual technological elements exist, such as accountability research in distributed systems (e.g., PeerReview) [13] and Certificate Transparency [14]. However, these are often discussed in the context of security or authenticity and have not been integrated under the objective of "fixation of the responsible entity" in AI or complex socio-technical systems.

While fragmented technological elements exist here, there is an unintegrated gap (Missing Link) in the engineering system. This is precisely the domain that Responsibility Engineering should occupy.

Declaration of Separation: Existing Responsible X deals with "norms that encourage responsible behavior." Responsibility Engineering, independently, deals with "structures that make the conditions of responsibility establishment unalterable ex-post." The two are not complementary; they are distinct engineering disciplines dealing with different objects (Software vs. Hardware/Architecture).

3. Core Definition of Responsibility Engineering

"Responsibility" in Responsibility Engineering is based not on the validity of moral blame but on the following formal definition:

Definition: Responsibility Fixation A state where a judgment $D$ at time $t$ is irreversibly linked to a specific entity $A$ at time $t+n$. And a state where the cost to unlink this connection is infinite (or computationally hard).

The threat to this state is "Responsibility Evaporation." To prevent this, Responsibility Engineering requires the implementation of the following three elements:

A. Hardened Pre-commitment

We implement the concept of "commitment" (binding oneself) from economics [15] as a system architecture. We apply the concept of the interlock seen in Certificate Transparency [14] and Sigstore [16]—where "what is not in the log is invalid"—to the decision-making process.

• Approach: The judgment logic, threshold, and responsible entity ID are combined via a cryptographic hash function and fixed to a distributed ledger or similar medium along with a timestamp. Unless consistency with this hash value is proven, the system is designed not to actuate (Interlock Mechanism).

B. Finite Evidence Closure

Traditional Audit Logs provide "traceability," but in Responsibility Engineering, they are used for the "limitation of alternatives." As seen in research like PeerReview [13], mechanisms that make malicious behavior non-repudiable are essential.

• Approach: Applying secure logging technology [17], we guarantee ex-ante the closure property that "at any point in the future, the referenceable evidence set is all that exists in this ledger (cannot be added to or hidden)." This precludes the ex-post selection or reinterpretation of evidence.

C. Fixation of the Worst Day

We implement protocols that determine before an accident occurs "who was the subject of that judgment" for the maximum risk (Worst Case) that the system could cause. This extends the concept of supply chain security (SLSA/SCITT, etc.) [16] to the supply chain of judgment.

Implementation Example: The Responsibility-Fixation Interlock

Responsibility Engineering reduces judgment from a "subject to be explained" to a "condition permitting execution." Its minimal form (Minimal Protocol) is defined as the following interlock structure:

1. Pre-commitment: Beforehand, (i) Judgment Rules (thresholds, objective functions, constraints), (ii) Input Schema, (iii) Responsible Entity ID (role/authority), and (iv) Definition of the Worst Case are fixed as a single commitment $C$ ($C$ becomes a "reference" made unique by hash/signature/timestamp).

2. Evidence Generation: Each judgment $D$ during operation is recorded as an evidence record $E$ bundling (a) Input Data $X$, (b) Output Action $Y$, (c) Reference Commitment $C$, and (d) Execution Time $t$.

3. Execution Control: The system does not execute unless $\text{Verify}(E, C)$ is established (physically and socially transitioning actions such as actuation, approval, or ordering are interlocked).

In other words, the paradigm is inverted from "logs are for reading later" to "a judgment not in the log does not exist." Here, responsibility fixation is realized not as reassembling a narrative ex-post, but as a structural pre-decision constraint where "execution simply does not occur as long as there is an inconsistency between $C$ and $E$."

4. Decisive Differences from Adjacent Fields

To avoid confusion with similar technological fields, we specify the following decision boundaries:

Comparison Target	Decision Boundary with Responsibility Engineering
Safety Case (GSN) [11][12]	Safety assurance cases show the grounds that the system is safe, whereas Responsibility Engineering constructs a structure where the judging entity cannot be changed.
Decision Provenance [18]	Provenance (W3C PROV, etc.) makes the lineage of data traceable, but Responsibility Engineering designs the "Point of No Return" at the moment of judgment. Traceability alone cannot completely prevent the rewriting of the responsible entity (Re-attribution).
Tamper-evident Logs [17]	Tamper-evident logs are "evidence" for ex-post verification. In Responsibility Engineering, logs function as a "Constraint" to permit transition to the next process.

5. Conclusion: Independence as an Engineering Discipline

Responsibility Engineering is neither an "implementation" nor an "evolution" of Responsible AI. While Responsible AI aims for "Better AI" through a normative approach, Responsibility Engineering is a structural approach designing "Non-evadable AI" and its operational structure.

The mathematical modeling of "Responsibility Evaporation" proposed in this paper constitutes the fundamental theory of this Responsibility Engineering. Quantifying when and at what speed responsibility evaporates, and embedding "Anchors" in the system architecture to stop that evaporation—this is the only methodology to place the responsibility, which is being lost in the fog of ethics, under engineering control.

References

[1] A. Jobin, M. Ienca, and E. Vayena, "The global landscape of AI ethics guidelines," Nature Machine Intelligence, vol. 1, no. 9, pp. 389–399, 2019. [2] L. Floridi et al., "AI4People—An Ethical Framework for a Good AI Society: Opportunities, Risks, Principles, and Recommendations," Minds and Machines, vol. 28, pp. 689–707, 2018. [3] European Parliament and Council, "Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act)," Official Journal of the European Union, L, 2024. [4] ISO/IEC, "Information technology — Artificial intelligence — Management system," ISO/IEC 42001:2023. [5] R. E. Nisbett and T. D. Wilson, "Telling more than we can know: Verbal reports on mental processes," Psychological Review, vol. 84, no. 3, pp. 231–259, 1977. [6] J. Haidt, "The emotional dog and its rational tail: A social intuitionist approach to moral judgment," Psychological Review, vol. 108, no. 4, pp. 814–834, 2001. [7] National Institute of Standards and Technology (NIST), "AI Risk Management Framework (AI RMF 1.0)," NIST AI 100-1, Jan. 2023. [8] IEEE Global Initiative on Ethics of Autonomous and Intelligent Systems, "Ethically Aligned Design: A Vision for Prioritizing Human Well-being with Autonomous and Intelligent Systems," First Edition, IEEE, 2019. [9] M. Wieringa, "What to account for when accounting for algorithms: A systematic literature review on algorithmic accountability," in Proceedings of the 2020 Conference on Fairness, Accountability, and Transparency (FAT '20)*, pp. 1–18, 2020. [10] M. Busuioc, "Accountable Artificial Intelligence: Holding Algorithms to Account," Public Administration Review, vol. 81, no. 5, pp. 825-836, 2021. [11] T. Kelly and R. Weaver, "The Goal Structuring Notation – A Safety Argument Notation," in Proceedings of the Dependable Systems and Networks 2004 Workshop on Assurance Cases, 2004. [12] ISO/IEC/IEEE, "Systems and software engineering — Systems and software assurance — Part 1: Concepts and vocabulary," ISO/IEC/IEEE 15026-1:2019. [13] A. Haeberlen, P. Kuznetsov, and P. Druschel, "PeerReview: Practical Accountability for Distributed Systems," in Proceedings of the 21st ACM Symposium on Operating Systems Principles (SOSP '07), pp. 175–188, 2007. [14] B. Laurie, A. Langley, and E. Kasper, "Certificate Transparency," RFC 6962, 2013. [15] T. C. Schelling, The Strategy of Conflict. Harvard University Press, 1960. [16] L. K. Pryor et al., "Sigstore: Software Signing for Everybody," in Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security (CCS '22), pp. 1435–1449, 2022. [17] B. Schneier and J. Kelsey, "Secure Audit Logs to Support Computer Forensics," ACM Transactions on Information and System Security, vol. 2, no. 2, pp. 159-176, 1999. [18] W3C PROV Working Group, "PROV-DM: The PROV Data Model," W3C Recommendation, 2013.