> **v3.0 framing:** The canonical source-of-truth for Design Review (DR) in the Infrastructure domain is [`../practices/DR-Infrastructure-OnePager.md`](../practices/DR-Infrastructure-OnePager.md). This questionnaire is authored against that one-pager. Canonical subject and through-lines: [`../HAIAMM-v3.0-Framing.md`](../HAIAMM-v3.0-Framing.md) §8.

---

# Design Review (DR) - Infrastructure Domain
## HAIAMM Assessment Questionnaire v3.0

**Practice:** Design Review (DR)
**Domain:** Infrastructure
**Purpose:** Assess organizational maturity in operating the design checkpoint between intake approval and provisioning for every new AI/HAI infrastructure component, confirming SA-Infrastructure pattern adherence, SR-Infrastructure coverage, workload identity, per-tenant isolation, and documented residual risks before provisioning begins
**Scoring Model:** Evidence + Outcome Metrics (see Scoring Methodology below)

---

## Instructions

- Answer each question honestly based on **current, implemented practices** (not plans or aspirations)
- Each question has two components: **Evidence** (what you did) and **Outcome Metrics** (how well it worked)
- **Scoring uses 4 tiers:** Fully Mature (1.0), Implemented (0.67), Partial (0.33), Not Implemented (0.0)
- **Answer progressively** - Complete all Level 1 questions before Level 2
- **Level progression** - Achieve ALL questions at lower level before advancing
- **Baseline first** - Record current metric values before setting targets

---

## Scoring Methodology

| Score | Label | Criteria |
|-------|-------|----------|
| 1.0 | Fully Mature | Evidence complete AND ≥3 outcome metrics meet targets |
| 0.67 | Implemented | Evidence complete AND 2 outcome metrics meet targets |
| 0.33 | Partial | Evidence partially complete OR <2 outcome metrics meet targets |
| 0.0 | Not Implemented | No evidence of practice |

**Level Score** = average of question scores within a level
**Overall DR-Infrastructure Score** = weighted average: L1 × 0.5 + L2 × 0.3 + L3 × 0.2

---

## Maturity Level 1
**Objective:** Run a per-archetype design checkpoint for every AI/HAI infrastructure component before provisioning, producing a written decision traceable to the SA-Infrastructure reference pattern, SR-Infrastructure requirements pack, and TA-Infrastructure threat snapshot

---

### Question 1: Per-Archetype AI/HAI Infrastructure Design Checklist

**Q1.1:** Is there a published, versioned per-archetype AI/HAI Infrastructure Design Checklist, one per SM-Infrastructure archetype (inference endpoint / model-serving cluster, model registry, GPU / accelerator fleet, orchestrator / control plane, vector-store infrastructure, AI-specific CI/CD, feature store / online serving cache), traceable to the applicable SA-Infrastructure reference pattern, SR-Infrastructure requirements pack, and TA-Infrastructure threat snapshot?

**Q1.2:** Does the common spine of each checklist cover pattern adherence, workload identity (service account per component, no shared credentials, no long-lived static keys), per-tenant isolation (namespace / VPC / IAM scope), encryption (at rest and in transit, KMS placement), region/data-residency, observability, patch/image hygiene, quotas/rate-limits, backup/recovery, failure-mode documentation, and residual risk list?

**Q1.3:** Do archetype-specific checklists include their mandatory additions, inference endpoint (mTLS, per-tenant rate-limit, signed model at load time, canary plan, PII-redaction-at-logging), model registry (signed-artifacts-only, lineage required), GPU fleet (residual-state-clearing, classification-aware scheduling), and AI-CI/CD (pipeline signing, SLSA provenance, eval gate, secrets-leak-prevention scan)?

**Evidence Required:**
- [ ] Per-archetype checklist set published and version-controlled, one file or section per SM-Infrastructure archetype with an explicit version stamp
- [ ] GPU fleet checklist includes residual-state-clearing mechanism and classification-aware scheduling items
- [ ] Inference endpoint checklist includes mTLS, per-tenant rate-limit, signed-model-at-load, canary plan, and PII-redaction-at-logging
- [ ] AI-CI/CD checklist includes pipeline signing, SLSA provenance generation, eval gate, and secrets-leak-prevention scan
- [ ] Each checklist item carries an evidence pointer traced to a specific SA-Infrastructure pattern control or SR-Infrastructure requirement
- [ ] Named lead reviewer per archetype confirmed (EG-Infrastructure L1 completion verified)

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % AI/HAI infrastructure components going to production with a completed DR decision record before provisioning | ___% | ___% | ≥95% | ☐ | SM inventory × DR records |
| % DR records referencing the applicable SA reference pattern and SR REM | ___% | ___% | 100% | ☐ | DR records |
| Median review turnaround, fast-lane | ___ BD | ___ BD | ≤2 BD | ☐ | Review SLA telemetry |
| Median review turnaround, full-lane | ___ BD | ___ BD | ≤5 BD | ☐ | Review SLA telemetry |

**Metric Collection Guidance:**
- **DR coverage**: Count infrastructure components reaching production with a dated DR decision record predating provisioning start, divided by total components promoted to production. Source: SM-Infrastructure inventory joined to DR record store. Measured quarterly.
- **Pattern and REM reference rate**: Inspect DR records for a hyperlink or identifier referencing the SA-Infrastructure reference pattern and SR-Infrastructure REM. Automated field validation preferred.
- **Fast-lane SLA**: P50 of (DR decision date − review submission date) for fast-lane reviews. Source: review-tracking system.
- **Full-lane SLA**: P50 of same calculation for full-lane reviews (inference endpoints and GPU fleet nodes handling regulated data default to full-lane).

**Answer:**
- ☐ **Fully Mature** (Evidence complete + ≥3 metrics meet targets)
- ☐ **Implemented** (Evidence complete + 2 metrics meet targets)
- ☐ **Partial** (Evidence partially complete + <2 metrics meet targets)
- ☐ **Not Implemented** (No per-archetype checklist published)

| Evidence Location | Validation Date | Notes |
|-------------------|-----------------|-------|
| | | |

---

### Question 2: Two-Lane Routing and Decision Records

**Q2.1:** Is a two-lane routing model operational, fast-lane (Low/Medium tier, on-pattern, ≤2 BD) and full-lane (High/Critical tier, pattern deviation, regulated data, shared GPU, inference endpoint, AI-CI/CD, or orchestrator, ≤5 BD), with routing criteria published and applied consistently?

**Q2.2:** Does every DR decision record contain: decision (approve / approve-with-conditions / send-back); checklist completed with evidence pointers; deviations listed with rationale; residual risks with named owner and expiry; reviewer name and date; links to SM-Infrastructure inventory record, TA-Infrastructure threat snapshot, and SR-Infrastructure REM?

**Q2.3:** Are open approve-with-conditions items tracked to resolution, with named owners, expiry dates, and an enforcement path before go-live?

**Evidence Required:**
- [ ] Routing criteria document specifying which tier/archetype/deviation combinations trigger full-lane vs. fast-lane (inference endpoints, GPU fleets, AI-CI/CD, and orchestrators always route full-lane at L1)
- [ ] Decision record template with all required fields used for the last 10 reviews (sample auditable)
- [ ] Approve-with-conditions items in a trackable backlog with named owner and expiry date per item
- [ ] Sample of ≥5 decision records showing the residual-risk list populated (not blank)
- [ ] Two-lane review SLAs (≤2 BD fast-lane, ≤5 BD full-lane) communicated to infrastructure teams
- [ ] Reviewer training records confirming EG-Infrastructure L1 completion for all active reviewers

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % AI/HAI infrastructure components going to production with a completed DR decision record before provisioning | ___% | ___% | ≥95% | ☐ | SM inventory × DR records |
| Open approve-with-conditions items aging >60 days | ___ | ___ | 0 | ☐ | Action-item backlog |
| Median review turnaround, fast-lane | ___ BD | ___ BD | ≤2 BD | ☐ | Review SLA telemetry |
| Median review turnaround, full-lane | ___ BD | ___ BD | ≤5 BD | ☐ | Review SLA telemetry |

**Metric Collection Guidance:**
- **Approve-with-conditions aging**: Query action-item backlog for items where (today − condition creation date) > 60 days and status is not resolved. Measured weekly.
- **DR coverage**: same as Q1 guidance above.

**Answer:**
- ☐ **Fully Mature** (Evidence complete + ≥3 metrics meet targets)
- ☐ **Implemented** (Evidence complete + 2 metrics meet targets)
- ☐ **Partial** (Evidence partially complete + <2 metrics meet targets)
- ☐ **Not Implemented** (No two-lane routing model)

| Evidence Location | Validation Date | Notes |
|-------------------|-----------------|-------|
| | | |

---

### Question 3: Loop-back to SA-Infrastructure, SR-Infrastructure, and IM-Infrastructure

**Q3.1:** Are recurring pattern deviations and repeatedly-waived SR-Infrastructure requirements automatically queuing SA-Infrastructure pattern-update and SR-Infrastructure pack-update reviews, with a threshold of three deviations in the same direction for the same archetype triggering a pattern-update review?

**Q3.2:** Does every IM-Infrastructure incident trigger a re-examination of the DR decision record that approved the affected component, asking which checklist item would have caught the issue?

**Q3.3:** Is the pattern-deviation rate tracked by archetype and surfaced in a regular program review?

**Evidence Required:**
- [ ] Documented trigger rule: three same-direction deviations per archetype auto-queues SA-Infrastructure pattern-update review
- [ ] SA-Infrastructure pattern-update queue and SR-Infrastructure pack-update queue showing items from DR feedback in the last 12 months
- [ ] IM-Infrastructure incident post-mortems including a section linking back to the DR decision record with checklist re-examination findings
- [ ] Checklist updated in response to at least one IM-Infrastructure incident finding (before/after version comparison available)
- [ ] Pattern-deviation rate by archetype surfaced in a program review in the last quarter

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % DR records referencing the applicable SA reference pattern and SR REM | ___% | ___% | 100% | ☐ | DR records |
| SA/SR update items queued from DR feedback in last 12 months | ___ | ___ | ≥1 | ☐ | SA/SR update queues |
| % IM-Infrastructure incidents with a DR record re-examination step | ___% | ___% | 100% | ☐ | IM post-mortems |
| Open approve-with-conditions items aging >60 days | ___ | ___ | 0 | ☐ | Action-item backlog |

**Metric Collection Guidance:**
- **SA/SR queue items from DR**: Count items in SA-Infrastructure or SR-Infrastructure update queues with a DR-feedback source reference. Measured quarterly.
- **IM incident DR re-examination**: Review IM-Infrastructure incident records and confirm each has a linked DR record with a re-examination finding. Track coverage as a percentage. Measured after each incident closes.

**Answer:**
- ☐ **Fully Mature** (Evidence complete + ≥3 metrics meet targets)
- ☐ **Implemented** (Evidence complete + 2 metrics meet targets)
- ☐ **Partial** (Evidence partially complete + <2 metrics meet targets)
- ☐ **Not Implemented** (No loop-back mechanism)

| Evidence Location | Validation Date | Notes |
|-------------------|-----------------|-------|
| | | |

---

## Maturity Level 2
**Objective:** Upgrade Critical-tier reviews to scenario-based walkthroughs driven by TA-Infrastructure per-component models, detect design drift for High and Critical components on a published cadence, and run joint DR-Infrastructure / DR-Software reviews for Critical-tier software artifacts integrating with shared AI infrastructure

---

### Question 4: Scenario-Based Reviews for Critical and High-Tier Components

**Q4.1:** Are 100% of Critical-tier DR reviews conducted as scenario-based walkthroughs, with 3–5 specific threat scenarios sourced from the TA-Infrastructure per-component deep threat model and anonymized IM-Infrastructure incidents, with the DR decision tied explicitly to how the proposed design handles each scenario?

**Q4.2:** Are scenario sources refreshed quarterly from TA-Infrastructure per-component deep models and MITRE ATLAS techniques (TA0001 Reconnaissance, inference endpoint attack surface; TA0004 ML Model Access, model registry signed-artifact enforcement; TA0012 ML Attack Staging, GPU fleet residual state; TA0013 Exfiltration, vector store cross-tenant retrieval)?

**Q4.3:** For High-tier components, is the standard full-lane review augmented with at least one scenario from the TA-Infrastructure archetype library?

**Evidence Required:**
- [ ] DR records for Critical-tier components showing scenario-based walkthrough format with ≥3 named scenarios per review, specific to the component's data classification, tenant population, and connectivity
- [ ] Each scenario maps to a design control or an accepted residual risk with named owner and expiry
- [ ] Scenario library version-controlled with quarterly refresh dates and ATLAS tactic citation provenance (TA0001/TA0004/TA0012/TA0013 coverage confirmed)
- [ ] TA-Infrastructure per-component deep threat model referenced in each Critical-tier DR record
- [ ] High-tier DR records showing at least one augmenting scenario from the TA-Infrastructure archetype library
- [ ] Reviewer population trained on scenario-based walkthrough technique including infrastructure-specific ATLAS tactics

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % Critical-tier DR records using scenario-based walkthrough | ___% | ___% | 100% | ☐ | DR records |
| % Critical/High-tier components with drift check on published cadence | ___% | ___% | ≥95% | ☐ | Drift-check schedule × SM inventory |
| % material drift findings re-routed to DR | ___% | ___% | 100% | ☐ | Drift-detection queue |
| IR-stage design surprises (findings at IR with no corresponding DR condition) | ___ | ___ | trending down | ☐ | IR records |

**Metric Collection Guidance:**
- **Scenario-based coverage**: Count Critical-tier DR records with a "scenarios" section listing ≥3 named threat scenarios with ATLAS tactic citations, divided by total Critical-tier DR records. Measured quarterly.
- **IR-stage surprises**: Count IR findings with no corresponding DR condition for the same component. Source: IR records joined to DR records. Trend tracked quarter-over-quarter.

**Answer:**
- ☐ **Fully Mature** (Evidence complete + ≥3 metrics meet targets)
- ☐ **Implemented** (Evidence complete + 2 metrics meet targets)
- ☐ **Partial** (Evidence partially complete + <2 metrics meet targets)
- ☐ **Not Implemented** (No scenario-based reviews conducted)

| Evidence Location | Validation Date | Notes |
|-------------------|-----------------|-------|
| | | |

---

### Question 5: Design-Drift Detection for Infrastructure Components

**Q5.1:** Is design-drift detection operating quarterly for Critical-tier and annually for High-tier components, using IaC repository changes, cloud-provider API state, Kubernetes / orchestrator API manifest drift, model-registry events, and CI/CD job parameter changes?

**Q5.2:** Are material drift findings (new tenant on shared component without isolation review, GPU scheduling changed to allow sharing on Critical workloads, rate-limit removed, workload identity changed to shared credential, encryption key changed to unmanaged key, pipeline signing disabled) automatically re-opening the DR record and routing back through the appropriate lane?

**Q5.3:** Does the drift-detection tooling produce a staleness alert if a Critical component has no drift check in the last 90 days?

**Evidence Required:**
- [ ] Drift-detection schedule showing Critical components checked quarterly and High components annually
- [ ] Drift check artifacts (written diffs) for ≥3 Critical-tier components in the last 12 months
- [ ] Classification criteria defining which delta types are material vs. non-material for infrastructure components
- [ ] At least one material drift finding that re-opened a DR record and routed to a new review
- [ ] Staleness alert configuration confirmed (Critical component silent for >90 days triggers alert)
- [ ] Drift-detection sources confirmed: IaC repo, cloud-provider API, Kubernetes/orchestrator manifests, model registry events, CI/CD parameters

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % Critical/High-tier components with drift check on published cadence | ___% | ___% | ≥95% | ☐ | Drift-check schedule × SM inventory |
| % material drift findings re-routed to DR | ___% | ___% | 100% | ☐ | Drift-detection queue |
| % Critical-tier DR records using scenario-based walkthrough | ___% | ___% | 100% | ☐ | DR records |
| IR-stage design surprises (findings at IR with no corresponding DR condition) | ___ | ___ | trending down | ☐ | IR records |

**Metric Collection Guidance:**
- **Drift check cadence**: Count Critical components with a documented drift check in the last 90 days, divided by total Critical components in SM-Infrastructure inventory. Measured monthly.
- **Material drift re-routing**: Count material drift findings with a corresponding DR re-review record, divided by total material findings. Measured per drift-check cycle.

**Answer:**
- ☐ **Fully Mature** (Evidence complete + ≥3 metrics meet targets)
- ☐ **Implemented** (Evidence complete + 2 metrics meet targets)
- ☐ **Partial** (Evidence partially complete + <2 metrics meet targets)
- ☐ **Not Implemented** (No drift-detection mechanism)

| Evidence Location | Validation Date | Notes |
|-------------------|-----------------|-------|
| | | |

---

### Question 6: Joint DR-Infrastructure / DR-Software Reviews

**Q6.1:** Are joint DR-Infrastructure / DR-Software review records on file for 100% of Critical-tier software artifacts integrating with shared AI infrastructure, with the responsibility boundary (infrastructure team vs. software team) documented in both records?

**Q6.2:** Do both records share residual-risk ownership, with risks spanning both the shared component and the software artifact named in both records with a single named resolution owner?

**Q6.3:** Where a software integration is new and no DR-Infrastructure record exists for the referenced component, does DR-Software withhold Sanctioned status until DR-Infrastructure completes?

**Evidence Required:**
- [ ] Joint review calendar or coordination log showing DR-Infrastructure and DR-Software reviewers attending the same session for Critical-tier integrations
- [ ] DR-Infrastructure decision records for Critical-tier integrations referencing the corresponding DR-Software record identifier
- [ ] Responsibility boundary explicitly documented in both records (infrastructure controls vs. software artifact controls)
- [ ] Shared residual risks noted in both records with a single named resolution owner
- [ ] Sanctioned-status hold mechanism confirmed, no Critical-tier software artifact with a new shared-infrastructure integration advanced without a DR-Infrastructure record on file
- [ ] Cross-domain coordination channel with DR-Software established

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % Critical-tier software-to-infrastructure integrations with a joint DR record | ___% | ___% | 100% | ☐ | DR records × integration tracker |
| % material drift findings re-routed to DR | ___% | ___% | 100% | ☐ | Drift-detection queue |
| % Critical-tier DR records using scenario-based walkthrough | ___% | ___% | 100% | ☐ | DR records |
| IR-stage design surprises (findings at IR with no corresponding DR condition) | ___ | ___ | trending down | ☐ | IR records |

**Metric Collection Guidance:**
- **Joint record coverage**: Count Critical-tier software artifacts with a shared-infrastructure integration that have a paired DR-Infrastructure record identifier in their DR-Software record, divided by total such artifacts. Measured quarterly.
- **Responsibility boundary completeness**: Spot-check 5 joint reviews per quarter, verify the responsibility boundary is explicitly documented in both records with a single named resolution owner for shared residual risks.

**Answer:**
- ☐ **Fully Mature** (Evidence complete + ≥3 metrics meet targets)
- ☐ **Implemented** (Evidence complete + 2 metrics meet targets)
- ☐ **Partial** (Evidence partially complete + <2 metrics meet targets)
- ☐ **Not Implemented** (No joint review process established)

| Evidence Location | Validation Date | Notes |
|-------------------|-----------------|-------|
| | | |

---

## Maturity Level 3
**Objective:** Operate continuous design attestation via IaC-compliance scans and cloud-policy enforcement, automate drift-triggered DR exception tickets, and contribute review rubrics and scenario templates to CNCF AI, OpenSSF, and OWASP LLM / Agentic Top 10 infrastructure patterns

---

### Question 7: Continuous Design Attestation via IaC-Compliance Scans

**Q7.1:** Are ≥90% of Critical-tier AI/HAI infrastructure components producing a daily automated attestation signal, checking IaC compliance (Terraform / Pulumi plan-vs-state diff, Kyverno / Gatekeeper admission-controller policies), cloud-provider API state (workload identity, encryption keys in KMS, rate-limit config, per-tenant isolation), model-registry signing policy, and logging completeness, with deviations automatically opening DR-exception tickets triaged within 3 business days?

**Q7.2:** Are attestation artifacts machine-readable and regulator-consumable, producing EU AI Act Art. 9 risk-management evidence and ISO/IEC 42001 AIMS operational records without manual assembly?

**Q7.3:** Do human reviewers handle only: novel architectures not covered by existing attestation rules, accepted exceptions with documented rationale, and IM-Infrastructure escalations?

**Evidence Required:**
- [ ] Attestation pipeline configuration showing daily scan cadence for Critical-tier components
- [ ] Coverage report: % of Critical-tier components producing a fresh attestation signal in the last 24 hours
- [ ] Sample attestation artifact covering all four check domains: IaC compliance scan, cloud-provider API state, model-registry signing policy, logging completeness
- [ ] DR-exception ticket queue showing tickets opened automatically on attestation deviation
- [ ] Evidence that at least one DR-exception ticket was triaged within 3 business days of opening
- [ ] Staleness alert confirmed (Critical component silent for >48 hours triggers alert)

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % Critical-tier components producing a daily attestation signal | ___% | ___% | ≥90% | ☐ | Attestation telemetry |
| Mean DR-exception ticket age from open to triage | ___ BD | ___ BD | ≤3 BD | ☐ | DR-exception queue |
| Review backlog age, non-exception items | ___ days | ___ days | ≤7 days | ☐ | Review queue telemetry |
| Quarterly pattern-evolution reviews conducted | ___ | ___ | 4 / year | ☐ | Pattern-update log |

**Metric Collection Guidance:**
- **Attestation coverage**: Count Critical components with a completed attestation scan in the last 24 hours, divided by total Critical components. Source: attestation pipeline run log. Measured daily; alert if below 90%.
- **Exception ticket SLA**: P50 of (triage timestamp − open timestamp) for DR-exception tickets. Measured weekly.
- **Review backlog age**: P90 age of non-exception review queue items. Measured weekly.

**Answer:**
- ☐ **Fully Mature** (Evidence complete + ≥3 metrics meet targets)
- ☐ **Implemented** (Evidence complete + 2 metrics meet targets)
- ☐ **Partial** (Evidence partially complete + <2 metrics meet targets)
- ☐ **Not Implemented** (No continuous attestation pipeline)

| Evidence Location | Validation Date | Notes |
|-------------------|-----------------|-------|
| | | |

---

### Question 8: Contribute Review Rubrics and Scenario Templates to Industry

**Q8.1:** Has the program contributed ≥2 substantive review artifacts per year (per-archetype infrastructure design rubrics, scenario templates keyed to ATLAS tactics TA0001/TA0004/TA0012/TA0013, pattern-evolution frameworks) to CNCF AI, OpenSSF AI / MLOps, or OWASP LLM / Agentic Top 10 infrastructure patterns, with documented adoption?

**Q8.2:** Are internal rubrics and templates kept aligned to the published external versions, with internal deviations proposed as upstream changes rather than silently forked?

**Q8.3:** Is adoption tracked via citations, forks, or direct acknowledgment from peer organizations or standards bodies?

**Evidence Required:**
- [ ] Contribution log showing ≥2 published artifacts in the last 12 months, per-archetype infrastructure design rubrics, scenario templates with ATLAS tactic coverage, or pattern-evolution frameworks
- [ ] Publication links (Apache 2.0 or equivalent) to CNCF AI Working Group, OpenSSF AI / MLOps, or OWASP LLM / Agentic Top 10 infrastructure-pattern workstream
- [ ] Adoption evidence: citations, GitHub forks, or written acknowledgment from a peer organization or standards body
- [ ] Internal rubric version compared to external published version, confirmed aligned or upstream PR submitted for divergences
- [ ] At least one artifact in draft, in-review, or published at the time of assessment

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| Industry contributions per year (rubrics, scenario templates, pattern-evolution frameworks) | 0 | ___ | ≥2 | ☐ | Contribution log |
| % Critical-tier components producing a daily attestation signal | ___% | ___% | ≥90% | ☐ | Attestation telemetry |
| Mean DR-exception ticket age from open to triage | ___ BD | ___ BD | ≤3 BD | ☐ | DR-exception queue |
| Quarterly pattern-evolution reviews conducted | ___ | ___ | 4 / year | ☐ | Pattern-update log |

**Metric Collection Guidance:**
- **Industry contributions**: Count distinct published artifacts publicly accessible under an open license. Measured annually.
- **ATLAS tactic coverage**: Verify that published scenario templates cover at least TA0001, TA0004, TA0012, and TA0013 scenarios for the primary infrastructure archetypes.

**Answer:**
- ☐ **Fully Mature** (Evidence complete + ≥3 metrics meet targets)
- ☐ **Implemented** (Evidence complete + 2 metrics meet targets)
- ☐ **Partial** (Evidence partially complete + <2 metrics meet targets)
- ☐ **Not Implemented** (No external contributions)

| Evidence Location | Validation Date | Notes |
|-------------------|-----------------|-------|
| | | |

---

### Question 9: Quarterly Pattern Evolution Driven by External and Internal Signals

**Q9.1:** Is there a quarterly pattern-evolution review driven by external signals (MITRE ATLAS technique additions for TA0001/TA0004/TA0012/TA0013; CNCF AI and OpenSSF MLOps advisories; OWASP LLM / Agentic Top 10 revisions affecting infrastructure patterns) and internal signals (IM-Infrastructure incident patterns, ML-Infrastructure telemetry anomalies, ST-Infrastructure red-team findings), with a versioned change log?

**Q9.2:** Are downstream DR records for in-flight reviews notified of pattern changes that affect their archetype?

**Q9.3:** Where a new ATLAS technique or IM-Infrastructure incident reveals a checklist gap, is the gap propagated to SA-Infrastructure and SR-Infrastructure to maintain the traceability chain?

**Evidence Required:**
- [ ] Quarterly pattern-evolution review calendar with at least 4 sessions completed in the last 12 months, each with a dated agenda and change log entry
- [ ] Change log showing signal provenance (ATLAS tactic ID, CNCF AI advisory reference, or IM incident ID) for each update
- [ ] Evidence that ATLAS techniques for TA0001/TA0004/TA0012/TA0013 were reviewed in the last quarter
- [ ] In-flight DR review notifications sent when a pattern change affected the archetype under review
- [ ] SA-Infrastructure and SR-Infrastructure update items queued from pattern-evolution checklist gaps
- [ ] ATLAS and CNCF AI feeds ingested monthly into the pattern-update queue

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| Quarterly pattern-evolution reviews conducted | ___ | ___ | 4 / year | ☐ | Pattern-update log |
| % Critical-tier components producing a daily attestation signal | ___% | ___% | ≥90% | ☐ | Attestation telemetry |
| Industry contributions per year | 0 | ___ | ≥2 | ☐ | Contribution log |
| Review backlog age, non-exception items | ___ days | ___ days | ≤7 days | ☐ | Review queue telemetry |

**Metric Collection Guidance:**
- **Pattern-evolution cadence**: Count completed quarterly reviews with a dated agenda and at least one change log entry citing an external signal source. Measured annually.
- **Signal provenance completeness**: Spot-check 5 change log entries per quarter, verify each has a named source (ATLAS tactic ID, CNCF AI or OpenSSF advisory reference, or IM incident ID).

**Answer:**
- ☐ **Fully Mature** (Evidence complete + ≥3 metrics meet targets)
- ☐ **Implemented** (Evidence complete + 2 metrics meet targets)
- ☐ **Partial** (Evidence partially complete + <2 metrics meet targets)
- ☐ **Not Implemented** (No pattern-evolution process)

| Evidence Location | Validation Date | Notes |
|-------------------|-----------------|-------|
| | | |

---

## Summary Scorecard

| Question | Level | Score (0 / 0.33 / 0.67 / 1.0) | Notes |
|----------|-------|-------------------------------|-------|
| Q1: Per-Archetype Infrastructure Design Checklist | L1 | | |
| Q2: Two-Lane Routing and Decision Records | L1 | | |
| Q3: Loop-back to SA / SR / IM | L1 | | |
| Q4: Scenario-Based Reviews (Critical/High) | L2 | | |
| Q5: Design-Drift Detection | L2 | | |
| Q6: Joint DR-Infrastructure / DR-Software Reviews | L2 | | |
| Q7: Continuous Design Attestation via IaC Scans | L3 | | |
| Q8: Industry Contributions | L3 | | |
| Q9: Quarterly Pattern Evolution | L3 | | |

**Level 1 Score:** ___ / 1.0 (average of Q1–Q3)
**Level 2 Score:** ___ / 1.0 (average of Q4–Q6)
**Level 3 Score:** ___ / 1.0 (average of Q7–Q9)
**Overall DR-Infrastructure Score:** ___ / 1.0 (L1 × 0.5 + L2 × 0.3 + L3 × 0.2)

**Current Maturity Level:** ☐ L1 ☐ L2 ☐ L3
**Assessment Date:**
**Assessor:**
**Next Review Date:**

---

**Document Version:** HAIAMM v3.0
**Practice:** Design Review (DR)
**Domain:** Infrastructure
**Questionnaire Date:** 2026-05-15
**Author:** Verifhai