> **v3.0 framing:** The canonical source-of-truth for Design Review (DR) in the Processes domain is [`../practices/DR-Processes-OnePager.md`](../practices/DR-Processes-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) - Processes Domain
## HAIAMM Assessment Questionnaire v3.0

**Practice:** Design Review (DR)
**Domain:** Processes
**Purpose:** Assess organizational maturity in operating the design checkpoint between intake approval and go-live for every new AI-embedded business workflow, confirming HITL placement, Art. 50 disclosure UX, decision logging, override audit, output-integrity SLA, reviewer capacity, affected-persons rights, DPIA/FRIA status, and fallback/kill-switch are covered before the workflow touches affected persons
**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-Processes Score** = weighted average: L1 × 0.5 + L2 × 0.3 + L3 × 0.2

---

## Maturity Level 1
**Objective:** Run a per-archetype design checkpoint for every new AI-embedded workflow before go-live, producing a written decision traceable to the SA-Processes pattern, SR-Processes requirements pack, and TA-Processes threat snapshot

---

### Question 1: Per-Archetype AI-Embedded Workflow Design Checklist

**Q1.1:** Is there a published, versioned per-archetype AI-Embedded Workflow Design Checklist for all seven archetypes (decision pipeline, customer-facing flow, human-AI collaboration chain, back-office augmentation, approval/review workflow, content-generation workflow, knowledge-management workflow), traceable to the applicable SA-Processes reference pattern, SR-Processes requirements pack, and TA-Processes threat snapshot?

**Q1.2:** Does the common spine of each checklist cover HITL placement and depth (reviewer role, trigger condition, timeout, fallback, capacity model), Art. 50 disclosure design (UX present for AI-generated content or AI-assisted decisions visible to external persons), decision logging (field granularity, system, retention, traceability to affected person), override audit trail (reviewer identity, rationale, timestamp, queryable), output-integrity SLA (error rate, staleness, degraded-mode behavior), reviewer-capacity gating (SLA arithmetically achievable given staffed headcount), affected-persons rights surface (contestation channel identified and responsive), DPIA/FRIA status (DPIA triggered if Art. 35 applies; FRIA required if Annex III applies), and fallback/kill-switch (manual-process path for AI component outage; test plan defined)?

**Q1.3:** Do decision-pipeline checklists include the Annex III screen, Art. 22 lawful basis, appeal/explanation path, and class-shift monitoring baseline; and do customer-facing flow checklists include brand-safety filter placement and escalation path to human agent with SLA?

**Evidence Required:**
- [ ] Per-archetype checklist set published and version-controlled, one file or section per SM-Processes archetype with an explicit version stamp
- [ ] All nine common spine items present across all seven checklists
- [ ] Decision-pipeline checklist includes Annex III screen, Art. 22 lawful basis documentation, appeal/explanation path, and class-shift monitoring baseline
- [ ] Customer-facing flow checklist includes Art. 50 UX evidence pointer, brand-safety filter placement, and escalation path with SLA
- [ ] Each checklist item carries an evidence pointer traced to a specific SA-Processes pattern control or SR-Processes requirement
- [ ] Named lead reviewer per archetype confirmed (EG-Processes L1 completion verified); Privacy and Legal participation confirmed for full-lane reviews

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % AI-embedded workflows going live with a completed DR decision record | ___% | ___% | ≥95% | ☐ | SM inventory × DR records |
| % DR records referencing the applicable SA pattern and SR REM | ___% | ___% | 100% | ☐ | DR records |
| % Annex III / Art. 22 workflows with FRIA / DPIA status documented in the DR record | ___% | ___% | 100% | ☐ | DR records × compliance tracker |
| Median review turnaround, fast-lane | ___ BD | ___ BD | ≤2 BD | ☐ | Review SLA telemetry |

**Metric Collection Guidance:**
- **DR coverage**: Count AI-embedded workflows going live with a dated DR decision record predating go-live date, divided by total workflows promoted to production. Source: SM-Processes inventory joined to DR record store. Measured quarterly.
- **Annex III / Art. 22 coverage**: Count Annex III or Art. 22 workflows with FRIA/DPIA status documented in the DR record, divided by total Annex III / Art. 22 workflows. Source: DR record store joined to compliance tracker. Measured per deployment cycle.
- **Fast-lane SLA**: P50 of (DR decision date − review submission date) for fast-lane reviews. Full-lane (High/Critical, Annex III, Art. 22, sector-regulated, or pattern deviation) always routes to architect review with Privacy and Legal.

**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, FRIA/DPIA Identification, and Decision Records

**Q2.1:** Is a two-lane routing model operational, fast-lane (Low/Medium tier, on-pattern, no Annex III, no Art. 22, no sector-regulated, ≤2 BD) and full-lane (High/Critical tier, Annex III trigger, Art. 22 solely-automated-decision risk, sector-regulated, or pattern deviation, ≤5 BD with Privacy and Legal sign-off), with routing criteria published and applied consistently?

**Q2.2:** Are Annex III and Art. 22 triggers identified at design time, not post-deployment, and linked to the DR record with FRIA/DPIA status noted?

**Q2.3:** Does every DR decision record contain: decision (approve / approve-with-conditions / send-back); checklist with evidence pointers; deviations with rationale; residual risks with named owner and expiry; Privacy and Legal acknowledgment for Art. 22 / Annex III workflows; links to SM-Processes inventory, TA threat snapshot, SR REM, and FRIA/DPIA status?

**Evidence Required:**
- [ ] Routing criteria document specifying which tier/archetype/compliance combinations trigger full-lane vs. fast-lane (decision pipelines and customer-facing flows processing personal data default to full-lane at L1)
- [ ] Decision record template with all required fields used for the last 10 reviews (sample auditable)
- [ ] Privacy and Legal acknowledgment confirmed for at least one Art. 22 or Annex III full-lane review in the last 12 months
- [ ] Annex III screen embedded in the checklist for decision-pipeline archetype reviews
- [ ] Approve-with-conditions items in a trackable backlog with named owner and expiry date
- [ ] Sample of ≥5 decision records showing HITL capacity model confirmation (not blank)

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % Annex III / Art. 22 workflows with FRIA / DPIA status documented in the DR record | ___% | ___% | 100% | ☐ | DR records × compliance tracker |
| Open approve-with-conditions items aging >60 days | ___ | ___ | 0 | ☐ | Action-item backlog |
| Median review turnaround, full-lane | ___ BD | ___ BD | ≤5 BD | ☐ | Review SLA telemetry |
| % AI-embedded workflows going live with a completed DR decision record | ___% | ___% | ≥95% | ☐ | SM inventory × DR records |

**Metric Collection Guidance:**
- **Annex III / Art. 22 at-DR rate**: Count workflows where the Annex III / Art. 22 status was documented in the DR record before go-live, divided by total such workflows. Source: DR record store joined to compliance tracker. Measured per deployment cycle.
- **Approve-with-conditions aging**: Query action-item backlog for items where (today − condition creation date) > 60 days and status is not resolved. 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 two-lane routing model)

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

---

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

**Q3.1:** Are recurring pattern deviations and repeatedly-waived SR-Processes requirements automatically queuing SA-Processes pattern-update and SR-Processes 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-Processes incident trigger a re-examination of the DR decision record that approved the affected workflow, 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-Processes pattern-update review
- [ ] SA-Processes pattern-update queue and SR-Processes pack-update queue showing items from DR feedback in the last 12 months
- [ ] IM-Processes 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-Processes incident finding (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 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-Processes 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-Processes or SR-Processes update queues with a DR-feedback source reference. Measured quarterly.
- **IM incident DR re-examination**: Review IM-Processes 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; conduct FRIA workshops for Annex III workflows; detect design drift for High and Critical workflows; run cross-domain coordination with DR-Software for workflows wrapping first-party AI features

---

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

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

**Q4.2:** Do scenarios include compliance-specific cases, Annex III high-risk category scenarios, Art. 22 automated-decision challenge scenarios, Art. 50 disclosure failure scenarios, and sector-specific regulatory scenarios, specific to this workflow's HITL placement, data classes, and affected-person population?

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

**Evidence Required:**
- [ ] DR records for Critical-tier workflows showing scenario-based walkthrough format with ≥3 named scenarios per review, specific to the workflow's HITL placement, data classes, and affected-person population
- [ ] 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 signal provenance (TA-Processes model version, IM incident ID, or regulatory scenario reference)
- [ ] TA-Processes per-workflow deep threat model referenced in each Critical-tier DR record
- [ ] High-tier DR records showing at least one augmenting scenario from the TA-Processes archetype library
- [ ] Reviewer population trained on scenario-based walkthrough technique including compliance-scenario selection

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % Critical-tier DR records using scenario-based walkthrough | ___% | ___% | 100% | ☐ | DR records |
| % Annex III workflows with a completed FRIA workshop before go-live | ___% | ___% | 100% | ☐ | DR records × Annex III register |
| % Critical/High-tier workflows with drift check on published cadence | ___% | ___% | ≥95% | ☐ | Drift-check schedule × SM inventory |
| 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 or compliance scenarios, divided by total Critical-tier DR records. Measured quarterly.
- **FRIA workshop coverage**: Count Annex III workflows with a completed FRIA workshop artifact linked from the DR record, divided by total Annex III workflows. Source: DR record store joined to Annex III register. Measured per deployment 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 scenario-based reviews conducted)

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

---

### Question 5: FRIA Workshops and Joint DR-Processes / DR-Software Reviews

**Q5.1:** Do 100% of Annex III workflows receive a completed FRIA workshop before go-live, with attendees including named architect, Privacy, Legal, business owner, and an affected-person representative where feasible, and with the FRIA output linked from the DR decision record?

**Q5.2:** When a Critical-tier workflow wraps a first-party AI feature, do DR-Processes and DR-Software produce joint review records, with the handoff boundary (workflow controls vs. AI feature controls) documented in both records and shared residual risks assigned to a single named resolution owner?

**Q5.3:** Where the AI feature has no DR-Software record, does DR-Processes hold the workflow's Sanctioned status until DR-Software completes?

**Evidence Required:**
- [ ] FRIA workshop agenda template with all five required sections: affected-person population mapping, fundamental rights at stake, likelihood/severity assessment, mitigation design, residual rights exposure documentation
- [ ] At least one completed FRIA workshop artifact from the last 12 months, linked from the DR record, attendee list confirming Privacy and Legal participation
- [ ] Joint review calendar or coordination log showing DR-Processes and DR-Software reviewers attending the same session for Critical-tier workflows wrapping first-party AI features
- [ ] DR-Processes decision records referencing the corresponding DR-Software record identifier for Critical-tier joint reviews
- [ ] Handoff boundary documented in both records
- [ ] Sanctioned-status hold mechanism confirmed

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % Annex III workflows with a completed FRIA workshop before go-live | ___% | ___% | 100% | ☐ | DR records × Annex III register |
| % Critical-tier workflows wrapping first-party AI features with a joint DR-Processes / DR-Software record | ___% | ___% | 100% | ☐ | DR records × software integration tracker |
| % 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:**
- **FRIA workshop coverage**: Count Annex III workflows with a FRIA artifact linked from DR record before go-live, divided by total Annex III workflows. Measured per deployment cycle.
- **Joint record coverage**: Count Critical-tier workflows wrapping first-party AI features with a paired DR-Software record identifier in their DR-Processes record, divided by total such workflows. Measured quarterly.

**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 FRIA workshop process or joint review mechanism)

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

---

### Question 6: Design-Drift Detection for Workflows

**Q6.1:** Is design-drift detection operating quarterly for Critical-tier and annually for High-tier workflows, using workflow-tool config repos (Camunda / Temporal / Argo / ServiceNow BPM model versions), product-flow analytics, HITL queue configuration, override-audit-log schema, and Art. 50 disclosure presence in the deployed UI?

**Q6.2:** Are material drift findings (HITL gate removed or bypassed, AI component swapped, new affected-person population added, Art. 50 disclosure removed, decision-logging scope reduced, class-shift monitor disabled) automatically re-opening the DR record and routing back through the appropriate lane?

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

**Evidence Required:**
- [ ] Drift-detection schedule showing Critical workflows checked quarterly and High workflows annually
- [ ] Drift check artifacts (written diffs) for ≥3 Critical-tier workflows in the last 12 months, using workflow-config, product-flow analytics, HITL queue config, override-audit schema, and Art. 50 disclosure presence sources
- [ ] Classification criteria defining which delta types are material vs. non-material for workflow design
- [ ] At least one material drift finding that re-opened a DR record and routed to a new review
- [ ] Staleness alert configuration confirmed (Critical workflow silent for >90 days triggers alert)
- [ ] Art. 50 disclosure presence confirmed as a drift-check item (screenshot audit vs. approved disclosure design)

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % Critical/High-tier workflows 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 workflows with a documented drift check in the last 90 days, divided by total Critical workflows in SM-Processes 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 |
|-------------------|-----------------|-------|
| | | |

---

## Maturity Level 3
**Objective:** Operate continuous design attestation from workflow-execution telemetry, automate drift-triggered DR exception tickets, and contribute review rubrics and FRIA frameworks to OECD AI, ISO/IEC 42005, and sector standards bodies

---

### Question 7: Continuous Design Attestation via Workflow-Execution Telemetry

**Q7.1:** Are ≥90% of Critical-tier workflows producing a daily attestation signal, covering HITL gate health (queue throughput, override-rationale completion rate), decision-logging completeness (required fields flowing at expected volume), Art. 50 disclosure presence (automated probe confirms disclosure fires on every AI-touched interaction), override-audit freshness (entries written at rate implied by HITL throughput), and fallback/kill-switch readiness (synthetic test on published cadence), 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, Art. 26 deployer-duty documentation, and ISO/IEC 42001 AIMS operational records without manual assembly?

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

**Evidence Required:**
- [ ] Attestation pipeline configuration showing daily signal generation for Critical-tier workflows
- [ ] Coverage report: % of Critical-tier workflows producing a fresh attestation signal in the last 24 hours across all five signal types
- [ ] Sample attestation artifact covering: HITL gate health, decision-logging completeness, Art. 50 disclosure presence, override-audit freshness, fallback/kill-switch readiness
- [ ] 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 workflow silent for >48 hours triggers alert)

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % Critical-tier workflows 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 workflows with all five attestation signal types present in the last 24 hours, divided by total Critical workflows. Measured daily; alert if below 90%.
- **Exception ticket SLA**: P50 of (triage timestamp − open timestamp) for DR-exception tickets. 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 FRIA Frameworks to Industry

**Q8.1:** Has the program contributed ≥2 substantive review artifacts per year (per-archetype workflow design rubrics, FRIA workshop frameworks, scenario templates including Art. 22 challenge scenarios) to OECD AI Policy Observatory, ISO/IEC 42005 working groups, applicable sector bodies, or OWASP SAMM AI extensions, with documented adoption?

**Q8.2:** Are internal rubrics and the FRIA framework 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, sector bodies, or regulators?

**Evidence Required:**
- [ ] Contribution log showing ≥2 published artifacts in the last 12 months, per-archetype rubrics, FRIA workshop framework, or scenario templates
- [ ] Publication links (Apache 2.0 or equivalent) to OECD AI, ISO/IEC 42005, OWASP SAMM AI, or applicable sector body
- [ ] Adoption evidence: citations, forks, or written acknowledgment from a peer organization or regulatory body
- [ ] Internal FRIA framework compared to published version, confirmed aligned or upstream PR submitted
- [ ] 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, FRIA frameworks, scenario templates) | 0 | ___ | ≥2 | ☐ | Contribution log |
| % Critical-tier workflows 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. FRIA framework adoption tracked separately from rubric and scenario template adoption.
- **Adoption evidence**: Log citations and forks quarterly. Regulatory citations (references in supervisory guidance or enforcement decisions) tracked as a premium adoption signal.

**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 (OECD AI guidance on high-risk AI and HITL requirements; ISO/IEC 42005 updates; sector regulatory AI guidance; Annex III expansion or amendment updates) and internal signals (IM-Processes incident patterns, ML-Processes telemetry anomalies, ST-Processes 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 regulatory update or IM-Processes incident reveals a checklist gap, is the gap propagated to SA-Processes and SR-Processes to maintain the traceability chain from compliance obligation to requirement to design review?

**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 (OECD AI guidance reference, ISO/IEC 42005 update, Annex III amendment, or IM incident ID) for each update
- [ ] Evidence that Annex III expansion updates and sector regulatory AI guidance were reviewed in the last quarter
- [ ] In-flight DR review notifications sent when a pattern change affected the archetype under review
- [ ] SA-Processes and SR-Processes update items queued from pattern-evolution checklist gaps
- [ ] OECD AI, ISO/IEC 42005, and sector 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 workflows 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 (OECD AI guidance reference, ISO/IEC standard update, Annex III amendment, sector guidance, 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 Workflow Design Checklist | L1 | | |
| Q2: Two-Lane Routing, FRIA/DPIA Triggers, Decision Records | L1 | | |
| Q3: Loop-back to SA / SR / IM | L1 | | |
| Q4: Scenario-Based Reviews (Critical/High) | L2 | | |
| Q5: FRIA Workshops and Joint DR-Processes / DR-Software | L2 | | |
| Q6: Design-Drift Detection | L2 | | |
| Q7: Continuous Design Attestation | 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-Processes 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:** Processes
**Questionnaire Date:** 2026-05-15
**Author:** Verifhai