# AEGIS — Verification Strategy

- **Document ID:** ARCH-27
- **Phase:** D — Deployment & Long View
- **Status:** Draft for review (post four-reviewer discipline)
- **Version:** 0.1
- **Date:** 2026-07-10
- **Owner:** Chief Security Architect

---

## 1. Purpose

Codify how AEGIS *verifies* its architectural claims. Implements mandate #35 (Verification First) and #36 (Assurance Levels). This document is the framework; Phase E (Platform Verification) contains the detailed instruments (Threat Simulation Framework, Red/Blue/Purple Team, Chaos, Formal Verification Candidates, etc.).

Core principle: **if a claim isn't verified, it isn't trusted.**

## 2. Assurance Levels

| Level | Name | Meaning |
|---|---|---|
| L0 | None | No verification; explicit "untrusted" posture |
| L1 | Basic | Automated tests, code review, SAST/DAST/SCA |
| L2 | Independent | External review + auditor sign-off on evidence |
| L3 | Continuous | Continuous validation via canary/chaos/red-team + drift alarms |
| L4 | High | L3 + property tests of security invariants + partial formal analysis |
| L5 | Critical | L4 + formal specification of key invariants + external independent replication of verification |

Every subsystem has a **target assurance level** (per ARCH-26 sizing and per subsystem criticality) and a **current assurance level** — the delta feeds ARCH-29 (Debt Register).

## 3. Subsystem Assurance Targets (v1)

| Subsystem | Target | v0-GA current | v1 |
|---|---|---|---|
| Security Kernel | L5 | L3 | L4 → L5 |
| Cryptographic Identity | L5 | L3 | L4 |
| Capability Model | L5 | L3 | L4 |
| Audit Chain | L5 | L4 | L5 |
| Watchdog Quorum | L4 | L3 | L4 |
| AI Safety Layer | L4 | L3 | L4 |
| Evidence Engine | L4 | L3 | L4 |
| Policy Engine | L4 | L3 | L4 |
| Risk Engine | L3 | L2 | L3 |
| Plugin Isolation | L4 | L3 | L4 |
| Recovery Engine | L4 | L3 | L4 |
| Supply Chain (build path) | L4 | L3 | L4 |
| Storage Engine | L3 | L2 | L3 |
| Detection Engine | L3 | L2 | L3 |
| Case Engine | L2 | L2 | L3 |
| Telemetry Engine | L2 | L2 | L2 |
| UI (Next.js) | L2 | L1 | L2 |
| Connector Engine | L3 | L2 | L3 |

Deltas at v0-GA are recorded in the Debt Register (ARCH-29) with mitigation plans and target resolution dates.

## 4. Verification Instruments (categories)

### 4.1 Static
- **SAST** (semgrep + CodeQL) with the ARCH-19 rule bank.
- **SCA** (npm audit, cargo audit, plus commercial as needed).
- **SBOM** generation + review per ARCH-14.
- **Type checking** (TS strict; Rust with clippy pedantic).

### 4.2 Dynamic
- **Unit tests** and **integration tests** per ARCH-19.
- **Property tests** (fast-check TS / proptest Rust) for security invariants (ARCH-19 M-43a).
- **Fuzz tests** for parsers on ingest/normalization/AI-response paths.
- **Contract tests** for substitutable substrates (ARCH-26 D-26-2).

### 4.3 Runtime
- **Canary drills** — synthetic evidence + injection + integrity events on rotating test tenants.
- **Chaos** — Emergency-mode entries, watchdog silence, network partition, KMS unavailability (Phase E detailed).
- **Live red team** — periodic scoped engagements.
- **Continuous validation** — Adaptive Trust decays + revalidation cycles per ARCH-11.

### 4.4 External
- **Independent audit** annually (ARCH-23).
- **Public verifier CLI** (ARCH-20 M-28) — third parties can verify audit chains.
- **Transparency logs** for release hashes (ARCH-14 D-14-4).
- **Community review** where source is public (verifier CLI, SDKs).

### 4.5 Formal (Phase E)
- **TLA+ / Alloy** models for the capability directory and Kernel decision loop.
- **CBMC / Prusti** for critical Rust hot paths.
- Selection criteria + candidates in Phase E.

## 5. Verification Mapping (mandate #37 Traceability)

Every ARCH-* doc's mandatory rules map to at least one verification instrument. The mapping is code-enforced (ARCH-24 M-metric-to-mandate map). Example excerpt:

| Mandate | Instrument |
|---|---|
| Capability attenuation | Property test (M-43a) + Kernel Watchdog (ARCH-13) |
| Classification propagation | Property test + boundary integration test |
| Audit hash-chain monotonicity | Property test + Audit Watchdog + verifier CLI |
| Redaction correctness | Canary drill (ARCH-20) + property test + fuzz |
| Kernel integrity | RIV + Integrity Beacons + Watchdog quorum |
| Recovery integrity | Recovery Integrity Attestation + Drill (ARCH-18/23) |

Full mapping lives in `docs/verification/mapping.md` (executable — CI checks coverage).

## 6. Continuous Architecture Validation (Mandate #38)

Assumptions to continuously validate:
- **Threat assumptions.** Threat model diffs per incident; annual review; adversary-profile updates (ARCH-03).
- **Trust assumptions.** Trust vectors decay; providers re-evaluated.
- **Performance assumptions.** SLO drift monitors (ARCH-24).
- **Operational assumptions.** Drill outcomes; on-call health.
- **Recovery assumptions.** Recovery Integrity Attestations.
- **AI assumptions.** Canary evals; adaptive-response ceilings; hallucination rates.

Each has a schedule + owner + reporting cadence.

## 7. Independent Architecture Review

- **F-1.** *"Verification-first" claim risks becoming aspirational.* Delta between target and current assurance is a metric (ARCH-24) and a Debt Register entry.
- **F-2.** *Level definitions are subjective.* Framework anchors levels to concrete instruments; audits calibrate.
- **F-3.** *Formal methods overhead.* Bounded to critical hot paths; not applied everywhere.

## 8. Adversarial Architect Review

- **A-1.** *Insider changes assurance-level targets to hide missing verification.* Targets are configuration (ARCH-22 C-C class); ceremony + audit.
- **A-2.** *Attacker compromises verifier CLI.* Reproducible build + open source + published hash + third-party verifiers.
- **A-3.** *Attacker gams verification with narrow tests that miss real behavior.* Property tests over the actual invariants; red-team engagements; auditor review.

## 9. Operational Reliability Review

- **O-1.** Assurance levels reviewed per release; visible in dashboards.
- **O-2.** Verifier CLI ships alongside; upgrade compat maintained.
- **O-3.** Public verification path documented so auditors can operate independently.

## 10. Self-Critique

- **S-1.** *Level 5 for Kernel is aspirational — v0 realistically L3.* Explicit in table + Debt Register (§3).
- **S-2.** *Formal methods candidates unclear.* Detailed in Phase E; §4.5 flags.
- **S-3.** *"Continuous validation"* can degrade if not owned. Assigned owners per assumption class in §6.

## 11. First-Target Analysis and Redesign

**Target: verifier CLI.** If everyone verifies with a single CLI and that CLI is compromised, verifications are false. Response:
1. Verifier CLI is Rust + reproducible-build + published hash + transparency log.
2. Specification is published so third-party verifiers can be built.
3. AEGIS provides a **reference test corpus** — bundles with known-good and known-bad cases — so a verifier's own correctness is testable.
4. External auditors are encouraged to bring their own verifier; AEGIS produces open protocol conformance suite.

**Second target:** assurance-level target settings. Response: ceremony-controlled with Auditor visibility; delta is a security metric.

## 12. Decisions

### D-27-1. Six-level assurance model with per-subsystem targets

- **Advantages.** Explicit posture; Debt Register-integrated; auditor legible.
- **Reason.** Mandate #36.

### D-27-2. Reference test corpus for verifier CLI conformance

- **Advantages.** Enables third-party verifier verification.
- **Reason.** §11 first-target response.

## 13. Open Questions

- Q-27-1. Formal-verification candidate finalization. Resolved in Phase E Doc E-8.
- Q-27-2. External auditor selection cadence. Resolved in ARCH-23 addendum.

## 14. Change Log

- **0.1 (2026-07-10)** — Initial draft.