Monitoring & Logging (ML) - Infrastructure Assessment

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

v3.0 canonical: This questionnaire is authored against the v3.0 source-of-truth one-pager ../practices/ML-Infrastructure-OnePager.md and the §10.2 priority compliance map in ../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.

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.

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.

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.

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.

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.

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.

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.

Evidence Location: _____ Validation Date: ____ Notes: ______

Summary Scorecard

Question	Level	Activity
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

Instructions:

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

↓ Download as Markdown