> **v3.0 canonical:** This questionnaire is authored against the v3.0 source-of-truth one-pager [`../practices/ML-Software-OnePager.md`](../practices/ML-Software-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. 30 records of processing · ISO/IEC 42001 AIMS operational evidence.

---

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

**Practice:** Monitoring & Logging (ML)
**Domain:** Software
**Purpose:** Assess organizational maturity in establishing the per-archetype logging baseline, operating a high-signal detection set targeting TA-Software threats, and producing the evidence trail that satisfies EU AI Act Art. 12, GDPR Art. 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-Software 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-Software threats, and produce an on-demand evidence trail that satisfies EU AI Act Art. 12, GDPR Art. 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 software archetype in the SM-Software inventory, and has compliance of each production artifact been measured against it within the last quarter?

**Evidence Required:**
- [ ] Published baseline document specifying minimum event schema for each archetype: LLM-integrated app (prompt/completion/guardrail-decision/rate-limit), AI agent (all LLM-app events + tool-call/agent-goal-delta/HITL-gate/kill-switch), RAG pipeline (retrieval/injection-defense), fine-tune/training workload (training-job/model-promotion), eval harness (eval-run), model-serving service (version-deployment/canary-decision/rollback), classical ML (inference/drift-detection), and admin-audit + identity events across all archetypes
- [ ] Retention window configured to meet or exceed the longest applicable regulation: EU AI Act Art. 12 high-risk logs ≥6 months, GDPR Art. 30 per data-class and purpose, HIPAA PHI ≥6 years where applicable; longest governs per §10.2 priority compliance map
- [ ] Export path (JSON or structured CSV) tested at least annually per archetype; on-demand pull SLA ≤24 hours documented
- [ ] Log integrity: write-once or append-only storage for admin-audit and deployer-duty evidence tiers; access-control separation between application teams and log store administrators
- [ ] Compliance audit completed within the last quarter, each production artifact scored against its archetype baseline; gaps on IM-Software backlog with named owner
- [ ] PII scrubbing applied per SR-Software data-boundary requirements before logging; prompt text hashed where regulated data may be present

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % production AI/HAI software artifacts meeting per-archetype logging baseline | ___% | ___% | ≥90% | ☐ | |
| % production AI/HAI artifacts with retention meeting longest applicable regulation | ___% | ___% | 100% | ☐ | |
| Export SLA test result, on-demand pull time (quarterly drill) | ___h | ___h | ≤24h | ☐ | |
| Archetype-baseline gap count on IM-Software backlog with named owner | ___ | ___ | 0 unowned gaps | ☐ | |

**Metric Collection Guidance:**
- **Logging baseline compliance**: Cross-reference each production artifact in the SM-Software inventory against the published baseline checklist. Count artifacts meeting all required fields divided by total artifacts. Source: logging configuration audit.
- **Retention compliance**: For each artifact, compare configured log retention window against the longest applicable regulation from the §10.2 priority compliance map. Source: log-store retention policy audit.
- **Export SLA**: Time the quarterly deployer-duty drill, measure minutes from evidence-request trigger to assembled package. Source: drill records.
- **Gap count**: Count IM-Software open findings tagged "logging-baseline-gap" that have a named owner assigned. Source: IM-Software 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 evidence of 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-Software archetype threat, including AGH multi-turn drift, prompt-injection success, tool-scope violation, training-data-leakage canary, shadow-AI emergence, kill-switch-not-triggered, and HITL-gate-bypass, with false-positive rates tracked per detection and monthly tuning reviews occurring?

**Evidence Required:**
- [ ] Detection registry listing all active detections; each entry includes: owner, detection query, SLA (time-to-IM-ticket), ATLAS-tactic or HAI-TTP tag, last-tuned date, and false-positive rate
- [ ] AGH multi-turn drift detection active: agent goal declared at session start vs. tool invocations across turns; delta above threshold fires detection
- [ ] Prompt-injection success detection active: completion text matching exfiltration signatures (data-format markers, credential patterns, canary strings) on outbound completions
- [ ] Tool-scope-violation detection active: tool-call event where tool name is not in the artifact's declared allowlist or argument exceeds scoped range
- [ ] Training-data-leakage canary detection active: canary string injected into training corpus emitted verbatim in a completion
- [ ] Shadow-AI emergence detection active: new outbound network flow to an unsanctioned LLM provider domain from a service not in the SM-Software inventory
- [ ] Kill-switch-not-triggered detection active: incident-state flag active and kill-switch event absent within declared response SLA
- [ ] HITL-gate-bypass attempt detection active: repeated HITL decline followed by tool invocation attempt in same session without a new gate event
- [ ] Monthly tuning review log showing review dates, detections reviewed, changes made or deferred

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| Total active detections in detection registry | ___ | ___ | ≤12 | ☐ | |
| Median detection-to-IM-ticket time for Critical-tier artifacts | ___h | ___h | ≤1h | ☐ | |
| % detections with false-positive rate tracked (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 time from detection alert to IM-Software ticket creation for Critical-tier artifact detections. Source: alert → ticket telemetry (P50).
- **FP rate tracked**: Count detections with a false-positive rate field populated and last-tuned date within 30 days, divided by total active detections. Source: detection tuning log.
- **Monthly reviews**: Count monthly tuning review sessions with recorded 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 Art. 30, and ISO/IEC 42001 AIMS been wired to the ML-Software log store, and has a quarterly deployer-duty drill confirmed that the evidence package for a randomly selected production artifact can be assembled within the ≤24-hour SLA?

**Evidence Required:**
- [ ] EU AI Act Art. 12 wiring: for every Annex III high-risk or decision-affecting artifact, prompt/completion, tool-call, and admin-audit events are captured at required retention; deployer-duty evidence view (log record + retention attestation + export test result) produced per such artifact
- [ ] GDPR Art. 30 wiring: for every artifact processing personal data, prompt/completion log entries with principal identity, data-class tag, and purpose label link to the Art. 30 record; log-store retention policy linked to the Art. 30 record per artifact
- [ ] ISO/IEC 42001 AIMS wiring: training-job events, model-promotion events, eval-run events, and admin-audit events identified as AIMS operational records; gaps opened as IM-Software findings
- [ ] Quarterly deployer-duty drill records showing: artifact selected, drill start time, package assembly time, gaps found (if any), and disposition of gaps to IM-Software
- [ ] §10.2 priority compliance map referenced in retention and exportability evidence requirements for each high-risk artifact

**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 | ☐ | |
| % high-risk/decision-affecting artifacts with deployer-duty evidence view produced | ___% | ___% | 100% | ☐ | |
| Drill gaps routed to IM-Software with named owner | ___ | ___ | 0 unowned | ☐ | |

**Metric Collection Guidance:**
- **Drill completion**: Count quarterly drill sessions executed with documented output in the last four calendar quarters. Source: drill records.
- **Assembly time**: Time from the drill's evidence-request trigger to assembled package, as recorded in the most recent drill record. Source: drill records.
- **Evidence view coverage**: Count Annex III high-risk and decision-affecting artifacts with a deployer-duty evidence view on file (log record + retention attestation + export test result) divided by total such artifacts in the SM-Software inventory. Source: evidence registry.
- **Unowned gaps**: Count drill-gap IM-Software findings without an owner assigned. Source: IM-Software 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 evidence trail wiring or drill program)

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

---

## Maturity Level 2
**Objective:** Calibrate logging depth and detection set to the SM-Software L2 risk-tier rubric; integrate with SIEM for cross-artifact 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-Software L2 tier-treatment matrix, Critical-tier artifacts retaining full prompt/completion and tool-call corpora at the longest regulatory window, Low-tier artifacts receiving baseline only, and is this calibration automatically updated when an artifact is re-tiered?

**Evidence Required:**
- [ ] Tier-treatment matrix implemented: Critical = full prompt text + completion text + full tool-call arguments + returns at longest regulatory window; High = full prompt/completion retained; Medium = prompt/completion hashes retained; Low = baseline schema only
- [ ] Critical-tier artifacts: full prompt/completion and tool-call corpora retained; per-tenant log isolation enforced (Critical-tier logs partitioned from other tiers); all detections tuned to the artifact
- [ ] Re-tier update process documented: Critical re-tier logging depth updated within 14 days; other tiers within 30 days
- [ ] ML log store is the primary source for PC-Software compliance evidence bundles; ML logging-baseline validation element ≤30 days stale for Critical-tier artifacts
- [ ] Evidence of most recent re-tier event showing logging depth updated within the required window

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % Critical-tier artifacts with full prompt/completion + tool-call corpora retained at longest regulatory window | ___% | ___% | 100% | ☐ | |
| % artifacts with logging depth matching current tier assignment | ___% | ___% | 100% | ☐ | |
| ML logging-baseline validation freshness for Critical-tier artifacts (days since last validation) | ___d | ___d | ≤30d | ☐ | |
| Re-tier events with logging depth updated within required window (last 4 quarters) | ___% | ___% | 100% | ☐ | |

**Metric Collection Guidance:**
- **Critical-tier full corpus**: Audit log-store retention configuration for each Critical-tier artifact in SM-Software inventory. Confirm full prompt/completion text (not hashes) retained for the longest regulatory window. Source: log-store retention audit × SM inventory.
- **Tier-match coverage**: Compare current tier assignment for each artifact to its logging configuration; count matches. Source: SM inventory × logging configuration audit.
- **Validation freshness**: Check the date of the most recent ML logging-baseline validation in the PC-Software compliance evidence bundle for each Critical-tier artifact. Source: evidence registry.
- **Re-tier compliance**: For each re-tier event in the last 4 quarters, measure days from re-tier decision to logging configuration update. Source: SM inventory change log × logging configuration 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-Artifact Correlation

**Q2.2:** Is the SIEM ingesting ML-Software log feeds with ≥3 cross-artifact correlation rules active, covering multi-artifact AGH correlation, training-to-inference leakage chain, and shadow-AI emergence plus identity pivot, and is a quarterly detection tuning cycle operating from IM-Software post-incident and ST-Software finding inputs?

**Evidence Required:**
- [ ] SIEM ingesting all tier-appropriate ML-Software log feeds; ingestion health monitored
- [ ] Multi-artifact AGH correlation rule active: same principal in HITL-gate-bypass attempts on ≥2 agent artifacts in same session window fires a unified incident
- [ ] Training-to-inference leakage chain rule active: canary-string detection in a completion correlated to the training-job event linking to the canary-containing dataset version escalates to Critical
- [ ] Shadow-AI emergence plus identity pivot rule active: shadow-AI emergence detection correlates to unusual SSO sign-in to LLM provider admin console from same service-principal in same time window
- [ ] Quarterly detection review cycle records showing: IM-Software post-incident reviews, ST-Software findings, external advisory updates (ATLAS, OWASP LLM, AVID) assessed; ≥1 net detection change per cycle
- [ ] Monthly anomaly-baseline refresh for Critical and High-tier artifacts documented

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| Cross-artifact SIEM correlation rules live and firing within last 90 days (or no applicable events) | ___ | ___ | ≥3 active | ☐ | |
| Quarterly detection tuning cycles executed (last 4 quarters) | ___/4 | ___/4 | 4/4 | ☐ | |
| % Critical/High-tier artifacts 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 correlation rules in the rule registry with status = active. Verify last-fired date ≤90 days or document that no applicable events occurred in the window. Source: SIEM rule registry.
- **Tuning cycles**: Count quarterly detection review sessions with documented IM-Software and ST-Software feedback integration and ≥1 net change (new, updated, or retired detection). Source: detection change log.
- **Anomaly baselines**: Count Critical/High-tier artifacts with a behavioral anomaly-detection baseline established divided by total Critical/High-tier artifacts. Source: detection telemetry.
- **FP rate trend**: Compare anomaly-detection FP rate in the current quarter to the prior quarter for Critical-tier artifacts. 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: Anomaly Detection and Detection Tuning Loop

**Q2.3:** Are ≥90% of Critical/High-tier artifacts running anomaly-detection baselines with behavioral 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 artifacts in PC-Software compliance evidence bundles?

**Evidence Required:**
- [ ] Behavioral baselines established for Critical and High-tier artifacts: prompt volume, tool-call patterns, completion-latency distribution, tool-call argument distributions
- [ ] Monthly anomaly-baseline refresh cadence honored; refresh records showing last-refresh date per artifact
- [ ] FP rate tracked per detection; detections exceeding 20% FP rate reviewed at quarterly cycle for retirement
- [ ] Detections not firing a true positive in 90 days reviewed at quarterly cycle for retirement
- [ ] PC-Software compliance evidence bundle showing ML logging-baseline validation element with freshness ≤30 days for each Critical-tier artifact

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % Critical/High-tier artifacts with anomaly-detection behavioral baselines established | ___% | ___% | ≥90% | ☐ | |
| % anomaly-detection baselines refreshed monthly (last 3 months) | ___% | ___% | 100% of Critical-tier | ☐ | |
| Compliance evidence bundle ML validation element freshness, Critical-tier (days) | ___d | ___d | ≤30d | ☐ | |
| Detections with FP rate >20% still active without retirement review | ___ | ___ | 0 | ☐ | |

**Metric Collection Guidance:**
- **Baseline establishment**: Count Critical/High-tier artifacts with a documented behavioral baseline in the anomaly detection system divided by total Critical/High-tier artifacts. Source: detection telemetry.
- **Refresh cadence**: For each Critical-tier artifact baseline, verify last-refresh date is within 30 days. Source: anomaly baseline refresh records.
- **Evidence bundle freshness**: Check ML logging-baseline validation date in the PC-Software compliance evidence bundle for each Critical-tier artifact. Source: evidence registry.
- **FP retirement review**: Count active detections with last-recorded FP rate >20% that have not been reviewed at a quarterly cycle since the rate was recorded. 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 anomaly detection baselines)

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

---

## Maturity Level 3
**Objective:** Express detections as code with automated deployment; apply ML-driven anomaly detection to prompt/completion and tool-call corpora; contribute anonymized detection signatures and telemetry schemas to OWASP LLM, MITRE ATLAS, and sector ISACs.

---

### Question 7: Detection-as-Code

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

**Evidence Required:**
- [ ] Detection registry showing ≥90% of active detections with a source-control reference (repo, path, version)
- [ ] Detection CI/CD pipeline: changes trigger a test suite (unit tests over synthetic log data, integration tests against log replay environment) before production deployment
- [ ] Detection tests use realistic synthetic log data (not generic events), unit test coverage for each detection query
- [ ] Detection deployment via the same change-management pipeline as AI/HAI software; no ad hoc SIEM console edits
- [ ] Automation verifying detection coverage on SM inventory change events: new archetype registration or Critical re-tier triggers a gap check within 24 hours; gap findings opened in IM-Software 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 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 in the registry with a source-control reference divided by total active detections. Source: detection registry × source control.
- **Auto-verification**: For each SM inventory change event in the last quarter, verify an automated gap check was triggered and completed within 24 hours. Source: automation telemetry.
- **Pipeline health**: Count CI/CD detection pipeline builds with result = success divided by total builds in the 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: ML-Driven Anomaly Detection on AI/HAI Corpora

**Q3.2:** Are ≥90% of Critical/High-tier artifacts running ML-driven anomaly detection on prompt/completion and tool-call corpora, with anomaly models retrained monthly on production log data, model versions tracked in the ML-Software model registry, and anomaly-model alerts feeding the IM-Software incident backlog through the same detection-to-ticket pipeline?

**Evidence Required:**
- [ ] Anomaly models applied to prompt/completion and tool-call corpora for Critical and High-tier artifacts: prompt-sequence anomaly (attacker-probing, jailbreak-escalation, multi-turn goal-hijack), completion-distribution anomaly (output integrity regression or prompt-injection influence), tool-call argument anomaly (novel TM TTP variants)
- [ ] Model registry entries for each anomaly model version: retraining date, training data window, performance metrics, lineage
- [ ] Monthly retraining cadence honored; retrained-model versions visible in the model registry
- [ ] Anomaly model alerts route to IM-Software through the same detection-to-ticket pipeline as rule-based detections; anomaly severity tagged to the artifact's tier
- [ ] Evidence that anomaly model training excludes labeled attacker-session logs from past incidents (poisoned baseline prevention)

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % Critical/High-tier artifacts with ML-driven anomaly detection active on prompt/completion + tool-call corpora | ___% | ___% | ≥90% | ☐ | |
| Anomaly model retraining cadence honored (last 6 months) | ___/6 | ___/6 | 6/6 monthly | ☐ | |
| % anomaly model alerts routed to IM-Software within ≤1h of detection | ___% | ___% | ≥95% | ☐ | |
| True-positive incidents surfaced first by anomaly detection (vs. rule-based), trend | ___ | ___ | trending up | ☐ | |

**Metric Collection Guidance:**
- **Anomaly detection coverage**: Count Critical/High-tier artifacts with active anomaly detection models on both prompt/completion and tool-call corpora divided by total Critical/High-tier artifacts. Source: anomaly model registry.
- **Retraining cadence**: Count months in the last 6 where a new anomaly model version was registered in the model registry per artifact. Source: model registry.
- **Alert routing**: Count anomaly alerts that reached an IM-Software ticket within 1 hour of detection divided by total anomaly alerts. Source: alert → ticket telemetry.
- **TP trend**: Count incidents where the first detection signal was an anomaly model alert (vs. rule-based or external notification) 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 ML-driven anomaly detection)

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

---

### Question 9: Industry Contribution, Detection Signatures and Telemetry Schemas

**Q3.3:** Has the program contributed ≥2 telemetry-standard artifacts per year to the OpenTelemetry AI workgroup or equivalent and ≥12 anonymized detection signatures per year to sector ISACs, and has it proposed or validated ≥2 MITRE ATLAS AML.M00xx detection-mitigation entries, with contributions maintained current and external adoption tracked?

**Evidence Required:**
- [ ] OpenTelemetry AI workgroup contribution records: semantic conventions for AI/HAI event types (prompt/completion spans, tool-call spans, agent-session traces, training-job events); schema-spec format compatible with OTel specification process
- [ ] MITRE ATLAS AML.M00xx mitigation entries proposed or validated: priority, TA0001 Reconnaissance (shadow-AI emergence), TA0008 Defense Evasion (HITL-gate bypass), TA0013 Exfiltration (canary detection), TA0014 Impact (kill-switch coverage)
- [ ] OWASP LLM / Agentic Top 10 contribution records: detection-pattern examples from production telemetry; at least one detection pattern per annual cycle
- [ ] Sector ISAC submission records (FS-ISAC, H-ISAC, IT-ISAC AI working groups): anonymized, generalized detection signatures; legal-vet records for each submission
- [ ] Contribution maintenance evidence: schema versioning showing contributions updated when internal practice changes; not point-in-time submissions

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| Telemetry-standard contributions per year (OpenTelemetry AI workgroup or equivalent) | ___ | ___ | ≥2 | ☐ | |
| ISAC detection signatures contributed per year (sector ISACs) | ___ | ___ | ≥12 | ☐ | |
| ATLAS AML.M00xx detection-mitigation entries proposed or validated | ___ | ___ | ≥2 | ☐ | |
| Contributions with evidence of external adoption (citations, integrations, acknowledgments) | ___ | ___ | ≥1 | ☐ | |

**Metric Collection Guidance:**
- **Telemetry contributions**: Count schema or semantic-convention contributions submitted to OpenTelemetry AI workgroup or equivalent in the last 12 months with status (draft, in-review, submitted, published). Source: contribution log.
- **ISAC signatures**: Count anonymized detection signatures submitted to sector ISACs in the last 12 months; one per submission event. Source: contribution log × ISAC submission receipts.
- **ATLAS entries**: Count ATLAS AML.M00xx entries with the organization listed as proposer or validator. Source: ATLAS contribution log.
- **External adoption**: Count external citations, integrations, or standards-body acknowledgments of contributed artifacts in the last 12 months. Source: contribution tracking record.

**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-Artifact Correlation | L2 | B | | |
| Q6: Anomaly Detection and Tuning Loop | L2 | C | | |
| Q7: Detection-as-Code | L3 | A | | |
| Q8: ML-Driven Anomaly Detection on AI/HAI Corpora | L3 | B | | |
| Q9: Industry Contribution | 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-Software 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:** Software
**Source of Truth:** `docs/practices/ML-Software-OnePager.md`
**Compliance Map:** `docs/HAIAMM-v3.0-Framing.md` §10.2