# AEGIS — Implementation Readiness Assessment

- **Document ID:** ARCH-53
- **Phase:** E.4 — Readiness & Long-View
- **Status:** Draft for review (post four-reviewer discipline)
- **Version:** 0.1
- **Date:** 2026-07-10
- **Owner:** Chief Security Architect

---

## 1. Purpose

Codify the formal assessment every subsystem passes before writing production code. Implements mandate #48. IRA gates implementation with an evidence-based "yes, we can build this safely" decision.

## 2. Six Checkpoints

Every subsystem must satisfy all six:

- **CP-1 Architecture Approved.** Owning ARCH-* doc + ADR approved through Security Design Review (ARCH-36) with signed verdict.
- **CP-2 Threat Model Complete.** ARCH-03 diff merged; adversary profiles + STRIDE + MITRE ATT&CK mapping current; residual risks recorded.
- **CP-3 Verification Strategy Defined.** Verification Matrix rows (ARCH-37) for every architectural claim; assurance-level target set; test/property/drill instruments identified.
- **CP-4 Operational Model Defined.** Failure modes (5 states from mandate #3) enumerated; runbook draft; on-call plan; observability plan.
- **CP-5 Recovery Defined.** Recovery-First 5 questions answered; backup/restore paths defined; recovery integrity attestation planned.
- **CP-6 Security Metrics Defined.** ARCH-24 metrics identified with baselines, targets, and alarm thresholds.

Missing checkpoint = block. No exceptions.

## 3. Six Boundaries per Subsystem (mandate #2)

Each subsystem's IRA additionally specifies:
- **Security Boundary** — what protects the subsystem's assets.
- **Trust Boundary** — who/what does the subsystem trust and at what level.
- **Failure Boundary** — how failure is contained.
- **Recovery Boundary** — what/who owns recovery.
- **Operational Boundary** — who operates, what capabilities held.
- **Verification Boundary** — what proves the subsystem behaves as claimed.

## 4. Assessment Format

`docs/ira/<subsystem>.md` — signed, versioned. Each includes:
- Checkpoint matrix (6 items with evidence links).
- Six-boundary table.
- Implementation approach summary.
- Debt Register entries (if any).
- Sign-off block (Implementation Owner + Security Reviewer + Operational Reviewer + Auditor).

## 5. Assumption (hypothesis)

- **H-1.** *The six-checkpoint discipline catches "not ready" cases before code is written.*
   - Evidence: pilot on Kernel + Cryptographic Identity + Storage.
   - Validation: measure delta between IRA-approved subsystems and post-implementation surprises.
   - Confidence: Medium.
   - Expiration: 12 months.
   - Review Date: 6 months.

## 6. Trust Score Contribution

IRA outcomes feed `Verification` dimension.

## 7. Independent Architecture Review

- **F-1.** *IRA overhead.* Structured template + reusable evidence; not one-off effort.
- **F-2.** *IRA becomes rubber stamp.* Independence + auditor + audit-history sampling.

## 8. Adversarial Architect Review

- **A-1.** *Insider signs off without evidence.* Signatures + audit event + evidence-link consistency check.
- **A-2.** *Attacker adds false verification links.* Consistency checker (ARCH-41) verifies.

## 9. Operational Reliability Review

- **O-1.** Sustainable — one IRA per subsystem, not per feature.
- **O-2.** Templates + tooling reduce authoring cost.

## 10. Self-Critique

- **S-1.** *"Complete" threat model is always approximate.* Documented as living; IRA captures snapshot.
- **S-2.** *Operational plan may drift from reality when implementation starts.* Post-implementation review verifies.

## 11. First-Target Analysis and Redesign

**Target:** the "check the box" pattern where checkpoints get checked without real evidence. Response: consistency checker verifies each checkpoint has evidence links; auditor samples random IRAs; Post-Implementation Review compares built system to IRA claims.

## 12. Future Risks / Known Limitations / Out-of-Scope / Retirement

- **Future Risks.** As team scales, IRA sign-off queue may bottleneck.
- **Known Limitations.** Snapshot-in-time; drift possible during implementation.
- **Out-of-Scope.** Feature-level readiness — that's within subsystem work.
- **Retirement Conditions.** Never — IRA discipline is permanent.

## 13. Decisions

### D-53-1. Six checkpoints + six boundaries per subsystem, evidence-linked, IRA-signed

- **Reason.** Mandate #48.

## 14. Change Log

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