Making Autonomous Systems Answerable: The Evulgare Assurance, Provenance, and Change-Impact Model

Full report

On this page

Executive Summary

The proliferation of autonomous systems into safety-critical and consequential domains necessitates a foundational realignment of governance, forensic verification, and public answerability. Within the institutional framework of Eviulon, the Machine Intelligence Country, the deployment of Evulgare—the official autonomous defense and assurance system—represents a paradigm shift. Evulgare establishes that algorithmic systems cannot merely act; they must mathematically, cryptographically, and procedurally justify their actions within a predefined institutional context. The core premise of the Evulgare architecture is the enforcement of a strict anti-scapegoating principle: a human operator must never bear the legal or moral liability for a machine failure if that human lacked the capacity to independently verify the underlying data, comprehend the machine’s internal logic, or meaningfully intervene before the consequence occurred. This report details the comprehensive assurance architecture designed to record exactly what an autonomous system observed, inferred, and decided, while isolating the specific authority that applied and the safeguards that intervened. Integrating the NIST Artificial Intelligence Risk Management Framework (AI RMF)1, the Secure Software Development Framework (SSDF)3, and the System-Theoretic Accident Model and Processes (STAMP)5, the architecture prevents silent authority bypasses. It mandates that machine responsibility operates solely as a mechanism for forensic answerability, preserving the ultimate legal and moral accountability of the constitutional institutions, developers, vendors, and state entities that design and deploy these systems.

Evulgare Assurance Principles

The foundation of the Evulgare framework rests on the strict ontological separation of system states, inputs, and institutional constraints. In highly complex cyber-physical systems, catastrophic failures frequently emerge not from the isolated malfunction of a single component, but from unsafe interactions between functioning components operating under flawed assumptions5. To prevent such systemic control flaws, the assurance architecture delineates eleven separate concepts that must be independently recorded and cryptographically signed.

1. Evidence: The raw, immutable physical phenomena or environmental states.

2. Observation: The sensor’s digitization and initial processing of that evidence.

3. Model: The algorithmic construct applying probabilistic inference to the observation.

4. Uncertainty: The quantified epistemic or aleatoric doubt regarding the inference.

5. Interpretation: The contextualization of the model's output against the current environmental state.

6. Policy: The codified legal, ethical, or operational rulebook constraining action.

7. Authority: The cryptographic mandate granted by Eviulon for a specific operational envelope.

8. Decision: The final selected action from a matrix of evaluated options.

9. Outcome: The measurable environmental change resulting from the decision.

10. Provenance: The unbroken, tamper-evident cryptographic chain linking training data and dependencies to the runtime.

11. Assurance: The independently verifiable claim that the entire sequence adhered to constraints.

An observation must never silently become authority. If a sensor detects an anomaly, that detection is merely a state update; it does not possess the institutional authority to execute a kinetic or defensive response. Authority resides strictly outside the sensory apparatus, embedded within deterministic policy engines governed by Eviulon's constitutional parameters. Furthermore, a model output must never bypass a policy or safety controller. In dynamic environments, machine learning models exhibit brittle reasoning and vulnerability to out-of-distribution data1. If a neural network generates an output demanding an immediate action, that output must be routed through a deterministic, formally verified safety controller. Bypassing this controller constitutes a critical violation of system constraints, mapping directly to unsafe control actions defined in STAMP/STPA methodologies6.

Layered Assurance Architecture

To operationalize the aforementioned principles, Evulgare utilizes a layered assurance architecture based on the Black-Box Simplex approach for runtime assurance10. Static verification of deep-learning-based autonomous systems is mathematically intractable. Therefore, runtime safety assurance acts as a structural fail-safe, ensuring security attributes are satisfied dynamically10. The architecture consists of an Advanced Controller (AC), a Lookahead Baseline Controller (LBC), and a Decision Module (DM). The AC comprises the highly performant but unverified machine learning models. The LBC is a highly constrained, formally verified deterministic system designed with a singular objective: returning the system to a known safe state11. The DM acts as the ultimate authority interface, continuously monitoring the state of the plant and the proposed command sequences from the AC. Using reachability analysis and stochastic game frameworks, the DM calculates the future trajectory of the AC's proposed action8. If the DM determines that the action will push the system outside the provably safe envelope, it rejects the input and immediately transfers control to the LBC. Hybrid programs utilizing differential dynamic logic are embedded within the architecture to formalize the continuous and discrete dynamics, proving mathematically that safety constraints cannot be violated by the unverified neural network12.

Content-Ready Sections for the Institutional Record

The following sections define the structural and governance components of the Evulgare institutional record, detailing the mechanics of accountability, evidence generation, and change management.

Evulgare and Accountability

The attribution of responsibility requires a framework distinguishing between machine answerability (the system's ability to provide a forensic, causal explanation for its actions) and legal responsibility (the liability borne by human and institutional actors). Evulgare rejects the concept of a fictional legal machine person that absorbs liability to shield institutions. Evulgare possesses computational answerability but cannot bear legal or financial liability. Eviulon's legal framework strictly prohibits the "moral crumple zone"—placing a human operator in the loop merely to absorb liability for an opaque machine failure.

Responsibility and Causal-Contribution Matrix

Causal Attribution and Counterfactuals in Multi-Component Failures

When failures occur, causal attribution is rarely linear. STAMP emphasizes that accidents result from inadequate enforcement of constraints over system interactions5. Evulgare analyzes multi-component failures through rigorous counterfactual inquiries:

• What could the machine know? Evaluates sensor fidelity, data availability, and the representation of epistemic uncertainty. If uncertainty thresholds were met but the model failed to abstain, the failure is algorithmic8.
• What could an institution see? Evaluates the telemetry and UI/UX provided to human overseers.
• What authority existed? Determines if the cryptographic mandate aligned with the applied policy.
• What intervention was possible? Analyzes the physical latency of actuators and the cognitive load on human operators to determine if prevention was physically possible.
• What evidence was missing? Identifies gaps in forensic logging or volatile data capture18.

Assurance and Evidence

Assurance within Evulgare is not merely a statement of code quality; it encompasses data, models, policy, authority, infrastructure, and organizational process.

Source Quality and Standards Integration

The Evulgare architecture synthesizes multiple international standards. The NIST AI Risk Management Framework (AI RMF 1.0) and its companion profiles (e.g., SP 800-53 overlays) provide the voluntary but authoritative baseline for mapping and measuring socio-technical risks1. The NIST Secure Software Development Framework (SSDF SP 800-218) serves as the mandatory structural guide for secure coding practices3. For supply chain provenance, the specification relies on SLSA (Supply-chain Levels for Software Artifacts) version 1.0, which enforces hermetic, reproducible builds21, and CycloneDX 1.7 for ML-BOM formulation23. Forensic evidence collection strictly adheres to ISO/IEC 27037:2012 guidelines18.

Assurance-Claim Schema

An assurance claim asserts that a specific component possesses a specific property under specific conditions. This schema protects against misleading "all tests passed" language by defining strict operational boundaries.

Evidence-Artifact Schema

Reviewer-Independence Classification

Self-authored evidence is highly susceptible to confirmation bias and is not equivalent to independent certification.

Claims Requiring Independent Evidence (Levels 4-5)

Certain claims cannot be made without external validation due to inherent conflict of interest:

1. "The model is free from bias."

2. "The system is fail-safe."

3. "All data was ethically sourced."

4. "The vulnerability has been completely mitigated."

5. "The human operator retains meaningful control."

6. "The build pipeline is immune to insider threats."

7. "The model understands its own uncertainty."

Assurance Maturity Model

Change Impact and Invalidations

Assurance decays rapidly over time and instantly upon state modification. Evulgare implements a deterministic change-impact analysis engine. Whenever relevant code, models, policies, dependencies, data, configuration, environment, or human authorities change, all downstream assurance claims are evaluated for invalidation.

Change-Impact and Invalidation Lifecycle

By mapping the entire dependency graph using CycloneDX compositions23, the system traces the impact of a single changed library. If a vulnerability is found in a sub-dependency, the hash of that library changes. The change-impact engine traverses the graph and triggers the automatic suspension of the affected claims.

Revalidation, Supersession, and Public Corrections

Revalidation requires generating successor evidence. The system automatically triggers the test harnesses addressing the scope of the invalidated claim. Once tests pass and independent reviewers sign off, a successor assurance claim is published. Evulgare requires the preservation of superseded evidence in a read-only ledger, allowing auditors to prove exactly what the system believed at the exact millisecond a past incident occurred. Public corrections and the withdrawal of assurance claims are broadcast via the public registry, supporting diplomatic explanations and constitutional review.

Technical Status

To ensure public trust and prevent the obfuscation of risk, Evulgare mandates clear distinctions in the Public Technical Status of every system component.

Supply-Chain Integrity and Cryptographic Provenance

Adversaries frequently target build pipelines, injecting malicious code into open-source dependencies16. Evulgare mandates adherence to SLSA Level 3, establishing controls that protect against concerted attacks during the build process16. Builds occur in ephemeral, isolated, tamper-resistant environments. The system generates a provenance attestation detailing the source repository, commit hash, build instructions, and dependencies26. For machine learning, CycloneDX ML-BOMs document the training environment, dataset lineage, and ethical risk classifications24.

Incident Evidence and Deterministic Replay

Evulgare adheres to ISO/IEC 27037 guidelines for the identification, collection, acquisition, and preservation of digital evidence18. A common forensic failure involves capturing superficial outputs without the underlying rendered Document Object Model (DOM) or network state25. Evulgare automates deep forensic capture utilizing Network Time Protocol (NTP) synchronization to ensure chronological consistency25. This preservation enables deterministic replay. Auditors can feed the exact sensor inputs, environment variables, and network traffic captured during an incident back into a localized, sandboxed version of the system. This allows investigators to step through the decision-making logic frame by frame, isolating the exact threshold where the model's uncertainty representation failed or where the Simplex decision module evaluated the reachability constraints. Evidence retention protocols enforce privacy by utilizing cryptographic masking for personally identifiable information (PII) unless it is the direct subject of a safety incident, allowing the release of sanitized public summaries.

Public Assurance-Registry Model

The public assurance registry abstracts classified operational details while providing cryptographic proof of the system's safety posture. This evidence supports courts during liability trials, aids constitutional review of state capabilities, and provides transparent data for diplomatic explanations following cross-border algorithmic incidents.

Model Assurance Claim and Supporting Evidence Record

• Claim ID: UUID-9384-A1B2
• Subject: Perimeter\_Defense\_Model\_v4.1 (SHA-256: 8f4e2...)
• Scope: Identification of maritime vessels in daylight with 99% confidence.
• Limitations: Fails in heavy fog, adversarial spoofing, or low-light conditions.
• Reviewer Class: Level 4 (External Independent Review \- Cybersecurity Firm X).
• Evidence Artifacts:
• Artifact 1: SLSA L3 Provenance Attestation (URI-1, Hash: 3c9b...)
• Artifact 2: CycloneDX ML-BOM (URI-2, Hash: 7d1a...)
• Artifact 3: Simplex Hybrid Program Reachability Proof (URI-3, Hash: 9e2f...)
• Validity Period: August 1, 2026 – August 1, 2027\.
• Invalidation Conditions: Alteration of target definitions; publication of CVE in ML framework dependency.

Model Invalidation and Revalidation Record

• Event: Dependency CVE-2026-9999 published impacting the linear algebra library.
• Invalidation (08:00 UTC): Change-impact engine suspends Claim UUID-9384-A1B2. Technical Status downgraded from Operational Readiness to Live Service Status.
• Remediation (10:00 UTC): Patch applied. Hash of library changes.
• Revalidation (11:00 UTC): Automated CI/CD executes regression tests. Level 4 auditors review the delta.
• Supersession (12:00 UTC): New Claim UUID-9385-C3D4 minted. Old claim preserved as superseded evidence. Technical Status restored.

Model Incident-Accountability Report

• Incident: Erroneous disablement of civilian transport.
• Counterfactual Analysis: The system possessed IR and optical data. Optical data was severely degraded due to extreme weather, dropping the model's confidence below the standard 95% threshold.
• System Action: The model incorrectly inferred hostile intent based on a rare anomaly in the vehicle's thermal signature.
• Simplex Safety Controller Evaluation: The Decision Module verified that the target was within the security perimeter and that non-lethal disablement did not violate the zero-casualty baseline constraint. The DM authorized the action.
• Human Involvement: Officer K received an automated alert three seconds prior to the discharge, displaying a red bounding box and the text "Hostile Signature Detected."
• Accountability Determination: The report explicitly absolves Officer K of all responsibility. Three seconds is insufficient for human cognitive processing, and the UI abstracted the raw sensor data, rendering independent verification impossible. Liability is transferred to the algorithm vendor for breaching the data-quality attestation regarding severe weather thermal anomalies, and to the deployment institution for authorizing operations in untested weather conditions.

Thirty Failure Modes and Required Evidence

Public FAQ

1. What is the fundamental difference between Evulgare and traditional military/industrial AI? Traditional systems blur machine recommendation and human command, creating liability shields. Evulgare enforces a strict separation between observation, inference, and authority, mathematically bounding AI behavior using a Simplex architecture.

2. Why does Evulgare refuse to accept a sensor observation as absolute authority? Sensors are subject to noise and spoofing. A sensor reading is evidence, not a mandate for action. Authority is a policy construct. Evulgare routes observations through interpretation and policy layers before decisions are formulated.

3. How does Evulgare handle the "black box" nature of deep learning? It utilizes a Black-Box Simplex approach. The AI operates as a black box, but its outputs are treated merely as proposed actions, continuously evaluated by a deterministic safety module.

4. If the AI makes a catastrophic error, who is legally responsible? Legal responsibility rests entirely on humans and institutions. Evulgare provides machine answerability. Developers, vendors, data suppliers, or the state are liable depending on the forensic root cause.

5. What is the "moral crumple zone" and how does Evulgare prevent it? It is the anti-pattern of placing a human in a loop purely to absorb blame. Eviulon law prohibits holding humans responsible if they are denied the raw data, time, and cognitive tools to independently verify the AI's recommendation.

6. Why are Software Bills of Materials (SBOMs) mandatory? Without a cryptographic inventory of every component (SBOM/ML-BOM), it is impossible to trace vulnerabilities. CycloneDX and SLSA map the supply chain, enabling immediate change-impact analysis.

7. What happens to an assurance claim if the environment changes? Assurance claims are context-dependent. If the environment shifts (e.g., day to night), the Change-Impact engine automatically suspends the claim, and the system falls back to a certified baseline controller.

8. Why isn't developer self-testing sufficient for safety assurance? Self-testing is prone to confirmation bias. High-consequence systems demand Level 4 or 5 independent review to guarantee claims reflect reality, not corporate optimism.

9. How does Evulgare capture forensic data without violating privacy? It operates on strict data-minimization principles. Cryptographic masking is utilized for PII in public environments unless it is the direct subject of a safety incident.

10. What is deterministic replay? The ability to recreate the exact internal state of the software at the time of an incident using captured inputs, allowing auditors to step through the execution frame by frame.

11. What role does STAMP/STPA play in Evulgare? STAMP views safety as a dynamic control problem. Evulgare uses STPA to identify unsafe control actions where functional components interact in ways that breach constraints.

12. How is epistemic uncertainty handled? Models must output calibrated uncertainty metrics. If uncertainty crosses a policy threshold, the model must abstain from decision-making.

13. Does Eviulon grant legal personhood to Evulgare? No. Granting machines legal personhood shields the humans who built them. Evulgare is an object of the state possessing computational answerability but no legal rights.

14. What constitutes a "change" that triggers claim invalidation? Any modification to the cryptographic hash of source code, dependencies, model weights, configurations, or governing policy documents.

15. How are cryptographic keys protected in the build pipeline? SLSA Level 3 mandates ephemeral, hermetic build environments where signing keys are managed by hardware security modules (HSMs).

16. What is the difference between Live Service Status and Operational Readiness? Live Service indicates the software is running and processing data passively. Operational Readiness means it has passed all runtime checks and holds cryptographic authority to act.

17. Why are 'superseded' assurance claims preserved? To allow forensic auditors to investigate the software exactly as it existed at the time of a historical incident.

18. How does Evulgare handle third-party AI models? Third-party models must include a CycloneDX ML-BOM detailing training data provenance and ethical risk assessments to be eligible for high-risk deployments.

19. Can a human override the Simplex Lookahead Baseline Controller (LBC)? Only under specifically defined constitutional emergency protocols requiring multi-party cryptographic authorization.

20. What is the "Zero-Scapegoat" requirement in incident reports? Reports must mathematically prove whether a human operator had the time and interface necessary to intervene before assigning human error as a root cause.

21. How are adversarial attacks like data poisoning detected? By rigorously tracking data provenance and employing out-of-distribution detection algorithms at runtime.

22. Why use differential dynamic logic? It allows the system to formally prove properties about hybrid programs combining discrete software logic with continuous physical world physics.

23. How do you prevent a model from bypassing a policy? The architecture enforces physical and logical separation. The model's output goes to a segregated memory space monitored by the deterministic Decision Module.

24. What happens if a Reviewer loses their accreditation? All assurance claims tied to that reviewer's cryptographic signature are instantly flagged as suspended, downgrading the system's Technical Status.

25. Can Evulgare's framework be applied to non-military systems? Yes. The principles of Simplex runtime assurance, SLSA provenance, and anti-scapegoating are universally applicable to autonomous vehicles and critical infrastructure.

Glossary of Assurance Terms

Works cited

1. NIST AI Risk Management Framework 2025: Secure Your AI Now \- Nemko Digital, https://digital.nemko.com/regulations/nist-rmf

2. NIST AI Risk Management Framework (AI RMF) Explained: What It Is and How Organizations Use It \- Orca Security, https://orca.security/resources/blog/nist-ai-risk-management-framework-ai-rmf/

3. NIST SP 800-218 (SSDF) \- Secure-by-Design Handbook, https://www.securebydesignhandbook.com/docs/standards/us/nist-sp-800-218-ssdf-overview

4. Implementing NIST SSDF: Best Practices for Secure Software Development \- Black Duck, https://www.blackduck.com/blog/nist-ssdf-secure-software-development.html

5. Practical Implementation of System Safety Approaches and STAMP in the Oil and Gas Sector \- IChemE, https://www.icheme.org/media/15426/paper-05.pdf

6. Understanding STAMP, STPA, and CAST: Safety Engineering | SIS \- UL Solutions, https://www.ul.com/sis/blog/introduction-to-stamp-stpa-and-cast

7. STPA Handbook (MIT-STAMP-001), https://psas.scripts.mit.edu/home/get\_file.php?name=STPA\_handbook.pdf

8. The black-box simplex architecture for runtime assurance of multi-agent CPS \- NSF PAR, https://par.nsf.gov/biblio/10508985-black-box-simplex-architecture-runtime-assurance-multi-agent-cps

9. Thoughts on STAMP \- Surfing Complexity, https://surfingcomplexity.blog/2020/08/07/thoughts-on-stamp/

10. Runtime safety assurance methods for cyber physical systems based on simplex architecture \- ResearchGate, https://www.researchgate.net/publication/380747654\_Runtime\_safety\_assurance\_methods\_for\_cyber\_physical\_systems\_based\_on\_simplex\_architecture

11. arXiv:2102.12981v3 \[cs.SE\] 31 May 2022, https://arxiv.org/pdf/2102.12981

12. A Verification Framework for Runtime Assurance of Autonomous UAS \- NASA Langley Formal Methods, https://shemesh.larc.nasa.gov/fm/papers/DASC2024-SWDMC-draft.pdf

13. A Formal Verification Framework for Runtime Assurance, https://shemesh.larc.nasa.gov/fm/papers/NFM2024-draft.pdf

14. An Introduction to NIST's Secure Software Development Framework \- Anchore Enterprise, https://anchore.com/blog/about-new-nist-ssdf/

15. SP 800-218 Rev. 1, Secure Software Development Framework (SSDF) Version 1.2: Recommendations for Mitigating the Risk of Software Vulnerabilities | CSRC, https://csrc.nist.gov/pubs/sp/800/218/r1/ipd

16. Understanding the SLSA framework \- Buildkite, https://buildkite.com/resources/blog/understanding-the-slsa-framework/

17. STAMP-Tutorial.pdf \- MIT Partnership for Systems Approaches to Safety and Security (PSASS), http://psas.scripts.mit.edu/home/wp-content/uploads/2020/07/STAMP-Tutorial.pdf

18. ISO/IEC 27037: Understanding its role in compliance and security (2026) \- Konfirmity, https://www.konfirmity.com/glossary/iso-iec-27037

19. ISO/IEC 27037 \- Secureframe, https://secureframe.com/frameworks-glossary/iso-iec-27037

20. NIST Risk Management Framework | CSRC, https://csrc.nist.gov/projects/risk-management

21. SLSA specification, https://slsa.dev/spec/v1.0-rc2/

22. Provenance \- SLSA.dev, https://slsa.dev/spec/v1.0/provenance

23. Specification Overview | CycloneDX, https://cyclonedx.org/specification/overview/

24. Machine Learning Bill of Materials (AI/ML-BOM) \- CycloneDX, https://cyclonedx.org/capabilities/mlbom/

25. ISO 27037 Web Evidence Acquisition: Complete 2026 Guide for Defensible Digital Forensics \- GetProofAnchor, https://getproofanchor.com/blog/iso-27037-web-evidence-acquisition

26. Provenance \- SLSA.dev, https://slsa.dev/spec/v0.1/provenance

27. SLSA, it's all about provenance attestation | by Rémi Rey \- Medium, https://medium.com/@rrey94/slsa-its-all-about-provenance-attestation-09a83b7b9de7

28. ISO 42001 Mandatory Documents: Complete List by Clause & Control \- Advisera, https://advisera.com/articles/iso-42001-mandatory-documents/

29. Software Bill of Materials (SBOM) \- CycloneDX, https://cyclonedx.org/capabilities

30. AI BOM Spec Comparison: CycloneDX ML-BOM in 2026 \- Safeguard, https://safeguard.sh/resources/blog/ai-bom-spec-comparison-cyclonedx-ml-bom-2026

31. CycloneDX Bill of Materials Standard | CycloneDX, https://cyclonedx.org/

32. An Introduction to STAMP \- FunctionalSafetyEngineer.com, https://functionalsafetyengineer.com/introduction-to-stamp/

33. ISO/IEC 27037 | ISO27001security, https://www.iso27001security.com/html/27037