Design Review (DR)

Software Domain - HAIAMM v3.0

Practice Overview

Objective: Operate the design checkpoint between intake approval and build-out for every non-trivial AI/HAI software artifact, confirming the proposed design follows the applicable SA reference pattern, covers the SR requirements pack, and documents residual risks before engineering begins.

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

Context: Without a design checkpoint, AI/HAI software builds happen without a verified data boundary, without a confirmed tool allowlist, and without an output-filter placement decision. The SA reference pattern and the SR requirements pack exist, but teams skip them under sprint pressure, deviate without recording rationale, or simply do not find the pattern before build begins. DR-Software enforces the handoff between "design approved" and "build 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.

Maturity Level 1

Objective: Run a per-archetype design checkpoint for every AI/HAI software artifact before build-out, producing a written decision traceable to SA pattern, SR requirements, and TA threat snapshot

At this level, design review is a consistent gate, not a heroic intervention when things go wrong. Every AI/HAI software artifact above the triage threshold receives a review before engineering begins, and every review produces a written decision linked to the SM inventory record.

Dependencies

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

Desired Outcomes

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

Activities

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

One checklist per SM-Software archetype, derived from the applicable SA-Software reference pattern and keyed to the SR-Software 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, using the SA reference pattern or documented deviation with rationale. - Data boundary, which data classes reach the model, LLM provider, RAG index, or fine-tune corpus; DLP inspection points and output-filter placement defined. - Identity, SSO-backed human access to all admin and operational interfaces; service-principal model (not a shared credential) for automated or agent access; secrets-vault-backed API keys to LLM providers, no hardcoded keys in code, config, environment variables, or prompt templates. - Logging, prompt + completion + tool-call + admin-audit + identity events captured per the SR-Software base pack; retention meeting the longest applicable regulation; export mechanism available. - Failure modes, documented fallback or degraded-mode behavior for LLM provider outage, model deprecation, and rate-limit events; no silent failure producing misleading output. - Disclosure, EU AI Act Art. 50 user-facing disclosure present for customer-visible AI interaction; deployer-duty evidence trail per Art. 26. - Residual risk list, explicit list of residual risks with named owner, accepted rationale, and expiry date.

Archetype-specific additions:

• LLM-integrated app: output filter wired and active before response leaves the service boundary; hallucination-consequence classification performed (does this output gate a decision, if yes, output-integrity requirement from SR applies); per-customer context isolation (no cross-tenant prompt leakage).

• AI agent: tool allowlist (every tool explicitly declared; no implicit tool access); per-tool scope minimization (each tool's parameter range restricted to the minimum required for the stated use case); human-in-the-loop gate (synchronous approval required for destructive actions, external-network calls, and customer-account-affecting tool invocations, gate specification includes timeout and fallback); kill-switch (emergency-halt mechanism in the design; test plan defined); session memory bounds (multi-turn memory bounded by session and token budget; no unbounded context accumulation across sessions); tool-call logging (full args and return value captured). Threats verified: EA (tool allowlist and scope minimization present), AGH (session memory bounds and HITL gate present), TM (argument schema validation per tool), RA (session termination condition defined and not bypassable by injected instructions). Primary ATLAS defensive mitigations checked: TA0007 Privilege Escalation mitigated by tool allowlist and scope minimization; TA0008 Defense Evasion mitigated by tool-call logging and kill-switch; TA0006 Persistence mitigated by session memory bounds.

• RAG pipeline: retrieval-source allow-list (all corpus sources enumerated; no dynamic source addition without change review); retrieval-source provenance (every document has a known origin, last-verified date, and trust classification); injection-defense (prompt structure separates instruction from retrieved content; retrieved content treated as untrusted); per-tenant retrieval isolation (verified at query time, not only at index time).

• Fine-tune / training workload: training-data provenance (every dataset has a documented origin, data-class classification, and consent basis or GDPR Art. 6 lawful basis for personal data); no-train assertion (vendor API contract explicit no-train clause AND admin-console setting confirmed, not DPA text alone); training-job isolation (training environment has no production network access); data minimization (corpus scoped to what is necessary for the stated capability objective); eval gating (model does not enter the model registry until it passes the eval harness).

• Eval harness: data isolation (eval data does not flow to training pipelines; production data handled with full logging and access controls); reproducibility (pinned data and model versions); regression corpora present in source control; findings routing to IM-Software backlog with severity tags; access control restricted to named personnel.

• Model-serving service: model-version pinning (callers cannot be silently moved to a different model family); canary deployment plan for new model versions; rollback playbook documented; rate-limit and abuse-detection at the serving layer; per-tenant isolation for multi-tenant serving; model version tracked in SM inventory.

• Classical ML model: model provenance (training data, feature set, version) tracked; model card published; inference-endpoint access control (no unauthenticated inference); per-request logging; model-drift monitoring baseline defined; rollback tested.

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

The two-lane model is driven by the SM 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 inventory record.
• Full-lane (High / Critical tier OR any pattern deviation OR agent archetype OR regulated-data involved): 45–60 minute architect review with the engineering team walking the SA 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 L2 tiers are established): agent archetypes and artifacts processing regulated data 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 inventory record, TA threat snapshot, and SR REM.

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

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-Software ownership. Recurring deviations are a signal the pattern is miscalibrated, not that engineering teams are wrong.
• SR pack update trigger: an SR requirement repeatedly waived with a compensating control auto-queues an SR pack-revision review. If every agent team waives the same base requirement, the pack needs recalibration.
• IM incident feedback loop: every IM-Software incident re-examines the DR decision record that approved the affected artifact. 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-Software 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 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.
• Engineering cycle-time impact, DR adds a small, predictable window; 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 reference pattern, SR requirements pack, and TA threat snapshot.
• 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 software artifacts going to production in the last 90 days carry a completed DR decision record before build-out begins.
• SA pattern-update and SR pack-update triggers wired so recurring deviations and waived requirements feed back; every IM-Software incident re-examines the DR record that approved the affected artifact.
• Named reviewer population trained (EG-Software L1) and active.

Maturity Level 2

Objective: Upgrade Critical-tier reviews to scenario-based walkthroughs driven by TA-Software per-artifact models, detect design drift for High and Critical artifacts on a published cadence, and run joint DR-Software / DR-Vendors reviews for Critical-tier first-party artifacts integrating with vendor AI

At this level, design review for Critical-tier artifacts moves from checklist conformance to scenario-based conversations. The TA-Software per-artifact deep threat models (available at TA L2) drive the scenarios. Design drift, the live artifact diverging from the approved design, is detected on a published cadence and automatically re-routed to DR. Where a Critical-tier first-party artifact integrates with an AI vendor, DR-Software coordinates a joint review with DR-Vendors.

Dependencies

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

Desired Outcomes

• Every Critical-tier DR covers 3–5 specific threat scenarios from the TA-Software library, with the decision tied explicitly to how the proposed 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 first-party artifact integrates with vendor AI, DR-Software and DR-Vendors produce joint review records with an explicit handoff 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 artifacts

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

• Source 3–5 specific threat scenarios from the TA-Software per-artifact deep threat model and from the TA-Software archetype library. Scenarios must be specific to this artifact's tool list, retrieval sources, data classes, and output-integrity-critical paths, not generic archetype scenarios.
• Walk each scenario: "If an adversary does X, does the proposed 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-Software per-artifact deep threat model; anonymized IM-Software incidents from the same archetype; MITRE ATLAS technique candidates for the artifact's primary defensive tactic coverage (TA0006 Persistence, TA0007 Privilege Escalation, TA0008 Defense Evasion mitigations verified as present in the design; TA0001 Reconnaissance and TA0003 Initial Access scenarios added where design decisions affect the initial-access surface); OWASP LLM / Agentic Top 10 entries relevant to the archetype.
• For High-tier artifacts: standard full-lane review augmented with at least one scenario from the TA archetype library; not a full scenario walkthrough.

B) Cross-org joint reviews for Critical-tier vendor AI integrations

When a Critical-tier first-party artifact integrates with a vendor AI service (an agent calling an external LLM API, a RAG pipeline over a vendor-hosted embedding service, a fine-tune job using a vendor-hosted training API), DR-Software coordinates with DR-Vendors:

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

C) Design-drift detection

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

• Critical-tier: quarterly drift check. Sources checked: code repository (changes since last DR that affect SA-pattern controls); model registry (model version or fine-tune lineage changes); deploy events (configuration changes at deploy time); CI/CD job parameters; IaC state (Terraform / Pulumi drift against the approved IaC module from SA-Software L2).
• High-tier: annual drift check using the same sources.
• Material drift (new tool added to an agent, new data class flowing into RAG or fine-tune, customer-exposure switched on, model family changed, new retrieval source added, new region) 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-Software refreshed quarterly; scenario content aligned to current TA-Software per-artifact models.
• Drift-detection tooling health monitored, staleness alert if a Critical artifact has no drift check in the last 90 days.
• Cross-org coordination channel with DR-Vendors 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-Software / DR-Vendors reviews reduce handoff gaps between first-party and vendor AI security decisions for Critical-tier artifacts.

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) artifacts; 100% of material drifts re-routed to DR.
• Joint DR-Software / DR-Vendors review records on file for 100% of Critical-tier first-party artifacts with vendor AI integrations.
• IR-stage design surprises measurably fewer than at L1 over consecutive quarters.

Maturity Level 3

Objective: Operate continuous design attestation via automated SA-pattern-compliance scans, automate drift-triggered DR exception tickets, and contribute review rubrics and scenario templates to OpenSSF AI, CSA, and OWASP SAMM AI

At this level, Critical-tier artifacts attest continuously rather than being reviewed periodically. SA-pattern-compliance scans produce a daily signal that the artifact's configuration and code remain 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, sector ISACs, IM-Software incidents) and internal signals (ML-Software telemetry, ST-Software red-team findings) on a quarterly cadence.

Dependencies

• DR-Software L2 (required): scenario reviews, drift detection, and joint-review process must be established before automation is trustworthy.
• SA-Software L3 (required): externalized patterns supply the attestation frame; automated SA-pattern-compliance scans verify against the published pattern.
• ML-Software L2+ (required): monitoring signals (config telemetry, logging completeness, model-version events) feed the continuous attestation pipeline.
• IM-Software 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 artifacts' 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, ISACs) and internal signals (IM-Software, ML-Software, ST-Software) 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 design-review ecosystem.
• DR review backlog shrinks to exception and novel-architecture work.

Activities

A) Continuous design attestation via automated SA-pattern-compliance scans

• Critical-tier artifacts produce a daily attestation signal covering: code-repo scan (SA reference pattern controls present and unmodified in the deployed codebase); model-registry check (model version and fine-tune lineage within the bounds approved at DR); IaC drift check (deployed configuration within tolerance of the approved IaC module from SA-Software L2); logging completeness check (ML-Software signal that required prompt/completion/tool-call/admin-audit event types are flowing at expected volume).
• Deviations from the approved design automatically open a DR-exception ticket in IM-Software; 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 that do not fit existing attestation rules; accepted exceptions with documented rationale; escalations from the IM-Software backlog.

B) Contribute review rubrics and scenario templates to industry

• Publish under Apache 2.0 or equivalent through OpenSSF AI, CSA AI Safety Initiative, OWASP SAMM AI extensions, or an applicable sector body:
• Per-archetype AI/HAI software design review rubric (tier-assignment criteria, checklist items with evidence pointers, scenario-selection guidance keyed to ATLAS tactics).
• Scenario template library (scenario format, per-archetype examples, debrief rubric for calibration exercises).
• Pattern-evolution framework (how external signals, ATLAS updates, ISACs 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 and refinements for TA0006 Persistence / TA0007 Privilege Escalation / TA0008 Defense Evasion as primary pre-deployment defensive tactic coverage; TA0001 Reconnaissance scenarios where design decisions affect the initial-access surface; sector ISAC AI-specific advisories; OWASP LLM / Agentic Top 10 revisions) plus internal signals (IM-Software incident patterns by archetype, ML-Software telemetry anomalies, ST-Software 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-Software and SR-Software as well, the traceability chain from threat to requirement to design review is maintained.

Outcome Metrics (L3)

Process Metrics (leading)

• Attestation-scan health, % Critical artifacts producing a fresh attestation signal in the last 24 hours; staleness alert if any Critical artifact silent for >48 hours.
• External-signal ingestion cadence, ATLAS and ISAC feeds processed monthly into the pattern-update queue.
• Contribution pipeline, ≥1 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 artifact 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 artifacts; DR-exception tickets opened on deviation and triaged within 3 business days.
• ≥2 externally contributed review artifacts per year (per-archetype rubrics, scenario templates, pattern-evolution frameworks) 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 TA0006/TA0007/TA0008, ISACs) and internal (IM-Software, ML-Software, ST-Software) signals with a versioned change log.

Key Success Indicators

Level 1: - Per-archetype AI/HAI Software Design Checklists published and versioned, one per SM-Software archetype (LLM-integrated app, agent, RAG, fine-tune/training, eval harness, model-serving service, classical ML), each traceable to the applicable SA reference pattern, SR requirements pack, and TA threat snapshot; agent checklist includes tool allowlist, per-tool scope minimization, HITL gate specification, kill-switch design, and tool-call logging items. - Two-lane review model operational (fast-lane ≤2 BD, full-lane ≤5 BD) with named lead reviewers per archetype trained on EG-Software L1 practitioner curriculum. - ≥95% of AI/HAI software artifacts going to production in the last 90 days carry a completed DR decision record before build-out 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-Software incident re-examines the DR record that approved the affected artifact.

Level 2: - 100% of Critical-tier DR reviews conducted as scenario-based walkthroughs with 3–5 scenarios sourced from TA-Software per-artifact deep models and anonymized IM-Software incidents; the DR decision is tied to how the design handles each scenario. - Design-drift detection operating quarterly for Critical and annually for High, using code-repo, model-registry, deploy-event, CI/CD, and IaC sources; 100% of material drifts re-routed to DR. - Joint DR-Software / DR-Vendors records on file for 100% of Critical-tier first-party artifacts integrating with vendor AI services. - IR-stage design surprises measurably fewer over consecutive quarters.

Level 3: - ≥90% of Critical-tier artifacts producing a daily automated SA-pattern-compliance attestation signal; deviations auto-open DR-exception tickets triaged within 3 business days. - ≥2 externally contributed review artifacts per year published to OpenSSF AI / CSA / OWASP SAMM AI with documented adoption; internal practice aligned to published versions. - Quarterly pattern-evolution loop traceable to MITRE ATLAS (TA0006/TA0007/TA0008 and TA0001), sector ISACs, IM-Software incidents, ML-Software telemetry, and ST-Software 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 engineering team has already built the feature, the checkpoint loses leverage because rework cost is already sunk; the review becomes a retrospective, not a gate. - ❌ Checklists are identical across archetypes, the agent checklist does not include HITL gate, tool allowlist, or kill-switch items because it was copy-pasted from the LLM-integrated app checklist. - ❌ Fast-lane becomes the default for everything, agent archetypes and regulated-data artifacts 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 inventory record, the program cannot answer "was this artifact reviewed?" without a manual search. - ❌ Checklist items are not traced to SA pattern controls or SR requirements, reviewers cannot explain why a specific item is on the checklist, so items get skipped without consequence.

Level 2: - ❌ "Scenario-based" review is the same checklist read aloud in a meeting, same items, different format; 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 TA-Software per-artifact deep model or recent IM-Software 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 artifact has diverged. - ❌ Joint DR-Software / DR-Vendors reviews never happen because the coordination channel with DR-Vendors was never established, Critical-tier first-party agents calling vendor AI APIs have no handoff 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 artifacts but the underlying checks cover only logging settings, tool allowlist state, model-version pinning, and HITL gate wiring are not checked; attestation is cosmetic. - ❌ Externally published rubrics diverge from internal practice, the published artifact reflects how the org reviewed artifacts 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 prompt-template commit opens a DR-exception ticket; reviewers suppress the signal source to stop the noise 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 OWASP / OpenSSF / CSA with documented adoption.

Practice Maturity Questions

Level 1: 1. Is there a published, versioned per-archetype AI/HAI Software Design Checklist, one per SM-Software archetype (LLM-integrated app, agent, RAG, fine-tune/training, eval harness, model-serving service, classical ML), traceable to the applicable SA reference pattern, SR requirements pack, and TA threat snapshot, with the agent checklist covering tool allowlist, per-tool scope minimization, HITL gate specification, kill-switch design, and tool-call logging? 2. Do ≥95% of AI/HAI software artifacts going to production in the last 90 days carry a completed DR decision record (approve / approve-with-conditions / send-back) before build-out begins, with a two-lane routing model (fast-lane ≤2 BD, full-lane ≤5 BD), named lead reviewers per archetype trained on EG-Software 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 pattern-update and SR pack-update reviews, and does every IM-Software incident trigger a re-examination of the DR record that approved the affected artifact?

Level 2: 1. Are 100% of Critical-tier DR reviews conducted as scenario-based walkthroughs, with 3–5 specific threat scenarios sourced from TA-Software per-artifact deep models and anonymized IM-Software incidents, 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 code-repository changes, model-registry events, deploy-event configs, CI/CD parameters, and IaC state, with 100% of material drifts automatically re-routed to DR for a new review? 3. Are joint DR-Software / DR-Vendors review records on file for 100% of Critical-tier first-party artifacts integrating with vendor AI services, with an explicit handoff boundary and shared residual-risk ownership documented in both DR records?

Level 3: 1. Are ≥90% of Critical-tier AI/HAI software artifacts producing a daily automated SA-pattern-compliance attestation signal, checking code-repo control presence, model-registry bounds, IaC drift, 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 OpenSSF AI, CSA AI Safety Initiative, or OWASP SAMM AI, 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 updates for TA0006/TA0007/TA0008 and TA0001, sector ISAC advisories) and internal signals (IM-Software incidents, ML-Software telemetry, ST-Software 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: Software Last Updated: 2026-05-13 Author: Verifhai