Design Review (DR)

Infrastructure Domain - HAIAMM v3.0

Practice Overview

Objective: Operate the design checkpoint between intake approval and build-out for every new AI/HAI infrastructure component, confirming the proposed design follows the applicable SA-Infrastructure reference pattern, covers the SR-Infrastructure requirements pack, and documents residual risks before provisioning begins.

Description: DR-Infrastructure is the single moment where infrastructure architecture (SA-Infrastructure), requirements (SR-Infrastructure), and threats (TA-Infrastructure) meet a specific planned component. At L1 the review is deliberate but lean: a per-archetype design checklist, a named reviewer, and a written decision (approve / approve-with-conditions / send-back) stored against the SM-Infrastructure inventory record. The review runs before the infrastructure team begins provisioning, catching deviations when they cost hours to correct, not migration cycles. A two-lane model routes Low / Medium-tier components to an async fast-lane (≤2 BD) and High / Critical-tier or pattern-deviation cases to a full-lane architect review (≤5 BD). Loop-back signals ensure the review process improves SA-Infrastructure patterns and SR-Infrastructure packs over time rather than accumulating silent technical debt.

Context: Without a design checkpoint, AI/HAI infrastructure components reach production without verified workload identity, without per-tenant isolation bounds, without encryption-key placement decided, and without a signed-artifact requirement on the model registry. The SA-Infrastructure reference pattern and SR-Infrastructure requirements pack exist, but teams skip them under sprint pressure, deviate without recording rationale, or simply provision before the archetype pattern is consulted. DR-Infrastructure enforces the handoff between "design approved" and "provisioning begins," making deviations visible and deliberate. EU AI Act Art. 9 risk management requires documented pre-deployment decisions for high-risk AI systems; the DR decision record is that documentation for the infrastructure layer.

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

At this level, design review is a consistent gate, not a heroic intervention when a production incident reveals that an inference endpoint has no rate-limit or a GPU node shares memory across workloads. Every AI/HAI infrastructure component above the triage threshold receives a review before provisioning begins, and every review produces a written decision linked to the SM-Infrastructure inventory record.

Dependencies

• SA-Infrastructure L1 (required): the reference patterns for each infrastructure archetype are what the checklist measures the proposed design against; without patterns there is no review baseline.
• SR-Infrastructure L1 (required): the requirements pack (base plus archetype deltas) defines the acceptance bar; the REM is the primary evidence input to the review.
• TA-Infrastructure L1 (required): the per-archetype threat snapshot names what the design must defend against; the reviewer walks the snapshot's top threats against the proposed infrastructure design.
• EG-Infrastructure L1 (required): reviewers must be able to recognize Infrastructure-domain archetypes, HAI TTPs, and ATLAS tactics relevant to AI infrastructure before they can produce a credible DR decision.
• Supports / unblocks: IR-Infrastructure L1 (implementation reviews check actual deployed configuration against the approved design), ST-Infrastructure L1 (tests target the approved architecture), IM-Infrastructure L1 (incident triage references design assumptions).

Desired Outcomes

• Every AI/HAI infrastructure component above the triage threshold is reviewed before provisioning begins; no production deployment occurs without a DR decision on file.
• DR decisions are written, versioned, and stored against the SM-Infrastructure inventory record, not tribal knowledge held by the reviewing architect or platform team.
• Deviations from SA-Infrastructure reference patterns are approved or rejected explicitly with a named reviewer, a rationale, and a residual-risk acceptance.
• Review is timeboxed: teams know whether to expect a 2 BD async check or a 5 BD architect session based on the SM-Infrastructure tier and deviation status.
• Recurring deviation themes feed back into SA-Infrastructure (pattern updates) and SR-Infrastructure (pack updates), the review accumulates organizational learning, not only per-ticket decisions.

Activities

A) Publish the per-archetype AI/HAI Infrastructure Design Checklist

One checklist per SM-Infrastructure archetype, derived from the applicable SA-Infrastructure reference pattern and keyed to the SR-Infrastructure base pack and archetype delta. Each item is a yes/no with an evidence pointer. The seven checklists share a common spine and carry archetype-specific additions.

Common spine across all seven checklists: - Pattern adherence, the proposed design uses the SA-Infrastructure reference pattern or carries a documented deviation with rationale. - Workload identity, workload identity is declared (service account per component; no shared credentials; no long-lived static keys in code, config, or environment variables); secrets managed via vault. - Per-tenant isolation, isolation boundary between tenants (data, compute, and network) is specified in the design; isolation mechanism is explicit (namespace, VPC, IAM policy, API key scope). - Encryption, encryption at rest and in transit declared (algorithm, key management, KMS placement); no encryption keys in code or environment variables. - Region / data residency, data-residency requirements satisfied; cross-region data movement constrained; compliance classification applied. - Observability, logging, tracing, and alerting design declared; required event types specified per SR-Infrastructure requirements; log destination and retention period named. - Patch / image hygiene, base image provenance declared; image scan required before deployment; patch cadence specified; no use of unpinned or latest-tagged base images. - Quotas / rate-limits, resource quotas, API rate-limits, and burst-limit design specified; no unbounded consumption of GPU, memory, or API capacity. - Backup / recovery, backup policy and RTO/RPO targets for the component declared; restore procedure referenced. - Failure-mode documentation, documented degraded-mode behavior for component failure; no silent failure producing misleading output or undefined system state. - Residual risk list, explicit list of residual risks with named owner, accepted rationale, and expiry date.

Archetype-specific additions:

• Inference endpoint / model-serving cluster: mTLS between clients and the serving endpoint declared; per-tenant rate-limit design specified (not only global); model artifact signed and signature verified at load time; canary deployment plan for new model versions; PII-redaction-at-logging design (any PII in prompts or completions is redacted before logs are written, not post-hoc).

• Model registry: signed-artifacts-only policy declared (unsigned model artifacts must not be promotable to production); lineage required for every artifact (training data version, eval suite results, provenance chain); access control for promotion rights restricted to named principals; rollback mechanism documented.

• GPU / accelerator fleet: residual-state-clearing mechanism specified (GPU memory wiped between jobs using vendor-supported clear procedures); classification-aware scheduling design (regulated or Critical-tier workloads must not share a physical GPU node with other-classification workloads); no-shared-GPU policy for Critical-tier workloads documented; credential-isolation design (each job's credentials scoped to that job and expire on job completion).

• Orchestrator / control plane: workflow-signing requirement declared (unsigned workflow definitions must not be schedulable in production); per-step principal design (each workflow step executes under its own minimal-scope identity, not the orchestrator's full identity); control-plane API authentication method specified (not network-implicit); agent-state tampering prevention design named.

• Vector-store infrastructure: per-tenant partitioning design (embeddings from different tenants in logically or physically separated namespaces); classification labels on stored embeddings declared and propagated through query results; query observability design (queries logged with tenant context, query volume, and result-count per tenant); inversion-defense design (raw vector access controlled; nearest-neighbor query scope bounded).

• AI-specific CI/CD: pipeline signing requirement declared (unsigned pipeline definitions must not run in production); SLSA provenance generation for model artifacts as a required pipeline step; evaluation gate as a required check before model promotion (pipeline cannot promote a model artifact without a passing eval attestation); secrets-leak-prevention scan declared as a required pipeline step.

• Feature store / online serving cache: feature skew monitoring design declared (offline/online skew alert threshold and alerting target specified); feature lineage tracking design specified (every feature version traceable to its source dataset and transformation); rollback playbook for feature versions documented; access-control design for feature reads and writes specified.

B) Triage and route reviews by risk tier and deviation status

The two-lane model is driven by the SM-Infrastructure tier assignment and the deviation flag:

• Fast-lane (Low / Medium tier, on-pattern): async checklist review by the designated reviewer; target SLA ≤2 business days. Output: one structured decision record, approve / approve-with-conditions (explicit list) / send-back (reasons stated), stored against the SM-Infrastructure inventory record.
• Full-lane (High / Critical tier OR any pattern deviation OR regulated data processed OR component running on shared GPU): 45–60 minute architect review with the infrastructure team walking the SA-Infrastructure reference pattern section-by-section; target SLA ≤5 business days. Output: written decision record with the residual-risk list reviewed by a named architect.

Triage rules at L1 (before SM-Infrastructure L2 tiers are established): inference endpoints and GPU fleet nodes handling regulated data default to full-lane. AI-specific CI/CD pipelines and orchestrators default to full-lane. All others default to fast-lane with override to full-lane available on reviewer judgment.

Decision record contents (both lanes): decision (approve / approve-with-conditions / send-back); checklist completed with evidence pointers; deviations listed with rationale; residual risks listed with named owner and expiry; reviewer name and date; links to SM-Infrastructure inventory record, TA-Infrastructure threat snapshot, and SR-Infrastructure REM.

C) Close the loop with SA-Infrastructure, SR-Infrastructure, and IM-Infrastructure

Design review is a learning surface for the program:

• SA pattern update trigger: three deviations in the same direction for the same archetype auto-queue a pattern-update review with SA-Infrastructure ownership. Recurring deviations are a signal the pattern is miscalibrated, not that infrastructure teams are wrong.
• SR pack update trigger: an SR requirement repeatedly waived with a compensating control auto-queues an SR pack-revision review.
• IM incident feedback loop: every IM-Infrastructure incident re-examines the DR decision record that approved the affected component. Was the issue visible at design time? Which checklist item would have caught it? The answer updates the checklist and feeds the next archetype review cycle.

Outcome Metrics (L1)

Process Metrics (leading)

• Reviewer population staffed and trained (EG-Infrastructure L1 completion confirmed); named lead reviewer per archetype.
• Fast-lane vs. full-lane ratio monitored, a drift toward all-fast-lane may indicate under-review; toward all-full-lane may indicate over-routing.
• Pattern-deviation rate tracked by archetype, feeds the SA-Infrastructure pattern-update trigger.
• Checklists aligned to current SA reference patterns and SR pack; updated within 30 days of any SA or SR change.

Effectiveness Metrics (business value)

• Issues caught at design vs. caught at IR or in incident, design-stage catch rate trends up as the program matures.
• Provisioning cycle-time impact, DR adds a small, predictable window; infrastructure teams can plan; the gate is not open-ended.
• SA/SR update volume driven by DR feedback, a healthy program generates pattern and pack improvements, not only per-ticket decisions.

Success Criteria

• Per-archetype design checklists published, versioned, and traceable to the applicable SA-Infrastructure reference pattern, SR-Infrastructure requirements pack, and TA-Infrastructure threat snapshot, one per archetype (inference endpoint, model registry, GPU fleet, orchestrator, vector-store, AI-CI/CD, feature store).
• Two-lane review model operational with published SLAs (≤2 BD fast-lane, ≤5 BD full-lane) and named lead reviewers per archetype.
• ≥95% of AI/HAI infrastructure components going to production in the last 90 days carry a completed DR decision record before provisioning begins.
• SA pattern-update and SR pack-update triggers wired so recurring deviations and waived requirements feed back; every IM-Infrastructure incident re-examines the DR record that approved the affected component.
• Named reviewer population trained (EG-Infrastructure L1) and active.

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

At this level, design review for Critical-tier infrastructure components moves from checklist conformance to scenario-based conversations. The TA-Infrastructure per-component deep threat models (available at TA L2) drive the scenarios. Design drift, the live component diverging from the approved design, is detected on a published cadence and automatically re-routed to DR. Where a Critical-tier first-party software artifact integrates with shared AI infrastructure (inference cluster, vector store, GPU fleet), DR-Infrastructure coordinates a joint review with DR-Software.

Dependencies

• DR-Infrastructure L1 (required): per-archetype checklists, two-lane model, and loop-back triggers.
• TA-Infrastructure L2 (required): per-component deep threat models are the source material for Critical-tier scenario walkthroughs.
• SA-Infrastructure L2 (required): IaC-encoded patterns and tier-conditional overlays are what L2 reviews verify the design against.
• SM-Infrastructure L2 (required): the risk-tier rubric (Critical / High / Medium / Low) determines which components receive scenario-based reviews and drives the per-tier drift-detection cadence.
• Supports / unblocks: IR-Infrastructure L2 (drift detected here re-opens IR), ST-Infrastructure L2 (scenario-based reviews feed the security test suite).

Desired Outcomes

• Every Critical-tier DR covers 3–5 specific threat scenarios from the TA-Infrastructure library, with the decision tied explicitly to how the proposed infrastructure design handles each scenario.
• Design drift is detected quarterly for Critical-tier and annually for High-tier; material drift automatically re-opens the DR record.
• Where a Critical-tier software artifact integrates with shared AI infrastructure, DR-Infrastructure and DR-Software produce joint review records with an explicit responsibility boundary.
• Fewer IR-stage surprises, drift caught at the design review or drift-detection phase rather than at implementation review or incident.

Activities

A) Scenario-based reviews for Critical and High-tier components

For every Critical-tier infrastructure component, the full-lane checklist walkthrough is replaced by a scenario walkthrough:

• Source 3–5 specific threat scenarios from the TA-Infrastructure per-component deep threat model and from the TA-Infrastructure archetype library. Scenarios must be specific to this component's data classification, tenant population, network placement, and connectivity, not generic archetype scenarios.
• Walk each scenario: "If an adversary does X, does the proposed infrastructure design have a control that prevents or detects it? Where? What is the residual risk?" The DR decision record maps each scenario to a design control or an accepted residual risk with a named owner and expiry.
• Scenario sources: TA-Infrastructure per-component deep threat model; anonymized IM-Infrastructure incidents from the same archetype; MITRE ATLAS technique candidates for the component's primary defensive coverage (TA0001 Reconnaissance, does the design minimize the inference endpoint's attack surface?; TA0004 ML Model Access, does the model registry enforce signed artifacts and access control?; TA0012 ML Attack Staging, does the GPU fleet prevent residual state leakage?; TA0013 Exfiltration, does the vector store prevent cross-tenant retrieval extraction?); OWASP LLM / Agentic Top 10 infrastructure-relevant entries.
• For High-tier components: standard full-lane review augmented with at least one scenario from the TA-Infrastructure archetype library; not a full scenario walkthrough.

B) Cross-domain joint reviews for Critical-tier software-to-infrastructure integrations

When a Critical-tier first-party software artifact integrates with shared AI infrastructure (an agent calling a shared inference endpoint, a RAG pipeline backed by a shared vector store, a fine-tune job running on the shared GPU fleet), DR-Infrastructure coordinates with DR-Software:

• Joint review: the DR-Infrastructure reviewer and the DR-Software reviewer attend the same session; the responsibility boundary (which controls are the infrastructure team's responsibility vs. the software team's) is explicitly documented in both DR records.
• DR-Infrastructure decision covers the shared component's design; DR-Software decision covers the software artifact; residual risks spanning both are noted in both records with shared ownership and a single named resolution owner.
• Where the software integration is new and no DR-Infrastructure record exists for the referenced component, DR-Software flags the gap and withholds Sanctioned status until DR-Infrastructure completes.

C) Design-drift detection

Compare the live production component against its approved DR design at the published cadence:

• Critical-tier: quarterly drift check. Sources checked: IaC repository (changes since last DR that affect SA-pattern controls, workload identity, encryption, isolation policies, rate-limit configs, image pins); cloud-provider APIs (resource configuration changes vs. the DR-approved baseline); Kubernetes / orchestrator API (deployment manifest drift vs. approved manifests); model-registry events (model version changes, signing policy changes); CI/CD job parameter changes.
• High-tier: annual drift check using the same sources.
• Material drift (new tenant added to a shared component without isolation review, GPU scheduling policy changed to allow sharing on Critical workloads, rate-limit removed or raised, workload identity changed to a shared credential, encryption key changed to an unmanaged key, pipeline signing disabled) automatically re-opens the DR record and routes back through the appropriate lane.
• Drift check produces a written artifact: the diff between approved design and live configuration, each delta classified as material / non-material, material deltas tracked to DR re-review or accepted residual.

Outcome Metrics (L2)

Process Metrics (leading)

• Scenario library from TA-Infrastructure refreshed quarterly; scenario content aligned to current TA-Infrastructure per-component models.
• Drift-detection tooling health monitored, staleness alert if a Critical component has no drift check in the last 90 days.
• Cross-domain coordination channel with DR-Software established; joint-review calendar maintained.
• Reviewer population trained on scenario-based walkthrough technique (scenario selection, design-to-scenario mapping, residual-risk documentation).

Effectiveness Metrics (business value)

• Fewer IR-stage surprises, drift caught pre-IR, not post-deployment.
• Scenario-driven reviews produce more specific approve-with-conditions lists; conditions are more actionable than checklist items.
• Joint DR-Infrastructure / DR-Software reviews reduce responsibility-boundary gaps for Critical-tier components.

Success Criteria

• 100% of Critical-tier DR reviews conducted as scenario-based walkthroughs with the decision tied to how the design handles each scenario.
• Design-drift detection operating for Critical (quarterly) and High (annual) components; 100% of material drifts re-routed to DR.
• Joint DR-Infrastructure / DR-Software review records on file for 100% of Critical-tier software-to-infrastructure integrations.
• IR-stage design surprises measurably fewer than at L1 over consecutive quarters.

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 the OWASP LLM / Agentic Top 10 infrastructure patterns

At this level, Critical-tier infrastructure components attest continuously rather than being reviewed periodically. IaC-compliance scans and cloud-policy enforcement produce a daily signal that the component's configuration remains within the bounds of the approved design. Pattern drift opens a DR-exception ticket automatically. Review rubrics, scenario templates, and pattern-evolution frameworks are contributed to industry bodies. Pattern evolution is driven by external signals (MITRE ATLAS updates, CNCF AI / MLOps community advisories, IM-Infrastructure incidents) and internal signals (ML-Infrastructure telemetry, ST-Infrastructure red-team findings) on a quarterly cadence.

Dependencies

• DR-Infrastructure L2 (required): scenario reviews, drift detection, and joint-review process must be established before automation is trustworthy.
• SA-Infrastructure L3 (required): externalized IaC patterns supply the attestation frame; automated compliance scans verify against the published pattern.
• ML-Infrastructure L2+ (required): monitoring signals (config telemetry, logging completeness, model-version events) feed the continuous attestation pipeline.
• IM-Infrastructure L2+ (required): incidents auto-trigger DR re-examination; the IM → DR feedback loop must be operational before L3 automation is meaningful.

Desired Outcomes

• Critical-tier infrastructure components' design posture is readable from a daily attestation signal, reviewers handle exceptions and novel architecture cases, not routine checks.
• Pattern evolution is driven quarterly by external signals (ATLAS, CNCF AI, OpenSSF AI) and internal signals (IM-Infrastructure, ML-Infrastructure, ST-Infrastructure) with a traceable change log.
• Review rubrics and scenario templates are published externally and adopted by peer organizations; the program contributes to the AI-assurance infrastructure design-review ecosystem.
• DR review backlog shrinks to exception and novel-architecture work.

Activities

A) Continuous design attestation via IaC-compliance scans and cloud-policy enforcement

Critical-tier infrastructure components produce a daily attestation signal covering: IaC compliance scan (SA-Infrastructure reference pattern controls present and enforced in the deployed IaC state, Terraform / Pulumi plan-vs-state diff, admission-controller policy checks via Kyverno / Gatekeeper); cloud-provider API check (workload identity not reverted to long-lived keys, encryption keys in KMS not inline, rate-limit configuration active, per-tenant isolation policy intact); model-registry check (signing policy enforced, lineage required for every artifact in scope); logging completeness check (ML-Infrastructure signal that required event types are flowing at expected volume).

Deviations from the approved design automatically open a DR-exception ticket in IM-Infrastructure; the ticket is triaged within 3 business days.

Attestation artifacts are machine-readable and regulator-consumable, EU AI Act Art. 9 risk-management evidence and ISO/IEC 42001 AIMS operational records are produced by the attestation pipeline without manual assembly.

Human reviewers handle: novel architectures not covered by existing attestation rules; accepted exceptions with documented rationale; escalations from the IM-Infrastructure backlog.

B) Contribute review rubrics and scenario templates to CNCF, OpenSSF, and OWASP

Publish under Apache 2.0 or equivalent through CNCF AI Working Group, OpenSSF AI / MLOps, or OWASP LLM / Agentic Top 10 infrastructure-pattern workstream: - Per-archetype AI/HAI infrastructure design review rubric (tier-assignment criteria, checklist items with evidence pointers, scenario-selection guidance keyed to ATLAS tactics TA0001, TA0004, TA0012, TA0013). - Scenario template library (scenario format, per-archetype examples, debrief rubric). - Pattern-evolution framework (how external signals, ATLAS updates, CNCF AI advisories, IM incidents, feed DR checklist and scenario updates on a quarterly cadence).

Internal rubrics and templates remain aligned to the published external versions; internal deviations are proposed as upstream changes, not silently forked. Adoption tracked: citations, forks, direct acknowledgment from peer organizations or standards bodies.

C) Pattern evolution driven by external and internal signals

Quarterly pattern-evolution review: external signals (MITRE ATLAS technique additions for TA0001 Reconnaissance, TA0004 ML Model Access, TA0012 ML Attack Staging, TA0013 Exfiltration; CNCF AI and OpenSSF MLOps advisories; OWASP LLM / Agentic Top 10 revisions affecting infrastructure patterns) plus internal signals (IM-Infrastructure incident patterns by archetype, ML-Infrastructure telemetry anomalies, ST-Infrastructure red-team findings) feed structured checklist and scenario library updates.

Updates change-logged with signal provenance; downstream DR records for in-flight reviews notified of pattern changes that affect their archetype. Where a new ATLAS technique or IM incident reveals a checklist gap, the gap is propagated to SA-Infrastructure and SR-Infrastructure as well, the traceability chain from threat to requirement to design review is maintained.

Outcome Metrics (L3)

Process Metrics (leading)

• Attestation-scan health, % Critical components producing a fresh attestation signal in the last 24 hours; staleness alert if any Critical component silent for >48 hours.
• External-signal ingestion cadence, ATLAS and CNCF AI feeds processed monthly into the pattern-update queue.
• Contribution pipeline, at least one artifact in draft, in-review, or published at any time.
• Exception-queue freshness, DR-exception tickets triaged within 3 business days of opening.

Effectiveness Metrics (business value)

• Reviewer-hours per component trending down quarter-over-quarter as continuous attestation absorbs routine design-check work.
• External adoption of published rubrics and scenario templates, citations from peer organizations, sector bodies, or regulators signal industry recognition.
• Critical-incident MTTR shortened because design posture is continuously visible; incident responders do not need to reconstruct the approved design from scratch during an incident.

Success Criteria

• Daily attestation operating for ≥90% of Critical-tier components; DR-exception tickets opened on deviation and triaged within 3 business days.
• ≥2 externally contributed review artifacts per year published to CNCF AI / OpenSSF / OWASP with documented adoption.
• Review backlog for non-exception work inside ≤7 days; attestation has absorbed the pre-L3 routine review volume.
• Quarterly pattern-evolution cadence traceable to external (MITRE ATLAS TA0001/TA0004/TA0012/TA0013, CNCF AI, OpenSSF) and internal (IM-Infrastructure, ML-Infrastructure, ST-Infrastructure) signals with a versioned change log.

Key Success Indicators

Level 1: - Per-archetype AI/HAI Infrastructure Design Checklists published and versioned, one per SM-Infrastructure archetype (inference endpoint, model registry, GPU fleet, orchestrator, vector-store, AI-CI/CD, feature store), each traceable to the applicable SA reference pattern, SR requirements pack, and TA threat snapshot; GPU fleet checklist covers residual-state-clearing and classification-aware scheduling; inference endpoint checklist covers mTLS, per-tenant rate-limit, signed-model, canary, and PII-redaction-at-logging; model registry checklist covers signed-artifacts-only and lineage-required. - Two-lane review model operational (fast-lane ≤2 BD, full-lane ≤5 BD) with named lead reviewers per archetype trained on EG-Infrastructure L1 practitioner curriculum. - ≥95% of AI/HAI infrastructure components going to production in the last 90 days carry a completed DR decision record before provisioning begins; every decision record includes the residual-risk list with named owner and expiry. - SA pattern-update and SR pack-update triggers wired so recurring deviations and waived requirements automatically queue SA and SR reviews; every IM-Infrastructure incident re-examines the DR record that approved the affected component.

Level 2: - 100% of Critical-tier DR reviews conducted as scenario-based walkthroughs with 3–5 scenarios sourced from TA-Infrastructure per-component deep models and anonymized IM-Infrastructure incidents, keyed to ATLAS tactics TA0001, TA0004, TA0012, TA0013; the DR decision is tied to how the design handles each scenario. - Design-drift detection operating quarterly for Critical and annually for High, using IaC repository, cloud-provider APIs, Kubernetes API manifest drift, model-registry events, and CI/CD parameters; 100% of material drifts re-routed to DR. - Joint DR-Infrastructure / DR-Software records on file for 100% of Critical-tier software-to-infrastructure integrations. - IR-stage design surprises measurably fewer over consecutive quarters.

Level 3: - ≥90% of Critical-tier components producing a daily automated IaC-compliance attestation signal; deviations auto-open DR-exception tickets triaged within 3 business days. - ≥2 externally contributed review artifacts per year published to CNCF AI / OpenSSF / OWASP with documented adoption; internal practice aligned to published versions. - Quarterly pattern-evolution loop traceable to MITRE ATLAS (TA0001/TA0004/TA0012/TA0013), CNCF AI, OpenSSF, IM-Infrastructure incidents, ML-Infrastructure telemetry, and ST-Infrastructure findings; versioned change log maintained. - Review backlog ≤7 days for non-exception items; attestation volume has replaced routine review work.

Common Pitfalls

Level 1: - ❌ Design review runs after the infrastructure team has already provisioned the component, the checkpoint loses leverage because re-provisioning cost is already sunk; the review becomes a retrospective, not a gate. - ❌ Checklists are identical across archetypes, the GPU fleet checklist does not include residual-state-clearing or classification-aware scheduling items because it was copy-pasted from the inference endpoint checklist. - ❌ Fast-lane becomes the default for everything, GPU fleet nodes and orchestrators slip through with a 15-minute async check rather than the full-lane architect session they require. - ❌ Approve-with-conditions is issued but conditions have no named owner and no expiry date, conditions sit unresolved at go-live with no enforcement path. - ❌ Residual-risk list is blank because the reviewer does not want to document risk the business sponsor will be uncomfortable seeing, the design record understates real exposure. - ❌ DR decision records are not linked to the SM-Infrastructure inventory record, the program cannot answer "was this component reviewed?" without a manual search. - ❌ Checklist items are not traced to SA-Infrastructure pattern controls or SR-Infrastructure requirements, items get skipped without consequence.

Level 2: - ❌ "Scenario-based" review is the same checklist read aloud in a meeting, the scenario-to-design-control mapping is never actually performed. - ❌ Scenario library is not refreshed quarterly, scenarios pulled from a 12-month-old TA snapshot do not reflect the current per-component threat model or recent IM incidents. - ❌ Design-drift detection runs on a schedule but findings dead-end in a spreadsheet, no DR-exception ticket is opened; the approved design remains fiction while the live component has diverged. - ❌ Joint DR-Infrastructure / DR-Software reviews never happen because the coordination channel was never established, Critical-tier software artifacts calling shared inference endpoints have no responsibility-boundary documentation on file. - ❌ Per-tier drift-detection cadence exists on paper but the drift-check tooling was never configured, quarterly Critical-tier drift checks are reported on the scoreboard but never performed.

Level 3: - ❌ Attestation signals show green across all Critical components but the underlying checks cover only logging settings, workload identity state, encryption key placement, and rate-limit configuration are not checked; attestation is cosmetic. - ❌ Externally published rubrics diverge from internal practice, the published artifact reflects how the org reviewed components 18 months ago; peer adopters find inconsistencies when comparing the rubric to actual DR records. - ❌ Exception queue overwhelms reviewers because attestation thresholds are too sensitive, every image patch triggers a DR-exception ticket; reviewers suppress the signal source rather than tune the sensitivity threshold. - ❌ Industry contributions are conference talks and blog posts describing the program, no technical artifacts (rubrics, scenario templates, pattern-evolution frameworks) land in CNCF / OpenSSF / OWASP with documented adoption.

Practice Maturity Questions

Level 1: 1. Is there a published, versioned per-archetype AI/HAI Infrastructure Design Checklist, one per SM-Infrastructure archetype (inference endpoint, model registry, GPU fleet, orchestrator, vector-store, AI-CI/CD, feature store), traceable to the applicable SA reference pattern, SR requirements pack, and TA threat snapshot, with the GPU fleet checklist covering residual-state-clearing and classification-aware scheduling, the inference endpoint checklist covering mTLS, per-tenant rate-limit, signed-model, canary, and PII-redaction-at-logging, and the model registry checklist covering signed-artifacts-only and lineage-required? 2. Do ≥95% of AI/HAI infrastructure components going to production in the last 90 days carry a completed DR decision record (approve / approve-with-conditions / send-back) before provisioning begins, with a two-lane routing model (fast-lane ≤2 BD, full-lane ≤5 BD), named lead reviewers per archetype trained on EG-Infrastructure L1, and a residual-risk list with named owner and expiry in every record? 3. Are recurring pattern deviations and repeatedly-waived SR requirements automatically queuing SA-Infrastructure pattern-update and SR-Infrastructure pack-update reviews, and does every IM-Infrastructure incident trigger a re-examination of the DR record that approved the affected component?

Level 2: 1. Are 100% of Critical-tier DR reviews conducted as scenario-based walkthroughs, with 3–5 specific threat scenarios sourced from TA-Infrastructure per-component deep models and anonymized IM-Infrastructure incidents, keyed to ATLAS tactics TA0001, TA0004, TA0012, TA0013, with the DR decision tied explicitly to how the proposed design handles each scenario rather than checklist conformance alone? 2. Is design-drift detection running quarterly for Critical-tier and annually for High-tier, using IaC repository changes, cloud-provider API state, Kubernetes API manifest drift, model-registry events, and CI/CD parameter changes, with 100% of material drifts automatically re-routed to DR for a new review? 3. Are joint DR-Infrastructure / DR-Software review records on file for 100% of Critical-tier software artifacts integrating with shared AI infrastructure, with an explicit responsibility boundary and shared residual-risk ownership documented in both DR records?

Level 3: 1. Are ≥90% of Critical-tier AI/HAI infrastructure components producing a daily automated attestation signal, checking IaC compliance, cloud-provider API configuration, workload identity state, encryption key placement, rate-limit configuration, and logging completeness, with deviations auto-opening DR-exception tickets triaged within 3 business days? 2. Has the program contributed ≥2 substantive review artifacts per year (per-archetype rubrics, scenario templates, pattern-evolution frameworks) to CNCF AI, OpenSSF, or OWASP LLM / Agentic Top 10 infrastructure patterns, with documented adoption and internal practice aligned to the published versions? 3. Is there a quarterly pattern-evolution review driven by external signals (MITRE ATLAS TA0001/TA0004/TA0012/TA0013, CNCF AI, OpenSSF advisories) and internal signals (IM-Infrastructure incidents, ML-Infrastructure telemetry, ST-Infrastructure findings), with a versioned change log and notification to in-flight DR reviews affected by pattern changes?

Document Version: HAIAMM v3.0 Practice: Design Review (DR) Domain: Infrastructure Last Updated: 2026-05-14 Author: Verifhai