# AEGIS — Platform Design Principles - **Document ID:** ARCH-33 - **Phase:** E.1 — Governance Foundation - **Status:** Draft for review (post four-reviewer discipline) - **Version:** 0.1 - **Date:** 2026-07-10 - **Owner:** Chief Security Architect --- ## 1. Purpose Codify the twelve durable principles that govern every AEGIS decision through the platform's lifespan. Implements mandate #50. These principles are the vocabulary of every ADR (ARCH-35), Security Design Review (ARCH-36), and Continuous Architecture Review (ARCH-47). **Design intent.** Principles are stable. Everything else — engineering standards, deployment topologies, capability vocabulary, provider choices — may evolve; principles do not. Changing a principle is a strategic act, not an engineering act. ## 2. The Twelve Principles ### 2.1 Security over Convenience Convenience never justifies weakening security. If a workflow is easier because a control is disabled, the control was necessary and the workflow must adapt to it. *Applied:* every "easier if we skip X" argument in a design review is a signal to strengthen X, not remove it. ### 2.2 Verification over Assumption Every claim about the system carries a verification strategy. Untested claims are debt. *Applied:* ARCH-27 assurance levels + ARCH-38 testing + Golden Invariants (ARCH-28 §4). ### 2.3 Evidence over Opinion Decisions rest on cited evidence — events, audit records, threat-model rationale, drill outcomes, metrics. Opinion is a proposal for evidence, never a substitute. *Applied:* structured DraftRecommendation (ARCH-15 §8), explainability contract (ARCH-12 §7), post-mortems (ARCH-21). ### 2.4 Least Privilege Every identity, engine, plugin, user, and operation receives only the capabilities needed for the task, at the moment of the task, for the duration of the task. *Applied:* capability model (ARCH-08), per-task agent identities (ARCH-15 §5), Break-Glass discipline. ### 2.5 Defense in Depth Every property is guaranteed by at least two independent mechanisms. No single control is the last line of defense. *Applied:* mTLS + message signing; capability tokens + broker ACLs; Kernel policy + Watchdog quorum; runtime integrity + boot integrity. ### 2.6 Zero Trust Nothing is trusted by default — not networks, not engines, not humans, not identities, not artifacts. Trust is earned through verification, and it decays. *Applied:* every boundary crossing checks identity + capability + policy (ARCH-05); Adaptive Trust decay (ARCH-11 §6). ### 2.7 Privacy by Design Data collection is minimized; sensitive processing is local where practical; sensitive egress is opt-in and audited; PII redacted before it leaves the emitting process. *Applied:* Redaction pipeline (ARCH-20), classification-based routing (ARCH-15), tenant DEK isolation (ARCH-04). ### 2.8 Human Authority AI advises. Humans decide on consequential actions. The platform enforces this structurally, not merely by policy. *Applied:* Multi-Stage Decision Pipeline (ARCH-11), no autonomous action in v0 (F-4.5), broker-ACL segregation of Publish-Validated-Recommendation from AI Engine (ARCH-16). ### 2.9 Deterministic Core Critical capabilities operate without AI. The platform never fails because a model is down. *Applied:* L1 rules (Sigma/YARA), tier-fallback design, offline-capable topologies (R-5 air-gap). ### 2.10 Operational Simplicity Every procedure is executable by a well-trained security engineer without hidden knowledge. Complexity that cannot be operated is a security liability. *Applied:* runbook discipline (ARCH-21), no-hidden-knowledge rule (ARCH-23), simpler-when-improves-security (mandate #24). ### 2.11 Maintainability The platform is designed for a 15-year lifespan. Interfaces are versioned, deprecations are formal, debt is registered, ownership rotates. *Applied:* contract stability (ARCH-31), Debt Register (ARCH-29), team continuity discipline. ### 2.12 Cryptographic Trust Trust is cryptographically established, never asserted. Every artifact of consequence is signed; every identity is anchored; every signature is verifiable. *Applied:* cryptographic identity (ARCH-09), signed audit chain (ARCH-13), signed evidence bundles (ARCH-12). ## 3. Using the Principles ### 3.1 In ADRs Every ADR (ARCH-35) references at least one principle. If a decision satisfies no principle, the decision is either not architectural or is a violation. ### 3.2 In Security Design Reviews The Reviewer applies each principle as a lens (ARCH-36). "Which principles does this design honor? Which does it stress? Which does it violate?" A design cannot pass Review with an unresolved principle violation. ### 3.3 In Code Review Two-approver reviews on security-critical paths cite principles when required. ### 3.4 In Incident Retrospectives Post-mortems name which principles were preserved and which were stressed by the incident (ARCH-21). ### 3.5 In Debt Register Entries Every debt entry names the principles being compromised and the plan to restore them (ARCH-29). ## 4. Interaction and Conflict Principles occasionally tension. When they do: - **Safety-over-elegance rule.** When Security-over-Convenience conflicts with Operational Simplicity, security wins if the security gap is material; otherwise simplicity wins. - **Human-authority tie-breaker.** When any principle is unclear in an AI context, apply Human Authority. - **Documented resolution.** Conflicts resolved in an ADR that names both principles and the balance struck. There is no ranking beyond these tie-breakers; principles are peers. ## 5. Change Governance Principles change only through a formal amendment process: - Proposed change is an ADR referencing existing principle + rationale. - Reviewed by Chief Security Architect + Platform Architect + Auditor. - Requires Owner approval + ceremony. - Public transparency-log entry. - Not more than one principle change per year absent extraordinary reason. Adding principles is possible; removing is treated as a last resort. ## 6. Independent Architecture Review - **F-1.** *Principles are aspirational; engineering practice may drift.* Every ADR and Review cites principles; Continuous Architecture Review (ARCH-47) catches drift. - **F-2.** *Twelve is a lot to hold in mind.* Small enough for a reviewer's checklist; grouped by domain in §2. - **F-3.** *Some principles seem redundant (Zero Trust vs. Least Privilege).* They are related but distinct — Least Privilege is about *scope*; Zero Trust is about *default*. ## 7. Adversarial Architect Review - **A-1.** *Insider argues that a principle "doesn't apply here."* The Reviewer role's job is to require explicit reasoning; Auditor visibility on principle exceptions. - **A-2.** *Principle is edited silently.* Change governance (§5) + version control + ceremony + transparency log. - **A-3.** *Attacker exploits a principle-collision to argue for weakening.* The tie-breakers (§4) are explicit; ADRs must show reasoning. ## 8. Operational Reliability Review - **O-1.** Principles referenceable via short codes (P-01..P-12) for terse citation. - **O-2.** Onboarding materials memorize principles + examples per principle. - **O-3.** Principle-citation is a required field in the ADR template. ## 9. Self-Critique - **S-1.** *"Security over Convenience"* is easy to invoke selectively. Reviewer discipline; auditor challenges. - **S-2.** *"Evidence over Opinion"* can be weaponized to require evidence for legitimate expert judgment. Clarification: evidence includes documented expert reasoning; the principle rejects *un-cited* opinion, not judgment. - **S-3.** *Change governance is strict.* Intentionally — principles are supposed to be the constant. ## 10. First-Target Analysis and Redesign **Target:** the principles-change process itself. If someone can quietly amend a principle, everything downstream shifts silently. **Response:** ceremony + transparency log + Auditor + Owner sign-off + max frequency; amendments visible externally. **Second target:** principle-citation becoming rote. Response: Reviewer training + Auditor audits ADRs for meaningful citation. ## 11. Decisions ### D-33-1. Twelve principles, ranked as peers with two named tie-breakers - **Advantages.** Stable vocabulary; explicit conflict resolution. - **Reason.** Mandate #50. ### D-33-2. Amendment ceremony with max one change per year - **Reason.** Preserve stability. ## 12. Change Log - **0.1 (2026-07-10)** — Initial draft.