Monitoring & Logging (ML) - Software 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-Software-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 · 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.

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.

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.

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.

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.

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.

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.

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.

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

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