Design Review (DR) - Processes Assessment

Assessment questionnaire for measuring maturity. Answer each question honestly based on current, implemented practices.

v3.0 framing: The canonical source-of-truth for Design Review (DR) in the Processes domain is ../practices/DR-Processes-OnePager.md. This questionnaire is authored against that one-pager. Canonical subject and through-lines: ../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.

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.

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.

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.

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.

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.

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.

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).

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

Instructions:

Answer based on current practices, not plans
“Yes” requires documented evidence
Complete all Level 1 questions before Level 2
Partial implementation = “No”

↓ Download as Markdown