> **v3.0 canonical:** This questionnaire is authored against the v3.0 source-of-truth one-pager [`../practices/ML-Infrastructure-OnePager.md`](../practices/ML-Infrastructure-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 · sector cloud regulations (FedRAMP IR, ISO/IEC 27001 A.12) · GDPR processor obligations.

---

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

**Practice:** Monitoring & Logging (ML)
**Domain:** Infrastructure
**Purpose:** Assess organizational maturity in establishing the per-archetype logging baseline for all seven AI infrastructure archetypes, operating a high-signal detection set targeting TA-Infrastructure threats, and producing the evidence trail that satisfies EU AI Act Art. 12, applicable sector cloud regulations, and GDPR processor obligations 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-Infrastructure score** = weighted average: L1 × 0.5 + L2 × 0.3 + L3 × 0.2.

---

## Maturity Level 1
**Objective:** Establish the per-archetype logging baseline for all seven AI infrastructure archetypes, operate a small high-signal detection set targeting the top TA-Infrastructure threats, and produce an on-demand evidence trail satisfying EU AI Act Art. 12, applicable sector cloud regulations, and GDPR processor obligations 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 infrastructure archetype in the SM-Infrastructure inventory, and has compliance of each production component been measured against it within the last quarter?

**Evidence Required:**
- [ ] Published baseline specifying minimum events per archetype: inference endpoint (request/admin/rate-limit-abuse events), model registry (upload/promotion/deletion/access/signature-verification), GPU fleet (job-schedule/residual-state-clearing/anomalous-utilization), orchestrator (workflow-execution/step-principal/control-plane-API-audit/agent-state), vector store (query/ingest/retrieval-policy-decision), AI CI/CD (pipeline-run/eval-gate-decision/promotion/signature-verification), feature store (read/write/skew-detection), and admin-audit + identity events cross-archetype
- [ ] Retention window configured per §10.2 priority compliance map: EU AI Act Art. 12 high-risk logs ≥6 months; GDPR Art. 30 per data-class and purpose; sector-specific: FedRAMP IR ≥90 days, ISO/IEC 27001 A.12.4 per ISMS statement; HIPAA ≥6 years where applicable; longest governs
- [ ] Export path (JSON or structured format) 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 infrastructure operations teams and log store administrators
- [ ] Vector-store query events: query hash logged (not raw query text where regulated data may be present); retrieved document IDs and classification labels included
- [ ] Compliance audit within the last quarter, each production component scored against its archetype baseline; gaps on IM-Infrastructure backlog with named owner

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

**Metric Collection Guidance:**
- **Logging baseline compliance**: Cross-reference each production component in the SM-Infrastructure inventory against the published baseline checklist per archetype. Count components meeting all required fields divided by total components. Source: logging configuration audit × SM-Infrastructure inventory.
- **Retention compliance**: Compare configured retention against the longest applicable regulation from §10.2 for each component. Source: retention policy audit.
- **Evidence pull SLA**: Time the quarterly deployer-duty drill. Measure request trigger to assembled package. Source: drill records.
- **Gap count**: Count IM-Infrastructure open findings tagged "logging-baseline-gap" with a named owner. Source: IM-Infrastructure 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 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-Infrastructure archetype threat, including cross-tenant access, model swap without approval, GPU residual-state clearing failure, unsigned model artifact promotion, vector-store extraction pattern, CI/CD integrity failure, orchestrator workflow injection, and shadow inference endpoint, with false-positive rates tracked and monthly tuning reviews occurring?

**Evidence Required:**
- [ ] Detection registry: each entry includes owner, detection query, SLA, ATLAS-tactic or archetype-threat tag, last-tuned date, and false-positive rate
- [ ] Cross-tenant access attempt detection active: principal tenant-id in a request event does not match tenant-id of retrieved resource in a multi-tenant inference endpoint or vector store
- [ ] Model swap without approval detection active: model-swap or promotion event without an auditable approver principal and matching eval-gate-decision event
- [ ] GPU residual-state clearing failure detection active: residual-state-clearing event with result = failure fires immediately and routes to IM-Infrastructure as Critical
- [ ] Unsigned model artifact promoted to production detection active: promotion event where signature-verification result is failure or absent
- [ ] Vector-store extraction pattern detection active: principal's query event count or retrieved document count exceeds declared operational profile by 10× in rolling time window
- [ ] CI/CD pipeline integrity failure detection active: signature-verification result = failure on a pipeline artifact, or pipeline-run triggered by a principal not in the declared CI/CD service-account allowlist
- [ ] Orchestrator workflow injection detection active: step-principal event where executing principal does not match declared service account for that step type in the workflow definition
- [ ] Shadow inference endpoint detection active: cloud API discovery surfaces a new inference service endpoint not in the SM-Infrastructure inventory; fires on first-seen per endpoint-identity pair
- [ ] Monthly tuning review log with review dates and changes

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| Total active detections in detection registry | ___ | ___ | ≤12 (core 8 minimum) | ☐ | |
| Median detection-to-IM-ticket time for Critical-tier components | ___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-Infrastructure ticket creation for Critical-tier component 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 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, applicable sector cloud regulations, and GDPR processor obligations been wired to the ML-Infrastructure log store, and has a quarterly deployer-duty drill confirmed the evidence package for a randomly selected production component assembles within the ≤24-hour SLA?

**Evidence Required:**
- [ ] EU AI Act Art. 12 wiring: for every infrastructure component hosting an Annex III high-risk AI system, request/admin/identity events captured at required retention; deployer-duty evidence view (log record + retention attestation + export test result) produced per component
- [ ] Sector cloud regulation wiring: log completeness and retention mapped to active regulatory set per §10.2 priority compliance map (FedRAMP IR, ISO/IEC 27001 A.12.4, NIST AI RMF MANAGE); gaps between required event schema and deployed baseline are open IM-Infrastructure findings
- [ ] GDPR processor obligations wiring: for infrastructure components processing personal data (inference endpoints serving user inputs, vector stores holding PII-containing embeddings, CI/CD pipelines processing training data), request and ingest events with classification labels and tenant identifiers constitute operational records of processing; log-store retention linked to Art. 30 record per component
- [ ] Quarterly deployer-duty drill records showing: component selected per archetype, drill start time, package assembly time, gaps found, disposition to IM-Infrastructure

**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 infrastructure components with deployer-duty evidence view produced | ___% | ___% | 100% | ☐ | |
| Drill gaps routed to IM-Infrastructure with named owner | ___ | ___ | 0 unowned | ☐ | |

**Metric Collection Guidance:**
- **Drill completion**: Count quarterly drill sessions in the last 4 quarters with documented output, one per archetype in rotation. Source: drill records.
- **Assembly time**: Record the most recent drill's assembly time from request to assembled package. Source: drill records.
- **Evidence view coverage**: Count Annex III high-risk-hosting components with a deployer-duty evidence view on file divided by total such components. Source: evidence registry × SM-Infrastructure inventory.
- **Unowned gaps**: Count drill-gap IM-Infrastructure findings without an owner assigned. Source: IM-Infrastructure 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-Infrastructure L2 tier rubric; integrate with SIEM for cross-archetype 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-Infrastructure L2 tier-treatment matrix, Critical-tier components retaining full event corpora at the longest regulatory window, Low-tier components receiving baseline only, and is this calibration automatically updated when a component is re-tiered?

**Evidence Required:**
- [ ] Tier-treatment matrix applied: Critical = full request event corpus (including content or content hash) at longest regulatory window + full admin/identity/supply-chain events + per-tenant log isolation + all detections; High = full request and admin events; Medium = request-event summaries (tokens/latency/error, no content) + standard admin; Low = baseline schema only + shadow-endpoint detection only
- [ ] Critical-tier components: per-tenant log isolation enforced (Critical-tier logs partitioned from other tier logs); all detections tuned
- [ ] 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-Infrastructure log store is the primary source for PC-Infrastructure compliance evidence bundles; ML logging-baseline validation element ≤30 days stale for Critical-tier components

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % Critical-tier components with full event corpora retained at longest regulatory window | ___% | ___% | 100% | ☐ | |
| % components with logging depth matching current tier assignment | ___% | ___% | 100% | ☐ | |
| ML logging-baseline validation freshness, Critical-tier (days) | ___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 for each Critical-tier component. Confirm full event corpus at longest regulatory window. Source: log-store retention audit × SM-Infrastructure inventory.
- **Tier-match coverage**: Compare current tier assignment to logging configuration for each component. Source: SM-Infrastructure inventory × logging configuration audit.
- **Validation freshness**: Check date of most recent ML logging-baseline validation in PC-Infrastructure compliance evidence bundle per Critical-tier component. 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-Infrastructure 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-Archetype Correlation

**Q2.2:** Is the SIEM ingesting ML-Infrastructure log feeds with ≥3 cross-archetype correlation rules active, covering registry-to-endpoint pivot, identity pivot on supply-chain compromise, and vector-store mass-extraction plus JIT access anomaly, and is a quarterly detection tuning cycle operating from IM-Infrastructure post-incident and ST-Infrastructure inputs?

**Evidence Required:**
- [ ] SIEM ingesting all tier-appropriate ML-Infrastructure log feeds; ingestion health monitored; no rule silent >90 days without investigation
- [ ] Registry-to-endpoint pivot rule active: model registry promotion event for artifact X correlates to a model-swap event on an inference endpoint in the same time window without a change-calendar pre-approval fires unified incident
- [ ] Identity pivot on supply-chain compromise rule active: CI/CD pipeline integrity failure (unsigned pipeline execution) correlates to a subsequent model promotion from the same pipeline-id in the same session window; escalates to Critical regardless of tier
- [ ] Vector-store mass-extraction plus JIT access anomaly rule active: vector-store extraction pattern detection correlates to a JIT access grant to the vector-store admin interface from the same or related principal in the same time window
- [ ] Quarterly detection review cycle records: IM-Infrastructure post-incident input, ST-Infrastructure finding input, external advisory updates (ATLAS, CNCF security advisories, cloud-provider bulletins) assessed; ≥1 net detection change per cycle
- [ ] Monthly anomaly-baseline refresh for Critical and High-tier components documented; last-refresh date per component

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| Cross-archetype 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 components 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-Infrastructure and ST-Infrastructure feedback integration and ≥1 net change. Source: detection change log.
- **Anomaly baselines**: Count Critical/High-tier components with a behavioral anomaly-detection baseline divided by total Critical/High-tier components. Source: detection telemetry.
- **FP rate trend**: Compare anomaly-detection FP rate current quarter vs. prior quarter for Critical-tier components. 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 on AI Infrastructure Corpora

**Q2.3:** Are ≥90% of Critical/High-tier components 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 components in PC-Infrastructure compliance evidence bundles?

**Evidence Required:**
- [ ] Behavioral baselines established for Critical and High-tier components: request volume, retrieval volume, GPU utilization distribution, model-swap frequency, specific to each archetype's operational profile
- [ ] Monthly baseline refresh cadence honored; last-refresh date per component in the anomaly detection system
- [ ] FP rate tracked per detection; detections exceeding 20% FP reviewed at quarterly cycle; detections not firing a TP in 90 days reviewed for retirement
- [ ] PC-Infrastructure compliance evidence bundle showing ML logging-baseline validation element ≤30 days for each Critical-tier component

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % Critical/High-tier components with anomaly-detection behavioral baselines | ___% | ___% | ≥90% | ☐ | |
| % anomaly-detection baselines refreshed monthly, Critical-tier (last 3 months) | ___% | ___% | 100% | ☐ | |
| 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 components with a documented behavioral baseline divided by total Critical/High-tier components. Source: detection telemetry.
- **Refresh cadence**: For each Critical-tier component baseline, verify last-refresh date ≤30 days. Source: anomaly baseline refresh records.
- **Evidence bundle freshness**: Check ML logging-baseline validation date in PC-Infrastructure compliance evidence bundle per Critical-tier component. Source: evidence registry.
- **FP retirement review**: Count active detections with last-recorded FP rate >20% not 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 anomaly detection to request, access, and utilization corpora; contribute anonymized detection signatures and telemetry schemas to CNCF observability, OpenSSF AI, MITRE ATLAS, and sector ISACs.

---

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

**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-Infrastructure 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 infrastructure log data reflecting realistic archetype event patterns (inference endpoint request events, model registry promotion events, GPU residual-state clearing events, vector-store query events); integration tests against log replay environment
- [ ] Synthetic test data includes field combinations present in real cross-tenant access attempts and model-swap events, not generic HTTP events
- [ ] Detection deployment via same change-management pipeline as AI infrastructure IaC; no ad hoc SIEM console edits; detection changes reviewed before deployment
- [ ] Automation verifying detection coverage on SM-Infrastructure inventory change events within 24 hours; gap findings opened in IM-Infrastructure 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-Infrastructure 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-Infrastructure inventory change event in the last quarter, verify automated gap check 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 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: Anomaly Detection on AI Infrastructure Corpora at Scale

**Q3.2:** Are ≥90% of Critical/High-tier components running anomaly detection on request, access, and utilization corpora, with anomaly models retrained monthly on production log data and anomaly-model alerts feeding the IM-Infrastructure incident backlog through the same detection-to-ticket pipeline as rule-based detections?

**Evidence Required:**
- [ ] Request-volume anomaly on inference endpoints active: sessions or service accounts with request-volume or token-count distribution that is a statistical outlier from normal operational profiles (abuse patterns, prompt-bomb campaigns, scraping sessions)
- [ ] Retrieval-distribution anomaly on vector stores active: query sessions whose retrieved-document distribution shifts from baseline on a rolling window (systematic extraction of a specific corpus or tenant data)
- [ ] Model-swap frequency anomaly on model registry active: promotion frequency deviating from established baseline (multiple unscheduled swaps in a short window suggesting supply-chain tampering)
- [ ] GPU utilization anomaly active: GPU node utilization patterns deviating from the baseline for the registered workload (unauthorized training job, resource hijacking)
- [ ] Anomaly models retrained monthly; model versions tracked in the model registry; training data excludes labeled attacker-session logs from past incidents (poisoned baseline prevention)
- [ ] Anomaly model alerts route to IM-Infrastructure through same detection-to-ticket pipeline as rule-based detections; anomaly severity tagged to the component's tier

**Outcome Metrics:**
| Metric | Baseline | Current | Target | Met? | Notes |
|--------|----------|---------|--------|------|-------|
| % Critical/High-tier components with anomaly detection active on request, access, and utilization corpora | ___% | ___% | ≥90% | ☐ | |
| Anomaly model retraining cadence honored (last 6 months) | ___/6 | ___/6 | 6/6 monthly | ☐ | |
| % anomaly model alerts routed to IM-Infrastructure 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 components with active anomaly models covering the three corpus dimensions divided by total Critical/High-tier components. Source: anomaly model registry.
- **Retraining cadence**: Count months in the last 6 where a new anomaly model version was registered per component. Source: model registry.
- **Alert routing**: Count anomaly alerts reaching an IM-Infrastructure ticket within 1 hour divided by total anomaly alerts. Source: alert → ticket telemetry.
- **TP trend**: Count incidents where first detection signal was an 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 ML-driven anomaly detection on infrastructure corpora)

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

---

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

**Q3.3:** Has the program contributed ≥2 telemetry-standard artifacts per year to CNCF observability working group or OpenSSF AI Infrastructure, 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:**
- [ ] CNCF observability working group contribution records: OpenTelemetry semantic conventions for AI infrastructure event types (inference-endpoint request spans, model-registry promotion traces, GPU-job traces, vector-store query spans, orchestrator workflow traces); schema-spec format compatible with OTel specification process
- [ ] OpenSSF AI Infrastructure Working Group contribution records: detection-pattern examples for supply-chain events (unsigned model promotion, CI/CD integrity failure) and inference-infrastructure events (shadow endpoint, cross-tenant access) as OpenSSF reference detection modules
- [ ] MITRE ATLAS AML.M00xx mitigation entries proposed or validated: priority, cross-tenant access (TA0009 Collection), model swap without approval (TA0010 ML Supply Chain Compromise), orchestrator workflow injection (TA0008 Defense Evasion), GPU residual-state leakage (TA0013 Exfiltration)
- [ ] Sector ISAC submission records: anonymized, generalized AI infrastructure detection signatures; legal-vet records per submission; signatures implementable by partner organizations without significant adaptation
- [ ] Contribution maintenance evidence: schema versioning showing contributions updated when internal practice changes

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

**Metric Collection Guidance:**
- **Telemetry contributions**: Count schema or semantic-convention contributions to CNCF observability, OpenSSF AI Infrastructure, or equivalent in the last 12 months. Source: contribution log.
- **ISAC signatures**: Count anonymized AI infrastructure detection signatures submitted to sector ISACs in the last 12 months. Source: contribution log × ISAC submission receipts.
- **ATLAS entries**: Count AML.M00xx entries with the organization as proposer or validator. Source: ATLAS contribution log.
- **External adoption**: Count external citations, integrations, or acknowledgments. 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-Archetype Correlation | L2 | B | | |
| Q6: Anomaly Detection on Infrastructure Corpora | L2 | C | | |
| Q7: Detection-as-Code for Infrastructure Domain | L3 | A | | |
| Q8: Anomaly Detection at Scale | L3 | B | | |
| Q9: Industry Contribution, Infrastructure | 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-Infrastructure 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:** Infrastructure
**Source of Truth:** `docs/practices/ML-Infrastructure-OnePager.md`
**Compliance Map:** `docs/HAIAMM-v3.0-Framing.md` §10.2