Reference · v2.0.0 · Reference Implementation

AetherRuntime

A Falsification-First Investigation of Runtime Assurance in the Aether Family

A structured investigation of whether a runtime-assurance gap genuinely exists in the Aether family, or whether it is already covered by AetherFlow (post-merge verification), AetherProof (specifications), or AetherGovern (authority). v2.0.0 adds a reference implementation (16 modules, 60 tests, 3 experiments) alongside the v0.1.0 hypothesis.

Python Modules

Tests Passing

Experiments

Failure Conditions

Installation

# From PyPI (published)
pip install aetherruntime-arch

# From source (development)
git clone https://github.com/gitdeeper15/aetherruntime.git
cd aetherruntime
pip install -e ".[dev]"

# Run tests
pytest

# Run experiments
python experiments/detection_accuracy/run.py
python experiments/halt_window/run.py
python experiments/recovery_correctness/run.py

# CLI
aetherruntime info
aetherruntime verify

Note: The PyPI package (2.0.0) is the reference implementation. It is not a production system. The v0.1.0 paper remains the authoritative hypothesis record.

Project

Field	Value
Full title	AetherRuntime: A Falsification-First Investigation of Runtime Assurance in the Aether Family
Subtitle	A Falsification-First Investigation of Monitoring, Detection, Containment, and Recovery in Multi-Agent Software Ecosystems
Version	2.0.0 (Reference Implementation) + 0.1.0 (Formal Architecture)
Stage	Reference Implementation with Reproducible Experiments
License	MIT (code) · CC-BY-4.0 (docs, manuscript)
Domain	Distributed Systems / Software Engineering / Institutional Analysis
DOI (Zenodo)	10.5281/zenodo.24078477
DOI (Figshare)	10.6084/m9.figshare.34955746
OSF	10.17605/OSF.IO/KZU7P
PyPI	aetherruntime-arch 2.0.0 (published)
Record ID	AETHERRUNTIME-02

Central Question

Is there a body of monitoring, detection, containment, halt, and recovery requirements for multi-agent software ecosystems that (i) is not already specified by the five existing dimensions, (ii) is not reducible to verification or to governance, (iii) can be specified without reintroducing a central authority, and (iv) yields an observable benefit over existing mechanisms?

The Six Functional Dimensions

#	Dimension	Focus	Question
1	AetherGit	Storage and versioning	How are changes stored and versioned?
2	AetherFlow	Integration and operational verification	How are changes integrated and verified?
3	AetherProof	Specification and structured evidence	How is correctness proven?
4	AetherMesh	Distribution and eventual consistency	How is state synchronized without a central coordinator?
5	AetherGovern	Authority and policy	Who is authorized to do what, under which policy?
6	AetherRuntime (hypothesis)	Monitoring and runtime assurance	Are agents behaving acceptably while running?

Figure 1 — The Six Functional Dimensions of the Aether Family

Figure 1 — The Six Functional Dimensions of the Aether Family. The sixth dimension (AetherRuntime) is a hypothesis under investigation, not a confirmed dimension.

Failure Conditions F1–F5

ID	Claim under test	Status
F1	Non-redundancy	Not falsified (R3, R4, R5)
F2	Orthogonality to verification	Not falsified (narrowly)
F3	Boundary with governance	Not falsified (decentralized setting)
F4	Decentralizability	Not falsified (with residuals)
F5	Observable benefit	Untested

"Not falsified" is a weaker status than "confirmed". F5 (observable benefit) is untested. The paper does not promote "not falsified" to "confirmed".

Propositions

#	Proposition	Status
P1	Determinism of Local Anomaly Detection	Proof sketch · implemented in code
P2	Irreducible Halt Window	Proof sketch · implemented in code

Both propositions are stated with proof sketches; neither is machine-checked. They bear on F4 (decentralizability). Both are implemented in the reference implementation (v2.0.0) and covered by the test suite.

The Five Runtime Layers

Layer	Question	Status
1 — Monitoring	What is the agent doing?	Implemented
2 — Detection	Is this behaviour anomalous?	Implemented
3 — Containment	How do we isolate the agent?	Implemented
4 — Halt	How do we stop the agent?	Implemented
5 — Recovery	How do we restore the system?	Implemented

Figure 2 — The Five Layers of AetherRuntime

Figure 2 — The five layers of AetherRuntime (hypothesis). Ordering reflects conceptual dependency, not an enforcement hierarchy.

Figure 3 — The Runtime Lifecycle

Figure 3 — The runtime lifecycle in AetherRuntime (hypothesis): observe, detect, classify, contain, halt, recover.

Figure 4 — Anomaly Detection

Figure 4 — The central challenge: distinguish true anomalies (red) from benign deviations (orange) without excessive false positives.

Figure 5 — Runtime Assurance vs. Verification

Figure 5 — Runtime assurance versus verification in the Aether family. Orthogonality is a hypothesis tested as failure condition F2.

Figure 6 — Runtime State Machine

Figure 6 — The runtime state machine. Each state has defined entry and exit conditions; exception transitions (dashed) represent recovery paths.

v2.0.0 Experimental Results

#	Experiment	Result
1	Detection Accuracy (M1, M2)	M1 = 109.67 (S1–S5 total); M2 = 7.33 (S6 false positives)
2	Halt Window (M5)	10/10 enforced; mean window = 0.000243 s; median = 0.000220 s
3	Recovery Correctness (M6)	10/10 verified; M6 = 1.0000

Important: These are simulation results. The halt window is a property of the simulation's time step, not a real network measurement. M6 = 1.0 is a ceiling on real recovery quality, not a lower bound. See the full evaluation report.

Status note (v2.0.0): This is a reference implementation (v2.0.0) of the falsification-first runtime-assurance architecture specified in v0.1.0. 16 modules, 60 tests, 3 experiments. No real-world deployment has been evaluated. F1–F4 are not falsified by argument, with residual weaknesses. F5 (observable benefit) is untested. Propositions P1–P2 remain proof sketches (not machine-checked), though they are implemented in code. The final project structure (single, dual, triple, or quadruple) is undetermined. The paper is not peer reviewed.