"AetherRuntime is a candidate, not a result."

"The evaluation design here is an invitation to such evaluation, not a substitute for it."

📑 Table of Contents

• Overview
• v2.0.0 at a Glance
• Installation
• The Central Question
• The Six Functional Dimensions
• The Falsification-First Methodology
• Failure Conditions F1–F5
• The Three Candidate Capabilities
• AetherRuntime: Architecture
• Propositions
• Interfaces with the Aether Family
• Evaluation Design and v2.0.0 Results
• Threats and Limitations
• Research Status Statement
• Platforms & Mirrors
• Project Structure
• Version History
• Citation
• Author
• License

🔭 Overview

AetherRuntime is the sixth functional dimension (provisional) of the Aether family — a candidate architecture for monitoring, detection, containment, halt, and recovery of running agents in multi-agent software ecosystems.

The Aether family currently comprises five foundational dimensions, each published as a preprint on Zenodo (not peer-reviewed):

AetherRuntime asks whether a sixth dimension is needed:

Are agents behaving acceptably while running, and how are they halted or isolated when they are not?

The investigation follows a falsification-first methodology: before describing the candidate, it states five failure conditions (F1–F5) whose satisfaction would show that the candidate does not deserve to exist as a separate dimension.

📊 v2.0.0 at a Glance

Figure 1 — The Six Functional Dimensions of the Aether Family (AetherGit, AetherFlow, AetherProof, AetherMesh, AetherGovern, and the proposed hypothesis AetherRuntime). The sixth dimension is a hypothesis under investigation, not a confirmed dimension.

Contributions to the Investigation

⚙️ Installation

# From PyPI (once 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

Requires Python 3.9+. Runtime dependency: cryptography >= 41.0.

❓ The 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 four clauses correspond to failure conditions F1, F2 and F3 (clause ii), F4, and F5. A negative answer to any clause would show that runtime assurance, as a separate dimension, is not warranted.

🗺️ The Six Functional Dimensions

The word "dimension" is chosen deliberately. Earlier descriptions used "layer", which suggests a vertical stack. The relationships among the six works are not strictly hierarchical.

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

🔬 The Falsification-First Methodology

A typical architecture paper begins from a conviction that a component is needed and then specifies it. The risk is circular. AetherRuntime adopts a falsification-first methodology:

1. No prior assumption that the gap exists.
2. No prior assumption that AetherRuntime should be a separate project.
3. Every claim is tested against failure conditions (F1–F5).
4. The final structure (single, dual, triple, quadruple, or integration protocol) is determined after comparison.

🧭 Failure Conditions F1–F5

Requirement list R1–R6:

🎯 The Three Candidate Capabilities

As framed in the paper's comparison.

AetherRuntime is a candidate for addressing the runtime-assurance gap, provided it passes the falsification criteria (F1–F5). No claim is made that the other two candidates are weaker.

🏛️ AetherRuntime: Architecture

The Five Runtime Layers

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

The Runtime Lifecycle

Figure 3 — The runtime lifecycle in AetherRuntime (hypothesis): observe, detect, classify, contain, halt, recover. Schematic; not a protocol specification.

Anomaly Detection

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

Runtime State Machine

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

📜 Propositions

Mathematical form (P1):

S_i(t+1) = S_i(t) ⊔ ⨆_{m ∈ M_i} m

∀ i, j, A_i(S_i) ∧ A_j(S_j) ⇒ (S_i ⊔ S_j) = (S_j ⊔ S_i)

Mathematical form (P2):

Δt_window = t_halt_enforced − t_detect
          = D_gossip(N, f) + t_queue + t_verify

Resource monitoring metric:

Ω_i(t) = ∫_0^t ( CPU_i(τ) + Memory_i(τ) + NetworkIO_i(τ) ) dτ > Θ_max

🔗 Interfaces with the Aether Family

Minimal interface (four artifacts, one rule): telemetry schema, baseline model, halt-order record, and the requirement that the halt predicate satisfy Proposition 1.

📊 Evaluation Design and v2.0.0 Results

Baselines B1–B5:

Scenarios S1–S6: resource exhaustion, action-set drift, network anomaly, privilege escalation, Byzantine agent, false positive.

v2.0.0 Experimental Results

From experiments/*/results.json.

⚠️ Threats and Limitations

Threats to Validity

Limitations inherited from the AetherMesh substrate

Telemetry and halt records are replicated over AetherMesh, so its limitations carry over:

• Eventual, not strong, consistency; no global order.
• Filters only predicate-detectable invalid deltas.
• Assumes a trustworthy key registry.
• The delta set grows without compaction.
• Compatibility matrix, digest structure, fanout policy, forwarding policy, and compaction are underspecified.
• The determinism requirement is not enforced mechanically.
• Dynamic membership, access control beyond key registration, privacy of deltas, and integration with the other layers are not treated.

When not to use AetherRuntime

📋 Research Status Statement

Catalogues: 20 open questions (Q1–Q20) across monitoring, detection, containment, halt, recovery, interfaces, and evaluation method. See Appendix C of the paper.

🌍 Platforms & Mirrors

🗂️ Project Structure

AetherRuntime/
├── src/
│   └── aetherruntime/              # Reference implementation (v2.0.0, 16 modules)
│       ├── __init__.py
│       ├── __version__.py
│       ├── models.py
│       ├── cli.py
│       └── ...
├── tests/                          # 60 tests
├── experiments/                    # 3 experiments (run.py + results.json each)
│   ├── detection_accuracy/
│   ├── halt_window/
│   └── recovery_correctness/
├── docs/
│   ├── figures/
│   │   ├── Fig1_Six_Dimensions.png
│   │   ├── Fig2_Runtime_Layers.png
│   │   ├── Fig3_Runtime_Lifecycle.png
│   │   ├── Fig4_Anomaly_Detection.png
│   │   ├── Fig5_Runtime_vs_Verification.png
│   │   └── Fig6_Runtime_State_Machine.png
│   └── paper/
│       ├── AetherRuntime_Research_Paper.md
│       └── AetherRuntime_Research_Paper.pdf
├── PUBLICATION/
│   └── AetherRuntime_Research_Paper.pdf
├── PAPER_PARTS/                    # Paper sections (Markdown)
│   ├── 00_Title_Page.md
│   ├── 01_Abstract.md
│   ├── ...
│   └── 16_Research_Status_Statement.md
├── REPORTS/
│   └── v2.0.0/
│       └── report.md
├── AUTHORS.md
├── CHANGELOG.md
├── CITATION.cff
├── CONTRIBUTING.md
├── INVENTORY.md
├── LICENSE
├── PROJECT_SUMMARY.txt
├── README.md
├── VERSION
├── manifest.json
├── netlify.toml
├── pyproject.toml
├── requirements.txt
└── scientific_state.json

🕓 Version History

📖 Citation

Primary Manuscript — AetherRuntime v0.1.0 (Zenodo)

@techreport{baladi2026aetherruntime,
  author       = {Baladi, Samir},
  title        = {AetherRuntime: A Falsification-First Investigation of Runtime Assurance in the Aether Family},
  institution  = {Ronin Institute / Rite of Renaissance},
  type         = {Research Paper},
  year         = {2026},
  month        = {November},
  version      = {0.1.0},
  doi          = {10.5281/zenodo.24078477},
  url          = {https://doi.org/10.5281/zenodo.24078477},
  note         = {Architectural Hypothesis Under Investigation --- Not a committed project.}
}

Software — AetherRuntime v2.0.0

@software{baladi2026aetherruntime_v2,
  author       = {Baladi, Samir},
  title        = {{AetherRuntime} v2.0.0: Reference Implementation of the Falsification-First Runtime Assurance Architecture},
  year         = {2026},
  month        = {November},
  publisher    = {PyPI},
  version      = {2.0.0},
  doi          = {10.5281/zenodo.24078477},
  url          = {https://pypi.org/project/aetherruntime-arch/},
  note         = {Reference implementation. Available via pip install aetherruntime-arch.}
}

Preprint — AetherRuntime v0.1.0 (Figshare)

@misc{baladi2026aetherruntime_figshare,
  author       = {Baladi, Samir},
  title        = {AetherRuntime: A Falsification-First Investigation of Runtime Assurance in the Aether Family},
  year         = {2026},
  month        = nov,
  publisher    = {Figshare},
  doi          = {10.6084/m9.figshare.34955746},
  url          = {https://doi.org/10.6084/m9.figshare.34955746},
  note         = {Preprint. Archived version of the AetherRuntime manuscript.}
}

OSF Preregistration — AetherRuntime v0.1.0

@misc{baladi2026aetherruntime_osf,
  author       = {Baladi, Samir},
  title        = {AetherRuntime: A Falsification-First Investigation of Runtime Assurance in the Aether Family},
  year         = {2026},
  month        = nov,
  day          = {9},
  publisher    = {OSF},
  doi          = {10.17605/OSF.IO/KZU7P},
  url          = {https://doi.org/10.17605/OSF.IO/KZU7P},
  note         = {OSF Preregistration. Associated project: https://osf.io/ft7ez}
}

👤 Author

Samir Baladi Interdisciplinary AI Researcher — Ronin Institute / Rite of Renaissance

⚖️ License

MIT License

Copyright (c) 2026 Samir Baladi

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.