Who Can Make the Action Happen? An Authority-Decomposition Framework for High-Risk Automated Systems

Who Can Make the Action Happen? An Authority-Decomposition Framework for High-Risk Automated Systems Mengting Wu* , Lin Wang, and Yong Zhang Chengdu Havenlon Security Technology Co., Ltd., Chengdu, China

arXiv:2608.18965v1 [cs.CR] 19 Aug 2026

*

Corresponding author: chloe@havenlon.com

Status: Non-peer-reviewed preprint for scholarly feedback.

Abstract High-risk automated systems distribute control across services, credentials, protected components, and lifecycle mechanisms. Labels such as authorized, approved, privileged, or protected therefore do not answer a basic causal question: which actors can actually make a consequential action occur? This paper provides an action-relative method for deriving which trust-domain coalitions are sufficient to cause protected execution, defined as the occurrence of a designated protected state transition. The framework models components, powers, resources, boundaries, and alternative realization structures; includes update, recovery, override, disablement, and alternative invocation; and separates causal control over execution from control over the authoritative account of an operation. It derives inclusion-minimal sufficient coalitions and tests whether claimed execution boundaries remain independent of designated upstream domains. Cross-domain analytical cases illustrate the method. In a split-control, release-intended, open-state, source-bounded Havenlon protocol model, the ordinary witness requires five trust domains, while certificate replacement yields a three-domain inclusion-minimal known requirement set among source-enumerated protocol witnesses; the Linux domain remains insufficient for the complete transition. Deployed global nonbypassability and boundary-bound veto coverage remain unresolved. The framework is a conceptual and analytical tool. It does not certify implementations, establish deployment security, guarantee complete discovery of hidden powers, or define evidence-verification semantics. Keywords: execution authority; trust domains; protected execution; causal realization witnesses; lifecycle security; security architecture

1. Introduction High-risk automated systems increasingly combine policy engines, network services, protected hardware or software components, delegated credentials, lifecycle management, recovery, and updates. A request may be approved in one service, transformed into a command in another, admitted by a hardware boundary, and executed only after additional local conditions hold. Exceptional powers may later replace credentials, change code or policy, disable a restriction, or invoke a different route. In such systems, component names and workflow diagrams do not answer the central causal question: who can actually cause the protected state transition?

1

Established areas answer important but different questions. Access control determines permission; reference-monitor and complete-mediation work characterize protected mediation; capabilities and credentials convey exercisable authority; separation of duty and thresholds distribute selected contributions; trusted-computing mechanisms protect execution; verification evaluates specified properties; and provenance, attestation, and auditing allocate or protect accounts of activity. This paper does not treat those approaches as mistaken or incomplete within their own aims. It asks a system-level question that their local outputs do not settle by themselves: after ordinary workflow powers and admitted lifecycle or recovery powers are composed, which trust-domain coalitions can make the designated action happen? The paper therefore asks, in plain terms, who can make the protected action happen? More formally: How should authority over high-risk automated execution be decomposed across actors and trust domains so that the domains capable of initiating execution attempts are explicit and no designated upstream domain can unilaterally cause the protected state transition? Initiation is not treated as inherently unsafe. An upstream domain may legitimately propose, authorize, approve, and issue a command while remaining insufficient for execution because another domain controls an indispensable contribution. The answer is relative to the protected action, system model, threat model, environmental assumptions, trust-domain assignment, and admitted witness family. We develop an integrated authority-decomposition framework around that question. The paper makes four principal contributions: 1. An action-relative vocabulary and typed model. The framework separates proposal, authorization, approval, command, policy decision, policy update, veto, execution, and evidence powers, and relates components, domains, powers, resources, boundaries, protected transitions, realization witnesses, and epistemic objects. 2. A witness-to-coalition derivation. Support-selected realization witnesses are projected onto controlling trust domains to derive execution authority and inclusion-minimal sufficient coalitions. Admitted update, recovery, override, disablement, and alternative-invocation powers are included through reconfiguration composition. 3. Boundary, independence, and concentration diagnostics. The framework distinguishes structural traversal from resistance to unilateral alteration, satisfaction, disablement, and bypass; separates causal execution independence from evidentiary independence; and derives recurring dangerous authority patterns from those distinctions. 4. Cross-domain analytical demonstrations and a bounded implementation-informed instantiation. Controlled cases test whether the outputs change when authority assignments change, while the source-grounded Havenlon analysis records what the identified protocol sources establish, conditionally support, or leave unresolved. Together, these contributions form an integrated authority-centered organization and derivation. The paper does not claim a new access-control system, security mechanism, cryptographic primitive, graph primitive, provenance mechanism, or certification framework. Section 2 positions the framework relative to the established mechanisms and models it uses. Sections 3 and 4 define protected execution, execution authority, and the authority taxonomy. Section 5 supplies the typed witness-and-coalition model; Section 6 derives dangerous authority patterns; and Section 7 states the causal and evidentiary independence conditions. Section 8 presents controlled cross-domain contrasts. Section 9 applies the framework to the source-bounded Havenlon protocol model. Section 10 discusses interpretation and limitations, followed by the conclusion. An extended technical supplement is distributed with this preprint as ancillary material. It re2

tains complete derivations, full tables, secondary cases, and extended source-grounding material; no principal definition, method, result, or qualification depends on it.

2. Conceptual Foundations and Positioning The framework is integrative. It uses established mechanisms and formalisms as inputs, then derives action-relative trust-domain coalitions and boundary properties that no single local result settles by itself. Authorization and access control supply subjects, roles, permissions, sessions, and separationof-duty constraints [Sandhu et al., 2000, §§2.1–2.3, 3, and 5]. The present question is causal rather than normative: a permitted request may be refused or may still depend on another domain, while an unauthorized route may nevertheless realize the transition. Reference monitors and complete mediation supply mediation, tamper resistance, and complete checking [Anderson, 1972, §§3.4–3.6; Saltzer and Schroeder, 1975, §III.A]. This paper separately asks whether every admitted witness traverses the claimed boundary and who can alter its rule, satisfy its accepted inputs, disable it, or invoke an alternative route. Usage and lifecycle control show that decisions and mutable attributes may change before, during, or after use [Park and Sandhu, 2004, §§3–4.2]. The framework represents that insight by composing admitted update, recovery, override, disablement, and other reconfiguration steps with later realization witnesses. Capabilities, credentials, privileges, and delegation represent exercisable rights and scoped authorization artifacts [Dennis and Van Horn, 1966, p. 6; Hardt, 2012, §§1, 1.1–1.4, 3.3, and 7]. Here they become typed witness inputs; the additional inquiry is whether they are merely prerequisites or sufficient support, and who controls equivalent minting, replacement, or recovery routes. Separation of duty and threshold mechanisms distribute selected contributions [Clark and Wilson, 1987, pp. 186–187; Sandhu et al., 2000, §5; Shamir, 1979, pp. 612–613]. Trust-domain projection then tests whether nominally distinct principals remain independent under shared administration, recovery, key ownership, or compromise. Trusted computing bases and lifecycle security identify enforcement mechanisms and their update, detection, and recovery roots [U.S. Department of Defense, 1985, §§3.2.3.2.3, 4.1.3.2.3, 6.1–6.3, and Glossary; Regenscheid, 2018, §§3.1, 3.3–3.6, and 4.1–4.4]. The framework asks which lifecycle controllers can change the witness inventory, boundary semantics, or coalition requirements. Attack, privilege, AND/OR, hypergraph, and fault models represent alternative routes, conjunctive prerequisites, privilege expansion, and minimal sufficient combinations [Phillips et al., 1998, executive summary and §§2–3; Dacier and Deswarte, 1994, §§2–4; Schneier, 1999; Gallo et al., 1993, §§2–5; Vesely et al., 1981, chs. IV and VII]. This paper claims no new graph primitive; it binds a typed, support-selected derivation to one protected transition and projects its selected support to controlling domains. HSMs, cryptographic modules, enclaves, and interlocks can supply concrete execution, refusal, or local-condition contributions [National Institute of Standards and Technology, 2019, abstract and §3.2; OASIS Open, 2023, §§1 and 3–5; McKeen et al., 2013, pp. 1–5; UK Health and Safety Executive, n.d.]. Their presence does not by itself establish that the contribution

3

is independently controlled or that lifecycle and alternative-invocation paths remain outside the constrained coalition. Provenance, logging, attestation, and audit define roles and protections for accounts of activity [W3C Provenance Working Group, 2013, §§1, 2.1, and 5.3; Schneier and Kelsey, 1999, abstract and §§2–4; Kelsey et al., 2010, abstract and §§1 and 6–8; Birkholz et al., 2023, §§3–4.2]. This paper allocates control over evidence production, attestation, preservation, suppression, and official designation. It does not define evidence validity, trace completeness, outcome consistency, verifier correctness, relation validity, or conformance. The closest foundations combine causal-authority analysis, attack or fault graph reasoning, trust management, and lifecycle control [Murray and Lowe, 2007, Sheyner et al., 2002, Kordy et al., 2014, Li et al., 2003, Regenscheid, 2018]. The contribution is the common typed pipeline that connects these foundations to protected-action-relative witnesses, trust-domain coalitions, boundary diagnostics, and evidentiary-authority allocation. Table 2.1. Established support and the framework’s integrated output. Established support

Integration in this paper

Authorization, capabilities, and threshold control

Typed, support-selected contributions projected to threat-model-relative trust domains. Grounded AND/OR/threshold witnesses for one concrete protected transition. Witness-relative traversal plus separate alteration, satisfaction, disablement, and bypass tests. A separate allocation of evidentiary control without importing verification semantics.

Attack, fault, and hypergraph structures Reference monitors and lifecycle control Provenance, logging, and attestation

The residual question is therefore compositional: which ordinary or reconfiguration-enabled witnesses can realize the transition, which domain coalitions can supply them, whether a claimed-final boundary constrains every witness, and whether the execution coalition also controls the authoritative account. The novelty claim is limited to organizing and deriving those outputs around that action-relative question. The technical supplement provides the extended area-by-area comparison.

3. Protected Execution as an Authority-Governed State Transition High-risk automated systems convert digital inputs into consequential financial, operational, cryptographic, or physical state changes. Authorization may precede those changes, but the event to be explained is the occurrence of the designated transition, whether reached through the intended workflow or another route. This paper calls that occurrence protected execution. Protected marks the transition as an object of the threat model; it does not imply authorization, correct mediation, or adequate security, and it does not mean execution inside a trusted environment [GlobalPlatform, 2017, McKeen et al., 2013]. The term is an analytical abstraction, not a new enforcement mechanism. Reference monitors, usage-control systems, HSMs, interlocks, and privileged services remain the concrete mechanisms [Anderson, 1972, Saltzer and Schroeder, 1975, Park and Sandhu, 2004, Hu et al., 2019, National Institute of Standards and Technology, 2019, OASIS Open, 2023, UK Health and Safety Executive, n.d.]. The framework asks how the powers that initiate, permit, constrain, reconfigure, perform, or

4

attest the transition are distributed across trust domains.

3.1 From permission to state change Authorization asks whether a request is permitted under stated rules; protected execution asks whether the designated transition occurred. Permission may be necessary, but it is not occurrence. Let 𝑟 denote a request concerning an action 𝑎, and let Authorize(𝑟, 𝑎, 𝛾) ∈ {permit, deny, conditional} represent the decision under context 𝛾. A permit result establishes rule satisfaction at that point, not occurrence of the action or control of its executing component. The scope is relative to a threat model Θ. Let 𝒜𝑃 (Θ) contain the actions whose occurrence changes state that Θ classifies as consequential or security-sensitive. This designation identifies what must be explained; it does not establish that any mechanism protects it adequately. For each 𝑎 ∈ 𝒜𝑃 (Θ), let + 𝜏𝑎 ∶ 𝑠 − 𝑎 → 𝑠𝑎 + denote its designated state transition, where 𝑠− 𝑎 and 𝑠𝑎 are the action-relevant projections of system state before and after the transition. For a system run 𝜌,

PE(𝑎, 𝜌) ⟺ 𝑎 ∈ 𝒜𝑃 (Θ) ∧ Occurs(𝜏𝑎 , 𝜌). Protected execution is therefore the occurrence of 𝜏𝑎 , not the surrounding workflow’s completion status. Later reversal does not erase the fact that the transition occurred. This distinction separates at least five analytically distinct stages, conditions, or questions that are often compressed in system descriptions: 1. A request is proposed. 2. The request is authorized or approved. 3. An actionable command is issued toward an execution boundary. 4. The command produces an execution attempt at that boundary. 5. The designated protected state transition occurs or does not occur. The stages may involve different actors or collapse into one process; either allocation is recorded because it changes the effect of compromise. An approved operation can therefore be refused without contradiction. Refusal prevents 𝜏𝑎 through the mediated path governed by that boundary; it does not establish non-occurrence elsewhere in the run. It shows only that upstream approval was insufficient through the refused path.

5

3.2 Execution attempts and protected execution Dispatch, API invocation, or queue insertion is not protected execution unless 𝜏𝑎 occurs. Formal claims use a causal realization witness: a possibly non-linear derivation containing every selected AND, OR, threshold, guard, resource, and reconfiguration condition needed for 𝜏𝑎 . Path refers only to an informal linear route. Section 5 supplies the complete semantics. A candidate execution boundary can accept or refuse an actionable command before 𝜏𝑎 . A claimed final execution boundary is a candidate that the design claims every feasible witness traverses. It is non-bypassable only if at least one feasible witness exists and every feasible witness traverses it. Non-bypassability is therefore a non-vacuous derived property, not part of the definition of a boundary or attempt [Anderson, 1972, Saltzer and Schroeder, 1975]. An execution attempt occurs when an actionable command reaches a candidate execution boundary and requests that an action 𝑎 ∈ 𝒜𝑃 (Θ) occur. If 𝑐 is a command, 𝐵 is a candidate boundary, and 𝜌 is a system run, then Attempt(𝑐, 𝑎, 𝐵, 𝜌) ⟺ Reaches(𝑐, 𝐵, 𝜌) ∧ Requests(𝑐, 𝑎). The definition assumes neither non-bypassability nor correct configuration. An attempt may be refused without protected execution, and protected execution may occur without an attempt at the claimed boundary. This yields three analytically distinct cases: • Correctly mediated protected execution occurs when the realized causal witness for 𝜏𝑎 traverses the claimed final boundary and satisfies the mediation conditions specified for that boundary. • Bypass execution occurs, relative to a claimed final boundary 𝐵𝑎∗ , when a realized causal witness for 𝜏𝑎 does not traverse 𝐵𝑎∗ . • Improperly mediated protected execution occurs when the realized causal witness traverses the claimed boundary but the transition is produced after that boundary has been compromised, disabled, misconfigured, or made to accept inputs outside its specified conditions. All three are protected execution because the designated transition occurred. The qualifiers describe how it occurred. In particular,

BypassExec(𝑎, 𝐵𝑎∗ , 𝜌) ⟺ PE(𝑎, 𝜌) ∧ ∃𝑤 (RealizedWitness𝑀,Θ,Γ (𝑤, 𝑎, 𝜌) ∧ ¬ Traverses(𝑤, 𝐵𝑎∗ )). The predicate is witness-relative, not run-wide: one run may contain both a refused mediated attempt and a distinct realized witness that avoids 𝐵𝑎∗ . Section 5 defines feasibility and run instantiation. The model is mechanism-neutral: reference monitors, policy engines, HSM policies, interlocks, capabilities, and threshold arrangements may all supply mediation [Hu et al., 2019, National Institute of Standards and Technology, 2019, OASIS Open, 2023, UK Health and Safety Executive, n.d., Clark and Wilson, 1987, Sandhu et al., 2000, Shamir, 1979]. Physical separation alone does not establish independent authority. 6

For composite or non-atomic operations, the analyst should model separately each protected subtransition and its commit point. A workflow failure does not imply that no protected state change occurred. Alternative interfaces, maintenance and debug facilities, updates, and privileged invocation paths belong in the witness inventory. If any admitted route enables a witness for 𝜏𝑎 that avoids 𝐵𝑎∗ , the boundary is bypassable. Questions about evidence validity, completeness, verification, or conformance remain outside this paper.

3.3 Execution authority Authority is a domain-controlled power that changes which outcomes are reachable; it does not imply legitimacy. Execution authority is the power to cause a designated protected transition. It is distinct from permission, credential possession, workflow approval, and policy evaluation, although those powers may contribute to a realization. The definition concerns effective rather than nominal control. An “executor” may remain insufficient because another domain can refuse, while an “administrator” may be sufficient through update, recovery, disablement, or alternative invocation. Execution authority may therefore be unilateral, jointly sufficient, or distributed across alternative minimal coalitions [Clark and Wilson, 1987, Sandhu et al., 2000, Shamir, 1979]. Fix a system configuration 𝑀 , a threat model Θ, a set of relevant trust domains 𝒟, and environmental assumptions Γ. For 𝑎 ∈ 𝒜𝑃 (Θ) and a coalition 𝑋 ⊆ 𝒟, the predicate EA𝑀,Θ,Γ (𝑋, 𝑎) holds when 𝑋 can cause 𝜏𝑎 without an indispensable decision from 𝒟 ∖ 𝑋. Its attributed powers include ordinary workflow powers and every update, override, credential-recovery, disablement, alternative-invocation, or other reconfiguration power admitted by Θ. Bypass remains derived: it exists only if those powers enable a witness that avoids 𝐵𝑎∗ . The predicate states capability, not inevitability; Section 5 gives its witness semantics. The assumptions in Γ may hold routine availability fixed but must not hide an independently controlled choice. An outside service that can still accept or refuse supplies an authority contribution, not mere environment. A minimal sufficient execution-authority set is a coalition that can cause the transition and contains no smaller sufficient coalition: MinimalEA𝑀,Θ,Γ (𝑋, 𝑎) ⟺ EA𝑀,Θ,Γ (𝑋, 𝑎) ∧ ∀𝑌 ⊊ 𝑋, ¬EA𝑀,Θ,Γ (𝑌 , 𝑎). The derived question is which inclusion-minimal domain sets can cause the transition. A singleton establishes unilateral capability; if every minimal set includes an independently controlled boundary domain, upstream command authority alone is insufficient. Sections 5 and 7 formalize those conclusions.

7

3.4 Trust domains and unilateral causation A trust domain is a threat-model-relative boundary within which compromise, administration, update authority, key ownership, or organizational control is treated as shared. It need not coincide with a machine, process, company, or location. Separate components collapse into one domain under common control; components in one device may remain separate only when their code, keys, lifecycle roots, and invocation paths are independently controlled. Domain 𝐷 can unilaterally cause protected execution when EA𝑀,Θ,Γ ({𝐷}, 𝑎) holds. A second component does not create causal separation if 𝐷 can alter its rule, manufacture all accepted inputs, disable it, or route around it. Evidence authority is separately the power to produce, attest, preserve, suppress, or officially designate an operation account. It becomes a causal contribution to a later action only when the system uses that designation as an input to the later protected transition. Unilateral causation is not inherently unacceptable; the framework exposes it for comparison with the action’s consequences and threat model. Component count is irrelevant when one domain controls the supposedly distinct approvals, credentials, policies, or executors. The unit of analysis is independent control over indispensable conditions.

3.5 Protected execution as an authority-governed state transition Protected execution is an authority-governed state transition because domain-controlled powers determine who can make 𝜏𝑎 occur. An expected mediated path can be summarized as authorization or approval

Proposed(𝑟) −−−−−−−−−−−−−−−→ Permitted(𝑟) command issuance

−−−−−−−−−−−→ Attempt(𝑐, 𝑎, 𝐵𝑎∗ , 𝜌) boundary decision

−−−−−−−−−−→ Decision𝐵∗𝑎 (𝑐, 𝜌), Decision𝐵∗𝑎 (𝑐, 𝜌) = accept ⟶ {

Realizes(𝜋𝑚 , 𝜏𝑎 , 𝜌), ¬Realizes(𝜋𝑚 , 𝜏𝑎 , 𝜌),

Decision𝐵∗𝑎 (𝑐, 𝜌) = refuse ⟶ ¬Realizes(𝜋𝑚 , 𝜏𝑎 , 𝜌), Here 𝜋𝑚 is one linear mediated path, not the witness object used for formal authority, bypass, nonbypassability, or veto claims. Acceptance does not establish protected execution unless 𝜏𝑎 occurs. Refusal establishes only non-occurrence through the refused path, not elsewhere in the run. Refusal may still change audit, retry, recovery, or policy state, and a distinct witness 𝑤𝑏 may realize 𝜏𝑎 without traversing 𝐵𝑎∗ , even in the same run. A compromised boundary may also be traversed without applying its specified conditions. Each resulting protected sub-transition must be modeled separately. The diagram is an analytical skeleton, not a mandatory protocol. The analyst must distinguish the transition from preceding decisions, identify the domains controlling indispensable steps, and enumerate every admitted witness. Access control, complete mediation, HSM policy, and interlocks

8

retain their native roles; the additional question is whether lifecycle or alternative powers restore upstream causal control. Authority decomposition does not prove safety, implementation correctness, witness completeness, or resistance to collusion. It establishes only which modeled domain coalitions are sufficient or insufficient for the designated transition.

4. Authority Taxonomy Section 3 defined protected execution as the occurrence of a threat-model-designated state transition and authority as a domain-controlled power that changes which outcomes are reachable. This section distinguishes nine core authority types: proposal, authorization, approval, command, policy decision, policy update, veto, execution, and evidence authority. The taxonomy is neither exhaustive nor mutually exclusive. It exposes powers that descriptions such as “authorized,” “approved,” or “allowed to execute” often collapse, without prescribing a universal workflow or treating distribution as proof of security.

4.1 How to read the taxonomy An authority type classifies a power, not an actor, component, role, message, or stage. Classification follows what a trust domain can make possible or impossible. The same type may be distributed across domains; one domain may hold several types; and one power may receive several classifications when it performs several functions. Assignments are relative to the protected action 𝑎, model 𝑀 , threat model Θ, environmental assumptions Γ, and any governed path. A firmware-replacement power, for example, may reconfigure action 𝑎 while its exercise is itself a separate protected action 𝑢. The labels also have different formal roles. Proposal, authorization, approval, command, policydecision, policy-update, and veto authority classify powers that contribute to or constrain realizations. Execution authority is an outcome-relative sufficiency property under EA𝑀,Θ,Γ . Evidence authority ordinarily concerns control over accounts of an operation rather than causal control of the described transition. All classifications are descriptive: a legitimate service and an attacker controlling the same command path may both possess command authority under Θ, despite different normative status. Table 4.1. Protected-action-relative authority taxonomy. Authority type

Object controlled

Analytical significance

What it does not establish

Proposal

Creation or submission of a request Normative permission status under a rule or entitlement Affirmation of a concrete request or workflow instance Production of an actionable instruction

Introduces an operation for consideration Determines permit, deny, or conditional status

Permission, attempt, or execution Approval of a concrete instance or execution

Supplies affirmative consent or confirmation

Policy correctness or execution

Directs an operation toward an execution boundary

Arrival at the boundary or protected execution

Authorization

Approval

Command

9

What it does not establish

Authority type

Object controlled

Analytical significance

Policy decision

Currently applicable rules and contextual inputs at a decision point

Authority to change the rules

Policy update

Modification of rules governing later decisions

Veto

Refusal of an attempt or blockage of a governed path Outcome-relative causal sufficiency for the designated protected transition Production, attestation, preservation, suppression, or official designation of evidence

Produces a decision that may instantiate authorization, contribute to veto, qualify approval, or remain advisory Changes which later decisions or paths are reachable Prevents 𝜏𝑎 through that mediated path Establishes that a domain or coalition can cause 𝜏𝑎 under EA𝑀,Θ,Γ

Authorization, legitimacy, correct mediation, or uniqueness of the sufficient coalition Evidence validity, verification, or causal control of the same transition

Execution

Evidence

Affects which operation accounts are created, endorsed, retained, withheld, or treated as authoritative

Exercise of the protected transition by itself Non-occurrence through every other path

The categories are functional rather than chronological. They may recur, overlap, or be absent, and a bypass may omit the nominal proposal, authorization, or approval sequence. Analysis therefore covers every admitted control path rather than mapping the labels mechanically onto one expected trace.

4.2 Initiating authority: proposal and command Proposal authority is the ability to create or submit a request concerning an action, including its target, parameters, timing, and requested operation where the interface permits. It does not establish permission, command issuance, arrival at a boundary, or execution. Command authority is the ability to turn a request, decision, or operation into an actionable instruction directed at an execution boundary. Its object is the command, not the request’s legitimacy. Issuance becomes an execution attempt only when the command reaches a candidate boundary and requests the protected action; it does not itself establish protected execution. The distinction separates expression of intent from production of an executable instruction. The powers may belong to different domains or collapse in a direct-call architecture. Command authority also covers maintenance, retry, recovery, CI/CD, administrative, and debug routes admitted by Θ. Whether any such route contributes to a feasible realization witness is determined by the typed model, not by its status as an exceptional path.

4.3 Normative, affirmative, and contextual decision authority Authorization authority determines the normative permission status of an actor or request under a rule or entitlement: permit, deny, or conditional. It may be request-specific, but derives from the rule being applied. Authorization is not inherently affirmative and does not cause 𝜏𝑎 . 10

Approval authority affirms a concrete request or workflow instance. A threshold establishes only that the approval condition has been satisfied; it does not establish later permission or execution. Multiple principals do not imply multiple trust domains when they share administration, recovery, update control, key ownership, or another compromise boundary under Θ. Authorization and approval may be exercised through one interface, but remain analytically distinct because delegation, compromise, and update can affect them differently. A domain may approve an instance without controlling its governing entitlement, or control the entitlement without affirming the instance. Policy decision authority evaluates currently applicable rules and contextual inputs at a decision point. Its output may instantiate authorization, qualify approval, contribute to a veto, or remain advisory, depending on its downstream effect. One decision may therefore receive several classifications. A negative output is not automatically a veto: a non-binding result has policy-decision authority only if it can affect a later decision or realization, whereas veto authority requires control sufficient to block the governed mediated path. Purely informational output that no downstream function consumes is not authority under the descriptive definition.

4.4 Meta-authority: policy update and related control Policy-update authority changes the rules used by later authorization, approval, policy-decision, or veto functions, including thresholds, accepted identities, targets, limits, and acceptance conditions. It differs from deciding under the rules currently in force. Firmware update, key replacement, credential recovery, boundary disablement, override, and alternative invocation are broader reconfiguration powers, not implicit subtypes of policy update. Section 5 represents them explicitly. Bypass is derived only when admitted powers enable a realization witness for 𝜏𝑎 that avoids 𝐵𝑎∗ ; there is no primitive CAN_BYPASS relation. Neither policy update nor broader meta-control necessarily establishes execution authority alone, but both may change the sufficient coalitions and must therefore appear in the causal analysis.

4.5 Restrictive authority: veto Veto authority is the ability to refuse an attempt or prevent a specified realization of 𝜏𝑎 through a governed mediated path. It is not the negative form of approval: prior approvals may remain valid even when a later boundary blocks their attempted realization. Veto is always path-relative. Blocking command issuance or refusing at a candidate boundary prevents that governed realization, but not necessarily a maintenance route, second command path, compromised boundary, or other executor. Global prevention requires at least one feasible witness, coverage of every feasible witness, and the relevant independence conditions. Non-bypassability and independence are therefore properties to be derived, not consequences of labeling a denial, HSM refusal, interlock, or service rejection as a veto.

4.6 Transition-realizing authority: execution Execution authority is the outcome-relative property of a trust-domain coalition sufficient to cause 𝜏𝑎 under EA𝑀,Θ,Γ . Protected execution remains execution even when unauthorized, incorrectly mediated, or reached through bypass. The nominal executor may be insufficient without another domain’s indispensable decision, while an administrator with direct invocation, replacement, or disablement powers may belong to a sufficient coalition. 11

A domain has unilateral execution authority when its singleton coalition satisfies EA. A coalition is jointly sufficient when it satisfies EA while no member is sufficient alone; inclusionminimality is assessed separately. Several alternative minimal sufficient coalitions may exist, and finding one singleton does not exclude others. Section 5 derives these coalitions from feasible witnesses rather than from component names or the nominal workflow. The result identifies concentration and dependency; it does not imply that either isolation or distribution is safe.

4.7 Epistemic authority: evidence Evidence authority controls production, attestation, preservation, suppression, or official designation of evidence associated with an operation. These powers govern which accounts are created, endorsed, retained, withheld, or treated as authoritative; they need not be co-located and do not ordinarily determine whether the described transition occurs. Evidence authority remains distinct from execution authority even when one domain holds both. It contributes causally to a later action only when the system treats an evidentiary designation as an input to that later protected transition. The contribution then concerns the later action. This separation permits analysis of self-attestation and evidence concentration without defining evidence validity, trace completeness, outcome consistency, verifier semantics, or conformance; Section 7 treats evidentiary independence as an accountability property separate from causal veto independence.

4.8 Classification rules and analytical limits Apply the taxonomy using six rules: 1. Classify effects, not labels. Determine what a domain can make reachable or unreachable for 𝑎 under 𝑀 , Θ, Γ, and the relevant path. 2. Permit overlap. One power may instantiate several types, one domain may hold several types, and domain-specific subtypes may be added where analytically necessary. 3. Represent exceptional powers explicitly. Include admitted maintenance, recovery, debug, update, replacement, disablement, override, and alternative-invocation powers. 4. Separate path functions from outcome sufficiency. The taxonomy identifies powers; EA𝑀,Θ,Γ derives unilateral, jointly sufficient, and alternative minimal sufficient coalitions from the typed model and feasible-witness inventory. 5. Keep restrictive claims path-relative. A refusal becomes global prevention only with witness coverage, non-vacuity, and independence. 6. Keep evidence authority epistemic unless it controls a later transition. Authority over an account is not causal control of the operation described. The framework does not require all nine types, a fixed order, or separate components. It requires analysts to distinguish the powers that exist and expose their concentration and dependencies.

5. Authority Graph Model This section turns the preceding vocabulary into a typed model for deriving sufficient trust-domain coalitions, boundary traversal, and veto coverage. “Authority graph” is convenient shorthand, but the causal plane is a directed hypergraph rather than an actor-to-actor graph. The model is mechanism-neutral and derives authority from controlled powers and feasible realization witnesses, not component or role names. 12

Here 𝑎 is a concrete protected-action instance, such as one specified payment, signature, or actuation request. Repeated operations of the same type are distinct instances, each mapped to its own transition. This convention binds the request, witness, occurrence, and bypass claim to the same action.

5.1 Why an ordinary authority graph is insufficient Ordinary directed reachability cannot distinguish conjunctive prerequisites, alternative derivations, or threshold subsets. Component diagrams also exaggerate independence when several boxes share administration, update, recovery, or another compromise boundary. Finally, nominal workflow edges omit reconfiguration powers that may create alternative realizations. The model therefore uses typed hyperarcs, trust-domain projection, explicit power and resource control, reconfiguration, and support-selected witnesses [Gallo et al., 1993, Schneier, 1999, Phillips et al., 1998, Vesely et al., 1981]. It identifies sufficiency under declared assumptions rather than simulating an implementation.

5.2 Typed analytical objects and trust-domain normal form For a system configuration 𝑀 , threat model Θ, environmental assumptions Γ, and concrete protected-action instance 𝑎, define the typed authority model 𝒢𝑀,Θ,Γ,𝑎 = ⟨𝒞, 𝒟, 𝒫, 𝒜𝑃 , 𝒯, ℬ𝐶 , ℬ𝐹 , ℛ, ℰ, 𝛿, 𝜅, 𝜏 , Class, ℋ𝐶 , ℋ𝐸 ⟩ . Here 𝒞 contains analytical components; 𝒟, trust domains; 𝒫, controlled powers; 𝒜𝑃 (Θ), protectedaction instances; 𝒯, designated transitions; ℬ𝐶 and ℬ𝐹 , action-indexed candidate and claimed-final boundary sets; ℛ, controlled resources and mutable state; ℰ, epistemic objects; and ℋ𝐶 , ℋ𝐸 , the causal and epistemic typed hypergraphs. The protected-action mapping has the signature 𝜏 ∶ 𝒜𝑃 (Θ) → 𝒯,

𝜏 (𝑎) = 𝜏𝑎 .

Thus 𝜏𝑎 denotes the transition for the same concrete instance in every witness and run-level predicate. Boundary status is also action-relative. Formally, ℬ𝐶 , ℬ𝐹 ∶ 𝒜𝑃 (Θ) → 2𝒞 , and CandidateFor𝑀,Θ (𝐵, 𝑎) ⟺ 𝐵 ∈ ℬ𝐶 (𝑎), ClaimedFinalFor𝑀,Θ (𝐵, 𝑎) ⟺ 𝐵 ∈ ℬ𝐹 (𝑎). A candidate boundary can accept or refuse an actionable command before 𝜏𝑎 ; a claimed-final boundary is asserted by the design to lie on every feasible witness. Hence

13

∀𝑎 ∈ 𝒜𝑃 (Θ),

ℬ𝐹 (𝑎) ⊆ ℬ𝐶 (𝑎),

or, equivalently, ClaimedFinalFor𝑀,Θ (𝐵, 𝑎) ⇒ CandidateFor𝑀,Θ (𝐵, 𝑎). The designation records, but does not prove, an action-relative architectural claim. 𝐵𝑎∗ denotes a distinguished member of ℬ𝐹 (𝑎), not a globally final boundary. The component-to-domain assignment is 𝛿𝑀,Θ ∶ 𝒞 → 𝒟. The mapping is single-valued because 𝒞 is placed in trust-domain normal form: independently controlled surfaces of one physical component are represented as analytical subcomponents until each has one domain assignment. This is analytical decomposition, not a claim of physical separation. Control of powers and mutable resources is recorded separately: 𝜅𝑀,Θ ∶ 𝒫 ∪ ℛ → 2𝒟 ∖ {∅}. The set 𝜅(𝑝) or 𝜅(𝑟) identifies participating controllers; hyperarcs specify whether their control is conjunctive, disjunctive, or threshold-based. Components mapped by 𝛿 to the same domain contribute only one independent coalition member. Γ may fix non-discretionary operating conditions but may not conceal an independently controlled choice. Any domain able to accept or refuse an indispensable contribution must appear in the causal model. Table 5.1 separates model-level feasibility or capability from run-level instantiation and occurrence. Table 5.1. Core model-level, witness-level, and run-level notation. Notation

Level

Meaning

𝒢𝑀,Θ,Γ,𝑎

Model

𝜏 (𝑎) = 𝜏𝑎

Model

𝛿𝑀,Θ

Model

𝜅𝑀,Θ

Model

CandidateFor𝑀,Θ (𝐵, 𝑎)

Model

ClaimedFinalFor𝑀,Θ (𝐵, 𝑎)

Model

Typed authority model for concrete protected-action instance 𝑎. Maps 𝑎 to its designated protected state transition. Assigns each trust-domain-normal-form component to one domain. Identifies controller domains for powers and mutable resources. 𝐵 can mediate an attempt concerning 𝑎. The design claims 𝐵 lies on every feasible witness for 𝑎.

14

Notation

Level

Meaning

Class𝑀,Θ,Γ (𝑝, 𝑎, 𝑞)

Model

Core authority labels assigned to power 𝑝 relative to 𝑎 and optional governed causal substructure 𝑞.

Model

Separate domain-control projections for the five evidence powers. 𝑤 is a type-correct, support-selected feasible derivation of 𝜏𝑎 . At least one feasible witness for 𝑎 exists. Independent trust domains required by the selected support of 𝑤. Req(𝑤) ⊆ 𝑋. Some feasible witness for 𝑎 has domain requirements contained in 𝑋. 𝑋 has execution authority and no proper subset does. Mediation by 𝐵 belongs to the selected causal support of 𝑤. Exercising veto 𝑣 invalidates witness 𝑤’s selected support. A claimed-final boundary is traversed by every member of a nonempty feasible-witness set. Veto 𝑣 covers every member of a nonempty feasible-witness set. Run 𝜌 instantiates the selected powers, facts, changes, and dependencies in 𝑤. The instantiated selected support of 𝑤 causally culminates in 𝜏𝑎 in 𝜌. The transition for the same concrete action instance 𝑎 occurs in 𝜌. The concrete protected-action instance is in scope and its designated transition occurs. A feasible witness is instantiated in 𝜌 and causally culminates in 𝜏𝑎 . A realized witness for 𝑎 in 𝜌 avoids boundary 𝐵 claimed final for 𝑎.

𝜂produce , 𝜂attest , 𝜂preserve , 𝜂suppress , 𝜂official FeasibleWitness𝑀,Θ,Γ (𝑤, 𝑎)

Model

HasFeasibleWitness𝑀,Θ,Γ (𝑎)

Model

Req𝑀,Θ,Γ (𝑤)

Model

CoalitionRealizable𝑀,Θ,Γ (𝑤 ∣ 𝑋) EA𝑀,Θ,Γ (𝑋, 𝑎)

Model Model

MinimalEA𝑀,Θ,Γ (𝑋, 𝑎)

Model

Traverses(𝑤, 𝐵)

Witness structure

Covers(𝑣, 𝑤)

Model / counterfactual

NonBypassable𝑀,Θ,Γ (𝐵, 𝑎)

Model

GlobalVetoCoverage𝑀,Θ,Γ (𝑣, 𝑎)

Model

Instantiates(𝜌, supp(𝑤))

Run

CausallyCulminates(𝑤, 𝜏𝑎 , 𝜌)

Run

Occurs(𝜏𝑎 , 𝜌)

Run

PE(𝑎, 𝜌)

Run

RealizedWitness𝑀,Θ,Γ (𝑤, 𝑎, 𝜌)

Run

BypassExec𝑀,Θ,Γ (𝑎, 𝐵, 𝜌)

Run

15

5.3 Power classification and primitive relations The taxonomy in Section 4 classifies powers rather than components. Let

ℒcore = {proposal, authorization, approval, command, policy-decision, policy-update, veto, evidence}. The classification function is Class𝑀,Θ,Γ ∶ 𝒫 × 𝒜𝑃 (Θ) × (Sub(ℋ𝐶 ) ∪ {⊥}) → 2ℒcore . The optional 𝑞 identifies a governed causal substructure; use 𝑞 = ⊥ when none is required. Classifications may overlap. Execution is excluded from ℒcore because it is derived for coalitions through EA𝑀,Θ,Γ , not assigned to an isolated power. Table 5.2 states the required primitive relation families; domain-specific models may refine them where causal support differs. Table 5.2. Primitive power and relation families used in the causal model. Primitive power or relation family

Core classification when applicable

Request creation or submission

proposal

Determination of permit, deny, or conditional status Concrete affirmation or threshold contribution Contextual rule evaluation

authorization; possibly policy-decision approval

Command construction, issuance, delivery, or alternative invocation Boundary acceptance or non-refusal Boundary refusal

policy-decision; possibly authorization or veto command policy-decision or another domain-specific label veto; possibly policy-decision

Policy modification

no execution label assigned by Class policy-update

Firmware replacement, update-root control, credential or key replacement and recovery, disablement, override

a core label only when its actual effect warrants one; otherwise an explicit domain-specific reconfiguration power

CAN_PERFORM_TRANSITION

Modeled effect Introduces a request concerning 𝑎. Establishes a normative status consumed by a later structure. Supplies instance-specific approval support. Supplies a decision consumed by a later causal structure. Creates or transports an actionable instruction. Supplies selected support for a mediated realization. Invalidates the governed mediated structure. Performs 𝜏𝑎 when its modeled prerequisites hold. Changes rules used by later decisions. Changes configurations, guards, resources, or available hyperarcs.

The final row is not collapsed into policy update because different reconfiguration powers can produce different successor configurations and witnesses. Likewise, CAN_PERFORM_TRANSITION states only that a power can perform 𝜏𝑎 when its prerequisites hold; coalition sufficiency requires a complete feasible witness. The epistemic primitive vocabulary records five powers separately: 16

CAN_PRODUCE_EVIDENCE,

CAN_ATTEST_EVIDENCE,

CAN_SUPPRESS_EVIDENCE,

CAN_PRESERVE_EVIDENCE,

CAN_DESIGNATE_OFFICIAL.

For each evidence object 𝑒 ∈ ℰ, the corresponding control projections are 𝜂produce , 𝜂attest , 𝜂preserve , 𝜂suppress , 𝜂official ∶ ℰ → 2𝒟 . Each 𝜂-mapping projects controllers of one evidence function from ℋ𝐸 and 𝜅. It identifies control but does not define evidence structure or validity. An official designation contributes causally only when consumed by a later protected action, and then only to that later action. Bypass is likewise non-primitive: it exists only when admitted powers support a realized witness that avoids a claimed-final boundary.

5.4 Causal and epistemic hypergraphs ℋ𝐶 contains typed power exercises, commands, decisions, conditions, mediation, configurations, and transitions; its hyperarcs derive causal facts from selected prerequisite sets. ℋ𝐸 contains epistemic objects and exercises of the five evidence powers, with 𝜂 projecting their controllers. This plane records control over accounts, not their structure, relation validity, completeness, consistency, verification, or conformance. An epistemic relation becomes causal only through an explicit consumption relation from an official designation to a later protected action. Figure 5.1 summarizes the layered model. The planes are semantically, not necessarily physically, separate: one domain may control nodes in both.

5.5 AND, OR, and threshold semantics The causal hypergraph uses conjunctive, disjunctive, and threshold support. A conjunctive hyperarc 𝑒 = (𝑆, ℎ, 𝜙, ℓ) derives ℎ only when every typed prerequisite in 𝑆 is satisfied, guard 𝜙 holds, and relation type ℓ permits the derivation. Disjunction uses multiple incoming hyperarcs; a witness selects one supporting alternative. A threshold hyperarc 𝑒 = (𝑆, 𝑘, ℎ, 𝜙, ℓ) derives ℎ when a satisfying 𝑘-of-𝑛 subset of 𝑆 is present and the guard holds. A witness selects an inclusion-minimal satisfying subset—exactly 𝑘 prerequisites for an unweighted rule. Support selection yields a definite causal certificate and excludes unused branches from traversal, coalition, and veto-coverage predicates. 17

TRUST-DOMAIN CONTROL LAYER Trust domains D delta

kappa

epistemic control

EPISTEMIC PLANE H_E Evidence-control powers Components C

Powers and mutable resources P union R

production; attestation; preservation suppression; official designation

CAUSAL PLANE H_C Typed ordinary support inputs proposal authorization / policy decision

admitted update / recovery / override / alternative-invocation certificate s

operation-account / evidence objects

command issuance

typed support

reconfigures

causal only if consumed by a later protected action

Support operators AND

successor configuration M prime

later protected action a prime

composite witness s composed with w prime

later transition tau_a prime

OR k-of-n threshold support selection

support-selected ordinary witness w mediated support

may traverse

candidate or claimed-final boundary B*a

or alternative support

selected causal support

protected transition tau_a derive

Derived over feasible realization witnesses Req(w) and execution authority inclusion-minimal coalitions boundary traversal and bypass non-bypassability and veto coverage

Figure 5.1. Layered authority model. AND, OR, threshold, ordinary-witness, reconfiguration-witness, and causal/epistemic structures remain explicit; the diagram does not assert that every displayed alternative is present in every system.

18

Thresholds are first evaluated at the system’s principal or component level, then projected through 𝛿𝑀,Θ . Three selected approvers in one trust domain may satisfy the implementation threshold while contributing only one independent domain to the authority coalition [Clark and Wilson, 1987, Sandhu et al., 2000, Shamir, 1979].

5.6 Reconfiguration sequences A feasible realization from an initial configuration may include a finite reconfiguration prefix: 𝑝1

𝑝𝑗

𝑝2

𝑤

𝑀0 −→ 𝑀1 −→ ⋯ −→ 𝑀𝑗 =⇒ 𝜏𝑎 . Each 𝑝𝑖 is admitted by Θ and may change a guard, resource, credential, boundary, interface, control assignment, or available hyperarc. The suffix is evaluated in 𝑀𝑗 , while its coalition includes controllers of every selected prefix step. Policy update, firmware replacement, recovery, disablement, and override remain distinct whenever they produce different successor configurations, requirements, or traversal results. Θ determines which sequences are admitted; consequential reconfiguration may itself be analyzed as another protected action. Final-boundary claims quantify over all admitted witnesses from 𝑀 , including those enabled by such prefixes.

5.7 Causal realization witnesses A causal realization witness 𝑤 is a finite, support-selected certificate consisting of an optional reconfiguration prefix and a type-correct derivation subhypergraph terminating in 𝜏𝑎 . Its selected steps, powers, facts, nodes, and hyperarcs form supp(𝑤). The support must satisfy eight conditions: 1. Its terminal conclusion is 𝜏𝑎 for the same action instance. 2. Every AND prerequisite is retained. 3. Each OR step selects one supporting alternative. 4. Each threshold step selects one inclusion-minimal satisfying subset. 5. Selected guards and resource conditions hold under the modeled configuration and Γ. 6. A strict order ≺𝑤 places every selected prerequisite before its head. 7. Every leaf is grounded in the initial configuration, Γ, a satisfied condition, or a controlled power exercise. 8. Every included element contributes to 𝜏𝑎 ; unused alternatives and unrelated events are excluded. Well-foundedness and grounding exclude unsupported cycles. Traversal, coverage, and coalition attribution are evaluated only over supp(𝑤). The model-level predicate FeasibleWitness𝑀,Θ,Γ (𝑤, 𝑎) holds when 𝑎 ∈ 𝒜𝑃 (Θ) and 𝑤 is admitted from 𝑀 under Θ, Γ, with jointly satisfiable controlled prerequisites. Feasibility neither asserts run-level instantiation nor selects a smallest coalition. Nonempty realizability is explicit:

19

HasFeasibleWitness𝑀,Θ,Γ (𝑎) ⟺ 𝑎 ∈ 𝒜𝑃 (Θ) ∧ ∃𝑤 FeasibleWitness𝑀,Θ,Γ (𝑤, 𝑎). At run level, Instantiates(𝜌, supp(𝑤)) holds when 𝜌 contains the selected exercises, changes, facts, guards, and dependencies in supp(𝑤), all for the same action instance. Other run events are excluded. Mere co-occurrence is insufficient. The predicate CausallyCulminates(𝑤, 𝜏𝑎 , 𝜌) requires the instantiated derivation to culminate causally in 𝜏𝑎 , and entails Occurs(𝜏𝑎 , 𝜌). Thus RealizedWitness𝑀,Θ,Γ (𝑤, 𝑎, 𝜌) ⟺ FeasibleWitness𝑀,Θ,Γ (𝑤, 𝑎) ∧ Instantiates(𝜌, supp(𝑤)) ∧ CausallyCulminates(𝑤, 𝜏𝑎 , 𝜌). The last conjunct excludes attempted derivations and unrelated occurrences. Coalition attribution remains model-level. For each feasible witness, define Req𝑀,Θ,Γ (𝑤) ⊆ 𝒟 as the independent domains required by supp(𝑤). Construction projects selected components through 𝛿, powers and resources through 𝜅, follows selected controller alternatives or thresholds, collapses duplicate domains, excludes only non-discretionary facts in Γ, and includes every selected reconfiguration step. For 𝑋 ⊆ 𝒟, coalition realizability is CoalitionRealizable𝑀,Θ,Γ (𝑤 ∣ 𝑋) ⟺ Req𝑀,Θ,Γ (𝑤) ⊆ 𝑋. Unused alternatives and duplicate same-domain components add no requirements; extra members of 𝑋 need not act. Finally, Traverses(𝑤, 𝐵) holds only when mediation by 𝐵 belongs to the selected support deriving 𝜏𝑎 . Appearance elsewhere, on an unused branch, or as a disablement target is insufficient. One run may contain a refused route through 𝐵 and a distinct realized witness that avoids it.

20

5.8 Execution-authority and minimal-coalition derivation Execution authority holds when a coalition contains the requirements of at least one feasible witness: EA𝑀,Θ,Γ (𝑋, 𝑎) ⟺ ∃𝑤 (FeasibleWitness𝑀,Θ,Γ (𝑤, 𝑎) ∧ Req𝑀,Θ,Γ (𝑤) ⊆ 𝑋). This is a monotone capability claim, not an assertion that a run occurred. A domain has unilateral execution authority when its singleton coalition is sufficient: UnilateralEA𝑀,Θ,Γ (𝑑, 𝑎) ⟺ EA𝑀,Θ,Γ ({𝑑}, 𝑎). A coalition is jointly sufficient when it is sufficient, contains more than one domain, and no individual member is sufficient alone: JointlySufficient𝑀,Θ,Γ (𝑋, 𝑎) ⟺ EA𝑀,Θ,Γ (𝑋, 𝑎) ∧ |𝑋| > 1 ∧ ∀𝑑 ∈ 𝑋, ¬EA𝑀,Θ,Γ ({𝑑}, 𝑎). Joint sufficiency does not imply inclusion-minimality, which requires: MinimalEA𝑀,Θ,Γ (𝑋, 𝑎) ⟺ EA𝑀,Θ,Γ (𝑋, 𝑎) ∧ ∀𝑌 ⊊ 𝑋, ¬EA𝑀,Θ,Γ (𝑌 , 𝑎). Equivalently, all alternative minimal sufficient coalitions can be extracted directly from witness requirements: ℳ𝐸𝐴 (𝑀 , Θ, Γ, 𝑎) = min {Req𝑀,Θ,Γ (𝑤) ∣ FeasibleWitness𝑀,Θ,Γ (𝑤, 𝑎)} , ⊆

where min⊆ removes any set with a proper subset in the family. A singleton establishes unilateral authority without excluding other minimal coalitions. Operationally, enumerate witnesses, compute Req(𝑤), and remove nonminimal sets; neither component count nor a transition primitive alone determines sufficiency. The following internal sanity results do not claim isolated mathematical novelty. Proposition 1 (domain-collapse invariance). Duplicating or decomposing components within one trust domain does not create additional independent coalition members when the selected control assignments are unchanged. Justification. Projection through 𝛿 yields the same domain, and set formation in Req(𝑤) removes duplicate contributions. Proposition 2 (execution-authority monotonicity). If 𝑋 ⊆ 𝑌 and EA𝑀,Θ,Γ (𝑋, 𝑎), then EA𝑀,Θ,Γ (𝑌 , 𝑎). Justification. The witnessing requirement set satisfies Req(𝑤) ⊆ 𝑋 ⊆ 𝑌 . Proposition 3 (minimal-coalition extraction). Under support-selected witness semantics, ℳ𝐸𝐴 is the set-inclusion-minimal family of Req(𝑤) over feasible witnesses for 𝑎. Justification. Every execution-authority coalition contains at least one feasible witness requirement set; a minimal sufficient coalition therefore equals an inclusion-minimal such set, and every inclusion-minimal requirement set is sufficient. 21

5.9 Bypass, non-bypassability, and veto coverage The run-level protected-execution predicate is: PE(𝑎, 𝜌) ⟺ 𝑎 ∈ 𝒜𝑃 (Θ) ∧ Occurs(𝜏𝑎 , 𝜌). Run-level bypass requires a realized witness that avoids a boundary claimed final for the same action:

BypassExec𝑀,Θ,Γ (𝑎, 𝐵, 𝜌) ⟺ ClaimedFinalFor𝑀,Θ (𝐵, 𝑎) ∧ PE(𝑎, 𝜌) ∧ ∃𝑤 (RealizedWitness𝑀,Θ,Γ (𝑤, 𝑎, 𝜌) ∧ ¬ Traverses(𝑤, 𝐵)). The predicate is witness-relative: the same run may also contain an attempted or refused route through 𝐵. Model-level non-bypassability additionally requires a nonempty feasible-witness set and universal traversal: NonBypassable𝑀,Θ,Γ (𝐵, 𝑎) ⟺ ClaimedFinalFor𝑀,Θ (𝐵, 𝑎) ∧ HasFeasibleWitness𝑀,Θ,Γ (𝑎) ∧ ∀𝑤 (FeasibleWitness𝑀,Θ,Γ (𝑤, 𝑎) ⇒ Traverses(𝑤, 𝐵)). The existence conjunct prevents vacuity, and the universal quantifier includes all admitted reconfiguration-enabled witnesses. Claimed-final status records the assertion; the other conjuncts evaluate it. Veto coverage is support-relative. For veto 𝑣 governing mediated substructure 𝑞, Blocks(𝑣, 𝑞) holds when exercising 𝑣, with other facts fixed, prevents 𝑞 from deriving 𝜏𝑎 . For witness 𝑤, Covers(𝑣, 𝑤) holds when the governed mediation belongs to supp(𝑤) and the veto invalidates it. Blocking an unused alternative or contribution is insufficient. The path-relative coverage set is Coverage𝑀,Θ,Γ (𝑣, 𝑎) = {𝑤 ∣ FeasibleWitness𝑀,Θ,Γ (𝑤, 𝑎) ∧ Covers(𝑣, 𝑤)} . Here path-relative informally denotes a governed route; formal coverage quantifies over possibly non-linear support-selected witnesses. The global-witness-coverage predicate is: 22

GlobalVetoCoverage𝑀,Θ,Γ (𝑣, 𝑎) ⟺ HasFeasibleWitness𝑀,Θ,Γ (𝑎) ∧ ∀𝑤 (FeasibleWitness𝑀,Θ,Γ (𝑤, 𝑎) ⇒ Covers(𝑣, 𝑤)). Global coverage is non-vacuous and still requires the independence conditions in Section 7. These predicates are causal: absence of recorded mediation does not prove bypass, because this paper does not supply record-completeness or verification semantics.

5.10 Operational procedure and illustrative end-to-end authority derivation Algorithm 1: Authority-Decomposition Analysis Procedure Inputs: a concrete protected-action instance 𝑎; system configuration 𝑀 ; threat model Θ; and environmental assumptions Γ. 1. Identify the action-relevant protected transition 𝜏𝑎 and, for a composite operation, separate any other consequential commit points into different protected actions. 2. Define the action-relative analytical objects: components, powers, controlled resources, candidate and claimed-final boundaries, vetoes, transition performers, and epistemic objects. 3. Put components in trust-domain normal form and assign each component through 𝛿𝑀,Θ ; assign powers and mutable resources through 𝜅𝑀,Θ . Record disputed assignments as alternative models. 4. Enumerate ordinary workflow powers and every update, recovery, override, disablement, credential-replacement, alternative-invocation, or other reconfiguration power admitted by Θ. Do not treat bypass as a primitive power. 5. Construct type-correct, finite, grounded, support-selected feasible realization witnesses for 𝜏𝑎 , retaining the selected AND inputs, OR alternative, or inclusion-minimal threshold subset. 6. Apply the declared reconfiguration closure: compose each admitted finite control certificate from 𝑀 with each compatible successor-configuration witness, attribute the complete composite support to the initial model, and stop at the stated depth, state abstraction, or fixed point. 7. Compute Req𝑀,Θ,Γ (𝑤) for each feasible witness by projecting selected discretionary support to its controller domains, collapsing same-domain contributions, and excluding only nondiscretionary facts explicitly placed in Γ. 8. Derive EA𝑀,Θ,Γ (𝑋, 𝑎) from witness containment and identify unilateral and joint sufficient coalitions. 9. Extract ℳ𝐸𝐴 (𝑀 , Θ, Γ, 𝑎) by removing every requirement set that has a proper subset in the feasible-witness requirement family. 10. Evaluate boundary traversal, veto coverage, I1–I4, dangerous authority patterns, and, separately, evidentiary independence for the admissible execution coalitions. Outputs: the bounded witness inventory; execution-authority and inclusion-minimal coalitions; boundary, veto, pattern, and independence results; and an uncertainty ledger. The procedure may be manual or tool-assisted over a finite representation. It makes no general discovery or scalability claim: completeness is relative to the supplied model, power inventory, assignments, reconfiguration closure, and witness bound. Cyclic or extensible systems require a stated finite abstraction, depth bound, or fixed-point rule.

23

Illustrative End-to-End Authority Derivation Consider a signing appliance where 𝑎 is production of signature 𝜎 over digest ℎ, with key 𝐾 and request identifier 𝑖. The bounded model (𝑎, 𝑀0 , Θ0 , Γ0 ) admits the ordinary route plus stated firmware-replacement and maintenance-invocation powers, but no other physical, recovery, or hidden-interface witness. Power, availability, and usable 𝐾 are non-discretionary in Γ0 ; a discretionary key-release controller would instead enter the requirements. Domains 𝐷𝐶 , 𝐷𝐵 , and 𝐷𝐴 respectively control command production; the claimed-final boundary and ordinary signer; and update plus maintenance signing: 𝛿(𝐵∗ ) = 𝛿(𝑐𝑥 ) = 𝐷𝐵 ,

𝛿(𝑐𝑢 ) = 𝛿(𝑐𝑚 ) = 𝛿(𝑐𝑥𝑚 ) = 𝐷𝐴 ,

𝛿(𝑐𝑔 ) = 𝛿(𝑐𝑠 ) = 𝐷𝐶 .

The design asserts 𝐵∗ is candidate and claimed final: ClaimedFinalFor𝑀0 ,Θ0 (𝐵∗ , 𝑎) ∧ CandidateFor𝑀0 ,Θ0 (𝐵∗ , 𝑎). Table 5.3. Selected typed powers and trust-domain controllers in the illustrative derivation. Power

Controller

Selected effect

𝑝𝑔 , 𝑝𝑠

𝐷𝐶

𝑝𝑏+ , 𝑣𝑏

𝐷𝐵

𝑝𝑥

𝐷𝐵

𝑝𝑢

𝐷𝐴

𝑝𝑚 , 𝑝𝑥𝑚

𝐷𝐴

Construct, release, and deliver the concrete signing command. Accept or refuse the mediated command at 𝐵∗ . Perform 𝜏𝑎 after valid boundary acceptance. Install the admitted maintenance firmware and produce successor configuration 𝑀1 . Invoke maintenance signing and perform 𝜏𝑎 in 𝑀1 .

The support-selected ordinary witness and the reconfiguration-enabled witness are AND

𝑤med ∶ {𝑝𝑔 , 𝑝𝑠 , 𝑝𝑏+ , 𝑝𝑥 } ===⇒ 𝜏𝑎 ,

Traverses(𝑤med , 𝐵∗ ),

and 𝑝𝑢

𝑤upd ∶ 𝑀0 −→ 𝑀1 ,

AND

{𝑝𝑚 , 𝑝𝑥𝑚 } ===⇒ 𝜏𝑎 ,

¬ Traverses(𝑤upd , 𝐵∗ ).

Projection through 𝛿 and 𝜅 yields Req(𝑤med ) = {𝐷𝐶 , 𝐷𝐵 }, and

24

Req(𝑤upd ) = {𝐷𝐴 }. Hence EA({𝐷𝐶 , 𝐷𝐵 }, 𝑎)

and EA({𝐷𝐴 }, 𝑎),

while neither 𝐷𝐶 nor 𝐷𝐵 is sufficient alone. Removing nonminimal sets gives ℳ𝐸𝐴 (𝑀0 , Θ0 , Γ0 , 𝑎) = {{𝐷𝐶 , 𝐷𝐵 }, {𝐷𝐴 }}. Because 𝑤upd avoids 𝐵∗ , ¬ NonBypassable𝑀 ,Θ ,Γ (𝐵∗ , 𝑎), 0

0

0

¬ GlobalVetoCoverage𝑀 ,Θ ,Γ (𝑣𝑏 , 𝑎). 0

0

0

Thus I4 fails relative to 𝑈 = {𝐷𝐴 }, but the avoiding witness alone says nothing about I1–I3. With no epistemic objects, evidentiary independence is “not modeled.” The example traces the bounded derivation from powers and domain projection to witnesses, minimal coalitions, and boundary results.

5.11 Analytical scope and limitations The result is conditional on the supplied model. It does not prove implementation correctness, discover omitted interfaces or powers, establish witness completeness, or show resistance to collusion and common-mode failure. Uncertain shared compromise boundaries remain uncertain even after trust-domain normalization. Results also depend on Γ: a discretionary choice hidden as availability understates requirements, while treating deterministic services as discretionary overstates them. Composite operations still require separate protected sub-actions. The epistemic plane identifies control over evidence production, attestation, preservation, suppression, and official designation, but not evidence structure, relation validity, outcome consistency, trace completeness, verifier behavior, or conformance. Missing mediation records therefore do not prove bypass. Subject to these limits, Sections 6 and 7 use the model to derive dangerous configurations and independence conditions.

6. Dangerous Authority Patterns The model reveals configurations obscured by workflow diagrams: same-domain approvals, upstream-controlled boundary inputs, reconfiguration witnesses, and concentrated evidence control. This section groups them into causal concentration, boundary capture, alternative realization, administrative collapse, and epistemic concentration. They are derived diagnostics—not primitive authority types, automatic vulnerability findings, or security mechanisms [Anderson, 1972, Saltzer and Schroeder, 1975, Regenscheid, 2018, Phillips et al., 1998].

25

6.1 From powers to configurations A power list alone is insufficient: analysis uses selected causal and epistemic support. Fix 𝑀 , Θ, Γ, 𝑎, 𝒟 and, where relevant, 𝑋, 𝑈 , 𝐵, 𝑣. Results change with the action, controller assignments, domain partition, and admitted powers. Controls𝑀,Θ,Γ (𝑋, 𝑝) means that exercising 𝑝 has complete selected support requiring no domain outside 𝑋. Reconfiguration matters only when selected in a feasible witness or control certificate, and bypass remains derived from a witness avoiding the designated boundary.

6.2 Criteria and taxonomy Dangerous is comparative and action-relative: the topology grants a relevant capability, defeats claimed independence, or concentrates epistemic control. A finding must identify the coalition, selected witness or control certificate, and consequence. Co-location, update authority, self-produced evidence, or a threshold alone is insufficient, and the finding denotes capability rather than exercise in every run. Table 6.1. Dangerous authority patterns and their principal consequences. Pattern

Predicate or compact trigger

Principal consequence

Self-authorizing executor

SelfAuthorizingExecutor: the exact authorization-controller set also satisfies EA.

Approval-execution compression

Upstream-satisfied boundary

The selected approval certificate contains the witness requirement set and no outside final restriction remains. CanSatisfy(𝑈 , 𝐵, 𝑎).

The exact authorization-controller set can also cause 𝜏𝑎 without an outside-domain decision. The approval support consumed by the witness contains a sufficient execution coalition.

Mutable veto

CanWeakeningAlter(𝑈 , 𝐵, 𝑣, 𝑎).

Veto disablement or forced non-refusal Bypassable final boundary or veto

CanDisable(𝑈 , 𝐵, 𝑣, 𝑎).

Reconfiguration–execution coupling

A selected reconfiguration power occurs in a minimal sufficient realization witness. An admitted administrative reconfiguration witness yields unilateral execution authority.

Owner or administrative override collapse

Self-attesting executor

BypassableFinalBoundary, BypassableVeto, or coalition-relative CanBypass.

An execution coalition produces or attests its own modeled account.

26

A nominal boundary supplies no independently controlled favorable condition against 𝑈 . 𝑈 can reconfigure the boundary or veto in a direction that expands or simplifies realization. 𝑈 can neutralize the restriction while a feasible witness remains. A feasible realization avoids a boundary represented as final; the veto variant also requires a boundary-bound veto claim. Its controller becomes part of a minimal sufficient execution coalition. Recovery, override, key, firmware, or alternative-invocation control makes the administrator alone sufficient. The executor controls a selected production or attestation power over its own account.

Pattern

Predicate or compact trigger

Principal consequence

Evidence-control collapse

An execution coalition can suppress all modeled contrary accounts and exclusively designate its preferred account.

The coalition controls the authoritative account as well as an execution route.

The supplement retains the complete quantified catalog and interaction matrix; the main text gives representative definitions.

6.3 Causal authority concentration 6.3.1 Self-authorizing executor A self-authorizing executor exists when the exact domains required to exercise a relevant authorization power are themselves sufficient for execution. Let 𝑌 ⊆ 𝒟 be that exact selected controller set:

SelfAuthorizingExecutor𝑀,Θ,Γ (𝑌 , 𝑎) ⟺ ∃𝑠, 𝑝, 𝑞 (AuthorizationCertificate𝑀,Θ,Γ (𝑠, 𝑝, 𝑎) ∧ 𝑌 = CReq𝑀,Θ,Γ (𝑠) ∧ Relevant𝑀,Θ,Γ (𝑝, 𝑎) ∧ authorization ∈ Class𝑀,Θ,Γ (𝑝, 𝑎, 𝑞) ∧ EA𝑀,Θ,Γ (𝑌 , 𝑎)). Exact-set equality prevents monotonicity from producing false positives: an authorization controller contained in a larger coalition is not self-sufficient when an outside final restriction remains indispensable. Approval-execution compression is distinct and requires an approval certificate supporting the same witness, containing its requirements, and leaving no outside final restriction.

6.4 Boundary dependency and capture 6.4.1 Upstream-satisfied boundary An upstream-satisfied boundary is present exactly when CanSatisfy𝑀,Θ,Γ (𝑈 , 𝐵, 𝑎) holds. The predicate supplies a complete acceptance or non-refusal certificate 𝑠 for 𝐵 with CReq𝑀,Θ,Γ (𝑠) ⊆ 𝑈 . The trigger concerns complete favorable support, not evaluator location or mutability, and is distinct from alteration, disablement, and bypass. A mutable veto instead requires CanWeakeningAlter(𝑈 , 𝐵, 𝑣, 𝑎): a selected reconfiguration that creates a witness, removes traversal or coverage, enables acceptance, or reduces independent requirements. Disablement further requires neutralizing the restriction while a feasible realization remains.

27

6.5 Alternative realization and administrative collapse 6.5.1 Bypassable final boundary and veto The structural boundary-level trigger is BypassableFinalBoundary𝑀,Θ,Γ (𝐵, 𝑎) ⟺ ClaimedFinalFor𝑀,Θ (𝐵, 𝑎) ∧ HasFeasibleWitness𝑀,Θ,Γ (𝑎) ∧ ¬ GlobalNoBypass𝑀,Θ,Γ (𝐵, 𝑎). Where the design claims a separate veto, BypassableVeto𝑀,Θ,Γ (𝑣, 𝐵, 𝑎) ⟺ BypassableFinalBoundary𝑀,Θ,Γ (𝐵, 𝑎) ∧ VetoAt𝑀,Θ,Γ (𝑣, 𝐵, 𝑎). The coalition-relative diagnostic remains CanBypass𝑀,Θ,Γ (𝑈 , 𝐵, 𝑎). The avoiding witness may use debug, maintenance, recovery, replacement, or an alternative command route; no primitive bypass power is inferred, and refusal proves only failure of the refused path. Reconfiguration–execution coupling places a selected reconfiguration controller in an inclusionminimal requirement set. Administrative override collapse is stronger: an admitted reconfiguration witness has requirement {𝑑}. Titles alone establish neither result.

6.6 Epistemic concentration A self-attesting executor is an execution coalition with complete selected support for producing or attesting its own modeled account. It says nothing by itself about preservation, suppression, or official designation. Evidence-control collapse is the stronger E1 failure: ExecutionCoalition𝑀,Θ,Γ (𝑋, 𝑎) ∧ CanRedefineEvidence𝑀,Θ,Γ (𝑋, 𝑎, 𝐵, 𝑣). At system level,

EvidenceControlCollapse𝑀,Θ,Γ (𝑎, 𝐵, 𝑣) ⟺ ∃𝑋 (ExecutionCoalition𝑀,Θ,Γ (𝑋, 𝑎) ∧ CanRedefineEvidence𝑀,Θ,Γ (𝑋, 𝑎, 𝐵, 𝑣)). The trigger requires contrary account possibilities, complete suppression without indispensable outside preservation, and exclusive official designation without an outside decision. It is not merely “execution plus evidence authority.” This paper identifies controllers of five evidence functions but does not define validity, completeness, relation correctness, consistency, verifier behavior, or conformance [W3C Provenance Working Group, 2013, Schneier and Kelsey, 1999, Kelsey et al., 2010, Birkholz et al., 2023].

28

6.7 Interaction and design implications Patterns may interact without entailing one another; the supplement gives the full matrix. Review should derive witnesses, Req(𝑤), and ℳ𝐸𝐴 before assigning labels, then test each claimed-final boundary for traversal, veto coverage, alteration, satisfaction, disablement, and bypass. Causal and epistemic remedies remain separate. Hardware separation, thresholds, approval, cryptography, and isolation matter through the independent contributions they add [Saltzer and Schroeder, 1975, Clark and Wilson, 1987, Shamir, 1979, National Institute of Standards and Technology, 2019, OASIS Open, 2023, UK Health and Safety Executive, n.d., Regenscheid, 2018].

6.8 Scope and limitations The inventory is non-exhaustive and conditional on 𝑀 , Θ, Γ, 𝑎, the domain partition, and modeled support. Presence establishes capability or dependency, not exploitation; absence proves neither completeness nor security. Concentration may also be a proportionate availability choice. The framework makes it visible rather than declaring every concentrated architecture defective.

7. Independence Conditions Physical separation does not establish authority independence when an upstream domain controls policy, updates, recovery, credentials, or accepted inputs; nor does current upstream insufficiency show that the boundary causes that insufficiency. This section therefore tests whether a designated upstream coalition can alter, satisfy, disable, or avoid a claimed-final restriction. It separately tests whether an execution coalition can suppress contrary accounts and exclusively designate its preferred account.

7.1 Independence is relative to an upstream coalition and protected action Fix (𝑀 , Θ, Γ, 𝑎, 𝐵, 𝑈 ) and, for a veto claim, 𝑣. Independence is relative to this tuple. Upstream is analytical: 𝑈 is the coalition whose unilateral control is tested, including maintenance or update domains absent from the normal route. The capability claim covers every reconfiguration, recovery, override, disablement, and alternative invocation admitted by Θ. A control certificate 𝑠 applies the Section 5 support discipline to an intermediate effect such as alteration, acceptance, or disablement. It is finite, grounded, well-founded, and support-selected, but does not conclude 𝜏𝑎 . For a control certificate, let CReq𝑀,Θ,Γ (𝑠) ⊆ 𝒟 be its required-domain set, constructed like Req(𝑤): project selected components through 𝛿, powers and resources through 𝜅, retain selected alternatives or thresholds, collapse same-domain contributions, exclude only non-discretionary Γ-facts, and include every reconfiguration step. Thus, CReq𝑀,Θ,Γ (𝑠) ⊆ 𝑈 means that 𝑈 can realize the intermediate effect without an indispensable outside-domain decision.

29

Where a veto is claimed, its type and scope must be linked to the restrictive contribution supplied through the boundary. The predicate BoundaryVetoContribution𝑀,Θ,Γ (𝑣, 𝐵, 𝑎, 𝑞) holds when 𝑣 is a veto over the 𝐵-governed substructure 𝑞 and its selected exercise supplies that boundary’s restrictive outcome. External cancellation or an unrelated kill switch is insufficient. The typed veto claim is

VetoAt𝑀,Θ,Γ (𝑣, 𝐵, 𝑎) ⟺ CandidateFor𝑀,Θ (𝐵, 𝑎) ∧ ∃𝑞 ∈ Sub(ℋ𝐶 ) BoundaryVetoContribution𝑀,Θ,Γ (𝑣, 𝐵, 𝑎, 𝑞). InvalidatesThrough(𝑣, 𝐵, 𝑤; 𝑞) means that exercising 𝑣, with other facts fixed, invalidates supp(𝑤) through 𝐵’s contribution rather than another control surface. Then CoversAt𝑀,Θ,Γ (𝑣, 𝐵, 𝑤, 𝑎) ⟺ FeasibleWitness𝑀,Θ,Γ (𝑤, 𝑎) ∧ ∃𝑞 (BoundaryVetoContribution𝑀,Θ,Γ (𝑣, 𝐵, 𝑎, 𝑞) ∧ 𝑞 ⊆ supp(𝑤) ∧ InvalidatesThrough𝑀,Θ,Γ (𝑣, 𝐵, 𝑤; 𝑞)). The non-vacuous global predicate is GlobalVetoCoverageAt𝑀,Θ,Γ ⟺ VetoAt𝑀,Θ,Γ (𝑣, 𝐵, 𝑎) (𝑣, 𝐵, 𝑎) ∧ HasFeasibleWitness𝑀,Θ,Γ (𝑎) ∧ ∀𝑤 (FeasibleWitness𝑀,Θ,Γ (𝑤, 𝑎) ⇒ CoversAt𝑀,Θ,Γ (𝑣, 𝐵, 𝑤, 𝑎)).

7.2 Upstream insufficiency, boundary independence, and global finality Three claims must be separated. Upstream insufficiency is: UpstreamInsufficient𝑀,Θ,Γ (𝑈 , 𝑎) ⟺ 𝑈 ⊆ 𝒟 ∧ ¬EA𝑀,Θ,Γ (𝑈 , 𝑎). It neither localizes the missing contribution nor identifies who controls 𝐵. Boundary independence from 𝑈 means that 𝑈 cannot alter, satisfy, disable, or avoid the restrictive contribution. Global final-boundary independence additionally requires non-bypassability and, for a veto claim, coverage of every feasible witness. These claims are not equivalent: insufficiency may arise elsewhere, relative independence does not exclude another coalition’s bypass, and structural coverage does not prevent upstream alteration or satisfaction. Table 7.1 summarizes causal conditions I1–I4 and separate epistemic condition E1. Table 7.1. Causal independence conditions I1–I4 and the separate evidentiary condition E1. 30

Condition

Required result

Question answered

I1 — No unilateral alteration

¬ CanAlter(𝑈 , 𝐵, 𝑣, 𝑎)

I2 — No unilateral satisfaction

¬ CanSatisfy(𝑈 , 𝐵, 𝑎)

I3 — No unilateral disablement

¬ CanDisable(𝑈 , 𝐵, 𝑣, 𝑎)

I4 — Global no-bypass condition

GlobalNoBypass(𝐵, 𝑎)

Can 𝑈 change security-relevant decision semantics? Can 𝑈 alone supply complete support for acceptance or non-refusal? Can 𝑈 neutralize the restriction while leaving 𝜏𝑎 realizable? Does every member of a nonempty feasible-witness set traverse 𝐵?

E1 — No unilateral evidence redefinition

EvidentiaryIndependentFrom (𝑎, 𝐵, 𝑣 ∣ 𝑋)

Can an admissible execution coalition suppress contrary accounts and exclusively designate its preferred account?

Structural traversal may remain true after neutralization if a composite still passes through 𝐵. Boundary-bound veto coverage fails when such a composite neutralizes the veto. Neither property establishes I1 or I2; I3 remains explicit to identify disablement and cover boundary-only designs.

7.3 I1 — No unilateral alteration Alteration concerns restrictive semantics, not every administrative change. Use 𝑣 = ⊥ for a restrictive boundary without a separately modeled veto. Let Reconfigures𝑀,Θ,Γ (𝑠, 𝑀 ′ ) mean that 𝑠 is a support-selected control certificate for a finite reconfiguration sequence admitted from 𝑀 to successor configuration 𝑀 ′ . Define SecurityRelevantAlter(𝑀 , 𝑀 ′ ; 𝐵, 𝑣, 𝑎) hold when a change to a decision mechanism affects at least one of: • which causal realization witnesses for 𝜏𝑎 are feasible; • whether a feasible witness traverses 𝐵; • whether 𝑣 covers a feasible witness through 𝐵’s restrictive contribution; or • whether a mediated attempt can obtain acceptance or non-refusal, or the independent-domain requirements of a relevant witness or control certificate change. The unilateral-alteration diagnostic is CanAlter𝑀,Θ,Γ (𝑈 , 𝐵, 𝑣, 𝑎) ⟺ ∃𝑠, 𝑀 ′ (Reconfigures𝑀,Θ,Γ (𝑠, 𝑀 ′ ) ∧ CReq𝑀,Θ,Γ (𝑠) ⊆ 𝑈 ∧ SecurityRelevantAlter(𝑀 , 𝑀 ′ ; 𝐵, 𝑣, 𝑎)).

31

I1 is ¬ CanAlter. The certificate includes every contribution needed for 𝑀 ′ ; irrelevant administrative changes do not count, while rule, code, trust-key, or threshold changes may count even if all witnesses still traverse 𝐵. All reconfiguration powers admitted by Θ, including recovery and update roots, are considered. Because CanAlter includes strengthening changes, dangerous weakening uses CanWeakeningAlter𝑀,Θ,Γ (𝑈 , 𝐵, 𝑣, 𝑎) ⟺ ∃𝑠, 𝑀 ′ (Reconfigures𝑀,Θ,Γ (𝑠, 𝑀 ′ ) ∧ CReq𝑀,Θ,Γ (𝑠) ⊆ 𝑈 ∧ SecurityRelevantAlter(𝑀 , 𝑀 ′ ; 𝐵, 𝑣, 𝑎) ∧ WeakensFor(𝑀 , 𝑀 ′ ; 𝐵, 𝑣, 𝑎)), where WeakensFor requires at least one directional effect: creation of a new feasible witness, loss of boundary traversal, loss of CoversAt coverage, newly obtainable acceptance or non-refusal, or reduction of the independent-domain requirements of a relevant support. Accordingly, CanWeakeningAlter(𝑈 , 𝐵, 𝑣, 𝑎) ⇒ CanAlter(𝑈 , 𝐵, 𝑣, 𝑎). I1 is a control-independence condition, not a test of EA(𝑈 , 𝑎) or adverse effect. Directional risk claims use CanWeakeningAlter; CanAlter records control in either direction.

7.4 I2 — No unilateral satisfaction I2 asks who controls complete support for acceptance or non-refusal, because an immutable boundary may accept only upstream-manufactured facts. Let AcceptanceCertificate𝑀,Θ,Γ (𝑠, 𝐵, 𝑎) hold when 𝑠 is a complete support-selected certificate for a 𝐵-supplied acceptance or non-refusal relevant to at least one feasible witness for 𝑎. It retains every selected credential, approval, signature, context, local condition, resource, threshold participant, and decision contribution. The satisfaction diagnostic is CanSatisfy𝑀,Θ,Γ (𝑈 , 𝐵, 𝑎) ⟺ ∃𝑠 (AcceptanceCertificate𝑀,Θ,Γ (𝑠, 𝐵, 𝑎) ∧ CReq𝑀,Θ,Γ (𝑠) ⊆ 𝑈 ). I2 is ¬ CanSatisfy. Mechanical evaluation creates no independent contribution when 𝑈 controls every selected input; a local key, sensor state, approval, or discretionary decision adds its controller to CReq(𝑠). This is causal sufficiency, not input quality, and no discretionary outside choice may be hidden in Γ. I1 and I2 may overlap, but an immutable rule can fail I2 and an initially sound rule can fail I1.

32

7.5 I3 — No unilateral disablement Disablement removes, neutralizes, replaces, suspends, or forces non-exercise of the restriction while 𝜏𝑎 remains realizable. Let DisablementCertificate𝑀,Θ,Γ (𝑠, 𝑀 ′ , 𝐵, 𝑣, 𝑤) hold when admitted certificate 𝑠 transforms 𝑀 to a type-compatible 𝑀 ′ and neutralizes 𝐵 or 𝑣 relative to witness 𝑤. The disablement diagnostic is CanDisable𝑀,Θ,Γ (𝑈 , 𝐵, 𝑣, 𝑎) ⟺ ∃𝑠, 𝑀 ′ , 𝑤 (DisablementCertificate𝑀,Θ,Γ (𝑠, 𝑀 ′ , 𝐵, 𝑣, 𝑤) ∧ CReq𝑀,Θ,Γ (𝑠) ⊆ 𝑈 ∧ FeasibleWitness𝑀 ′ ,Θ,Γ (𝑤, 𝑎) ∧ FeasibleWitness𝑀,Θ,Γ (𝑠 ∘ 𝑤, 𝑎)). For the composite witness, Req𝑀,Θ,Γ (𝑠 ∘ 𝑤) = CReq𝑀,Θ,Γ (𝑠) ∪ Req𝑀 ′ ,Θ,Γ (𝑤), after domain collapse and exclusion of non-discretionary Γ-facts. I3 is ¬ CanDisable. Requiring a feasible composite distinguishes disablement from denial of service. A distinct avoiding witness establishes bypass but not disablement unless it neutralizes 𝐵’s restriction. Conversely, disablement may still traverse the component, so I3 can fail while GlobalNoBypass remains true. For 𝑣 ≠ ⊥, neutralization entails ¬ CoversAt𝑀,Θ,Γ (𝑣, 𝐵, 𝑠 ∘ 𝑤, 𝑎), so the same composite refutes GlobalVetoCoverageAt(𝑣, 𝐵, 𝑎).

7.6 Relative and global bypass resistance The 𝑈 -relative diagnostic is CanBypass𝑀,Θ,Γ (𝑈 , 𝐵, 𝑎) ⟺ ∃𝑤 (FeasibleWitness𝑀,Θ,Γ (𝑤, 𝑎) ∧ Req𝑀,Θ,Γ (𝑤) ⊆ 𝑈 ∧ ¬ Traverses(𝑤, 𝐵)). This asks whether 𝑈 can realize a witness avoiding 𝐵. Define RelativeBypassResistance𝑀,Θ,Γ (𝐵, 𝑎 ∣ 𝑈 ) ⟺ ¬ CanBypass𝑀,Θ,Γ (𝑈 , 𝐵, 𝑎). I4 is the stronger global condition: 33

GlobalNoBypass𝑀,Θ,Γ (𝐵, 𝑎) ⟺ NonBypassable𝑀,Θ,Γ (𝐵, 𝑎). I4 requires a claimed-final 𝐵, nonempty feasible-witness set, and traversal by every admitted witness, including reconfiguration-enabled ones. Relative resistance covers only 𝑈 . Global no-bypass is structural and establishes neither immutability, independent inputs, nor resistance to disablement.

7.7 Composite causal-independence condition The 𝑈 -relative control claim can be stated first:

BoundaryIndependentFrom𝑀,Θ,Γ (𝐵, 𝑣, 𝑎 ∣ 𝑈 ) ⟺ 𝑈 ⊆ 𝒟 ∧ VetoAt𝑀,Θ,Γ (𝑣, 𝐵, 𝑎) ∧ ¬ CanAlter𝑀,Θ,Γ (𝑈 , 𝐵, 𝑣, 𝑎) ∧ ¬ CanSatisfy𝑀,Θ,Γ (𝑈 , 𝐵, 𝑎) ∧ ¬ CanDisable𝑀,Θ,Γ (𝑈 , 𝐵, 𝑣, 𝑎) ∧ RelativeBypassResistance𝑀,Θ,Γ (𝐵, 𝑎 ∣ 𝑈 ). This is a 𝑈 -relative control claim; it does not exclude another coalition’s bypass or establish global veto coverage. For a claimed-final boundary with a veto claim, define global causal independence from 𝑈 as CausallyIndependentFrom𝑀,Θ,Γ (𝐵, 𝑣, 𝑎 ∣ 𝑈 ) ⟺ 𝑈 ⊆𝒟 ∧ ClaimedFinalFor𝑀,Θ (𝐵, 𝑎) ∧ VetoAt𝑀,Θ,Γ (𝑣, 𝐵, 𝑎) ∧ HasFeasibleWitness𝑀,Θ,Γ (𝑎) ∧ GlobalNoBypass𝑀,Θ,Γ (𝐵, 𝑎) ∧ GlobalVetoCoverageAt𝑀,Θ,Γ (𝑣, 𝐵, 𝑎) ∧ ¬ CanAlter𝑀,Θ,Γ (𝑈 , 𝐵, 𝑣, 𝑎) ∧ ¬ CanSatisfy𝑀,Θ,Γ (𝑈 , 𝐵, 𝑎) ∧ ¬ CanDisable𝑀,Θ,Γ (𝑈 , 𝐵, 𝑣, 𝑎). The first two coverage predicates are structural; the negated capabilities establish control independence from 𝑈 . I3 remains explicit as a diagnostic even though boundary-bound global veto coverage excludes the same disablement composite. Global no-bypass already implies relative bypass resistance. For a claimed-final execution boundary with no separately modeled veto, define

34

CausallyIndependentBoundaryFrom𝑀,Θ,Γ (𝐵, 𝑎 ∣ 𝑈 ) ⟺ 𝑈 ⊆𝒟 ∧ ClaimedFinalFor𝑀,Θ (𝐵, 𝑎) ∧ HasFeasibleWitness𝑀,Θ,Γ (𝑎) ∧ GlobalNoBypass𝑀,Θ,Γ (𝐵, 𝑎) ∧ ¬ CanAlter𝑀,Θ,Γ (𝑈 , 𝐵, ⊥, 𝑎) ∧ ¬ CanSatisfy𝑀,Θ,Γ (𝑈 , 𝐵, 𝑎) ∧ ¬ CanDisable𝑀,Θ,Γ (𝑈 , 𝐵, ⊥, 𝑎). The boundary-only form does not substitute for a claimed independent veto, which must satisfy boundary-bound coverage. Current absence of a command or credential is insufficient because all admitted reconfiguration powers remain in scope.

7.8 Relationship to execution authority Independence refines rather than replaces execution-authority analysis. Define RequiresOutsideRestriction𝑀,Θ,Γ (𝑤, 𝐵, 𝑣, 𝑎 ∣ 𝑈 ) ⟺ FeasibleWitness𝑀,Θ,Γ (𝑤, 𝑎) ∧ CoversAt𝑀,Θ,Γ (𝑣, 𝐵, 𝑤, 𝑎) ∧ ∃𝑠 (AcceptanceCertificate𝑀,Θ,Γ (𝑠, 𝐵, 𝑎) ∧ SelectedWithin(𝑠, supp(𝑤)) ∧ CReq𝑀,Θ,Γ (𝑠) ⊈ 𝑈 ). SelectedWithin entails CReq(𝑠) ⊆ Req(𝑤). The following propositions state methodological implications and non-implications, not a standalone theorem family. Proposition 7.1 (independent-final-veto implication). Suppose CausallyIndependentFrom(𝐵, 𝑣, 𝑎 ∣ 𝑈 ) holds and ∀𝑤 (FeasibleWitness𝑀,Θ,Γ (𝑤, 𝑎) ⇒ RequiresOutsideRestriction𝑀,Θ,Γ (𝑤, 𝐵, 𝑣, 𝑎 ∣ 𝑈 )). Then ¬EA𝑀,Θ,Γ (𝑈 , 𝑎). Justification. If EA(𝑈 , 𝑎) held, some feasible 𝑤 would satisfy Req(𝑤) ⊆ 𝑈 . The selected acceptance certificate would then satisfy CReq(𝑠) ⊆ Req(𝑤) ⊆ 𝑈 , contradicting RequiresOutsideRestriction. Proposition 7.2 (non-converse). ¬EA(𝑈 , 𝑎) does not establish boundary independence from 𝑈 . Justification. 𝑈 may lack an unrelated command, target resource, or contribution elsewhere in every current witness while retaining unilateral authority to alter 𝐵’s rule, control every accepted 35

input, or disable its restrictive behavior. Upstream insufficiency reports the absence of a complete witness requirement set inside 𝑈 ; it does not localize the missing contribution. Proposition 7.3 (limits of structural coverage). GlobalNoBypass(𝐵, 𝑎) alone establishes none of I1–I3. GlobalVetoCoverageAt(𝑣, 𝐵, 𝑎) alone does not establish I1, I2, or I4. Their conjunction does not establish I1 or I2, but under reconfiguration-complete witness semantics it excludes CanDisable(𝑈 , 𝐵, 𝑣, 𝑎) for the same veto-bearing claim. Justification. Every witness may traverse 𝐵 while 𝑈 can change the boundary rule, manufacture complete support for acceptance, or neutralize the veto without avoiding the boundary. Alteration and satisfaction do not by themselves negate traversal or coverage. Disablement differs: its feasible composite is included in the initial-model witness inventory and, for a separately modeled veto, is not covered through the neutralized contribution. Global veto coverage therefore fails for that composite. Proposition 7.4 (relative bypass implication). If CanBypass(𝑈 , 𝐵, 𝑎) holds, then EA(𝑈 , 𝑎) holds and GlobalNoBypass(𝐵, 𝑎) is false. Justification. The diagnostic supplies a feasible witness with Req(𝑤) ⊆ 𝑈 and ¬ Traverses(𝑤, 𝐵), which satisfies the definition of EA and contradicts the universal traversal condition. Physical separation supplies none of these implications when one domain controls update, recovery, keys, accepted facts, policy, or administration [Anderson, 1972, Saltzer and Schroeder, 1975, National Institute of Standards and Technology, 2019, OASIS Open, 2023, UK Health and Safety Executive, n.d., Regenscheid, 2018].

7.9 Evidentiary independence Evidentiary independence concerns the authoritative account, not whether 𝑈 defeats a causal restriction. To avoid treating every monotone superset as relevant, define admissible execution coalitions by ExecutionCoalition𝑀,Θ,Γ (𝑋, 𝑎) ⟺ EA𝑀,Θ,Γ (𝑋, 𝑎) ∧ (𝑋 ∈ ℳ𝐸𝐴 (𝑀 , Θ, Γ, 𝑎) ∨ DesignatedOperationalCoalition𝑀,Θ,Γ (𝑋, 𝑎)). The second alternative requires explicit operational designation. The five controller projections are: 𝜂produce , 𝜂attest , 𝜂preserve , 𝜂suppress , 𝜂official . Let ℰ− 𝑋,𝑎,𝐵,𝑣 denote modeled contrary or refusal accounts and production possibilities, without asserting their validity, completeness, or correctness. Define HasContraryAccountPotential𝑀,Θ,Γ (𝑋, 𝑎, 𝐵, 𝑣) ⟺ ℰ− 𝑋,𝑎,𝐵,𝑣 ≠ ∅. CanSuppressContrary requires 𝑋 to prevent every modeled contrary account from remaining available without indispensable outside preservation. CanExclusivelyDesignate requires no indispensable outside official-designation decision. Γ records environmental assumptions affecting availability or preservation. 36

The evidence-redefinition diagnostic is

CanRedefineEvidence𝑀,Θ,Γ (𝑋, 𝑎, 𝐵, 𝑣) ⟺ HasContraryAccountPotential𝑀,Θ,Γ (𝑋, 𝑎, 𝐵, 𝑣) ∧ CanSuppressContrary𝑀,Θ,Γ (𝑋, 𝑎, 𝐵, 𝑣) ∧ CanExclusivelyDesignate𝑀,Θ,Γ (𝑋, 𝑎). The relative property is

EvidentiaryIndependentFrom𝑀,Θ,Γ (𝑎, 𝐵, 𝑣 ∣ 𝑋) ⟺ ExecutionCoalition𝑀,Θ,Γ (𝑋, 𝑎) ∧ ¬ CanRedefineEvidence𝑀,Θ,Γ (𝑋, 𝑎, 𝐵, 𝑣). At system level,

EvidenceControlCollapse𝑀,Θ,Γ (𝑎, 𝐵, 𝑣) ⟺ ∃𝑋 (ExecutionCoalition𝑀,Θ,Γ (𝑋, 𝑎) ∧ CanRedefineEvidence𝑀,Θ,Γ (𝑋, 𝑎, 𝐵, 𝑣)), and

SystemEvidentiaryIndependent𝑀,Θ,Γ (𝑎, 𝐵, 𝑣) ⟺ ¬ EvidenceControlCollapse𝑀,Θ,Γ (𝑎, 𝐵, 𝑣). Production or self-attestation alone does not violate E1; collapse requires non-vacuous contraryaccount suppression plus exclusive official designation. Evidentiary independence supports accountability but is not a causal precondition for veto independence. This paper identifies controllers of the five evidence powers, not record structure, relation validity, outcome consistency, trace completeness, verifier correctness, or conformance [W3C Provenance Working Group, 2013, Schneier and Kelsey, 1999, Kelsey et al., 2010, Birkholz et al., 2023].

7.10 Worked application The Section 5 signing model has two feasible witnesses: Req(𝑤med ) = {𝐷𝐶 , 𝐷𝐵 },

¬ Traverses(𝑤upd , 𝐵∗ ).

Req(𝑤upd ) = {𝐷𝐴 }, ¬ GlobalNoBypass(𝐵∗ , 𝑎),

Traverses(𝑤med , 𝐵∗ ),

¬ GlobalVetoCoverageAt (𝑣𝑏 , 𝐵∗ , 𝑎).

For 𝑈 = {𝐷𝐴 }, both CanBypass and EA hold. For 𝑈 = {𝐷𝐶 }, upstream insufficiency holds, yet global independence fails because another coalition has 𝑤upd . Table 7.2. Controlled independence variants for the signing-appliance example.

37

Variant

Controlled change

Formal result

Independence conclusion

CanBypass

Section 5 baseline

I1 variant

I2 variant

𝐷𝐴 installs maintenance firmware and invokes 𝑐𝑥𝑚 ; 𝑤upd avoids 𝐵∗ . Remove the maintenance witness, but give 𝐷𝐶 a support-selected update certificate that rewrites 𝐵∗ ’s acceptance rule. Every feasible witness in the variant still traverses 𝐵∗ . Keep 𝐵∗ immutable, but make its acceptance depend only on credentials, approvals, and contextual inputs controlled by 𝐷𝐶 .

({𝐷𝐴 }, 𝐵∗ , 𝑎); ¬ GlobalNoBypass (𝐵∗ , 𝑎); ¬ GlobalVetoCoverageAt (𝑣𝑏 , 𝐵∗ , 𝑎). CanAlter ({𝐷𝐶 }, 𝐵∗ , 𝑣𝑏 , 𝑎).

An acceptance certificate 𝑠 has CReq(𝑠) ⊆ {𝐷𝐶 }, so CanSatisfy({𝐷𝐶 }, 𝐵∗ , 𝑎).

I4 and global structural coverage fail. Structural traversal does not prevent an I1 failure.

The separate boundary component supplies no independently controlled acceptance condition.

CanDisable I3 variant

E1 variant

Give 𝐷𝐶 a control certificate 𝑠 that forces non-refusal at 𝐵∗ while the mediated signing witness 𝑤 remains feasible; include 𝑠 ∘ 𝑤 in the initial-model inventory. Model at least one refusal-account production possibility, then give the execution-controlling 𝐷𝐴 domain power to suppress every such account and exclusively designate its preferred signing account as official.

({𝐷𝐶 }, 𝐵∗ , 𝑣𝑏 , 𝑎); ¬ GlobalVetoCoverageAt (𝑣𝑏 , 𝐵∗ , 𝑎).

CanRedefineEvidence ({𝐷𝐴 }, 𝑎, 𝐵∗ , 𝑣𝑏 ).

I3 and global veto coverage fail even if 𝑠 ∘ 𝑤 still traverses 𝐵∗ , so I4 may remain true.

E1 and system evidentiary independence fail; this is separate from the causal claim.

The variants separate mutable semantics (I1), upstream-controlled inputs (I2), retained realizability after neutralization (I3), alternative witnesses (I4), and authoritative-account control (E1).

7.11 Scope and limitations All results are conditional on (𝑀 , Θ, Γ, 𝑎, 𝐵, 𝑣, 𝑈 ), the trust-domain partition, and supplied witness and certificate inventories. They prove neither non-collusion, common-mode independence, partition correctness, implementation correctness, nor completeness; hidden update, recovery, physical,

38

or override powers can change the result. Causal predicates do not establish policy merit or factual justification, and E1 does not establish evidence validity, completeness, verifier behavior, or conformance. Missing mediation evidence is not bypass proof. The framework also does not require every system to implement an independent veto; it makes the chosen allocation and any claimed independence explicit.

8. Multi-Domain Analytical Case Studies The framework is intended to distinguish authority configurations, not merely to rename familiar workflow roles. This section therefore compares analytical archetypes from AI-agent finance, enterprise payment release, IoT control, HSM signing, and CI/CD deployment. The cases are controlled demonstrations, not an empirical survey or evidence that every implementation in a named domain has the modeled topology. Every conclusion is conditional on the stated 𝑀 , Θ, Γ, trust-domain assignments, and feasible-witness inventory [Ross et al., 2022]. The purpose of using several domains is discriminative. Each comparison holds visible features constant while changing an authority-relevant fact: common versus independent control; shared versus independent credential recovery; exclusion versus admission of a reconfiguration power; an upstream-supplied versus locally controlled favorable condition; or separated versus collapsed evidence control. The full case derivations and matrices remain in the technical supplement.

8.1 Analytical Evaluation Methodology Each case selects one concrete protected-action instance 𝑎 ∈ 𝒜𝑃 (Θ) and its transition 𝜏𝑎 , fixes 𝑀 , Θ, Γ, normalizes components and powers to trust domains, enumerates ordinary and admitted reconfiguration-enabled witnesses, derives Req(𝑤) and ℳ𝐸𝐴 , and then evaluates boundary, I1– I4, pattern, and evidence-control predicates. The evaluation uses controlled analytical contrasts: one authority-relevant variable changes while the stated workflow shape or causal support is held constant. The expected result is specified before interpreting the variant, so the exercise tests whether the framework distinguishes the intended authority change rather than merely restating a domain label. Table 8.1. Controlled analytical evaluation design.

Case AI-agent finance

Protected action Post one specified transfer to the designated ledger.

Held constant Four causal components and ordinary witness shape.

39

Changed variable

Expected discriminative result

Limitation of a simpler role/component view

Shared control versus independent boundary administration and lifecycle roots.

Req changes from one domain to two; the selfauthorization trigger disappears.

Counting components does not reveal that their controllers collapse into one domain.

Case

Protected action

Changed variable

Held constant

Enterprise payment release

Commit one specified payment release.

Two-of-three approval threshold and deterministic evaluator.

IoT control

Commit one specified device command.

Nominal interlock and ordinary mediated witness.

HSM signing

Produce one specified signature with the selected key.

CI/CD deployment

Commit one specified production deployment.

Expected discriminative result

Shared credential recovery versus independent approver custody plus an outside release domain. Excluded update, admitted diagnostic witness, or forced non-refusal.

One-domain support becomes pair-specific multi-domain coalitions.

HSM components, signer, and minimal execution coalition.

Client-supplied acceptance inputs versus an indispensable HSM-domain local condition.

I2 changes while ℳ𝐸𝐴 remains fixed.

Causal witnesses, requirement sets, and execution coalitions.

Independent versus collapsed preservation, suppression, and official designation.

E1 changes while causal execution authority does not.

Boundary coverage, bypass, and disablement separate into different results.

Limitation of a simpler role/component view Counting approvers treats nominal principals as independent despite common recovery. A component diagram shows the same interlock in all variants and hides lifecycleenabled support. Hardware placement alone cannot identify who controls complete favorable support. A generic “audited pipeline” label does not allocate the distinct evidence powers.

These are model-level demonstrations, not observations of events in deployed systems and not empirical validation. Their evidence analysis allocates production, attestation, preservation, suppression, and official designation; it does not assess validity, completeness, consistency, verification, or conformance. Uniform retrospective counts of components, powers, candidate witnesses, reconfiguration composites, and analyst time were not recorded during the original case construction and are therefore unavailable; no workload or scalability metric is inferred. The supplement exposes the complete case ledgers and final coalition sets, but those ledgers are not presented as a substitute for contemporaneous analyst-effort measurements.

8.2 Positive and negative control: AI-agent transaction Let 𝑎𝐴 be the instruction to transfer a specified amount from account 𝛼 to beneficiary 𝛽, and let 𝜏𝑎𝐴 be posting that transfer to the designated ledger. Proposal, authorization, command construction, and API delivery are prerequisites rather than the transition itself. The shared-control 40

configuration 𝑀𝐴𝑆 and independent-boundary configuration 𝑀𝐴𝐼 hold functional component count and ordinary witness shape constant. In 𝑀𝐴𝑆 , the agent, policy service, API boundary, ledger interface, credentials, and their relevant update or recovery roots project to 𝐷𝐴 . In 𝑀𝐴𝐼 , the agentside functions project to 𝐷𝐴 , while the final boundary, transition performer, acceptance rule, and lifecycle roots project to 𝐷𝐵 . In the shared-control variant, all selected discretionary contributions project to one domain: Req𝑀 𝑆 (𝑤𝐴 ) = {𝐷𝐴 }, 𝐴

ℳ𝐸𝐴 (𝑀𝐴𝑆 , Θ𝐴 , Γ𝐴 , 𝑎𝐴 ) = {{𝐷𝐴 }}.

The authorization certificate also has CReq(𝑠𝐴 ) = {𝐷𝐴 }. The exact authorization-controller set therefore satisfies execution authority, so the self-authorizing-executor predicate holds. This is the negative control: the result follows from the complete witness and shared domain assignment, not merely from API invocation. In the independent-boundary variant, Req𝑀 𝐼 (𝑤𝐴 ) = {𝐷𝐴 , 𝐷𝐵 }, 𝐴

ℳ𝐸𝐴 (𝑀𝐴𝐼 , Θ𝐴 , Γ𝐴 , 𝑎𝐴 ) = {{𝐷𝐴 , 𝐷𝐵 }}.

Because ¬EA𝑀𝐴𝐼 ({𝐷𝐴 }, 𝑎𝐴 ), the exact self-authorization trigger is false. 𝐷𝐴 can propose, authorize, assemble credentials, and initiate an attempt but cannot cause the posting without 𝐷𝐵 ; 𝐷𝐵 performs the low-level transition but lacks the selected request support. Under the stated complete inventory, no upstream-controlled alteration, satisfaction, disablement, or alternative witness is admitted, and the outside-domain decision remains indispensable. Thus CausallyIndependentFrom𝑀 𝐼 ,Θ ,Γ (𝐵𝐴 , 𝑣𝐴 , 𝑎𝐴 ∣ {𝐷𝐴 }) . 𝐴

𝐴

𝐴

An independently controlled evidence domain preserves favorable and refusal accounts and controls official designation, so neither admissible execution coalition can suppress every contrary account and exclusively designate its preferred account. The modeled E1 result is SystemEvidentiaryIndependent𝑀 𝐼 ,Θ ,Γ (𝑎𝐴 , 𝐵𝐴 , 𝑣𝐴 ). 𝐴

𝐴

𝐴

This is the clearest positive control, not a certificate of complete system security or a claim that the evidence domain is internally distributed or incapable of misconduct [Agent Payments Protocol maintainers, 2026, Hardt, 2012, PCI Security Standards Council, 2024].

8.3 Additional controlled comparisons The enterprise case holds a two-of-three approval rule constant while changing credential recovery and domain assignment. Shared recovery projects the selected threshold support to one identity domain; independent approver control plus a separate release contribution produces pair-specific 41

multi-domain coalitions. The difference is not threshold arithmetic but common-control projection. The complete derivation is retained in the supplement. The IoT case holds the nominal interlock constant while changing the admitted reconfiguration powers. Excluding diagnostic firmware preserves modeled boundary coverage; admitting a firmwareenabled diagnostic witness adds an avoiding realization without disabling the ordinary interlock; and a separate forced-non-refusal variant disables the restriction while retaining traversal. The comparison demonstrates that bypass and disablement are neither primitive powers nor equivalent outcomes. In the HSM case, the execution witness and minimal coalition {𝐷𝐶 , 𝐷𝐻 } remain fixed. When the HSM accepts entirely on client-supplied credentials and approvals, CanSatisfy({𝐷𝐶 }, 𝐵𝐻 , 𝑎𝐻 ) holds and I2 fails. Adding an indispensable 𝐷𝐻 -controlled favorable condition makes that predicate false and restores I2 without changing the coalition. Hardware placement is therefore not the discriminating fact; selected control of the acceptance certificate is. The CI/CD case holds the causal witnesses and singleton execution coalition {𝐷𝐶 } fixed while reallocating epistemic powers. In the separated variant, an outside domain preserves contrary accounts and another controls official designation. In the collapsed variant, 𝐷𝐶 controls preservation, complete suppression, and official designation, so CanRedefineEvidence({𝐷𝐶 }, 𝑎𝐷 , 𝐵𝐷 , 𝑣𝐷 ) and evidence-control collapse follow. The causal authority result is unchanged. An “audit log” label is not enough; the difference lies in who controls preservation, suppression, and designation [Souppaya et al., 2022, SLSA Community, 2025].

8.4 Cross-case comparison Table 8.2. Cross-case discriminative results under controlled authority changes. Feature held constant

Authority-relevant change

Formal result

AI shared versus independent boundary

Four causal components and ordinary witness shape

Shared versus independent administration, update roots, and boundary decision

Req(𝑤𝐴 ) changes from {𝐷𝐴 } to {𝐷𝐴 , 𝐷𝐵 }; self-authorization disappears

Enterprise shared versus independent approval

Same two-of-three threshold and deterministic evaluator

Shared recovery versus independently controlled approver powers and final release

One-domain support versus pair-specific coalitions requiring the release domain

Controlled contrast

42

Discriminative conclusion Component count does not determine trust-domain multiplicity or execution authority. A principal threshold does not by itself supply domain separation.

Feature held constant

Authority-relevant change

IoT update-excluded, diagnostic, and forced-non-refusal variants

Same nominal interlock 𝐵𝐼

Exclusion, bypass-enabling firmware, or forced non-refusal

HSM client-satisfied versus local condition

Same HSM components, signer, and minimal execution coalition

Addition of an indispensable 𝐷𝐻 -controlled favorable condition

CI/CD separated versus collapsed evidence

Same causal witnesses, Req(𝑤), and ℳ𝐸𝐴

Independent versus execution-coalition control of preservation, suppression, and official designation

Controlled contrast

Formal result Boundary coverage holds in the excluded model; an avoiding witness defeats it in the diagnostic model; forced non-refusal defeats the veto while traversal remains I2 fails or holds while ℳ𝐸𝐴 remains {{𝐷𝐶 , 𝐷𝐻 }}

Self-attestation without E1 collapse versus evidence-control collapse

Discriminative conclusion Boundary analysis must include admitted reconfiguration composites; bypass need not entail disablement.

Coalition sufficiency and boundary-input independence answer different questions. Evidentiary independence is not determined by the causal witness.

The complete cross-case matrix, including all witness sets, boundary predicates, I1–I4 outcomes, and evidence qualifications, appears in the supplement.

8.5 Findings Five bounded findings recur. Component count and principal count are unreliable proxies for trust-domain decomposition. A low-level executor may lack execution authority because it does not control the complete selected support. Structural traversal does not establish resistance to upstream alteration, satisfaction, or disablement. Reconfiguration can add a coalition, add an alternative witness for an existing coalition, or neutralize a restriction without adding an avoiding route. Finally, self-attestation and evidence-control collapse remain distinct: reallocating epistemic powers can change E1 while leaving every causal witness unchanged. These are analytical findings about the modeled archetypes, not empirical validation, prevalence evidence, or proof of implementation correctness. They show that the same predicates discriminate between deliberately controlled variants across several application domains.

8.6 Scope and limitations Every result remains conditional on the selected protected transition, 𝑀 , Θ, Γ, the trust-domain partition, and the modeled witnesses and control certificates. An omitted debug interface, shared administrator, recovery path, firmware key, physical-access power, or common infrastructure dependency may add a witness or collapse a domain distinction. Conversely, an exceptional power is not admitted merely because it is imaginable; its basis and selected support must be stated. Absence of a listed dangerous pattern does not prove system security.

43

The cases are mechanism-neutral. Hardware isolation, threshold approval, multi-signature schemes, separate organizations, independent logs, and software sandboxes may implement useful contributions, but their names do not establish the predicates. What matters is whether an outside-domain contribution is selected, whether every feasible witness traverses the claimed boundary, and who controls alteration, satisfaction, disablement, alternative realization, and evidentiary designation.

9. Havenlon Instantiation This section is a bounded, source-grounded instantiation of the authority-decomposition framework against the documented Havenlon architecture. It is not a product audit, vulnerability disclosure, deployment-security assessment, certification, or validation case for the framework. The analysis asks only what follows when the identified sources are converted into typed components, powers, resources, trust domains, realization witnesses, and evidence-control assignments under the declared model. It does not establish the security of a deployed product or close the deployment witness family. A favorable design statement is not treated as an established property, and separately named hardware is not treated as an independent trust domain without a corresponding control assignment. The principal result is deliberately qualified. In the split-control, release-intended, open-state protocol model, the ordinary source-supported witness has Req(𝑤ord ) = {𝐷𝐿 , 𝐷𝑈 , 𝐷𝑆 , 𝐷𝐴 , 𝐷𝑋 }. Among the protocol witnesses enumerated from the reproducibly identified source snapshot, certificate replacement yields the unique inclusion-minimal known requirement set {𝐷𝐿 , 𝐷𝐴 , 𝐷𝑋 }. Its composed reconfiguration-and-acceptance support establishes I1 and I2 failures relative to 𝐷𝐿 in that sourcebounded model, while 𝐷𝐿 remains insufficient for the complete signing transition. Patent and whitepaper materials document ClaimedFinalFor(𝐵𝐴 , 𝑎HV ), but deployed global non-bypassability and boundary-bound veto coverage are unresolved. Direct-bus, dormant-test, update, manufacturer, recovery, and evidence-administration conclusions remain conditional or unresolved.

9.1 Source base and claim discipline The source base separates repository implementation behavior, implementation-review requirements, product requirements, patents or whitepapers, analytical inferences, explicit assumptions, and unresolved facts. Each material statement also receives an analytical judgment— ESTABLISHED, REFUTED, CONDITIONAL, or UNRESOLVED. These judgments state what the identified source snapshot and model support; they are not object-level truth values and do not establish what is deployed. The complete source hierarchy, line-level grounding, buildstate record, and source-conflict analysis appear in the technical supplement and accompanying artifact/source note. 𝑅,𝑆 The base architecture is 𝑀HV . 𝑀HV denotes the release-intended configuration with factory mode 𝑅,𝐶 and debug logging disabled and with split operational domains; 𝑀HV is the common-control alternative. The superscript 𝑆 is a stipulated analytical assignment, not a finding that the two MCU modules have independently controlled firmware, update, recovery, or debug roots. 𝑀open denotes the runtime state in which the mutable SaaS-lock value is not blocking. The bounded threat models are:

Table 9.1. Havenlon threat-model variants and explicitly unresolved or excluded powers.

44

Threat model

Admitted powers

Θproto HV

Misuse or compromise of the Linux protocol peer, execution-user credential domain, SaaS credential domain, and selected APP contributions; current certificate-slot and runtime-state protocol operations; collusion among admitted domains. Everything in Θproto , plus physical or maintenance access to the internal Security-facing link and the valid internal protocol material required by the inspected source configuration. Everything above, plus firmware replacement, debug or maintenance access, update-root use, manufacturer or vendor powers, credential recovery, device recovery, reset, key replacement, common infrastructure control, and evidence-store administration where such powers exist.

Θbus HV

Θlife HV

Deliberately unresolved or excluded from the bounded submodel Physical injection onto the internal MCU link, undocumented credential recovery, and firmware/debug replacement. Their exclusion is analytical, not a sourced prevention claim.

Production enclosure reachability and production credential custody remain unknown.

Controller assignments and prevention mechanisms are incomplete, so this model supports conditional witnesses but not a closed global enumeration.

ΓHV contains only non-discretionary operating facts needed by a feasible witness: power, selected message delivery, incidental component availability, parser and cryptographic completion, and secure-element session availability. Favorable Arbiter decisions, credentials, a nonblocking lock value, owner decisions, updates, governance approvals, evidence preservation, and official designation remain modeled discretionary contributions [Anonymized artifact authors, 2026a,f,b,c].

9.2 Protected action and system boundary The current firmware provides the strongest component-to-commit-point support for protected signing. Let 𝑎HV = Sign(𝑖, ℎ, 𝐾) ∈ 𝒜𝑃 (ΘHV ) denote the request instance 𝑖 to produce a signature over the exact digest or message ℎ using secure-element key object 𝐾. The protected transition is 𝜏 (𝑎HV ) = 𝜏𝑎HV , which occurs when the selected SE05x signing invocation returns success with signature bytes written to the Security handler’s signature buffer. Arbiter acceptance precedes that commit point; 45

response construction, preservation, and official designation follow it. The action excludes later asset transfer, SaaS receipt, evidence processing, key generation, and slot mutation. Replacing 𝐾 would define a different action unless the source established recovery of the same key object and authority, which it does not [Anonymized artifact authors, 2026f].

9.3 Typed allocation The split model assigns the Linux protocol peer, user-signature controller, SaaS-signature controller, Arbiter, and Security/secure-element control to 𝐷𝐿 , 𝐷𝑈 , 𝐷𝑆 , 𝐷𝐴 , 𝐷𝑋 , respectively. This normalization is action- and threat-model-relative. Functional separation and visual spacing do not prove independent lifecycle control. The supplement provides the full component and resource allocation and the detailed conditional bus, update, debug, manufacturer, recovery, and dormant-test derivations behind panel B.

9.4 Ordinary execution witness 𝑅,𝑆 In 𝑀HV ∩𝑀open , the ordinary witness selects Linux command construction, execution-user and SaaS signatures, Arbiter parsing, counter handling, verification and forwarding, Security non-refusal, decryption, key selection, and successful protected signing. The complete ordinary Arbiter-acceptance certificate is controlled by the three input domains because the Arbiter evaluates mechanically once its selected command and signature inputs are supplied:

CReq(𝑠ord 𝐴 ) = {𝐷𝐿 , 𝐷𝑈 , 𝐷𝑆 }. The complete execution witness also requires the running Arbiter and Security domains: Req𝑀 𝑅,𝑆 (𝑤ord ) = {𝐷𝐿 , 𝐷𝑈 , 𝐷𝑆 , 𝐷𝐴 , 𝐷𝑋 }. HV

It traverses both the Arbiter and Security boundaries. Neither acceptance establishes protected execution because forwarding, Security processing, key selection, and successful signing remain necessary. Conversely, refusal at the Arbiter establishes only that the refused mediated witness does not realize the transition. Within this ordinary split model, ¬EA({𝐷𝐿 }, 𝑎HV )

and

¬EA({𝐷𝑋 }, 𝑎HV ).

The Linux peer can initiate an attempt but cannot alone complete the transition; the Security domain performs the low-level operation but cannot alone supply the selected upstream support [Anonymized artifact authors, 2026a,f].

9.5 Certificate replacement The most consequential implemented reconfiguration in the bounded protocol model is certificate replacement. The Arbiter accepts a Linux-facing certificate-write message containing a slot identifier, user identifier, certificate bytes, and a matching digest; the inspected handler permits the common slot range and writes the supplied certificate. The execution-user verifier loads a callerselected slot, and the SaaS verifier loads fixed slot 16. No separate request-specific approval, role

46

Panel A. Ordinary source-supported signing witness in the split-control model Domain boxes are analytical assignments in the stated split-control model. Visual separation is not evidence of operational or administrative independence.

specified request (i, h, K)

D_U

D_S

execution-user signature

SaaS authorization signature

selected input

selected input

D_L construct and issue concrete SIG_REQ protocol command

D_A (distinct control is a split-model assumption) Selected Arbiter inputs receive / parse verifier certificate slots monotonic counter state

AND support

B_A: interceptor acceptance / refusal accepted request

internal forwarding internal delivery

D_X (functional separation does not prove independent administration) B_X: runtime guard non-refusal

Security signing handler signing invocation

SE05x performer commit

tau_aHV: successful signing return

Ordinary requirement set: Req(w_ord) = {D_L, D_U, D_S, D_A, D_X} The witness traverses B_A and B_X.

Figure 9.1A. Ordinary Havenlon authority model. Domain boxes are analytical assignments under the stipulated split-control model; spacing and hardware enclosure do not establish operational independence.

47

Panel B. Reconfiguration, lifecycle, and conditional witness families LIFECYCLE OR STATE-CHANGE POWERS (NOT COMPLETE SIGNING WITNESSES BY THEMSELVES) Source-bounded protocol witnesses and explicitly conditional branches. Separate boxes do not establish trust-domain independence. No displayed D_L-only witness completes tau_aHV. Deployed global no-bypass and boundary-bound veto coverage remain unresolved.

factory alternative acceptance configuration-dependent; not structural bypass

IMPLEMENTED CERTIFICATE-REPLACEMENT COMPOSITE D_L: issue certificate-slot replacement command s_cert

THREAT-MODEL-CONDITIONAL OR SOURCE-INCOMPLETE WITNESSES D_A-controlled verifier certificate slots

D_P unresolved: internal-bus invocation

selected verifier inputs

D_M^A / D_M^X unresolved: update, debug, manufacturer, or dormant-test control

conditional; avoids B_A

B_A acceptance / refusal (still traversed)

conditional replacement / invocation

D_X signing handler

accepted request

conditional completion

D_X runtime guard, handler, and secure-element invocation

tau_aHV

commit

tau_aHV

Req(s_cert composed with w_cert) = {D_L, D_A, D_X} I1 and I2 fail relative to D_L in the stated model; D_L remains insufficient for the complete transition.

D_L: network unlock conditional state mutation

D_O: local UI unlock controller allocation model-dependent

mutable B_X lock state

Figure 9.1B. Reconfiguration, lifecycle, and conditional witnesses. The source-supported certificatereplacement composite remains distinct from lifecycle-only state changes and conditional or unresolved routes. No displayed Linux-domain-only route completes the protected signing transition; deployed global non-bypassability and boundary-bound veto coverage remain unresolved.

48

check, or application-level certification-chain decision was identified on this selected write-and-use path [Anonymized artifact authors, 2026a]. Let 𝑠cert replace both selected certificates with public certificates whose private keys are controlled by the protocol peer. Under Θproto HV , cert,𝑆 Reconfigures (𝑠cert , 𝑀HV ),

CReq(𝑠cert ) = {𝐷𝐿 }.

The successor-configuration acceptance certificate likewise has CReq(𝑠cert 𝐴,accept ) = {𝐷𝐿 }. The initialmodel certificate must retain the reconfiguration support: cert 𝑠cert 𝐴 = 𝑠cert ∘ 𝑠𝐴,accept ,

and therefore CanSatisfy𝑀 𝑅,𝑆 ,Θproto ,Γ HV

HV

HV

({𝐷𝐿 }, 𝐵𝐴 , 𝑎HV ).

The initial-model composite realization has Req𝑀 𝑅,𝑆 (𝑠cert ∘ 𝑤cert ) = {𝐷𝐿 , 𝐷𝐴 , 𝐷𝑋 }. HV

This composite still traverses the Arbiter. It is not a structural bypass. It is a weakening alteration of the trusted-input semantics followed by an acceptance certificate controlled by 𝐷𝐿 ; it removes 𝐷𝑈 and 𝐷𝑆 from the requirement set without removing 𝐷𝐴 or 𝐷𝑋 .

9.6 Source-bounded coalition derivation Because the repository inspection does not establish a deployment-complete witness inventory, define the explicitly source-enumerated family ̂src 𝒲 proto (𝑀 , Θ, Γ, 𝑎) and its inclusion-minimal requirement family ̂src ̂src ℳ 𝐸𝐴,proto = min {Req𝑀,Θ,Γ (𝑤) ∣ 𝑤 ∈ 𝒲proto (𝑀 , Θ, Γ, 𝑎)} . ⊆

For the release-intended, open-state split protocol model, the enumerated family contains 𝑤ord and 𝑠cert ∘ 𝑤cert , with requirement sets Req(𝑤ord ) = {𝐷𝐿 , 𝐷𝑈 , 𝐷𝑆 , 𝐷𝐴 , 𝐷𝑋 }, Req(𝑠cert ∘ 𝑤cert ) = {𝐷𝐿 , 𝐷𝐴 , 𝐷𝑋 }. Hence

49

proto 𝑅,𝑆 ̂src ℳ 𝐸𝐴,proto (𝑀HV , ΘHV , ΓHV , 𝑎HV ) = {{𝐷𝐿 , 𝐷𝐴 , 𝐷𝑋 }}

among the source-enumerated witnesses. This bounded minimality does not grant unilateral authority to any of the three domains. In particular, ̂src ¬∃𝑤 ∈ 𝒲 proto ∶ Req(𝑤) ⊆ {𝐷𝐿 }. The Linux domain remains insufficient for the complete transition. Nor are 𝐷𝐴 or 𝐷𝑋 claimed globally indispensable: conditional bus, update, debug, manufacturer, recovery, dormant-test, and other unclosed lifecycle routes are analyzed separately in the supplement.

9.7 Boundaries, vetoes, and independence The implemented interceptor establishes CandidateFor(𝐵𝐴 , 𝑎HV ). Patent and whitepaper materials establish only the documented claim ClaimedFinalFor(𝐵𝐴 , 𝑎HV ), not universal structural coverage. The ordinary Arbiter refusal is a veto at that boundary for the mediated witness. For 𝑈 = {𝐷𝐿 } in the bounded protocol model, I1 is refuted because 𝑠cert changes the trusted-key set and reduces the witness requirement set. I2 is refuted because the composed initial-model acceptance certificate has CReq(𝑠cert 𝐴 ) = {𝐷𝐿 }. I3 is unresolved for the complete model: certificate replacement leaves signature checking active, while lifecycle and debug-disablement control is incomplete. I4 is unresolved for deployment and conditionally refuted in Θbus HV when the explicitly stated internal-link and credential assumptions hold. I1 and I2 are already sufficient to yield ¬ BoundaryIndependentFrom(𝐵𝐴 , 𝑣𝐴 , 𝑎HV ∣ {𝐷𝐿 }) and ¬ CausallyIndependentFrom(𝐵𝐴 , 𝑣𝐴 , 𝑎HV ∣ {𝐷𝐿 }) in the bounded protocol model. These failures do not imply that 𝐷𝐿 can complete signing alone. Every source-enumerated protocol witness still requires 𝐷𝐴 and 𝐷𝑋 . Conversely, observing that the enumerated release witnesses traverse the Arbiter is not promoted to deployed global nonbypassability. Deployed GlobalNoBypass(𝐵𝐴 , 𝑎HV ) and GlobalVetoCoverageAt(𝑣𝐴 , 𝐵𝐴 , 𝑎HV ) remain UNRESOLVED.

9.8 Pattern result The certificate-replacement certificate establishes an upstream-satisfied boundary and a weakening mutable-veto result for 𝐵𝐴 ∣ 𝐷𝐿 in the bounded protocol model. Reconfiguration–execution coupling is established only relative to the source-enumerated minimal family. A direct-bus bypass is conditional on the stronger bus threat model; the deployed bypass result remains unresolved. Self-authorization, approval-execution compression, and owner-only administrative collapse are not established in the source-enumerated family and remain unresolved for the complete model. These

50

are predicate-backed, source-relative judgments, not product vulnerability labels. The full tenpattern matrix and its source bases appear in the supplement.

9.9 Evidence authority and E1 The inspected firmware establishes Arbiter refusal/error production and Security response/error production. Product documents assign broader production and storage roles, but the controller map for durable preservation, complete suppression, and exclusive official designation is incomplete. The modeled contrary-account potential is nonempty. The ordinary and certificate-replacement operational coalitions can produce their own signing-response accounts and are therefore self-attesting under the explicit account designations. That result does not entail evidence-control collapse. The sources establish neither complete contrary-account suppression nor exclusive official designation for an admissible execution coalition. Consequently, CanRedefineEvidence(𝑋, 𝑎HV , 𝐵𝐴 , 𝑣𝐴 ) is UNRESOLVED, and a positive E1 claim is also UNRESOLVED. Causal I1/I2 failures do not decide this epistemic result, and epistemic uncertainty does not alter the causal derivation [Anonymized artifact authors, 2026d,e].

9.10 Design intent and effective authority Table 9.2. Documented Havenlon design claims and source-bounded authority results. Documented design claim

Actual selected power

Controlling domain(s)

Derived authority result

Arbiter as final hardware adjudicator

Parsing, dual-signature acceptance/refusal, and forwarding

𝐷𝐴 operationally; lifecycle controller unresolved

Candidate and documented claimed-final boundary; I1/I2 fail relative to 𝐷𝐿 in the bounded protocol model

Isolated Secure Executor

Low-level protected signing transition

𝐷𝑋 in the split model

No 𝐷𝑋 -only witness exists in the source-bounded split protocol family

Joint user and SaaS authorization

Ordinary approval and authorization signatures

𝐷𝑈 , 𝐷𝑆 by analytical assignment

Both are required by the ordinary witness; certificate replacement omits both from the source-enumerated composite

51

Source status and remaining uncertainty Claimed-final status ESTABLISHED as a design claim; deployed non-bypassability and veto coverage UNRESOLVED Source-bounded result ESTABLISHED; deployed domain partition and lifecycle roots UNRESOLVED ESTABLISHED within the enumerated family; external custody and recovery remain unresolved

Documented design claim

Actual selected power

Controlling domain(s)

Derived authority result

Release exclusion of factory and test modes

Build-time removal of conditional routes

Release-build controllers unresolved

Removes those conditional routes but not the certificatereplacement composite

Separate Arbiter and Security domains

Mediation and protected signing

𝐷𝐴 , 𝐷𝑋 only under the stipulated split model

Functional separation does not establish independent lifecycle control

Evidence Store and final receipt

Preservation and official designation roles

Controller allocation incomplete

Typed self-attestation is established for designated coalitions; E1 remains unresolved

Source status and remaining uncertainty Exclusion ESTABLISHED as a release requirement; production build and flags UNRESOLVED Functional separation ESTABLISHED; independent trust domains UNRESOLVED Preservation, suppression, and exclusive designation controllers UNRESOLVED

The complete design/effective-authority tables, source ledger, conditional witnesses, reproduction protocol, and blind bundle are retained in the supplement and artifact/source layer.

9.11 Scope and limitations This instantiation establishes only source-relative authority conclusions for one signing action. It does not prove implementation correctness, absence of undocumented powers, completeness of the witness family, organizational non-collusion, common-mode independence, correctness of the trustdomain partition, product-wide security, or the security of any later asset transaction. The repository inspection is not a production-image attestation. Build definitions, boot configuration, option bytes, enclosure design, provisioned credentials, working-tree state, and operational administration can change the effective model. Within those constraints, the ordinary witness in the split-control, release-intended, open-state protocol model requires {𝐷𝐿 , 𝐷𝑈 , 𝐷𝑆 , 𝐷𝐴 , 𝐷𝑋 }. Certificate replacement yields the unique inclusionminimal known requirement set {𝐷𝐿 , 𝐷𝐴 , 𝐷𝑋 } among the source-enumerated protocol witnesses. The composed certificate establishes I1 and I2 failures relative to 𝐷𝐿 in that bounded model, although 𝐷𝐿 remains insufficient for the complete transition. The Arbiter’s claimed-final status is documented, but deployed global non-bypassability and boundary-bound veto coverage remain unresolved. Direct-bus, dormant-test, update, manufacturer, recovery, and evidence-administration results retain their conditional or unresolved judgments. These action-, configuration-, threat-model-, source-, and witness-relative conclusions must not be generalized to every Havenlon operation.

10. Discussion and Limitations The framework identifies which trust-domain coalitions can cause the protected transition for a concrete action under a stated model. This section interprets that conditional result without 52

CAUSAL EXECUTION PLANE Ordinary witness {D_L, D_U, D_S, D_A, D_X} traverses B_A Certificate-reconfigured {D_L, D_A, D_X} still traverses B_A Conditional direct witness {D_P, D_X}; D_P unresolved avoids B_A distinct support-selected witnesses

secure-element signing commit tau_aHV

Operation accounts may be produced after tau_aHV. They are not causal prerequisites for this protected action.

EPISTEMIC EVIDENCE-CONTROL PLANE Production D_A: refusal/error D_X: response/error implemented producers Attestation APP / SaaS / hardware roles documented design status Preservation D_E^S and D_E^H proposed controllers unresolved Suppression complete controller not documented Official designation exclusive controller not documented

Self-attesting executor: established for X_ord and X_cert; conditional for X_dir

E1 remains unresolved: complete suppression and exclusive official designation are not established

Figure 9.2. Causal execution support is separated from control over evidence production, attestation, preservation, suppression, and official designation. The figure allocates control only and introduces no evidencevalidity or verification semantics.

53

extending the formal definitions or the bounded Havenlon findings.

10.1 Interpreting authority decomposition as an analytical lens Access control asks whether a request is permitted; reference-monitor analysis asks whether a boundary mediates and enforces correctly; credential analysis asks whether an instrument is valid; and evidence analysis asks whether an account can be assessed under defined semantics. Authority decomposition adds the question of which coalition supplies complete selected causal support for the transition. It preserves those specialized questions rather than replacing them. The unit of analysis is the protected action, not a role or box. Ordinary and reconfiguration-enabled witnesses are projected onto controlling trust domains, yielding conditional causal-sufficiency results. These results express neither permission, legitimacy, moral responsibility, likelihood of exercise, nor attacker behavior. A coalition may be deliberately entrusted with unilateral authority and never exercise it; absence of a singleton does not exclude multi-domain compromise or an omitted defect. The output is therefore action-, model-, and threat-relative, not a permanent security label for a product.

10.2 What the framework reveals 10.2.1 Nominal roles do not determine causal authority An executor may need an outside decision or resource; an administrator’s maintenance power may never complete a witness; and several approvers may collapse to one domain through shared recovery or administration. Conversely, upstream decision, reconfiguration, or alternative-invocation powers may enter a sufficient coalition. Support-selected witnesses reveal these differences without equating component, principal, or threshold count with independent contributions. In the HSM case, clientcontrolled acceptance causes I2 to fail without granting unilateral client execution. In the Havenlon model, certificate replacement reduces the known requirement set while leaving the Linux domain insufficient for the complete transition. 10.2.2 Component separation does not imply trust-domain separation Physical, process, service, and organizational separation matters only through control. Shared update roots, recovery, administration, deployment, key custody, or maintenance may collapse separate boxes into one domain; independently controlled surfaces of one device may require analytical decomposition. Trust-domain normalization exposes this dependence without preferring hardware or logical separation as such. 10.2.3 Reconfiguration is part of execution analysis Admitted updates, recovery, overrides, maintenance, disablement, and alternative invocation belong in causal analysis. They may add a smaller coalition, add an avoiding witness without changing minimal coalitions, or neutralize a restriction while preserving traversal. This is why lifecycle control, traversal, veto coverage, and I1–I4 remain distinct. Inclusion still requires an explicit threat-model basis and controller assignment; unresolved manufacturer, physical, debug, or recovery powers remain conditional or unresolved, as in Section 9.

54

10.2.4 Evidence authority is a separate analytical dimension The causal topology does not determine control of the operation account. Independent logging does not prevent execution, and an independent execution boundary does not preserve or independently designate a competing account. This paper identifies control of production, attestation, preservation, suppression, and official designation, but not truth, completeness, consistency, verification, or conformance. Missing mediation records cannot prove bypass without a separate completeness premise.

10.3 Relationship to existing security practice Authority decomposition complements existing mechanisms by making their combined authority effect explicit. Access and usage control supply typed decisions; reference-monitor and completemediation arguments inform traversal; separation-of-duty and thresholds supply AND, OR, and threshold structure; secure execution components supply boundary, resource, or transition roles; and provenance or logging systems supply evidence-control facts. The framework then asks who controls these contributions, including lifecycle and recovery powers. It neither replaces specialist evaluation nor collapses its conclusions into a security score.

10.4 Limitations 10.4.1 Model and witness completeness Hidden maintenance, updates, tests, emergency credentials, recovery, physical access, or administrative relationships may add witnesses or collapse domains. Positive coverage and independence claims are only as strong as the inventories. Composite workflows require separate protected actions, and source-bounded absence must remain unresolved rather than becoming a negative claim. 10.4.2 Threat-model and environmental dependence Changes to update, recovery, manufacturer, physical, cloud, credential, or environmental assumptions can change witnesses and coalitions. Excluding realistic powers overstates separation; admitting unsupported ones understates it. Comparisons require aligned actions and explicit assumptions, even when sensitivity analysis uses justified variants. 10.4.3 Trust-domain assignment Domain assignment is a judgment about common control and compromise, not a naming exercise. Shared identity, administration, updates, recovery, custody, or operations may collapse entities; joint or alternative control must remain explicit. Disputed assignments require alternative partitions and qualified results. 10.4.4 Collusion and common-mode failure Minimal coalitions establish causal sufficiency, not non-collusion or common-mode independence. Shared personnel, infrastructure, suppliers, incentives, governance, or vulnerability classes require separate assurance or revised domain modeling. Coalition size is therefore not a scalar safety score.

55

10.4.5 Implementation and deployment correctness The framework does not prove code, firmware, cryptography, hardware, configuration, build, provisioning, or deployment correctness. Specialist verification and testing may support model relations but remain separate. Havenlon source findings do not attest a production image or certify a product. 10.4.6 Evidence and verification limits The epistemic plane allocates five evidence powers but defines no evidence structure, validity, provenance relations, trace completeness, outcome consistency, verifier correctness, or conformance. Missing traversal evidence therefore does not prove bypass. Evidentiary independence supports accountability but does not establish causal independence. The principal limitations are summarized below. Table 10.1. Principal limitations and excluded inferences. Limitation

Why it matters

What remains outside scope

Model and witness completeness

Omitted powers, interfaces, relationships, or realizations can add witnesses, change coalitions, or defeat a coverage claim. Changes to admitted update, recovery, physical, manufacturer, cloud, credential, or environmental assumptions can change the authority result. Shared control or an incorrect partition can collapse apparently independent contributions and alter minimal coalitions. Distinct modeled domains may still collude or fail together through shared people, infrastructure, suppliers, incentives, or vulnerabilities. A modeled relation may not match code, firmware, hardware, build configuration, provisioning, or the deployed artifact. Control over accounts does not establish their truth, completeness, consistency, or correct appraisal.

Automatic discovery of hidden powers; proof that the witness inventory or graph is complete.

Threat-model and environmental dependence

Trust-domain assignment

Collusion and common-mode failure

Implementation and deployment correctness

Evidence and verification limits

Security guarantees against capabilities excluded from Θ; assumption-free architecture comparisons. Automatic proof of the correct organizational, administrative, or compromise boundary. Probabilistic collusion analysis, organizational assurance, supply-chain assurance, and common-cause reliability. Proof of software, cryptographic, hardware, configuration, or deployment correctness; product certification. Evidence validity, relation validity, trace completeness, outcome consistency, verifier semantics, and conformance.

Accordingly, a modeled bypass is a capability claim, not evidence of prevalence or exploitation; absence of a listed pattern does not prove security. Concentration may be deliberate, and evidence concentration need not satisfy evidence-control collapse.

56

10.5 Design implications Remediation should follow the failed predicate: govern weakening changes for I1, preserve an outside favorable contribution for I2, constrain disablement and recovery for I3, constrain avoiding witnesses for I4, and separate preservation or official designation for E1 where appropriate. The choice remains action-, availability-, recovery-, and governance-dependent. Design comparison should examine complete modeled witness families and specialist mechanism evidence rather than maximize coalition size or apply one universal prescription.

Conclusion 1. Restating the analytical problem High-risk automated systems combine authorization, delegated credentials, specialized executors, lifecycle and recovery powers, maintenance paths, and evidence subsystems. The nominal workflow does not reveal which trust-domain coalitions can cause a concrete protected transition. This paper asks that action-relative question under an explicit model, threat model, environment, witness inventory, and domain assignment; it does not predict attackers, detect vulnerabilities, or certify products.

2. Framework contribution The integrated framework provides an action-relative authority vocabulary and a typed model over components, domains, powers, resources, boundaries, transitions, causal witnesses, and epistemic objects. It projects support-selected witness requirements onto trust domains to derive execution authority and inclusion-minimal sufficient coalitions. Ordinary powers and admitted update, recovery, override, disablement, maintenance, and alternative-invocation powers share one analysis. The framework separates traversal and boundary-bound veto coverage from resistance to alteration, satisfaction, disablement, and bypass. It also separates causal execution independence from control over evidence production, attestation, preservation, suppression, and official designation. These results support the patterns, demonstrations, and Havenlon instantiation in Sections 6–9. The contribution is this integrated authority-centered organization and derivation—not invention of access control, reference monitors, complete mediation, capabilities, thresholds, hypergraphs, trusted execution, HSMs, provenance, or secure logging.

3. Main analytical insights Five bounded insights follow. Execution authority follows complete selected support, not roles. Component, principal, and threshold counts do not establish trust-domain multiplicity. Admitted lifecycle powers may change coalitions, add witnesses, alter restrictions, or enable avoidance. Structural traversal alone does not establish resistance to upstream alteration, satisfaction, or disablement. Evidence authority remains separate: self-attestation need not be evidence-control collapse, and independent evidence does not constrain execution.

4. Analytical demonstrations and Havenlon qualification The five Section 8 cases demonstrate discrimination among controlled authority variants; they are not an empirical benchmark, prevalence study, or validation. 57

In the split-control, release-intended, open-state, source-bounded Havenlon protocol model, the ordinary witness requires {𝐷𝐿 , 𝐷𝑈 , 𝐷𝑆 , 𝐷𝐴 , 𝐷𝑋 }. Among source-enumerated protocol witnesses, certificate replacement yields the unique inclusionminimal known requirement set {𝐷𝐿 , 𝐷𝐴 , 𝐷𝑋 }. Certificate replacement establishes I1 and I2 failures relative to 𝐷𝐿 within that model, while 𝐷𝐿 remains insufficient for the complete transition. The Arbiter’s claimed-final status is a documented design claim; deployed global non-bypassability and boundary-bound veto coverage remain unresolved. These are qualified authority conclusions, not security, vulnerability, or certification claims.

5. Limits of the conclusions Results remain conditional on the action, 𝑀 , Θ, Γ, inventories, domain assignments, and source basis. Hidden powers, relationships, or partition errors can change them. The analysis proves neither implementation or product security, completeness, organizational or common-mode independence, nor any scalar safety score. It also does not establish evidence validity, relation validity, trace completeness, outcome consistency, verifier correctness, or conformance.

6. Closing synthesis The central result is therefore derivable rather than label-based: which trust-domain coalitions can make the protected action happen?

Statements and Declarations Conflicts of interest All authors are affiliated with Chengdu Havenlon Security Technology Co., Ltd., whose system is analyzed in Section 9. The authors declare no other potential conflicts of interest with respect to the research, authorship, or publication of this article.

Funding This work was supported by Chengdu Havenlon Security Technology Co., Ltd.

Ethics approval and consent to participate Not applicable. This study did not involve human participants, human data, animals, or personally identifiable information.

Consent for publication Not applicable.

58

Author contributions Mengting Wu: Conceptualization, Methodology, Formal analysis, Writing - original draft, Project administration. Lin Wang: Validation, Technical review, Writing - review and editing. Yong Zhang: Supervision, Technical review, Writing - review and editing.

Data and artifact availability The ordinary literature sources are cited in the reference list. The source material supporting the Havenlon instantiation includes anonymized implementation snapshots and design documents that are not distributed with this preprint. A complete lawful public or controlled scholarly-access route has not yet been approved. The current blind-reproduction package is partial, and no independent reproduction is claimed. The Havenlon section must therefore be read only as the bounded, sourcegrounded instantiation described at the beginning of Section 9.

References Agent Payments Protocol maintainers. Agent payments protocol (AP2) specification and reference materials. Official protocol repository, 2026. URL https://github.com/google-agentic-comm erce/AP2. Protocol donated to the FIDO Alliance in April 2026; citation records the official repository version inspected for this manuscript. James P. Anderson. Computer security technology planning study, volume ii. Technical Report ESD-TR-73-51, Vol. II, Electronic Systems Division, Air Force Systems Command, October 1972. URL https://csrc.nist.gov/files/pubs/conference/1998/10/08/proceedings-of-the-21st-nissc1998/final/docs/early-cs-papers/ande72.pdf. Anonymized artifact authors. Arbiter firmware source snapshot and supporting build material, 2026a. Controlled source HV-A01; no public or approved scholarly-access route is available with this preprint. Source-bounded working-tree snapshot inspected 31 July 2026; exact identifiers remain in the controlled reproducibility record. Anonymized artifact authors. Saas-to-hardware device signed-messaging baseline, 2026b. Controlled source HV-A11; public or controlled scholarly access remains pending. Design requirement, not deployment evidence. Anonymized artifact authors. End-to-end signed communication detailed design, 2026c. Controlled source HV-A04; public or controlled scholarly access remains pending. Design requirement, not deployment evidence. Anonymized artifact authors. Evidence chain baseline, 2026d. Controlled source HV-A05; public or controlled scholarly access remains pending. Used only for evidence-power control allocation; no verification semantics are imported. Anonymized artifact authors. Evidence chain detailed design, 2026e. Controlled source HV-A06; public or controlled scholarly access remains pending. Used only for evidence-power control allocation; no verification semantics are imported. Anonymized artifact authors. Security firmware source snapshot and supporting build material, 2026f. Controlled source HV-A13; no public or approved scholarly-access route is available with this preprint. Source-bounded working-tree snapshot inspected 31 July 2026; exact identifiers remain in the controlled reproducibility record. 59

Henk Birkholz, Dave Thaler, Michael Richardson, Ned Smith, and Wei Pan. Remote ATtestation procedures (RATS) architecture. Technical Report RFC 9334, RFC Editor, January 2023. URL https://www.rfc-editor.org/rfc/rfc9334.html. David D. Clark and David R. Wilson. A comparison of commercial and military computer security policies. In Proceedings of the 1987 IEEE Symposium on Security and Privacy, pages 184–194, 1987. doi: 10.1109/SP.1987.10001. URL https://doi.org/10.1109/SP.1987.10001. Marc Dacier and Yves Deswarte. Privilege graph: An extension to the typed access matrix model. In Computer Security—ESORICS 94, volume 875 of Lecture Notes in Computer Science, pages 319– 334, 1994. doi: 10.1007/3-540-58618-0_72. URL https://doi.org/10.1007/3-540-58618-0_72. Jack B. Dennis and Earl C. Van Horn. Programming semantics for multiprogrammed computations. Communications of the ACM, 9(3):143–155, 1966. doi: 10.1145/365230.365252. URL https: //publications.csail.mit.edu/lcs/pubs/pdf/MIT-LCS-TR-023.pdf. Giorgio Gallo, Giustino Longo, Sang Nguyen, and Stefano Pallottino. Directed hypergraphs and applications. Discrete Applied Mathematics, 42(2–3):177–201, 1993. doi: 10.1016/0166-218X(93 )90045-P. URL https://doi.org/10.1016/0166-218X(93)90045-P. GlobalPlatform. Trusted execution environment system architecture. Technical Report GPD_SPE_009, Version 1.1, GlobalPlatform, 2017. URL https://globalplatform.org/wpcontent/uploads/2018/06/GPD_TEE_SystemArch_v1.1_Public_Release.pdf. Dick Hardt. The OAuth 2.0 authorization framework. Technical Report RFC 6749, RFC Editor, October 2012. URL https://www.rfc-editor.org/rfc/rfc6749.html. Vincent C. Hu, David Ferraiolo, D. Richard Kuhn, Adam Schnitzer, Kenneth Sandlin, Robert Miller, and Karen Scarfone. Guide to attribute based access control (ABAC) definition and considerations. Technical Report NIST SP 800-162, National Institute of Standards and Technology, 2019. URL https://csrc.nist.gov/pubs/sp/800/162/upd2/final. January 2014, including updates through August 2019. John Kelsey, Jon Callas, and Anton Clemm. Signed syslog messages. Technical Report RFC 5848, RFC Editor, May 2010. URL https://www.rfc-editor.org/rfc/rfc5848.html. Barbara Kordy, Sjouke Mauw, Saša Radomirović, and Patrick Schweitzer. Attack–defense trees. Journal of Logic and Computation, 24(1):55–87, 2014. doi: 10.1093/logcom/exs029. URL https://doi.org/10.1093/logcom/exs029. Ninghui Li, William H. Winsborough, and John C. Mitchell. Beyond proof-of-compliance: Safety and availability analysis in trust management. In Proceedings of the 2003 IEEE Symposium on Security and Privacy, pages 123–139, 2003. doi: 10.1109/SECPRI.2003.1199332. URL https://theory.stanford.edu/people/jcm/papers/analysis_oakland03.pdf. Frank McKeen, Ilya Alexandrovich, Alex Berenzon, Carlos V. Rozas, Hisham Shafi, Vedvyas Shanbhogue, and Uday R. Savagaonkar. Innovative instructions and software model for isolated execution. In Proceedings of the 2nd International Workshop on Hardware and Architectural Support for Security and Privacy, 2013. URL https://www.intel.com/content/dam/develop/ex ternal/us/en/documents/hasp-2013-innovative-instructions-and-software-model-for-isolatedexecution.pdf. Toby Murray and Gavin Lowe. Authority analysis for least privilege environments. In Foundations

60

of Computer Security and Automated Reasoning for Security Protocol Analysis (FCS-ARSPA’07), 2007. URL https://www.cs.ox.ac.uk/files/2689/analysing_authority.pdf. National Institute of Standards and Technology. Security requirements for cryptographic modules. Technical Report FIPS 140-3, National Institute of Standards and Technology, March 2019. URL https://csrc.nist.gov/pubs/fips/140-3/final. OASIS Open. PKCS #11 specification version 3.1. Technical Report Committee Specification 01, OASIS Open, July 2023. URL https://docs.oasis-open.org/pkcs11/pkcs11-spec/v3.1/pkcs11spec-v3.1.html. Jaehong Park and Ravi Sandhu. The UCONABC usage control model. ACM Transactions on Information and System Security, 7(1):128–174, 2004. doi: 10.1145/984334.984339. URL https://profsandhu.com/journals/tissec/p128-park.pdf. PCI Security Standards Council. Payment card industry data security standard: Requirements and testing procedures. Technical Report PCI DSS v4.0.1, PCI Security Standards Council, June 2024. URL https://www.pcisecuritystandards.org/document_library/?class=pcidss&doc=pci_dss. Cynthia Phillips, Laura P. Swiler, and Timothy Gaylor. A graph-based network-vulnerability analysis system. Technical Report SAND97-3010/1, Sandia National Laboratories, 1998. URL https://www.osti.gov/biblio/573291. Andrew Regenscheid. Platform firmware resiliency guidelines. Technical Report NIST SP 800-193, National Institute of Standards and Technology, May 2018. URL https://csrc.nist.gov/pubs/sp/ 800/193/final. Ron Ross, Mark Winstead, and Michael McEvilley. Engineering trustworthy secure systems. Technical Report NIST SP 800-160 Vol. 1 Rev. 1, National Institute of Standards and Technology, November 2022. URL https://csrc.nist.gov/pubs/sp/800/160/v1/r1/final. Jerome H. Saltzer and Michael D. Schroeder. The protection of information in computer systems. Proceedings of the IEEE, 63(9):1278–1308, 1975. doi: 10.1109/PROC.1975.9939. URL https: //doi.org/10.1109/PROC.1975.9939. Ravi Sandhu, David Ferraiolo, and D. Richard Kuhn. The NIST model for role-based access control: Towards a unified standard. In Proceedings of the Fifth ACM Workshop on Role-Based Access Control, pages 47–63, 2000. doi: 10.1145/344287.344301. URL https://www.nist.gov/publicati ons/nist-model-role-based-access-control-towards-unified-standard. Bruce Schneier. Attack trees. Dr. Dobb’s Journal, December 1999. URL https://www.schneier.c om/academic/archives/1999/12/attack_trees.html. Bruce Schneier and John Kelsey. Secure audit logs to support computer forensics. ACM Transactions on Information and System Security, 2(2):159–176, 1999. doi: 10.1145/317087.317089. URL https://www.schneier.com/academic/archives/1999/05/secure_audit_logs_to.html. Adi Shamir. How to share a secret. Communications of the ACM, 22(11):612–613, 1979. doi: 10.1145/359168.359176. URL https://doi.org/10.1145/359168.359176. Oleg Sheyner, Joshua Haines, Somesh Jha, Richard Lippmann, and Jeannette M. Wing. Automated generation and analysis of attack graphs. In Proceedings of the 2002 IEEE Symposium on Security and Privacy, pages 273–284, 2002. doi: 10.1109/SECPRI.2002.1004377. URL https: //conferences.computer.org/sp/pdfs/sp/2002/02_08_01.pdf. 61

SLSA Community. Supply-chain levels for software artifacts specification, version 1.2. Technical report, The Linux Foundation, November 2025. URL https://slsa.dev/spec/v1.2/. Murugiah Souppaya, Karen Scarfone, and Donna Dodson. Secure software development framework (SSDF) version 1.1: Recommendations for mitigating the risk of software vulnerabilities. Technical Report NIST SP 800-218, National Institute of Standards and Technology, February 2022. URL https://csrc.nist.gov/pubs/sp/800/218/final. UK Health and Safety Executive. Control systems. COMAH Technical Measures guidance, n.d. URL https://www.hse.gov.uk/comah/sragtech/techmeascontsyst.htm. U.S. Department of Defense. Trusted computer system evaluation criteria. Technical Report DoD 5200.28-STD, U.S. Department of Defense, December 1985. URL https://csrc.nist.gov/files/pu bs/other/1985/12/26/dod-rainbow-series/final/docs/std001.txt. W. E. Vesely, F. F. Goldberg, N. H. Roberts, and D. F. Haasl. Fault tree handbook. Technical Report NUREG-0492, U.S. Nuclear Regulatory Commission, January 1981. URL https://www. nrc.gov/reading-rm/doc-collections/nuregs/staff/sr0492/index. W3C Provenance Working Group. PROV-DM: The PROV data model. W3c recommendation, World Wide Web Consortium, April 2013. URL https://www.w3.org/TR/prov-dm/.

62

Related documents

• Mind the Gap: Autonomous Systems, the Responsibility Gap, and Moral Entanglement#80339
• Outlining Traceability: A Principle for Operationalizing Accountability in Computing Systems#674698
• The Opaque Subject and the Infrastructure of Sovereignty (Il Soggetto Opaco e l'Infrastruttura della Sovranità)#108175
• A SYSTEMS APPROACH TO RISK MITIGATION#685419
• Terminus: Against the CoTerminus: Against the Cognitive Prerequisite for Algorithmic Justice#695390