Status: Normative — authoritative statement of what aegis-lab is and what it is permitted to do.
Operational reference: aegis-ops/hosts/aegis-lab/ (private).
Purpose
aegis-lab is a laboratory environment for AEGIS development, controlled experimentation, and the first AEGIS-governed deployment. It is not production infrastructure. It exists to let the AEGIS Initiative:
- Run AEGIS runtime components against real agent workloads on real hardware.
- Reproduce the failure modes catalogued by studies like Agents of Chaos (Shapira et al., 2026) with AEGIS governance at the execution boundary, and observe whether that governance actually prevents them.
- Stage the reference deployment pattern (RDP-03) end-to-end before anything graduates to a production environment.
- Document decisions in sufficient detail that the environment is reproducible, auditable, and safe to reason about months later.
Design principles
These principles have governed the host since the original aegis-origin checkpoint in February 2026.
- Explain-first, stepwise configuration. No capability is added without a written reason. No change happens faster than it can be documented.
- Hardware stability before software complexity. Firmware, BIOS, and storage decisions favour debuggability and reversibility over optimization.
- Explicit deferral of risky operations. Items that are not yet implemented are enumerated, not omitted. “We haven’t done X yet” is a design statement, not an oversight.
- Two-tier admin model. Human operators (
finnoybu) and AI-driven operators (aegis-prime) are separate accounts with separate audit trails. Neither account inherits the other’s authority implicitly. - Mediation-only until proven otherwise. The host’s runtime directories require any AI-initiated action to pass through AEGIS governance before reaching infrastructure.
Repository split
| Repository | Role for aegis-lab |
|---|---|
aegis-labs (this repo) | Research rationale, safety posture, deferral record, design decisions |
aegis-ops | Operational specifications: hardware inventory, firmware, OS install, network |
aegis | ADRs that formalize architectural decisions derived from lab work |
aegis-core | Runtime code that runs on this host |
When a statement here disagrees with aegis-ops/hosts/aegis-lab/, the ops repo wins. This page records why decisions were made; ops records what the system is.
Change policy
Any of the following must be reflected in both the labs and ops directories before the change is considered complete:
- Firmware or BIOS changes
- Storage reconfiguration (ZFS creation, SSD mirroring, partition changes)
- User or privilege model changes
- Execution enablement or capability expansion beyond the mediation-only baseline
- GPU compute enablement
If the system changes and the docs don’t, the docs are wrong.
Philosophy
If it isn’t documented, it didn’t happen.
If it isn’t intentional, it isn’t allowed.
Inherited from the original aegis-origin lab docs (2026-02) and preserved here because the premise still holds: AEGIS development on this host proceeds deliberately, safely, and reversibly, or it does not proceed.
Hardware summary
The lab runs on dual Xeon Silver 4116 CPUs, 251 GB RAM, Debian 13. Full inventory and firmware state lives in the ops repo. The hardware profile is what made the bare-metal benchmark numbers reproducible — every number from Round 1 was measured on this host.