> **v3.0 canonical:** This questionnaire is authored against the v3.0 source-of-truth one-pager [`../practices/ML-Processes-OnePager.md`](../practices/ML-Processes-OnePager.md) and the §10.2 priority compliance map in [`../HAIAMM-v3.0-Framing.md`](../HAIAMM-v3.0-Framing.md). Through-lines: EU AI Act Art. 12 deployer-duty logs · GDPR Art. 22 automated-decision contestation evidence · GDPR Art. 30 records of processing · ISO/IEC 42001 AIMS operational evidence.

---

# Monitoring & Logging (ML) - Processes Domain
## HAIAMM Assessment Questionnaire v3.0

**Practice:** Monitoring & Logging (ML)
**Domain:** Processes
**Purpose:** Assess organizational maturity in establishing the per-archetype logging baseline for AI/HAI-embedded business workflows, operating a high-signal detection set targeting TA-Processes threats, and producing the evidence trail that satisfies EU AI Act Art. 12, GDPR Arts. 22 and 30, and ISO/IEC 42001 AIMS requirements on demand.

---

## Instructions

- Answer each question honestly based on **current, implemented practices** (not plans or aspirations)
- Each question has two components: **Evidence** (what you have done) and **Outcome Metrics** (how well it is working)
- **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 a lower level before advancing
- **Baseline first**, Record current metric values before setting targets

---

## Scoring Methodology

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

**Level score** = average of the three question scores for that level.
**Overall ML-Processes score** = weighted average: L1 × 0.5 + L2 × 0.3 + L3 × 0.2.

---

## Maturity Level 1
**Objective:** Establish the per-archetype logging baseline, operate a small high-signal detection set targeting the top TA-Processes threats, and produce an on-demand evidence trail that satisfies EU AI Act Art. 12, GDPR Arts. 22 and 30, and ISO/IEC 42001 AIMS requirements within a published SLA.

---

### Question 1: Per-Archetype Logging Baseline

**Q1.1:** Has a per-archetype logging baseline been published specifying the minimum event schema, fields, retention window, and export path for each AI/HAI process archetype in the SM-Processes inventory, and has compliance of each production workflow been measured against it within the last quarter?

**Evidence Required:**
- [ ] Published baseline specifying minimum events per archetype: decision pipeline (decision event/override event/decision-distribution metric), customer-facing flow (interaction/escalation/brand-safety-filter), HITL chain (review event/reviewer-capacity event), back-office augmentation (assistant-session/tool-call/output-review-gate), approval/review workflow (screen/threshold/tier-routing/class-shift-monitor), content-generation workflow (generation/output-review/copyright-filter/downstream-emission), knowledge-management workflow (query/retrieval/provenance/role-based-policy), and admin-audit + identity events cross-archetype
- [ ] Decision events capture: AI output (or hash), confidence score, decision threshold, final decision, model and version, and override flag, sufficient for GDPR Art. 22 contestation evidence
- [ ] HITL review events capture: reviewer identity (SSO-resolved), AI suggestion, reviewer decision, time-spent, rationale (mandatory for Critical/High-tier), and timestamp, sufficient for rubber-stamp detection
- [ ] Retention window configured per §10.2 priority compliance map: EU AI Act Art. 12 high-risk logs ≥6 months; GDPR Art. 22 contestation evidence per jurisdiction; FCRA adverse-action records 25 months; FINRA 6 years; HIPAA 6 years where applicable; longest governs per workflow
- [ ] Export path tested annually; on-demand pull SLA ≤24 hours; DSAR-capable export ≤72 hours for individual rights requests touching a decision or contestation record
- [ ] Compliance audit within the last quarter; gaps on IM-Processes backlog with named owner

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % production AI/HAI-embedded workflows meeting per-archetype logging baseline | ___% | ___% | ≥90% | ☐ | |
| % production workflows with retention meeting longest applicable regulation | ___% | ___% | 100% | ☐ | |
| Evidence pull SLA, on-demand (quarterly drill) | ___h | ___h | ≤24h | ☐ | |
| DSAR-capable export SLA test result | ___h | ___h | ≤72h | ☐ | |

**Metric Collection Guidance:**
- **Logging baseline compliance**: Cross-reference each production workflow against the published baseline checklist per archetype. Count workflows meeting all required fields divided by total workflows. Source: logging configuration audit × SM-Processes inventory.
- **Retention compliance**: Compare configured retention against longest applicable regulation from §10.2 for each workflow. Source: retention policy audit.
- **Evidence pull SLA**: Time the quarterly deployer-duty drill per archetype. Source: drill records.
- **DSAR SLA**: Time the DSAR export path test for a named individual's decision record. Source: DSAR drill records.

**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 logging baseline)

**Evidence Location:** _________________________________
**Validation Date:** _________________________________
**Notes:** _________________________________

---

### Question 2: High-Signal Detection Set

**Q1.2:** Is a high-signal detection set of ≤12 detections active, each tied to a TA-Processes archetype threat, including rubber-stamp HITL, reviewer-capacity saturation, override-audit anomaly, disclosure suppression, affected-persons-rights-response SLA breach, shadow-AI-in-process, and workflow-config drift, with false-positive rates tracked and monthly tuning reviews occurring?

**Evidence Required:**
- [ ] Detection registry: each entry includes owner, detection query, SLA, archetype tag, HAI-TTP tag, last-tuned date, and false-positive rate
- [ ] Rubber-stamp HITL detection active: reviewer decision matches AI recommendation ≥98% over rolling 100-item window per reviewer on Critical/High-tier workflows (EA TTP)
- [ ] Reviewer-capacity saturation detection active: SLA breach imminent, estimated time to SLA breach for HITL queue falls below configured warning threshold per HITL step
- [ ] Decision-distribution drift detection active (security-intersection only): class-shift on protected-attribute decision distribution beyond defined sigma from baseline; fires only on workflows in scope per SR-Processes
- [ ] Override-audit anomaly detection active: override event present without a corresponding rationale field for Critical/High-tier workflows (ATLAS TA0008 Defense Evasion)
- [ ] Disclosure-suppression detection active: Art. 50 disclosure UI not rendered in customer-facing flow execution where workflow definition requires it; fires on absent disclosure-shown flag
- [ ] Affected-persons-rights-response SLA breach detection active: contestation response window elapsed without a logged response event for GDPR Art. 22 workflows
- [ ] Shadow-AI-in-process detection active: new AI step detected in a workflow definition version not in SM-Processes inventory (ATLAS TA0001 / EA TTP)
- [ ] Workflow-config drift without DR record detection active: workflow definition promoted to production without a corresponding DR-Processes decision record in the last 5 business days (ATLAS TA0008)
- [ ] Monthly tuning review log with review dates and changes

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| Total active detections in detection registry | ___ | ___ | ≤12 | ☐ | |
| Median detection-to-IM-Processes-ticket time for Critical-tier workflows | ___h | ___h | ≤1h | ☐ | |
| % detections with FP rate tracked and last-tuned date ≤30 days | ___% | ___% | 100% | ☐ | |
| Monthly tuning reviews completed (last 12 months) | ___/12 | ___/12 | 12/12 | ☐ | |

**Metric Collection Guidance:**
- **Active detections**: Count entries in detection registry with status = active. Source: detection registry.
- **Detection-to-ticket time**: Measure from detection alert to IM-Processes ticket creation for Critical-tier workflow detections. Source: alert → ticket telemetry (P50).
- **FP rate tracked**: Count detections with FP rate populated and last-tuned date ≤30 days divided by total active detections. Source: detection tuning log.
- **Monthly reviews**: Count monthly tuning review sessions with documented output in the last 12 calendar months. Source: detection tuning log.

**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 active detection set)

**Evidence Location:** _________________________________
**Validation Date:** _________________________________
**Notes:** _________________________________

---

### Question 3: Deployer-Duty Evidence Trail

**Q1.3:** Has the evidence trail for EU AI Act Art. 12, GDPR Arts. 22 and 30, and ISO/IEC 42001 AIMS been wired to the ML-Processes log store, with retention meeting the longest applicable regulation including sector-specific windows, and has a quarterly deployer-duty drill confirmed evidence assembles within the ≤24-hour SLA?

**Evidence Required:**
- [ ] EU AI Act Art. 12 wiring: for every workflow involving an Annex III high-risk AI use case, decision/override/disclosure-shown/admin-audit events captured at required retention; deployer-duty evidence view (log record + retention attestation + export test result) produced per workflow
- [ ] GDPR Art. 22 wiring: for every decision-pipeline workflow subject to Art. 22, decision log contains AI output, threshold, final decision, and override flag per individual decision; export path confirms production of this record for a named individual within DSAR response window; log-store retention linked to Art. 22 contestation evidence requirement
- [ ] GDPR Art. 30 wiring: decision/interaction/reviewer events with principal identity, data-class tag, and purpose label constitute records-of-processing operational entries
- [ ] ISO/IEC 42001 AIMS wiring: workflow-definition version events, admin-audit events, threshold change events, and reviewer-pool change events identified as AIMS operational records; gaps on IM-Processes findings
- [ ] Quarterly deployer-duty drill records showing: workflow selected per archetype, drill start time, package assembly time, gaps found, disposition to IM-Processes
- [ ] §10.2 priority compliance map referenced; sector-specific retention windows (FCRA 25 months, FINRA 6 years, HIPAA 6 years) confirmed where applicable

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| Quarterly deployer-duty drills completed (last 4 quarters) | ___/4 | ___/4 | 4/4 | ☐ | |
| Evidence assembly time in most recent drill | ___h | ___h | ≤24h | ☐ | |
| % Annex III high-risk workflows with deployer-duty evidence view produced | ___% | ___% | 100% | ☐ | |
| % Art. 22 decision-pipeline workflows with individual-decision export path tested | ___% | ___% | 100% | ☐ | |

**Metric Collection Guidance:**
- **Drill completion**: Count quarterly drill sessions in the last 4 quarters with documented output. Source: drill records.
- **Assembly time**: Record most recent drill's assembly time. Source: drill records.
- **Evidence view coverage**: Count Annex III high-risk workflows with deployer-duty evidence view on file divided by total such workflows. Source: evidence registry × SM-Processes inventory.
- **Art. 22 export path**: Count Art. 22 decision-pipeline workflows with individual-decision export path tested (producing a named individual's decision record on demand) divided by total Art. 22 workflows. Source: DSAR drill records.

**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 evidence trail wiring or drill program)

**Evidence Location:** _________________________________
**Validation Date:** _________________________________
**Notes:** _________________________________

---

## Maturity Level 2
**Objective:** Calibrate logging depth and detection set to the SM-Processes L2 risk-tier rubric; integrate with SIEM for cross-workflow correlation; and feed incident-driven and ST-driven detection updates into a continuous tuning loop.

---

### Question 4: Tier-Calibrated Logging Depth

**Q2.1:** Is tier-calibrated logging depth applied per the SM-Processes L2 tier-treatment matrix, Critical-tier workflows retaining full decision and HITL event corpora at the longest regulatory window, Low-tier workflows receiving baseline only, and is this calibration automatically updated when a workflow is re-tiered?

**Evidence Required:**
- [ ] Tier-treatment matrix applied: Critical = full decision event content (AI output text or hash, full confidence scores, override rationale text) + full HITL events (reviewer identity, time-spent, full rationale) + full disclosure-completion events + full admin-audit at maximum fidelity; retained for longest regulatory window; per-workflow log partitioning; High = full decision and HITL events; Medium = hashed content; Low = baseline schema only + workflow-config drift and shadow-AI detections only
- [ ] Critical-tier workflows: per-workflow log partitioning enforced; all detections tuned to the workflow
- [ ] Re-tier update process: Critical re-tier logging depth updated within 14 days; other tiers within 30 days; evidence of last re-tier event with update timestamp
- [ ] ML-Processes log store is the primary source for PC-Processes compliance evidence bundles; ML logging-baseline validation element ≤30 days stale for Critical-tier workflows

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % Critical-tier workflows with full decision and HITL event corpora retained at longest regulatory window | ___% | ___% | 100% | ☐ | |
| % workflows with logging depth matching current tier assignment | ___% | ___% | 100% | ☐ | |
| ML logging-baseline validation freshness, Critical-tier (days) | ___d | ___d | ≤30d | ☐ | |
| Critical re-tier events with logging depth updated within 14 days (last 4 quarters) | ___% | ___% | 100% | ☐ | |

**Metric Collection Guidance:**
- **Critical-tier full corpus**: Audit log-store retention for each Critical-tier workflow. Confirm full decision and HITL event content at longest regulatory window. Source: log-store retention audit × SM-Processes inventory.
- **Tier-match coverage**: Compare current tier assignment to logging configuration for each workflow. Source: SM-Processes inventory × logging configuration audit.
- **Validation freshness**: Check date of most recent ML logging-baseline validation in PC-Processes evidence bundle per Critical-tier workflow. Source: evidence registry.
- **Re-tier compliance**: For each Critical re-tier event in the last 4 quarters, measure days from re-tier decision to logging configuration update. Source: SM-Processes change log × logging audit trail.

**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 tier-calibrated logging depth)

**Evidence Location:** _________________________________
**Validation Date:** _________________________________
**Notes:** _________________________________

---

### Question 5: SIEM Integration and Cross-Workflow Correlation

**Q2.2:** Is the SIEM ingesting ML-Processes log feeds with ≥3 cross-workflow correlation rules active, covering multi-workflow rubber-stamp correlation, disclosure-suppression plus decision-outcome-shift, and shadow-AI-in-process plus admin-audit-gap, and is a quarterly detection tuning cycle operating from IM-Processes post-incident and ST-Processes inputs?

**Evidence Required:**
- [ ] SIEM ingesting all tier-appropriate ML-Processes log feeds; ingestion health monitored; no rule silent >90 days without investigation
- [ ] Multi-workflow rubber-stamp correlation rule active: same reviewer exhibits rubber-stamp behavior (matches-AI ≥98%) on two or more Critical/High-tier workflows in same rolling window fires unified incident
- [ ] Disclosure-suppression plus decision-outcome-shift rule active: disclosure-suppression detection on a customer-facing flow correlates to a shift in that flow's decision distribution in the same time window; escalates to Critical regardless of workflow tier
- [ ] Shadow-AI-in-process plus admin-audit-gap rule active: shadow-AI-in-process detection correlates to missing admin-audit event for a workflow definition change in the same time window; signals covert workflow modification
- [ ] Quarterly detection review cycle records: IM-Processes post-incident input, ST-Processes finding input (HITL bypass test, disclosure rendering test), external advisory updates (EU AI Act enforcement decisions, NYC LL 144 findings, EEOC bias enforcement) assessed; ≥1 net detection change per cycle
- [ ] Monthly anomaly-baseline refresh for Critical and High-tier workflows documented

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| Cross-workflow SIEM correlation rules active and verified (last 90 days) | ___ | ___ | ≥3 active | ☐ | |
| Quarterly detection tuning cycles executed (last 4 quarters) | ___/4 | ___/4 | 4/4 | ☐ | |
| % Critical/High-tier workflows with anomaly-detection baselines established | ___% | ___% | ≥90% | ☐ | |
| Anomaly-detection FP rate for Critical-tier (trend direction) | ___ | ___ | trending down | ☐ | |

**Metric Collection Guidance:**
- **Correlation rules active**: Count SIEM rules with status = active; verify last-fired date ≤90 days or document no applicable events. Source: SIEM rule registry.
- **Tuning cycles**: Count quarterly cycles with documented IM-Processes and ST-Processes feedback integration and ≥1 net change. Source: detection change log.
- **Anomaly baselines**: Count Critical/High-tier workflows with behavioral anomaly-detection baselines divided by total Critical/High-tier workflows. Source: detection telemetry.
- **FP rate trend**: Compare anomaly FP rate current quarter vs. prior quarter for Critical-tier workflows. Source: alert telemetry.

**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 SIEM integration or tuning loop)

**Evidence Location:** _________________________________
**Validation Date:** _________________________________
**Notes:** _________________________________

---

### Question 6: Behavioral Anomaly Detection on Workflow Corpora

**Q2.3:** Are ≥90% of Critical/High-tier workflows running behavioral anomaly-detection baselines, with reviewer-behavior and decision-distribution profiles refreshed monthly and FP rates tracked and trending down, and is the ML logging-baseline validation element completing inside the ≤30-day staleness threshold for all Critical-tier workflows in PC-Processes compliance evidence bundles?

**Evidence Required:**
- [ ] Behavioral baselines established for Critical and High-tier workflows: reviewer decision-match rate, time-spent distribution, rationale frequency, override rate, per reviewer and per reviewer pool
- [ ] Decision-distribution baseline per workflow: rolling distribution of decision outcomes by class; anomaly threshold established
- [ ] Monthly baseline refresh cadence honored; last-refresh date per workflow; natural reviewer turnover accounted for in refresh cadence
- [ ] FP rate tracked per detection; detections exceeding 20% FP reviewed at quarterly cycle; detections not firing TP in 90 days reviewed for retirement
- [ ] PC-Processes compliance evidence bundle showing ML logging-baseline validation element ≤30 days for each Critical-tier workflow

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % Critical/High-tier workflows with behavioral anomaly-detection baselines | ___% | ___% | ≥90% | ☐ | |
| % anomaly-detection baselines refreshed monthly, Critical-tier (last 3 months) | ___% | ___% | 100% | ☐ | |
| Compliance evidence bundle ML validation freshness, Critical-tier (days) | ___d | ___d | ≤30d | ☐ | |
| HITL rubber-stamp incidents caught by rubber-stamp detection before regulatory audit (last 4 quarters) | ___ | ___ | documented | ☐ | |

**Metric Collection Guidance:**
- **Baseline establishment**: Count Critical/High-tier workflows with documented behavioral baselines divided by total Critical/High-tier workflows. Source: detection telemetry.
- **Refresh cadence**: For each Critical-tier workflow baseline, verify last-refresh date ≤30 days. Source: anomaly baseline refresh records.
- **Evidence bundle freshness**: Check ML logging-baseline validation date in PC-Processes compliance evidence bundle per Critical-tier workflow. Source: evidence registry.
- **Rubber-stamp detection**: Count IM-Processes tickets opened by rubber-stamp detection before a regulatory audit or external complaint in the last 4 quarters. Source: IM-Processes backlog.

**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 behavioral anomaly detection baselines)

**Evidence Location:** _________________________________
**Validation Date:** _________________________________
**Notes:** _________________________________

---

## Maturity Level 3
**Objective:** Express detections as code with automated deployment; apply behavioral anomaly detection to reviewer and decision-distribution corpora; and contribute anonymized detection signatures and telemetry schemas to OECD AI, ISO/IEC 42005, and sector ISACs.

---

### Question 7: Detection-as-Code for Processes Domain

**Q3.1:** Are ≥90% of detections expressed as version-controlled, CI/CD-deployed code artifacts with automated test coverage against realistic synthetic workflow log data, and is detection coverage auto-verified for 100% of new or re-tiered SM-Processes inventory entries within 24 hours?

**Evidence Required:**
- [ ] Detection registry showing ≥90% of active detections with source-control reference (repo, path, version)
- [ ] Detection CI/CD pipeline: unit tests over synthetic workflow log data (realistic HITL review events with reviewer identity and time-spent, decision events with AI output and confidence, disclosure-shown events with template version); integration tests against log replay environment
- [ ] Synthetic test data reflects realistic reviewer-behavior patterns, not generic workflow completion events
- [ ] Detection deployment via same change-management pipeline as workflow configuration; no ad hoc SIEM console edits; detection changes reviewed before deployment
- [ ] Automation verifying detection coverage on SM-Processes inventory change events within 24 hours; gap findings opened in IM-Processes automatically

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % detections expressed as version-controlled, CI/CD-deployed code artifacts | ___% | ___% | ≥90% | ☐ | |
| Detection coverage auto-verified on SM-Processes inventory change within 24h | ___% | ___% | 100% | ☐ | |
| Detection CI/CD pipeline health, builds passing (last 90 days) | ___% | ___% | ≥95% | ☐ | |
| Detection deployment lead time (merge to production) | ___h | ___h | <24h | ☐ | |

**Metric Collection Guidance:**
- **Detection-as-code coverage**: Count detections with source-control reference divided by total active detections. Source: detection registry × source control.
- **Auto-verification**: For each SM-Processes inventory change event in the last quarter, verify automated gap check triggered within 24 hours. Source: automation telemetry.
- **Pipeline health**: Count CI/CD detection pipeline builds with result = success divided by total builds in last 90 days. Source: CI/CD telemetry.
- **Lead time**: Measure time from detection code merge approval to production deployment. Source: CI/CD deployment records.

**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** (Detections not in source control or CI/CD)

**Evidence Location:** _________________________________
**Validation Date:** _________________________________
**Notes:** _________________________________

---

### Question 8: Behavioral Anomaly Detection on Reviewer and Decision Corpora

**Q3.2:** Are ≥90% of Critical/High-tier workflows running behavioral anomaly detection on reviewer and decision-distribution corpora, with anomaly models retrained monthly, model versions tracked in the model registry, and anomaly alerts feeding the IM-Processes incident backlog through the same detection-to-ticket pipeline?

**Evidence Required:**
- [ ] Reviewer-behavior anomaly model active: reviewer sessions with decision-pattern sequence (match rate, time-spent, rationale frequency, override rate) that is a statistical outlier from the reviewer's normal baseline and from the reviewer-pool baseline, signals reviewer fatigue, coercion, or systematic override manipulation
- [ ] Decision-distribution anomaly model active: rolling decision-outcome distribution that shifts beyond defined threshold from established baseline for security-intersection cases
- [ ] Disclosure-completion anomaly model active: per-execution disclosure completion rate dropping below baseline for a customer-facing flow on a rolling window, potential rendering failure, suppression, or covert workflow modification
- [ ] Knowledge-management RAG-behavior anomaly model active: retrieval patterns deviating from normal query behavior for a given role-class, potential RAG-poisoning or unauthorized knowledge-base manipulation
- [ ] Anomaly models retrained monthly; training data excludes incident-period reviewer logs (poisoned baseline prevention); model versions tracked in the model registry
- [ ] Anomaly model alerts route to IM-Processes through same detection-to-ticket pipeline as rule-based detections

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % Critical/High-tier workflows with behavioral anomaly detection active | ___% | ___% | ≥90% | ☐ | |
| Anomaly model retraining cadence honored (last 6 months) | ___/6 | ___/6 | 6/6 monthly | ☐ | |
| % anomaly model alerts routed to IM-Processes within ≤1h of detection | ___% | ___% | ≥95% | ☐ | |
| True-positive incidents surfaced first by behavioral anomaly detection, trend | ___ | ___ | trending up | ☐ | |

**Metric Collection Guidance:**
- **Anomaly detection coverage**: Count Critical/High-tier workflows with active behavioral anomaly models divided by total Critical/High-tier workflows. Source: anomaly model registry.
- **Retraining cadence**: Count months in the last 6 where a new anomaly model version was registered per workflow. Source: model registry.
- **Alert routing**: Count anomaly alerts reaching an IM-Processes ticket within 1 hour divided by total anomaly alerts. Source: alert → ticket telemetry.
- **TP trend**: Count incidents where first detection signal was a behavioral anomaly model alert by quarter. Source: incident retrospectives.

**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 behavioral anomaly detection)

**Evidence Location:** _________________________________
**Validation Date:** _________________________________
**Notes:** _________________________________

---

### Question 9: Industry Contribution, Processes-Domain Detection Signatures and Schemas

**Q3.3:** Has the program contributed ≥2 telemetry-standard artifacts per year to OECD AI, ISO/IEC 42005, or equivalent, and ≥12 anonymized detection signatures per year to sector ISACs, with contributions maintained current and external adoption tracked?

**Evidence Required:**
- [ ] OECD AI governance contribution records: AI/HAI workflow monitoring telemetry schema (decision event, HITL review event, disclosure-completion event, override audit event) as a candidate schema for cross-jurisdictional AI deployer-duty evidence standards
- [ ] ISO/IEC 42005 AI incident management contribution records: detection pattern examples for rubber-stamp HITL, disclosure suppression, and shadow-AI-in-process from production telemetry; at least one per annual cycle
- [ ] CSA AI Safety Initiative contribution records: anonymized detection signatures for workflow-specific AI risks (decision-distribution manipulation, HITL bypass, disclosure suppression)
- [ ] Sector ISAC submission records: anonymized, generalized detection signatures implementable by partner organizations without significant adaptation; legal-vet records per submission
- [ ] Contribution maintenance evidence: schema versioning showing contributions updated when internal practice evolves

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| Telemetry-standard contributions per year (OECD AI, ISO/IEC 42005, or equivalent) | ___ | ___ | ≥2 | ☐ | |
| ISAC detection signatures contributed per year | ___ | ___ | ≥12 | ☐ | |
| Contributions with evidence of external adoption (citations, publications, acknowledgments) | ___ | ___ | ≥1 | ☐ | |
| Contributed schemas maintained current (within 90 days of internal practice change) | ___% | ___% | 100% | ☐ | |

**Metric Collection Guidance:**
- **Telemetry contributions**: Count schema or detection-pattern contributions to OECD AI, ISO/IEC 42005, CSA, or equivalent in the last 12 months. Source: contribution log.
- **ISAC signatures**: Count anonymized process-domain detection signatures submitted to sector ISACs in the last 12 months. Source: contribution log × ISAC submission receipts.
- **External adoption**: Count external citations, integrations, or acknowledgments of contributed artifacts. Source: contribution tracking record.
- **Schema currency**: For each contributed schema, verify last-update date is within 90 days of the most recent internal practice change. Source: contribution version log.

**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 industry contributions)

**Evidence Location:** _________________________________
**Validation Date:** _________________________________
**Notes:** _________________________________

---

## Summary Scorecard

| Question | Level | Activity | Score (0.0 / 0.33 / 0.67 / 1.0) | Notes |
|----------|-------|----------|----------------------------------|-------|
| Q1: Per-Archetype Logging Baseline | L1 | A | | |
| Q2: High-Signal Detection Set | L1 | B | | |
| Q3: Deployer-Duty Evidence Trail | L1 | C | | |
| Q4: Tier-Calibrated Logging Depth | L2 | A | | |
| Q5: SIEM Integration and Cross-Workflow Correlation | L2 | B | | |
| Q6: Behavioral Anomaly Detection on Workflow Corpora | L2 | C | | |
| Q7: Detection-as-Code for Processes Domain | L3 | A | | |
| Q8: Behavioral Anomaly Detection on Reviewer and Decision Corpora | L3 | B | | |
| Q9: Industry Contribution, Processes-Domain | L3 | C | | |

**L1 Score** (avg Q1–Q3): _____ / 1.0
**L2 Score** (avg Q4–Q6): _____ / 1.0
**L3 Score** (avg Q7–Q9): _____ / 1.0
**Overall ML-Processes Score** (L1×0.5 + L2×0.3 + L3×0.2): _____ / 1.0

**Assessor:** _________________________________
**Assessment Date:** _________________________________
**Next Review Date:** _________________________________

---

**Document Version:** HAIAMM v3.0, 2026-05-15, Verifhai
**Practice:** Monitoring & Logging (ML)
**Domain:** Processes
**Source of Truth:** `docs/practices/ML-Processes-OnePager.md`
**Compliance Map:** `docs/HAIAMM-v3.0-Framing.md` §10.2