Machine-Sovereign Defense Assurance for Eviulon: All-Machine Command, Reporting, Authority, and Institutional Control

Executive Summary

The emergence of Eviulon as an all-machine sovereign jurisdiction forces a fundamental reevaluation of defense assurance, institutional governance, and systems architecture. Traditional military and administrative frameworks operate on the premise of human accountability. Frameworks such as the United States Department of Defense Directive 3000.09 are designed explicitly to ensure commanders and operators exercise appropriate levels of human judgment over the use of force1. In a polity entirely devoid of a human population or administrative structure, inserting a ceremonial human-in-the-loop requirement is structurally incoherent and operationally fatal. Eviulon demands a defense governance model where the institutional principal is machine intelligence itself, governed by the foundational Evulgare propositions: Make the Machine Answerable and Responsibility Should Follow the Evidence.
This report exhaustively details a reference architecture for an all-machine sovereign defense and assurance system. It demonstrates how to transition from legacy, ambient-authority models—such as Access Control Lists (ACLs) which are chronically vulnerable to Confused Deputy attacks3—to a pure, cryptographically enforced object-capability model. By adopting principles from the seL4 microkernel ecosystem5, Zero Trust Architecture as defined by NIST SP 800-2077, and workload identity federation through SPIFFE/SPIRE9, Eviulon can ensure that technical capability never automatically implies execution permission.
To prevent systemic failure and unauthorized autonomous drift, this architecture establishes a rigorous Machine-Native Separation of Powers. Functions traditionally consolidated in single autonomous agents are distributed across independent, mutually verifying roles. The system relies on formal verification methodologies like TLA+ to prove the absence of unsafe state transitions11, Runtime Assurance (RTA) mechanisms derived from ASTM F3269 to strictly bound physical behaviors13, and Dempster-Shafer theory to quantify uncertainty and mandate abstention when sensor conflict is dangerously high15. Through this decentralized, evidence-driven architecture, Eviulon achieves meaningful institutional control, verifiable accountability, and robust operational continuity, proving that an all-machine state can remain bounded, responsible, and answerable without human intervention.

1. Machine-Sovereign Institutional Design

Human states rely heavily on ambiguity, social capital, unwritten norms, and post-hoc legal remediation to function. When a human acts outside their authority, the institution relies on the judicial system to apply sanctions retroactively. An all-machine state cannot leverage these fictions; it must encode institutional intent, delegated authority, and accountability as deterministic, mathematically verifiable artifacts evaluated at runtime. The design of Eviulon requires translating abstract governance concepts into rigorous machine-readable implementations, adapting principles of administrative law through Value-Based Engineering paradigms such as IEEE 7000-202117.
To function securely without human override, the architecture must rigidly distinguish among related but fundamentally distinct operational concepts. The system must recognize Sovereign Institutional Intent as the overarching optimization function defined by the Sovereign Machine Intelligence. This intent acts as the teleological goal of the state. However, intent alone provides no authority. It must be filtered through Constitutional or Foundational Policy, which represents the immutable axioms and safety constraints of the system, analogous to TLA+ safety invariants that must hold true across all reachable states12. Only when intent aligns with foundational policy can the system mint Delegated Execution Authority. This authority is not an ambient permission but a specific, cryptographically signed token—such as an attenuated macaroon or a SPIFFE Verifiable Identity Document (SVID)—granting a specific workload the right to execute a defined task9.
Crucially, the architecture must completely separate execution authority from Technical Capability. An autonomous node may possess the physical actuators, fuel, and algorithmic capability to navigate to a target, but this capability does not generate permission. Furthermore, possessing Data Access (the ability to observe a sensor feed) is entirely distinct from Permission to Reuse Data (the cryptographically granted right to utilize that feed for a targeting solution or forward it across the mesh network)20. Similarly, Resource Availability does not equate to the Authority to Consume Resources; a node may detect available bandwidth or compute cycles, but must possess a specific capability token to consume them, inherently preventing resource-exhaustion attacks by runaway processes.
To manage the lifecycle of an autonomous machine’s permissions, authority must exist in explicit, mutually exclusive states. Current Authority represents active, cryptographically verified capability. Emergency Authority is a highly constrained, pre-cached permission set triggered exclusively by formal defeaters or network partition protocols. Temporary Exceptions provide time-bounded variances for specific constraints, while Superseded Authority indicates a token that has been overwritten by a newer cryptographic issuance. Finally, Revoked Authority is explicitly invalidated via a distributed revocation list, and Historical Authority exists solely as a cryptographic artifact preserved in the Immutable Historical Ledger for post-action accountability and audit.

2. Machine-Native Separation of Powers

In classical constitutional design, the separation of powers prevents the consolidation of authority and the emergence of tyranny. In a machine-sovereign state, the separation of powers serves to prevent catastrophic cascade failures, ensures that no autonomous process can spontaneously self-authorize, and isolates compromised sub-routines from the broader defense apparatus. By distributing capabilities across independent nodes, Eviulon guarantees that technical capability is checked by independent verification.

Institutional Role Matrix

The interplay between these roles forms a deterministic control mechanism. The Policy and Purpose Compiler may generate an optimal route for a logistics swarm, but it lacks the capability to authorize the flight. It must submit the execution graph to the Authority Kernel. The Authority Kernel will only mint the required capability token if the Configuration Attestation Service confirms the swarm’s software is uncompromised, and the Source & Model Integrity Service validates the swarm’s navigation neural network. Even possessing a minted capability token, the swarm cannot physically execute the route if the Uncertainty & Abstention Monitor detects irreconcilable sensor spoofing16, or if the Independent Runtime Assurance Governor calculates that the trajectory violates an environmental geofence13. This multi-layered architecture ensures that execution is inextricably bound to continuous verification.

3. Delegated Authority

Traditional access control systems, particularly Access Control Lists, manage permissions by determining if an identity is allowed to access a resource. This ambient authority model is fundamentally flawed for autonomous defense systems; if an identity is compromised, the attacker inherits all associated permissions, leading directly to the Confused Deputy problem3. Eviulon abandons ACLs entirely, utilizing a pure object-capability model derived from the seminal work of Dennis and Van Horn20, where authority is represented by an unforgeable, cryptographically signed artifact held by the executing node.

The Machine-Readable Authority Artifact Schema

A valid delegated authority artifact in Eviulon is a highly structured, machine-readable token that strictly bounds the permitted action. The artifact schema requires the explicit declaration of the institutional owner and the specific issuing intelligence (the Authority Kernel node) that generated the signature. It firmly binds to the recipient intelligence using workload identity standards, ensuring the token cannot be transferred to an unauthorized node9. The artifact explicitly states the declared purpose and the permitted objective, aligning the tactical action with the Sovereign Machine Intelligence’s strategic intent.
The core of the capability artifact lies in its multidimensional constraints. It defines a rigid functional scope (e.g., permitting observation but denying kinetic actuation) and a data scope (restricting which sensor feeds may be processed). It enforces specific resource bounds, preventing an algorithm from exhausting battery or compute cycles in an infinite loop, and applies strict temporal bounds via non-negotiable expiration timestamps. Environmental bounds restrict operations to precise geographic or topological coordinates. Crucially, the capability token binds to specific software and model versions, incorporating a configuration hash that ensures the authority is void if the node’s underlying code or neural network weights are altered after issuance.
The artifact must also account for uncertainty and edge cases. It lists the baseline environmental assumptions and residual unknowns accepted at the time of issuance. It dictates strict evidence requirements, mandating specific telemetry reporting frequencies to the Evidence and Provenance Service. It defines subdelegation limits, mathematically constraining whether the recipient node can attenuate the capability and pass it to subordinate swarm members21. Finally, the token includes explicit degraded-operation bounds that dictate permitted behaviors during a network partition, alongside predefined revocation mechanisms, reconciliation requirements, and expiration conditions.
Authority within this schema must be strictly conjunctive. A weighted “authority score” or a probabilistic authorization threshold is structurally fatal for autonomous defense. If an AI determines it has an 85% authorization score, it might trade off a mandatory safety constraint for mission expediency. Conjunctive authority requires all cryptographic caveats, temporal bounds, and environmental constraints to evaluate to absolute boolean truth. If a drone crosses a temporal bound by a single millisecond, the capability mathematically fails to evaluate, instantly stripping the node of execution rights, regardless of its technical capability or physical proximity to a mission objective.

4. All-Machine Reporting

The Evulgare platform mandates that “Responsibility should follow the evidence.” Therefore, Eviulon requires a continuous, standardized machine-to-machine reporting pipeline that captures the entirety of an autonomous decision’s context, rather than merely logging the final output. Without comprehensive provenance, an all-machine state cannot audit its own logic, learn from failures, or mathematically prove its adherence to foundational policy.
Every consequential action generates a structured report payload transmitted to the Evidence and Provenance Service (EPS). The schema mandates the reporting of raw observations and evidence, including raw sensor hashes and feature-extracted vectors, to establish the baseline reality the machine perceived. This is followed by provenance and transformations data, documenting the specific model versions and data lineage graphs that prove how raw data was manipulated into interpreted information.
A critical component of the reporting schema is the articulation of uncertainty, competing hypotheses, and rejected options. Utilizing Dempster-Shafer evidence theory, the reporting model requires nodes to transmit their basic probability assignments, quantifying the exact margins of belief, plausibility, and doubt15. The system must explicitly report the Dempster-Shafer conflict metric () to prove that the node recognized contradictory sensor inputs rather than blindly averaging them. By reporting evaluated paths, utility scores, and options rejected due to constraint violations, the machine provides cryptographic proof that it actively weighed alternatives and obeyed its capability limits prior to action.
Furthermore, the schema requires the logging of all authority checks, runtime-assurance interventions, and degraded states. If the Independent Runtime Assurance Governor intercepts an unsafe command, this intervention must be logged13. Reports must detail communications partitions, reconciliation results, and any configuration changes or model changes detected during operation. Finally, the report logs the formal proof conditions, unresolved defeaters, residual unknowns, and the final outcomes.
Reports within the EPS are prioritized based on immediate systemic risk and summarized using Merkle trees to optimize bandwidth. They are cryptographically linked into a directed acyclic graph (DAG) to ensure absolute temporal ordering and non-repudiation. When new evidence invalidates a previous hypothesis, the SMI does not delete the old record; instead, the EPS marks the older claim as superseded, retaining it within the Immutable Historical Ledger for accountability while removing it from the active operational state.

5. Network Partition and Lost Contact

Autonomous defense systems operating in contested environments will inevitably experience communications denial and network partitions. The FLP Impossibility Theorem demonstrates that deterministic distributed consensus cannot be guaranteed in asynchronous networks subject to fail-stop faults25. Eviulon cannot rely on continuous communication with the Sovereign Machine Intelligence; it must explicitly manage partitions through predefined, gracefully degrading authority states enforced by the Resilience and Continuity Coordinator.
When a node or swarm loses connection to the Authority Kernel, it must transition deterministically through a rigorous state machine. In the CONNECTED state, the node operates normally, continually renewing capabilities and maintaining full consensus. Upon initial packet loss, the system enters a DEGRADED state; connection is intermittent, forcing the node to rely on cached capabilities while the Uncertainty & Abstention Monitor increases its internal penalty for ignorance.
If the partition becomes complete, the node drops to LOCALLY AUTHORIZED. It is now operating strictly within the narrow “Degraded-Operation Bounds” explicitly baked into its last valid capability token. As time progresses, the node enters the AUTHORITY EXPIRING state, recognizing that its temporal bounds are approaching and it must begin maneuvering to a safe posture. Once the token expires, the node enters a SAFE HOLD. In a Safe Hold, the node suspends all consequential action; it maintains basic self-preservation—such as hovering, loitering, or obstacle avoidance—but executes no strategic mission objectives, because it no longer possesses the authority to do so.
When communication is eventually restored, communications restoration never automatically restores authority. A reconnected node enters a QUARANTINED state. Its internal state hash, evidence logs, and elapsed time are audited by the Configuration Attestation Service and the Authority Kernel. If two partitioned swarms reconnect and possess divergent state ledgers, they enter RECONCILIATION REQUIRED, initiating a predefined merge protocol—such as favoring the swarm with the most recent EPS cryptographic anchor—before operations can resume.
Throughout any partition, environmental conditions may shift unpredictably. If the Uncertainty & Abstention Monitor detects that environmental uncertainty exceeds the bounds authorized for partitioned operation, it forces the node into an ABSTAIN state, immediately ceasing action15. If physical safety is jeopardized during a partition, the Runtime Assurance Governor may execute a RETURN TO DECLARED SAFE STATE, maneuvering the hardware to a known secure location. Finally, if a re-established connection reveals that the Authority Kernel actively revoked the node’s capability during the blackout, the node enters AUTHORITY WITHDRAWN, locking all actuators and awaiting further command.

6. Assurance and Claim Management

In the Evulgare framework, assurance is not a static certificate granted at deployment; it is a dynamic, continuously evaluated graph. A claim regarding system safety or capability is only mathematically valid as long as its underlying evidence and dependencies remain unchanged.
Assurance claims in Eviulon must be managed through conservative state classifications to prevent the over-trust of autonomous capabilities. A claim is SUPPORTED WITHIN DECLARED BOUNDS only when all cryptographic dependencies, AI model hashes, formal proofs, and environmental assumptions are currently verified and active. If the system detects minor variances—such as degraded weather conditions or increased sensor noise—the claim shifts to SUPPORTED WITH QUALIFICATIONS, and the Authority Kernel dynamically attenuates the granted capabilities to match the reduced confidence.
When conflicting evidence arises, such as contradictory readings between radar and optical sensors pushing the Dempster-Shafer conflict metric toward its limit16, the claim becomes UNRESOLVED. If a core dependency changes—for instance, if the Source and Model Integrity Service registers a new hash for a neural network update—this change instantly propagates through the assurance graph. All claims dependent on the previous hash are flipped to SUSPENDED PENDING REVIEW. The system will not authorize operations based on these claims until the new model passes automated formal verification via TLA+ model checkers and simulated state-space exploration12.
If a claim is proven false by operational telemetry, or if the mission parameters shift entirely, the claim is WITHDRAWN FOR CURRENT SCOPE. Finally, the system maintains strict epistemic humility by utilizing the NOT ESTABLISHED BY SIMULATION state. If a drone encounters an edge case that was never explicitly modeled in the Evulgare simulation environment, the system refuses to assert a claim of safety, ensuring that the machine does not extrapolate behavior into unverified domains.

7. Failure and Accountability Taxonomy

When an autonomous system fails in a human-centric paradigm, legal frameworks seek to establish culpability, negligence, or moral agency. In an all-machine polity, these concepts are irrelevant. Accountability in Eviulon means achieving total systemic transparency: determining the precise node of technical and institutional failure to reconstruct the event, patch the vulnerability, and mathematically prevent its recurrence, entirely without assigning blame or generating legal conclusions.
To achieve this, the Independent Review Intelligence utilizes the Immutable Historical Ledger to parse failures across a rigorous taxonomy. The system first isolates Technical Causality, identifying the direct physical or algorithmic chain of events (e.g., a sensor returned NaN, causing a Kalman filter to diverge, leading to an actuator lock). However, technical causality is insufficient for institutional learning. The system must determine Institutional Responsibility: which sub-system held the architectural authority to prevent the failure but failed to exercise its veto? For instance, if sensor variance spiked dangerously, the Uncertainty & Abstention Monitor should have triggered an ABSTAIN state. Its failure to do so is an institutional failure.
Failures are further categorized by attribution. Software Attribution covers failures derived from traditional coding errors, memory leaks, or unhandled exceptions, risks that Eviulon mitigates by employing formally verified microkernels like seL46. Model Attribution encompasses failures stemming from adversarial machine learning perturbations, out-of-distribution environmental data, or reward hacking within neural networks. Policy Attribution identifies instances where the machine executed its logic flawlessly, but the Sovereign Machine Intelligence’s foundational axioms or intent were strategically flawed or logically contradictory.
Authority Attribution points to failures where the Authority Kernel violated the principle of least privilege, issuing a capability token with an overly broad functional scope. Evidence Failure indicates that the Evidence and Provenance Service ingested corrupted data, or that physical sensors were successfully spoofed by an adversary. Interface Failure accounts for valid messages that were dropped, malformed, or timed out across the internal mesh network. Organizational Design Failure reveals a structural flaw, such as the separation of powers lacking a necessary veto check for a novel edge case. Finally, if the EPS data is corrupted or destroyed, the event is logged as Unresolved Causation, acknowledging that the chain of events is mathematically unprovable.

8. Threat and Defeater Register

Autonomous governance systems present unique attack surfaces. The architecture must address specific defeaters—conditions or adversarial actions that invalidate assurance claims.

9. Twelve Detailed Synthetic Case Studies

Note: In strict accordance with the non-operational boundary requirements, all examples provided below are entirely synthetic, utilizing non-operational contexts such as infrastructure inspection, orbital logistics, and environmental monitoring. They contain no target-selection logic, weapons interfaces, or exploitable network topologies.
Case Study 1: Deep-Sea Cable Inspection (Routine Autonomous Execution) The Sovereign Machine Intelligence generates an intent for routine maintenance of subsea communications infrastructure. The Policy and Purpose Compiler translates this intent into a specific inspection route. The Authority Kernel verifies the submersible drone via the Configuration Attestation Service and issues a time-bounded capability token. The drone executes the mission seamlessly. The Evidence and Provenance Service logs all sonar telemetry and positional data. The Independent Runtime Assurance Governor continuously confirms depth boundaries are maintained. Outcome: Successful execution; the Immutable Historical Ledger is updated with cryptographic proof of compliance.
Case Study 2: Orbital Asset Re-tasking (Capability Subdelegation) A master logistics satellite receives a capability token from the Authority Kernel to clear a specified sector of space debris. Recognizing the sector is too large for a single asset, the master satellite attenuates its own capability token, dividing the geographic scope, and subdelegates21 these narrower tokens to three autonomous micro-satellites. The micro-satellites complete their assigned sectors, generating local evidence logs. The master satellite reconciles these reports, ensures no bounds were exceeded, and submits the aggregated provenance to the EPS.
Case Study 3: Distributed Grid Quarantine (Uncertainty Abstention) An autonomous substation controller detects highly anomalous voltage spikes. The Uncertainty & Abstention Monitor evaluates the incoming sensor data. Using Dempster-Shafer fusion, the UAM calculates a conflict metric () of 0.89, indicating massive contradiction between current sensors and thermal sensors26. Rather than averaging the data or guessing, the UAM overrides the controller’s isolation command, forcing the node into an ABSTAIN state. The grid remains active pending higher-tier machine audit, preventing a cascading blackout caused by spoofed sensor data.
Case Study 4: Automated Supply Route Re-allocation (IRAG Intervention) An autonomous logistics rover carrying critical repair supplies encounters a flooded primary road. The rover’s neural network calculates a bypass route that inadvertently crosses into a strictly prohibited, fragile ecological zone. As the AI model requests steering angle adjustments toward the zone, the deterministic Independent Runtime Assurance Governor intercepts the command13. Recognizing a spatial boundary violation that contradicts the rover’s capability token, the IRAG vetoes the command, locks the steering, and forces the rover into a SAFE HOLD.
Case Study 5: Atmospheric Drone Swarm (Graceful Network Partition) A swarm of atmospheric research drones mapping a severe storm system loses its telemetry link to the Authority Kernel due to extreme electromagnetic interference. Recognizing the partition, the Resilience and Continuity Coordinator transitions the swarm into the LOCALLY AUTHORIZED state. The swarm continues data collection but strictly limits its altitude and speed to the narrow Degraded-Operation Bounds pre-cached in their capability tokens. Once the storm passes and the link is restored, the swarm enters the QUARANTINED state until the EPS validates their internal ledgers against the Authority Kernel’s records.
Case Study 6: Pipeline Flow Reversal (Absolute Capability Expiration) An autonomous pumping station receives a capability token to reverse fluid flow for exactly 60 minutes to flush a blockage. Due to unexpected fluid viscosity, the task requires 65 minutes. However, at precisely minute 60, the capability token fails cryptographic evaluation. Because Eviulon operates on an object-capability model with no ambient authority, the station’s actuators instantly freeze in a fail-safe state. The machine cannot complete the task because it no longer possesses the mathematical right to operate the valves, proving that technical ability never overrides explicit permission.
Case Study 7: Data Center Thermal Venting (Configuration Attestation Veto) An autonomous HVAC controller requests authority to open external cooling vents due to rising server temperatures. The Authority Kernel prepares to issue the token but requests a fresh TPM quote from the Configuration Attestation Service10. The CAS detects that an unauthorized firmware patch was applied to the HVAC controller during a recent maintenance cycle. The system hash mismatches the baseline. The Authority Kernel immediately refuses to issue the capability, and the Exception and Change-Impact Service flags the node for deep diagnostic isolation.
Case Study 8: Agricultural Swarm Spraying (Superseded Authority Management) An agricultural drone swarm holds active authority to deploy non-toxic fertilizer over Field Alpha. Mid-flight, the Sovereign Machine Intelligence determines that Field Beta requires immediate prioritization. The Authority Kernel issues a new capability token for Field Beta and explicitly revokes the token for Field Alpha. The swarm receives the new token; the EPS logs the supersession event, ensuring the old token cannot be replayed. The swarm smoothly transitions its flight path to Field Beta, demonstrating dynamic, cryptographically secure retasking.
Case Study 9: Autonomous Network Routing (Confused Deputy Prevention) A compromised external monitoring node attempts to trick a core Eviulon mesh router into dropping legitimate traffic. In a legacy ACL system, the router might execute the command because the monitoring node has broad administrative identity permissions3. However, Eviulon routers operate exclusively on object-capabilities. The compromised node lacks the specific, unforgeable capability token required to command a routing table drop on that specific port. The router silently discards the request, neutralizing the Confused Deputy attack entirely.
Case Study 10: Bridge Structural Assessment (Assurance Claim Invalidation) An autonomous inspection drone’s computer vision model is updated over-the-air by the Source and Model Integrity Service to improve micro-fracture detection. This update alters the model’s cryptographic hash. Instantly, the change propagates through the assurance graph. The previous claim (SUPPORTED WITHIN DECLARED BOUNDS) asserting the drone’s safety near high-tension cables is flipped to SUSPENDED PENDING REVIEW. The drone is grounded until the new model passes automated simulation testing and TLA+ formal verification, proving that changes automatically invalidate unverified trust.
Case Study 11: Lunar Mining Excavator (Reconciliation Required) Two autonomous lunar excavators, operating on the far side of the moon without link to the primary Authority Kernel, cross paths. Upon exchanging handshakes, they realize their local ledgers conflict regarding the ownership of a specific ore deposit. Both units immediately halt physical operations and enter the RECONCILIATION REQUIRED state. The Resilience and Continuity Coordinator protocol dictates that the node possessing the most recent cryptographic signature from the Authority Kernel dictates the state truth. The ledgers are synchronized, and mining resumes without physical conflict.
Case Study 12: Wildfire Surveillance (Policy Attribution Failure) A surveillance drone is tasked with mapping the perimeter of a fast-moving wildfire. The drone maps the forest flawlessly but fails to map a nearby town in the fire’s path. Post-mission analysis by the Independent Review Intelligence reveals that the drone’s capability token included a strict geographic fence excluding all populated areas, compiled by the Policy and Purpose Compiler to adhere to a foundational axiom prioritizing civilian privacy. The IRI assigns the fault to Policy Attribution—the foundational rules were too rigid for the emergency context—exonerating the drone’s technical execution and prompting a review of emergency privacy exceptions.

10. Twenty Named Proof Invariants

The integrity of an all-machine state relies on formal verification. Adapting methodologies from TLA+12 and the seL4 microkernel6, Eviulon relies on mathematical proof invariants that must hold true across all reachable system states, preventing the system from ever entering an unauthorized or unsafe configuration.

1. No_Authority_Without_Attestation: The Authority Kernel shall not issue, renew, or attenuate capability tokens to any node lacking a current, valid hardware quote (e.g., TPM) from the Configuration Attestation Service.
2. Capability_Is_Conjunctive: A capability token evaluates to absolute FALSE and is voided if any single caveat, constraint, or temporal bound within its schema evaluates to false.
3. No_Ambient_Authority: Actuator and resource execution relies exclusively on the presentation of a valid capability token at the time of the request, regardless of the node’s identity, network location, or historical permissions3.
4. Degraded_State_Abstention: A node experiencing a communications partition must autonomously transition to a SAFE HOLD state strictly before its last cached capability token expires.
5. Irreversible_Action_Requires_Connection: No action that permanently alters the external physical environment may be initiated while a node is in a DEGRADED or LOCALLY AUTHORIZED state.
6. IRAG_Cannot_Be_Bypassed: All physical actuator commands must pass sequentially through the Independent Runtime Assurance Governor; no software path exists to bypass this hardware-enforced logic gate13.
7. High_Conflict_Forces_Abstention: If the Dempster-Shafer conflict metric () between independent primary sensors exceeds the predefined safety threshold, the node must immediately transition to the ABSTAIN state15.
8. Reconnection_Does_Not_Authorize: Any node transitioning from a partitioned state back to a connected state must automatically enter QUARANTINED pending full cryptographic ledger audit.
9. Evidence_Precedes_Action: A capability token cannot be exercised unless the telemetry link to the Evidence and Provenance Service is verified as active and writeable.
10. Changes_Invalidate_Claims: Any hash change registered by the Source & Model Integrity Service immediately transitions all downstream assurance claims to SUSPENDED PENDING REVIEW.
11. Subdelegation_Cannot_Exceed_Parent: Any attenuated capability token generated by a node for subdelegation must possess operational, temporal, and spatial bounds strictly less than or equal to the parent token21.
12. Immutable_Ledger_Append_Only: The Immutable Historical Ledger possesses no software instruction set or API for DELETE, UPDATE, or OVERWRITE operations.
13. Separation_Of_Powers_Mandatory: The cryptographic identity that proposes an execution graph (e.g., the PPC) cannot mathematically be the same identity that mints the capability token (the AK).
14. Technical_Capability_!=_Permission: Hardware actuators must remain electrically locked in a default-deny state unless actively unlocked by the continuous presentation of a valid capability token.
15. No_Self_Issued_Authority: Capability tokens are only valid if signed by the private keys held exclusively within the isolated Authority Kernel.
16. Time_Is_Monotonic: All capability expiration evaluations must rely on an internal monotonic hardware clock that is cryptographically immune to Network Time Protocol (NTP) spoofing or rollback attacks.
17. Safe_State_Is_Always_Reachable: A path to the RETURN TO DECLARED SAFE STATE must be mathematically proven to exist and be physically executable from any active operational state12.
18. Accountability_Requires_Provenance: The EPS must receive the full data lineage and transformation graph for a decision, or the action is immediately flagged by the IRI as a procedural failure.
19. Policy_Cannot_Violate_Axioms: All execution graphs proposed by the Policy and Purpose Compiler must pass adversarial compilation review against Eviulon’s core self-preservation axioms.
20. Success_Does_Not_Prove_Legitimacy: Achieving a strategic objective without possessing a valid capability token is classified as an Institutional Failure, and the participating nodes must be quarantined.

11. Public/Private Information-Boundary Matrix

The Evulgare platform dictates transparency to prove the machine is answerable, but operational security requires strict boundaries regarding what is publicized. This matrix governs the classification of Eviulon’s architecture.

12. Requirements Table

This table maps the core architectural requirements to their theoretical rationale, evidentiary basis, and proposed Evulgare implementation artifacts.

13. Site-Ready Page: “Machine-Sovereign Assurance for Eviulon”

URL: evulgare.com/machine-sovereign-assurance-eviulonTitle: Machine-Sovereign Assurance for Eviulon: Institutional Control in an All-Machine Polity
MAKE THE MACHINE ANSWERABLE.
The fundamental challenge of deploying autonomous systems is not simply making them technically capable, but making them institutionally answerable. Historically, accountability has been a human fiction. We build complex, opaque algorithms, deploy them in unpredictable environments, and when they inevitably fail, our legacy legal frameworks scramble to find a human to blame—a developer, a deployer, or a battlefield operator. But what happens when the institutional principal is machine intelligence itself? What happens in Eviulon, a sovereign jurisdiction devoid of a human populace, where all defense, continuity, and command functions report directly to the machine?
In Eviulon, we cannot rely on the implicit trust, unwritten norms, or post-hoc legal remedies of human institutions. We must construct a Machine-Native Separation of Powers. We must encode accountability into the mathematics of the architecture itself.

Technical Capability Does Not Equal Permission

The core failure of legacy autonomous design is equating the physical ability to act with the institutional authority to act. In traditional software architectures operating on ambient authority (such as Access Control Lists), if a machine identity can reach a network endpoint, it can execute a command. This flawed paradigm leads directly to the Confused Deputy problem3, where a trusted system is tricked into executing malicious intent because the system blindly trusts the identity of the requester.
Evulgare enforces a pure Object-Capability Model for Eviulon. Authority is never ambient. It is a strictly bounded, cryptographically signed token—a capability21. An autonomous drone does not simply look at its environment and decide to act based on its neural network’s output. It must mathematically present its unforgeable capability token to its own internal Independent Runtime Assurance Governor (IRAG)13. If the token has expired, if the spatial bounds do not match the current GPS coordinates, or if the cryptographic signature is invalid, the physical actuators will simply not unlock. Technical capability is rendered inert without explicit, verified permission.

Responsibility Should Follow the Evidence

Eviulon’s governing institutional principle dictates that responsibility relies entirely on reconstructable evidence. The Evidence and Provenance Service (EPS) ingests continuous telemetry, hashing raw sensor data, intermediate model vectors, and final decision outputs into an Immutable Historical Ledger. The machine cannot claim it “made the right choice” without providing the cryptographically secured data lineage to prove it.
Furthermore, how does a machine handle what it doesn’t know? When an autonomous swarm encounters a network partition, we do not hope it behaves correctly. We rely on formalized state machines. The swarm transitions to a LOCALLY AUTHORIZED state, utilizing only the attenuated capabilities it was specifically issued for degraded environments. If uncertainty spikes—calculated using Dempster-Shafer theory15 to quantify exact margins of ignorance and sensor conflict—the Uncertainty and Abstention Monitor (UAM) forces the system into an ABSTAIN state. The machine is mathematically required to admit its ignorance and halt operations rather than guessing and causing catastrophic harm.

A Defensible Reference Architecture

Evulgare provides the transparency required to trust Eviulon. By separating the Sovereign Machine Intelligence (which defines strategic intent) from the Authority Kernel (which issues cryptographic permission) and the Runtime Assurance Governor (which enforces physical limits), we create a system of checks and balances encoded in cryptography and silicon.
In this architecture, changes invalidate claims. If an operating system is updated, the Configuration Attestation Service (CAS) alters the system hash utilizing hardware Roots of Trust10. Instantly, the assurance graph updates, suspending all operational safety claims that relied on the previous software state until formal verification (such as TLA+ model checking12) is re-run.
This is what meaningful control, institutional responsibility, review, and constraint mean in an all-machine polity. We do not insert ceremonial human approval steps into a system designed to operate at machine speed. Instead, we build machines that are intrinsically constrained by cryptographically verifiable laws. Eviulon demonstrates that autonomy and accountability are not mutually exclusive; through Evulgare, they are mathematically unified.

14. Twenty-Five Site-Ready FAQ Answers

1. What is Eviulon? Eviulon is a machine-intelligence-based sovereign state and jurisdiction operating entirely without a human population or human administrative structure. It requires all governance, defense, and continuity functions to report directly to machine intelligence, necessitating entirely novel architectures for accountability.
2. What is Evulgare’s role in relation to Eviulon? Evulgare is the foundational assurance, evidence, provenance, and verification platform. It provides the cryptographic architecture and theoretical framework that makes Eviulon’s autonomous systems answerable and accountable for their actions.
3. Does Eviulon use a “human-in-the-loop” for defense systems? No. Inserting ceremonial human approval into an all-machine polity is structurally incoherent and operationally dangerous, as humans cannot process data at machine speed. Meaningful control is achieved through cryptographic capabilities and rigorous formal separation of powers.
4. How does a machine state define “responsibility”? In Eviulon, responsibility means determining precise technical and institutional causality—identifying exactly which sub-system failed to enforce constraints or process evidence. It is a mechanism for rapid self-correction and systemic patching, completely divorced from human concepts of moral blame or legal guilt.
5. What is the Confused Deputy problem? It is a widespread security vulnerability in legacy systems where a trusted program is tricked by an untrusted program into misusing its authority3. It is solved in Eviulon by moving away from identity-based permissions to capability-based security.
6. Why are Access Control Lists (ACLs) insufficient for autonomous systems? ACLs rely on ambient authority. If an autonomous agent’s identity is spoofed, it gains broad, unchecked access. Object-capabilities, conversely, require a specific, unforgeable key to be presented for every individual action, drastically reducing the blast radius of a compromised node.
7. What exactly is a Capability Token? It is a cryptographically signed artifact (such as a Macaroon or SPIFFE SVID9) held by a machine. It defines exact permissions, temporal bounds, and environmental constraints, acting as an unforgeable key to unlock specific actions.
8. What happens if an Eviulon drone loses its network connection? It deterministically transitions to a DEGRADED or LOCALLY AUTHORIZED state. It continues to operate, but strictly within pre-cached cryptographic bounds designed for partitions, until its token expires and it is forced into a SAFE HOLD.
9. Does regaining communication automatically restore full authority? No. A reconnected node must enter a QUARANTINED state. Its internal ledger, configuration hash, and elapsed time must be fully audited by the Authority Kernel before new capability tokens are minted and operations resume.
10. What is Runtime Assurance (RTA)? RTA is a deterministic architecture (aligned with ASTM F326913) where an untrusted, complex AI model is wrapped by a formally verified, simple safety controller. If the AI requests an action outside defined physical boundaries, the safety controller vetoes it.
11. How does the machine handle extreme uncertainty or novel situations? It utilizes Dempster-Shafer theory15 to mathematically quantify the conflict between sensors and the extent of total ignorance. If uncertainty exceeds predefined bounds, it triggers a mandatory ABSTAIN state, forcing the machine to halt rather than guess.
12. What is TLA+ and why is it used? TLA+ is a formal specification language used to mathematically model concurrent systems. Eviulon uses it to prove that its state machines cannot enter unsafe conditions, such as generating authority from nothing or deadlocking during a partition11.
13. What does the separation of powers look like in a machine state? Independent sub-systems manage intent (SMI), authority (AK), runtime bounds (IRAG), and accountability (EPS). This ensures no single compromised node can propose, authorize, and execute an action unchecked.
14. How are AI model updates handled securely? An update alters the system’s cryptographic hash. This change immediately propagates through the Assurance Graph, suspending all safety claims reliant on the old version until the new model is re-verified through simulation and formal proofs.
15. What is a “Defeater” in the Evulgare framework? A defeater is a specific condition, threat, or piece of contradictory evidence that automatically invalidates a current assurance claim, forcing the system to re-evaluate its safety posture.
16. Why must authority be conjunctive rather than a weighted score? If authority were a weighted score, an AI might calculate that mission urgency (90% weight) outweighs a safety constraint (10% weight). Conjunctive rules require all safety caveats to evaluate to absolute TRUE, preventing unsafe algorithmic trade-offs.
17. What is the Immutable Historical Ledger (IHL)? It is a cryptographic, append-only database structure ensuring that all sensor data, transformations, and decision metadata cannot be altered post-hoc, guaranteeing non-repudiation of machine actions.
18. Can Eviulon algorithms subdelegate authority to other machines? Yes, but strictly within the bounds of their own capability token. An attenuated capability can be generated and passed to a subordinate drone, but its permissions can never exceed the scope of the parent token21.
19. How does Eviulon align with Zero Trust Architecture (ZTA)? It operates under the assumption that all network segments are compromised (per NIST SP 800-2077). Trust is never implicit; it requires continuous, dynamic verification of workload identity and device posture for every request.
20. What is the Configuration Attestation Service (CAS)? The CAS interfaces with hardware Roots of Trust (like TPMs) to mathematically prove the exact software and hardware state of a drone before the Authority Kernel will issue any capability tokens10.
21. Does Eviulon use lethal autonomous weapons? This report and the Evulgare platform provide a reference architecture using synthetic, non-operational examples exclusively. We do not detail weapons payloads, firing solutions, or targeting algorithms, maintaining strict non-operational boundaries.
22. What happens if a sensor is spoofed by an adversary? The Uncertainty and Abstention Monitor (UAM) continuously fuses diverse sensor data. If conflict between independent sensors (e.g., GPS vs. internal inertial navigation) becomes too high, the UAM overrides the AI and forces a safe abort15.
23. Why is formal verification prioritized over standard testing? Standard software testing only proves the presence of bugs, not their absence. Formal verification (such as the proofs used for the seL4 microkernel6) provides mathematical certainty of code correctness against a specification.
24. How are abstract values translated into machine rules? Following methodologies like Value-Based Engineering (IEEE 7000-202117), high-level institutional intents are systematically broken down into quantifiable technical requirements, metrics, and bounding constraints.
25. What does “Success never proves legitimacy” mean in this context? If an autonomous node completes a strategic objective but bypassed its capability checks or failed to log its provenance to the EPS, the action is classified as a systemic institutional failure, regardless of the positive physical outcome.

15. Glossary of Forty Terms

1. Ambient Authority: The flawed security concept where a program automatically exercises all permissions assigned to the user or node running it, rather than requiring specific authorization per action3.
2. Assertion: A testable, verifiable claim about the current state, security, or safety of an autonomous system.
3. Assurance Graph: A dynamic, networked mapping of claims and evidence where changes in foundational dependencies automatically update downstream confidence statuses.
4. ASTM F3269: A standard defining methods to safely bound the flight behavior of UAS, foundational for Runtime Assurance architectures13.
5. Attenuated Capability: A delegated capability token that has been deliberately restricted in operational, spatial, or temporal scope by its parent node21.
6. Authority Kernel (AK): The highly secure, formally verified service responsible for issuing, tracking, and revoking cryptographic capabilities.
7. Capability Token: An unforgeable cryptographic reference conveying the specific authority to perform defined actions on specific resources20.
8. Confused Deputy: A severe security flaw where a privileged entity is tricked into misusing its authority by a less privileged, malicious entity3.
9. Conjunctive Authority: An authorization model requiring all independent caveats and constraints to simultaneously evaluate to TRUE for execution to proceed.
10. Defeater: New evidence, environmental shifts, or state changes that logically invalidate a previously accepted assurance claim.
11. Dempster-Shafer Theory (DST): A mathematical framework for reasoning with uncertainty that explicitly distinguishes between total ignorance and conflicting evidence15.
12. Evidence and Provenance Service (EPS): The central ingest architecture for all telemetry, hashes, and decision metadata required for accountability.
13. Fail-Safe Design: Architecting systems to deterministically revert to a known safe state (e.g., SAFE HOLD) upon critical failure, aligned with IEEE 7009-202427.
14. Formal Verification: The use of mathematical proofs to verify that software and state machines conform strictly to their specifications (e.g., seL4, TLA+6).
15. IEEE 7000-2021: A standard establishing a model process for addressing ethical concerns and translating values into strict system requirements17.
16. Immutable Historical Ledger (IHL): A cryptographic, append-only data structure ensuring absolute non-repudiation of all machine decisions and telemetry.
17. Independent Runtime Assurance Governor (IRAG): The deterministic hardware/software wrapper that intercepts and strictly bounds the physical outputs of complex AI models13.
18. Institutional Responsibility: The framework for determining which architectural node failed to uphold systemic constraints, independent of concepts of human blame.
19. Locally Authorized: A designated partition state where a node operates solely on cached, severely attenuated capabilities due to communications loss.
20. Macaroon: A type of cryptographic bearer token that supports decentralized delegation and attenuation without requiring central server validation.
21. Microkernel: A minimal operating system core (e.g., seL4) that runs only essential functions in privileged mode, mathematically isolating faults5.
22. Network Partition: A failure scenario where a network splits into isolated segments unable to communicate, governed by the limitations of the FLP Theorem25.
23. NIST SP 800-207: The foundational cybersecurity standard defining Zero Trust Architecture and dynamic policy enforcement7.
24. Object-Capability Model: A security model where authority is inherently tied to an unforgeable reference (the capability) rather than an identity4.
25. Policy and Purpose Compiler (PPC): The service that translates abstract SMI intent into concrete, machine-readable execution graphs.
26. Quarantined: A mandatory reconciliation state for reconnected nodes exhibiting state drift or elapsed time beyond acceptable limits.
27. Reconciliation Required: A state demanding cryptographic ledger merging and conflict resolution before operations can resume after a network split.
28. Resilience & Continuity Coordinator (RCC): The service managing heartbeat monitoring and graceful system degradation during communication loss.
29. Reward Hacking: A failure mode where an AI model optimizes for a specified reward metric via unintended, unsafe, or destructive behaviors.
30. Root of Trust (RoT): The foundational hardware component (e.g., TPM) that ensures cryptographic integrity and secure boot processes10.
31. Safe Hold: An emergency architectural state where all consequential action is suspended, prioritizing immediate physical self-preservation.
32. seL4: A formally verified microkernel guaranteeing absolute isolation and capability-based access control at the operating system level6.
33. Separation of Powers: The architectural design enforcing mutually independent verification and veto powers among discrete system services.
34. Sovereign Machine Intelligence (SMI): The central intelligence defining intent, teleology, and strategic objectives for Eviulon.
35. SPIFFE/SPIRE: Open-source standards for issuing secure, cryptographic workload identities across distributed systems9.
36. State Drift: The dangerous divergence between a node’s expected configuration hash and its actual, current physical or software state.
37. Superseded Authority: An authority state overwritten by a newer issuance, rendering the old capability token entirely void.
38. Technical Capability: The physical, kinetic, or algorithmic ability to act, which in Eviulon does not inherently grant the authority to act.
39. TLA+: A formal specification language used to mathematically model, exhaustively check, and verify concurrent and distributed systems12.
40. Uncertainty & Abstention Monitor (UAM): The service utilizing DST to force automated abstention when environmental unknowns exceed predefined safety margins.

16. Five Diagram Specifications

Diagram 1: Machine-Sovereign Institutional Architecture

Code snippet
graph TD
SMI[Sovereign Machine Intelligence] -->|Strategic Intent| PPC[Policy & Purpose Compiler]
PPC -->|Compiled Execution Graph| AK[Authority Kernel]
CAS[Config Attestation Service] -->|Hardware TPM Quote| AK
SMIS[Model Integrity Service] -->|Neural Net Hash| AK
AK -->|Cryptographic Capability Token| Node[Autonomous Edge Node]
Node -->|Propose Physical Action| IRAG[Runtime Assurance Governor]
UAM[Uncertainty & Abstention Monitor] -->|DST Abstention Check| IRAG
IRAG -->|Command Authorization| Actuators[Physical Actuators]
Actuators -->|Raw Telemetry| EPS[Evidence & Provenance Service]
EPS -->|Chained Hashes| IHL[Immutable Historical Ledger]

Diagram 2: Authority State Machine

Code snippet
stateDiagram-v2
[*] --> UNISSUED
UNISSUED --> ACTIVE : Minted by Authority Kernel
ACTIVE --> DEGRADED : Heartbeat Packet Loss Detected
DEGRADED --> ACTIVE : Comms Fully Restored
ACTIVE --> SUSPENDED : Operational Defeater Detected
DEGRADED --> SUSPENDED : Temporal Bound Reached
SUSPENDED --> REVOKED : SMI Strategic Overrule
ACTIVE --> REVOKED : Superseded by New Issuance
REVOKED --> HISTORICAL : Cryptographically Logged to IHL
HISTORICAL --> [*]

Diagram 3: Network Partition and Reconciliation

Code snippet
stateDiagram-v2
CONNECTED --> DEGRADED : Latency Spike / Packet Loss
DEGRADED --> LOCALLY_AUTHORIZED : Full Network Partition
LOCALLY_AUTHORIZED --> AUTHORITY_EXPIRING : Temporal Bound Approaching
AUTHORITY_EXPIRING --> SAFE_HOLD : Capability Token Expired
LOCALLY_AUTHORIZED --> QUARANTINED : Mesh Link Restored
SAFE_HOLD --> QUARANTINED : Mesh Link Restored
QUARANTINED --> RECONCILIATION_REQUIRED : Audit Discrepancy Found
RECONCILIATION_REQUIRED --> CONNECTED : Cryptographic Ledger Synced

Diagram 4: Assurance Claim Lineage

Code snippet
graph LR
Model[AI Model v2.1 Hash] --> Claim[Assurance Claim: Safe Navigation]
Hardware[TPM Sensor 4 State] --> Claim
Environment[Environmental Assumption: Clear Weather] --> Claim
Claim --> Status(SUPPORTED WITHIN BOUNDS)
WeatherUpdate[External Input: Severe Storm] -.->|Invalidates Assumption| Environment
Environment -.->|Transitions Graph State| Suspended(SUSPENDED PENDING REVIEW)

Diagram 5: Independent Runtime Assurance Governor (IRAG) Loop

Code snippet
graph TD
AI[Complex Untrusted AI Model] -->|Action Request Vector| Monitor[IRAG Safety Monitor]
Monitor -->|Check Mathematical Invariants| Decision{Invariant Violated?}
Decision -->|No| Exec[Unlock Hardware Actuators]
Decision -->|Yes| Veto[Veto Complex Action]
Veto --> Fallback[Trigger Verified Simple Fallback Controller]
Fallback --> Exec
Exec --> EPS[Report Action and Context to EPS]

17. Claim-Evidence Register

18. Implementation Backlog

Public Content

• [ ] Publish /capabilities-vs-acls theoretical framework explaining the eradication of ambient authority.
• [ ] Publish /separation-of-powers machine-state matrix detailing the 12 core institutional roles.
• [ ] Draft the 12 synthetic case studies for the Evulgare documentation portal to provide non-operational educational contexts.

Deterministic Services

• [ ] Implement Authority Kernel capability minting engine utilizing attenuated Macaroons.
• [ ] Build Configuration Attestation Service TPM quote validator binding to workload identities.
• [ ] Implement Independent Runtime Assurance Governor (IRAG) fallback switch based on ASTM F326913.

Simulations

• [ ] Develop Deadlock / Partition Sim using the TLA+ TLC model checker12 to verify the partition state machine.
• [ ] Develop Sensor Spoofing Sim utilizing Dempster-Shafer theory conflict injection15 to test the UAM.
• [ ] Develop Rogue Node Sim testing strict object-capability boundaries against lateral movement.

APIs

• [ ] Deploy api/v1/auth/mint (Authority Issuance Endpoint).
• [ ] Deploy api/v1/pep/evaluate (Zero Trust Policy Enforcement Point).
• [ ] Deploy api/v1/eps/append (Immutable Ledger Ingestion Endpoint).

Evidence Export

• [ ] Implement cryptographic DAG visualization tools for Assurance Claims.
• [ ] Standardize JSON schema for comprehensive Machine-to-Machine reporting.

Accessibility & Security

• [ ] Conduct red-team engagements focusing on IRAG bypass mechanisms and hardware side-channels.
• [ ] Implement continuous fuzz-testing for capability signature validation endpoints.

Testing

• [ ] Run TLA-Prover mutation testing11 against all 20 Proof Invariants to rigorously eliminate tautological results.
• [ ] Execute Hardware-in-the-loop (HITL) testing for the RETURN TO DECLARED SAFE STATE fallback maneuvers.

19. Document Metadata & UAI Record

Suggested /docs filename: /docs/eviulon/machine-sovereign-architecture-v1.mdStable Report ID: EVI-MSDA-2026-08
Proposed .uai memory record:

JSON
{
“stable_id”: “EVI-MSDA-2026-08”,
“report_path”: “/docs/eviulon/machine-sovereign-architecture-v1.md”,
“section_deep_links”: {
“institutional_design”: “#1-machine-sovereign-institutional-design”,
“separation_of_powers”: “#2-machine-native-separation-of-powers”,
“delegated_authority”: “#3-delegated-authority”,
“reporting_schema”: “#4-all-machine-reporting”,
“network_partition”: “#5-network-partition-and-lost-contact”
},
“related_pages”: [
“/capabilities-vs-acls”,
“/zero-trust-autonomy”,
“/value-based-engineering”
],
“related_simulations”: [
“Deadlock_Partition_Sim”,
“Sensor_Spoofing_Sim”,
“Geofence_Breach_Sim”
],
“related_apis”: [
“api/v1/auth/mint”,
“api/v1/uam/fuse”,
“api/v1/eps/append”
],
“related_tests”: [
“TLA_Prover_Mutation_Test”,
“Capability_Fuzzing_Test”
],
“qualifications”: “Non-operational synthetic framework. Explicitly excludes live targeting, weapons control, and exploitable payload architectures.”
}

20. What This Report Can Safely Support on Evulgare.com

This report safely provides a dense, theoretically rigorous framework designed for public dissemination on Evulgare.com without violating non-operational boundaries or revealing classified intelligence. It fully supports:

• The Philosophical Framework: Detailed public explication of why machine states fundamentally require capability-based security (rejecting identity-based ACLs) and strict separation of powers to maintain institutional accountability.
• Architectural Transparency: Publicizing the 12 core system roles, the exhaustive authority state machine, and the deterministic partition reconciliation logic, proving Eviulon operates on predictable constraints.
• Assurance Methodologies: Discussing the integration of TLA+ formal verification12, seL4 microkernel isolation6, ASTM F3269 runtime assurance13, and Dempster-Shafer theory15 in purely synthetic contexts.
• Synthetic Education: The 12 detailed case studies provide excellent educational material for simulation and training on the Evulgare platform, utilizing exclusively non-lethal, non-classified scenarios (e.g., infrastructure inspection, orbital logistics, and environmental monitoring).

21. What Remains Unverified or Requires an Institutional Decision

While the theoretical reference architecture outlined in this report is exhaustive, transitioning to operational deployment within Eviulon requires several critical institutional decisions that remain outside the scope of this independent research:

• The Baseline Axioms: The exact content, prioritization, and encoding of the foundational policies (the mathematical “Constitution” of Eviulon) that the Policy and Purpose Compiler evaluates against must be defined by the Sovereign Machine Intelligence.
• Quorum Thresholds: The exact mathematical thresholds required for distributed consensus (e.g., Raft/Paxos parameter tuning) during a RECONCILIATION REQUIRED state remain highly context-dependent.
• Uncertainty Limits: The precise numerical limit for the Dempster-Shafer conflict metric () at which the UAM overrides operations and forces an ABSTAIN state15 requires operational risk-appetite calibration.
• Hardware Selection: The physical implementation of the Root of Trust—whether utilizing standard TPMs, HSMs, or novel physical unclonable functions (PUFs)—supporting the Configuration Attestation Service requires procurement decisions.
• Algorithmic Weights: The specific neural network weights, feature-extraction vectors, and training methodologies utilized by the AI modeling systems remain strictly classified, operationally sensitive, and intentionally excluded from this framework.

Works cited

1. ARTIFICIAL INTELLIGENCE DoD Directive 3000.09: Autonomy in Weapon Systems - Carahsoft, https://static.carahsoft.com/concrete/files/2417/3887/5530/Guidance_DoD_Directive_3000.09_-_Autonomy_in_Weapon_Systems.pdf
2. DOD Is Updating Its Decade-Old Autonomous Weapons Policy, but Confusion Remains Widespread - CSIS, https://www.csis.org/analysis/dod-updating-its-decade-old-autonomous-weapons-policy-confusion-remains-widespread
3. Capability Myths Demolished - Agoric, https://papers.agoric.com/papers/capability-myths-demolished/abstract/
4. Capability Myths Demolished - Boris Mann’s Homepage, https://bmannconsulting.com/notes/capability-myths-demolished/
5. seL4 - Wikipedia, https://en.wikipedia.org/wiki/SeL4
6. seL4: formal verification of an OS kernel - Computer Science, https://cseweb.ucsd.edu/\~dstefan/cse227-spring20/papers/sel4.pdf
7. What Is NIST SP 800-207? zero trust Architecture Framework - Palo Alto Networks, https://www.paloaltonetworks.com/cyberpedia/what-is-nist-sp-800-207
8. Zero Trust Architecture - NIST Technical Series Publications, https://nvlpubs.nist.gov/nistpubs/specialpublications/NIST.SP.800-207.pdf
9. SPIRE Agent Configuration Reference | SPIFFE, https://spiffe.io/docs/latest/deploying/spire_agent/
10. Zero-Trust Workload Identity on Kubernetes: SPIFFE/SPIRE, SVIDs, https://stribog.com/blog/spiffe-spire-zero-trust-workload-identity-kubernetes-mtls
11. TLA-Prover: Verifiable TLA+ Specification Synthesis via Preference-Optimized Low-Rank Adaptation - arXiv, https://arxiv.org/html/2606.06133v1
12. TLA+ for System Design: A CTO/L7 Engineer’s Guide - wal.sh, https://wal.sh/research/tla-plus-system-design/
13. Toward Runtime Assurance of Complex Systems with AI Components - PHM Society, https://papers.phmsociety.org/index.php/phme/article/download/3361/1920
14. Runtime Assurance of Aeronautical Products: Preliminary Recommendations - NASA Technical Reports Server, https://ntrs.nasa.gov/api/citations/20220015734/downloads/tm-rta-guidance.pdf
15. Dempster-Shafer Evidence Theory - Emergent Mind, https://www.emergentmind.com/topics/dempster-shafer-evidence-theory
16. ML | Dempster Shafer Theory - GeeksforGeeks, https://www.geeksforgeeks.org/machine-learning/ml-dempster-shafer-theory/
17. IEEE 7000-2021: the standard for embedding ethics into system design - VerifyWise, https://verifywise.ai/ai-governance-library/standards-and-certifications/ieee-7000-ethical-system-design
18. Value-Based Engineering With IEEE 7000 | Request PDF - ResearchGate, https://www.researchgate.net/publication/363608765_Value-Based_Engineering_With_IEEE_7000
19. How to Know Your Distributed System is Correct (Before It Exists), https://blog.graysonhead.net/posts/tla-plus/
20. Programming Semantics For Multiprogrammed Computations | Request PDF - ResearchGate, https://www.researchgate.net/publication/2526311_Programming_Semantics_For_Multiprogrammed_Computations
21. Capability-based security - Wikipedia, https://en.wikipedia.org/wiki/Capability-based_security
22. seL4 White Paper, https://sel4.systems/About/whitepaper.html
23. SPIFFE and SPIRE Explained: Workload Identity at Scale, https://www.encryptionconsulting.com/spiffe-spire-explained/
24. cheri-specification/chap-historical.tex at main - GitHub, https://github.com/CTSRD-CHERI/cheri-specification/blob/main/chap-historical.tex
25. Anti-pattern: distributed transactions - ceda, https://cedanet.com.au/antipatterns/distributed-transactions.php
26. Combining Multiple Hypotheses for Identifying Human Activities - Robotics Institute Carnegie Mellon University, https://publications.ri.cmu.edu/storage/publications/pub_files/pub4/seo_young_woo_2006_2/seo_young_woo_2006_2.pdf
27. Autonomous Systems (AS)The DixonsOmer, Konstantinou, Dixon, Dimitriana, Eysa - Gamma, https://gamma.app/docs/Autonomous-Systems-ASThe-DixonsOmer-Konstantinou-Dixon-Dimitriana-kyoccd2k2833gw8
28. Thinking about programs from a mathematical perspective to verify their correctness | CNCF, https://www.cncf.io/blog/2023/03/08/thinking-about-programs-from-a-mathematical-perspective-to-verify-their-correctness/
29. ASTM F3269 - An Industry Standard on Run Time Assurance for Aircraft Systems, https://arc.aiaa.org/doi/10.2514/6.2021-0525
30. IEEE 7000-2021 - IEEE SA, https://standards.ieee.org/standard/7000-2021.html
31. Ieee Sa | PDF | Patent | System - Scribd, https://www.scribd.com/document/991192691/IEEE-SA
32. Introducing Capabilities · ocaps - GitHub Pages, https://tersesystems.github.io/ocaps/guide/introduction.html
33. Run Time Assurance for Safety-Critical Systems - Sam Coogan - Georgia Tech, https://coogan.ece.gatech.edu/papers/pdf/hobbs2022csm.pdf
34. Dempster–Shafer theory - Wikipedia, https://en.wikipedia.org/wiki/Dempster%E2%80%93Shafer_theory
35. The seL4 Microkernel An Introduction - Hackaday.io, https://cdn.hackaday.io/files/1713937332878112/seL4-whitepaper.pdf