# AEGIS — Security Design Review Process - **Document ID:** ARCH-36 - **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 five gates every new subsystem passes before implementation begins. Implements mandate #47. The Security Design Review (SDR) is the process by which architecture becomes ready for implementation. **Design intent.** SDR gates are ordered — earlier gates screen for issues before later gates. Later gates cannot compensate for earlier failures. A gate failure sends the design back to the appropriate earlier stage. ## 2. Scope - **In scope.** Every new subsystem (engine, standard, deployment topology, governance change) proposed by an Implementation Owner. - **Also in scope.** Substantial changes to existing subsystems that touch architecture (per ARCH-35 §3 ADR-required conditions). - **Out of scope.** Bug fixes within an approved architecture; routine dependency updates; minor UI changes. ## 3. The Five Gates ### G-1 Architecture Review - **Purpose.** Does the design fit the existing ARCH-* corpus? Which principles does it honor / stress / violate? - **Reviewer.** Security Reviewer (SR) drawn from a pool not on the proposer's team. - **Inputs.** Proposed ADR (ARCH-35), affected ARCH-* references, interface contracts, cross-subsystem impact analysis. - **Applies.** Twelve Platform Design Principles (ARCH-33) as a checklist. - **Verdicts.** Approved / Conditional / Rejected. - **Failure route.** Author revises; may be Withdrawn. ### G-2 Threat Review - **Purpose.** What new attack surface does the design introduce? What existing threats change? - **Reviewer.** SR + optionally external threat-model contributor. - **Inputs.** ADR's threat-model diff section; ARCH-03 draft update; Adversarial Architect Review notes. - **Applies.** STRIDE + MITRE ATT&CK per ARCH-03; adversary profiles reviewed for coverage. - **Verdicts.** Approved / Conditional / Rejected. - **Failure route.** Threat model updated; mitigations designed; return to G-1 if architecture changes. ### G-3 Operational Review - **Purpose.** Can we operate this over 15 years? Recovery / Availability / Maintenance / Observability / Upgrade Safety / Long-Term Operations. - **Reviewer.** Operational Reviewer (OR). - **Inputs.** Runbooks, drills plan, failure-mode enumeration (5 modes per engine), Recovery-First answers, observability plan. - **Applies.** Operational Reliability Review discipline (from ARCH-27/23/30). - **Verdicts.** Approved / Conditional / Rejected. - **Failure route.** Operational model refined; return to G-1 if architecture shifts. ### G-4 Verification Review - **Purpose.** How will we prove this works? Verification instruments per ARCH-27. - **Reviewer.** SR + verification lead (from testing / red / blue team as relevant). - **Inputs.** Verification strategy per subsystem, assurance-level target + gap analysis, test plan (unit/property/fuzz/integration/chaos as needed), Golden Invariants proposed. - **Applies.** Assurance-level targets from ARCH-27 §3. - **Verdicts.** Approved / Conditional / Rejected. - **Failure route.** Verification plan revised; may accept a debt entry with resolution plan (ARCH-29). ### G-5 Release Review - **Purpose.** Is the subsystem ready to enter the release pipeline (ARCH-28 gates)? - **Reviewer.** SR + OR + Auditor observer. - **Inputs.** All prior gate verdicts, dependency review, admission-policy delta, metrics catalog additions (ARCH-24), documentation completeness. - **Applies.** Release Security Gate (ARCH-28) alignment. - **Verdicts.** Approved / Conditional / Rejected. - **Failure route.** Address gaps; may return to earlier gates. ## 4. Verdicts - **Approved.** Subsystem may proceed to implementation. Recorded as an ADR approval. - **Conditional.** Approved subject to specified follow-ups tracked in the ADR. Follow-ups must be completed before Release Certification (ARCH-46). - **Rejected.** Author revises + resubmits; may withdraw. Rejections are recorded and reviewed for pattern analysis. Every verdict is signed (Reviewer + SR/OR + Approver as per ARCH-34 §5) and captured in Layer-A audit. ## 5. Timeline and SLOs - **Small subsystem review** (single engine touch): SLO 5 business days end-to-end (all gates). - **Standard subsystem review**: SLO 10 business days. - **Large / cross-cutting** (multiple engines, principle-touching): SLO 20 business days. - **Emergency review** (needed to unblock incident work): expedited path with same gates but compressed timing; post-hoc completeness required. SLOs are tracked; consistent overrun is a governance metric (ARCH-24). ## 6. Independence and Separation - Reviewer cannot review their own team's proposal (per ARCH-34 §7). - Auditor observes every G-5 and any G-* where explicitly requested. - Rule of Two (ARCH-34 §5) prevents any single individual from serving in both Reviewer and Approver roles for the same gate. ## 7. Documentation - Every SDR produces a **Review Record** — the ADR augmented with verdicts, reviewer identities, conditions, and follow-ups. - Review Records are ARCH-* corpus artifacts (Docs-as-Code mandate #43). - Retrospectives at Continuous Architecture Review (ARCH-47) analyze patterns of approved/rejected/conditional across gates. ## 8. Post-Implementation SDR - After implementation, a lightweight **Post-Implementation Review** verifies that the built system matches the approved design. Deltas trigger either code correction, ADR amendment, or a Debt Register entry. ## 9. Independent Architecture Review - **F-1.** *Five gates could delay time-to-implementation.* SLOs bound; parallelizable where dependencies allow. - **F-2.** *Gates could become perfunctory.* Reviewer pool trained; auditor visibility; retrospectives analyze verdict distributions. - **F-3.** *Small subsystems bear disproportionate process cost.* Small subsystem SLO reflects; template designed for lightness where appropriate. ## 10. Adversarial Architect Review - **A-1.** *Insider proposes a subsystem, reviews their own subsystem, and approves it.* Independence rule + auditor + Rule of Two structurally forbid. - **A-2.** *Attacker slips a change through by fragmenting a large design into small submissions to skip G-2 threat review.* Threat Review checks cross-cutting impact; fragmented reviews get bundled; PA has explicit "aggregation" oversight. - **A-3.** *Attacker uses "Emergency" path to bypass gates.* Emergency path retains all gates, only timing is compressed; Auditor + post-hoc review verify. ## 11. Operational Reliability Review - **O-1.** Gate cadence sustainable; SLOs feasible. - **O-2.** Reviewer pool sizing scales with proposal rate. - **O-3.** Retrospectives feed process improvement. - **O-4.** Onboarding for new SRs + ORs documented. ## 12. Self-Critique - **S-1.** *Small teams may struggle with reviewer independence.* Mitigated by rotating across teams + external contributors + Debt Register entry if temporary compromise needed. - **S-2.** *Emergency path could become a shortcut.* Metric-tracked; audits count. - **S-3.** *"Approved" is a strong word; conditions can accumulate.* Conditions have due dates; unresolved conditions block release certification. ## 13. First-Target Analysis and Redesign **Target:** the "Conditional" verdict. If Conditional becomes the default disposition, it hides unresolved architectural questions under a "good enough for now" wrapper. **Response:** 1. **Conditions are dated with due dates** and referenced from the Debt Register. 2. **Conditions must be Kernel-mediated tickets** with owners. 3. **Release Certification (ARCH-46)** cannot pass with open Conditionals. 4. **Trend metric** — ratio of Conditional to Approved is a governance signal; drift alarms. 5. **Auditor visibility** on Conditional accumulation. **Second target:** reviewer capture — a proposer's team building a relationship with a friendly reviewer. Response: rotation + explicit independence rule + auditor pattern analysis. ## 14. Decisions ### D-36-1. Five gates in ordered sequence, Conditional-with-due-dates - **Reason.** Mandate #47. ### D-36-2. Conditional verdicts must not accumulate; Release Certification requires clearance - **Reason.** §13 first-target response. ## 15. Change Log - **0.1 (2026-07-10)** — Initial draft.