# HAIAMM Unified Metrics Framework

**Version:** 3.0 (2026-05-14)
**Status:** Current
**Canonical reference:** [`HAIAMM-v3.0-Framing.md`](HAIAMM-v3.0-Framing.md) §10.5 (metrics taxonomy), §8.2 (level block schema), §12.3 (metric rule)

---

## Purpose

This document defines the **canonical metric vocabulary** shared across all 216 (domain × practice × level) cells in HAIAMM v3.0. Every one-pager carries three metric types in every level block; every metric follows the SMART criteria and favors outcome over output. This document is the single authoritative reference for what those metric types mean, how they are structured, and what distinguishes good metrics from anti-patterns.

**Scope.** This framework applies to all 12 practices (SM, PC, EG, TA, SR, SA, DR, IR, ST, EH, IM, ML) across all 6 domains (Software, Data, Infrastructure, Vendors, Processes, Endpoints) at all 3 maturity levels.

**What this document does not do.** It does not list every metric for every cell. Cell-specific metric values, baselines, targets, and sources live in the one-pagers themselves. This document defines the taxonomy, the four-column table format, the per-level expectations, the cross-domain metric families, and the anti-patterns to avoid.

---

## 1. The Three Metric Types

Per §10.5 of the v3.0 framing, every level block in every HAIAMM cell carries exactly three metric types. Together they cover *whether the outcome was achieved*, *whether the program is on track*, and *whether the outcome matters to the business*.

### 1.1 Outcome Metrics (Lagging)

**Definition.** Outcome metrics directly measure whether the level's stated goal was achieved. They are the ground-truth of the practice: if the outcome metrics are met, the level is credibly claimed.

**Timeframe.** Monthly or quarterly. Outcome metrics look backward at what has been accomplished.

**Format.** Every outcome metric appears in a four-column table (see §4). Each row states a metric name, a baseline requirement, a level-specific target, and the source from which the number is read.

**What qualifies.** The metric measures a *result*, not an activity. "Shadow-AI-in-engineering ratio at or below 15%" is an outcome. "Discovery sweeps completed" is not, it is an activity count and belongs in process metrics.

**Examples across practices:**

| Practice | Example Outcome Metric | Example L1 Target |
|---|---|---|
| SM | Shadow-AI ratio (unsanctioned ÷ total AI artifacts in production) | ≤15% and trending down |
| PC | AUP attestation coverage across in-scope population | ≥95% |
| EG | % practitioners passing role-based AI-security literacy assessment | ≥80% |
| TA | % AI/HAI archetypes with a current published threat snapshot | ≥90% |
| SR | % requirements in the base pack with a testable acceptance criterion | 100% |
| SA | % AI/HAI archetypes with a published reference pattern | ≥80% |
| DR | % intake submissions receiving a written DR decision within SLA | ≥90% |
| IR | % high/critical-tier artifacts with a current IR finding (≤12 months) | ≥95% |
| ST | % archetypes with a baselined foundational test battery | ≥80% |
| EH | % endpoints with AI-capable controls aligned to current EH policy | ≥90% |
| IM | % findings with severity tag and SLA assignment within 24h of creation | ≥95% |
| ML | % AI/HAI archetypes with a logging baseline and defined retention | ≥80% |

### 1.2 Process Metrics (Leading)

**Definition.** Process metrics predict whether outcome metrics will be achieved by measuring execution, cadence adherence, queue aging, coverage progress, and integration health. They fire early enough to act before the outcome metric degrades.

**Timeframe.** Weekly or at the cadence of the underlying activity. Process metrics look at what the program is doing right now.

**Format.** Bullet list inside the level block, under the heading `#### Process Metrics (leading)`. Two to four bullets per level block.

**What qualifies.** The metric measures the *execution of an activity* that is known to predict the outcome. "Discovery sweeps run monthly" is a process metric. "Shadow-AI ratio" is the outcome metric it predicts. The causal link must be defensible.

**Examples:**

- Discovery cadence, shadow-AI discovery sweeps run at least monthly.
- Intake SLA adherence, % of intake submissions triaged within 5 business days.
- Threat model review cadence, threat libraries reviewed quarterly.
- Drift detection cadence, IR configuration-drift checks run continuously for high-tier artifacts.
- Test-corpus freshness, prompt-injection regression corpus updated within 90 days.
- Queue aging, IM backlog median age by severity tier monitored weekly.

### 1.3 Effectiveness Metrics (Business Value)

**Definition.** Effectiveness metrics measure what the outcome means to the business, cycle-time reductions, avoided-incident stories, regulatory-evidence readiness, ROI, external recognition, and practitioner throughput improvements.

**Timeframe.** Quarterly, annually. Often qualitative plus quantitative.

**Format.** Bullet list inside the level block, under the heading `#### Effectiveness Metrics (business value)`. Two to four bullets per level block.

**What qualifies.** The metric answers a business question, not a security-practice question. "Engineering cycle time from intake request to provisional approval" is an effectiveness metric for SM, the program should make engineering faster over time, not slower.

**Examples:**

- Engineering cycle-time impact, intake-to-provisional-approval time *decreasing* as the program matures.
- Avoided-incident stories, documented cases where early threat assessment caught an AI-specific risk before production landing.
- Regulatory-evidence readiness, time to produce a complete EU AI Act Art. 26 deployer-duty evidence package on request.
- Reviewer reuse rate, % of new AI/HAI software artifacts reusing a sanctioned reference pattern vs. requiring a novel architecture review.
- Vendor-concentration reduction, number of high-tier AI vendors reduced through consolidation enabled by the sanctioned-vendor catalog.
- ROI narrative, program investment mapped to avoided-loss estimates, refreshed annually.

---

## 2. SMART Criteria

All metrics in HAIAMM v3.0 follow **SMART**:

| Criterion | Meaning in HAIAMM | Bad example | Good example |
|---|---|---|---|
| **Specific** | The metric names an exact quantity with a clear numerator and denominator | "improved security posture" | "% critical-tier AI/HAI artifacts with full-scope treatment in last 12 months" |
| **Measurable** | The number is readable from a named source without subjective judgment | "better coverage" | "≥90%, from inventory × discovery-source reconciliation" |
| **Achievable** | The target is demanding but reachable at this maturity level | "100% of all AI" on day one | "≥80% within 12 months" |
| **Relevant** | The metric connects directly to the level's stated objective | "tickets processed" for an outcome metric | "shadow-AI ratio" for SM |
| **Time-bound** | The target specifies a measurement horizon | "eventually" | "within 12 months of program charter" / "quarterly" |

**Outcome over output.** Activity counts ("reviews completed," "assessments run," "policies published") do not qualify as outcome metrics. They may appear in process metrics where they predict a causal outcome. An outcome metric states what the reviews *achieved*, what the assessments *found*, what the policies *changed*.

---

## 3. The Four-Column Outcome Metrics Table

Every level block contains exactly one outcome metrics table with exactly four columns. This is a structural rule enforced by §8.4 of the v3.0 framing.

```
#### Outcome Metrics (L{N})

| Metric | Baseline | L{N} Target | Source |
|---|---|---|---|
| {metric name} | {baseline instruction} | {target threshold or trend} | {where to read the number} |
```

### Column definitions

**Metric.** A precise, self-contained metric name. Should be readable without the table context. Prefer a ratio, rate, or count with a clear scope boundary.

**Baseline.** What the organization must do before it can track toward the target. At L1, "measure" is a valid baseline instruction, the first task is to establish the baseline. At L2 and L3, the baseline should be a known quantity from the prior level. Never leave this column blank.

**Target.** The specific threshold or trend direction the level is trying to achieve. Use concrete numbers wherever possible (percentages, ratios, counts, time-bounds). "Trending down" is acceptable only when a precise number cannot be established without domain-specific calibration, and it must be accompanied by a directionality statement.

**Source.** The specific system, artifact, or process from which the metric is read. "Inventory," "HR/LMS attestation," "SIEM query," "DR decision log," "IM backlog report" are all valid sources. "Internal review" or "team estimation" are not, they are unmeasurable.

### Table examples from canonical one-pagers

**SM-Software L1 (from SM-Software-OnePager.md):**

| Metric | Baseline | L1 Target | Source |
|---|---|---|---|
| AI/HAI software inventory coverage (% of discovered AI/HAI artifacts in inventory) | measure | ≥90% within 12 months | Inventory ↔ discovery-source reconciliation |
| Shadow-AI-in-engineering ratio (unsanctioned AI/HAI artifacts in production ÷ total AI/HAI artifacts in production) | measure | ≤15% and trending down | Inventory status field |
| % engineering headcount covered by an acknowledged AI Acceptable Use & Engineering Standards Policy | measure | ≥95% of engineering | HR / LMS attestation |
| % AI/HAI software artifacts in production with a named owning team | measure | 100% | Inventory |
| Known data-exposure events from AI/HAI software (per quarter) | measure | trending down QoQ | DLP, incident tracker, prompt/completion-log review |

---

## 4. Cell-by-Cell Metric Pattern

The following examples show how a specific cell instantiates the three metric types. Each example points to the canonical one-pager that defines the full metric set.

### Example A, SM-Software L1

**Level objective:** Stand up the AI/HAI Software Assurance program, build an inventory, and establish baseline metrics proving shadow AI in engineering is decreasing.

**Outcome metrics (selected):** Inventory coverage ≥90% within 12 months; shadow-AI-in-engineering ratio ≤15% and trending down; AUP attestation ≥95% of engineering headcount.

**Process metrics:** Discovery sweeps run monthly from source-code + dependency-manifest + CI/CD + runtime-egress; intake triaged within 5 BD; working group meets monthly.

**Effectiveness metrics:** Intake-to-provisional-approval cycle time decreasing; avoided-incident stories documented quarterly; archetype-reuse rate rising.

**Canonical source:** `docs/practices/SM-Software-OnePager.md`

### Example B, TA-Vendors L1

**Level objective:** Establish the archetype-level threat library for the five AI-vendor archetypes, mapped to HAIAMM HAI TTPs (EA/AGH/TM/RA) and to MITRE ATLAS tactics.

**Outcome metrics (selected):** % AI-vendor archetypes with a published threat snapshot ≥80% within 6 months; % threat items tagged to at least one HAI TTP or ATLAS tactic = 100%.

**Process metrics:** Threat-snapshot review cadence (quarterly); new vendor archetype triggers threat-snapshot within 30 days of intake.

**Effectiveness metrics:** Time from vendor intake submission to TA-cleared status decreasing; avoided-procurement stories where threat snapshot surfaced EA/AGH risk before contract.

**Canonical source:** `docs/practices/TA-Vendors-OnePager.md`

### Example C, SA-Data L2

**Level objective:** Publish tier-calibrated reference architectures for high-risk data-flow patterns, regulated-data at inference, cross-border training transfers, retrieval stores serving customer data, encoded as IaC for direct adoption.

**Outcome metrics (selected):** % high/critical-tier AI/HAI data architectures conforming to a published reference pattern ≥90%; % deviation approvals carrying a full-lane DR decision = 100%.

**Process metrics:** Pattern review cadence (semi-annual); new IaC template passes a test-environment deploy check before publication; deviations tracked in governance log.

**Effectiveness metrics:** Engineer time to design a compliant regulated-data architecture (using reference pattern vs. greenfield) decreasing; deviation rate at DR declining as patterns become the default path.

**Canonical source:** `docs/practices/SA-Data-OnePager.md`

---

## 5. Cross-Domain Metric Families

Some metrics recur structurally across all cells in a given practice or level, even though the precise targets and sources differ by domain. These **cross-domain metric families** let practitioners recognize patterns quickly and sanity-check their cell-specific metrics against the family norm.

### 5.1 Inventory Coverage (all SM cells)

Every SM cell at L1 establishes an inventory and measures its completeness. The family pattern:

- **Metric name:** `[Domain] AI/HAI inventory coverage (% of discovered [domain] assets in inventory)`
- **Baseline at L1:** measure
- **L1 target range:** ≥80% to ≥90% within 6–12 months (domain-specific; Vendors and Software tend toward ≥90%)
- **Source:** inventory reconciled against domain-appropriate discovery signals

Domain-specific discovery signals:
- **Software**, source-code imports, dependency manifests, CI/CD, runtime egress, model registries, cloud spend
- **Data**, data-catalog, pipeline telemetry, training-run registries, cloud storage, access-control groups
- **Infrastructure**, cloud asset inventory, model-registry, GPU fleet telemetry, vector-store registrations
- **Vendors**, contract/procurement records, SaaS management, browser extension audit, endpoint surveys, self-attestation
- **Processes**, workflow mapping sessions, business-process register, interview-based discovery
- **Endpoints**, MDM, endpoint management, browser extension audit, identity provider SSO app catalog

### 5.2 Shadow AI Ratio (all SM cells)

Every SM cell at L1 baselines and tracks the shadow AI ratio, the proportion of in-scope AI/HAI assets operating outside the program's visibility, attribution, and governance.

- **Metric name:** `Shadow AI ratio (unsanctioned [domain] AI/HAI assets in [scope] ÷ total [domain] AI/HAI assets)`
- **Baseline at L1:** measure (first quarter establishes the denominator and identifies unsanctioned items)
- **L1 target:** ≤15% and trending down; Critical-tier shadow AI = 0 at L2
- **Source:** inventory status field, reconciled with discovery signals

Domain-specific framing of shadow AI:
- **Vendors**, consumer GenAI, AI-embedded SaaS features silently enabled, AI tools adopted without intake
- **Endpoints**, browser-extension AI tools, copilots on unmanaged endpoints, sideloaded AI apps
- **Software**, LLM integrations shipped without security review, unsanctioned fine-tunes, ungoverned agents
- **Data**, data flows to AI services outside governed stores, canary-tag triggers from ungoverned training runs
- **Infrastructure**, unsanctioned model hosting, GPU-shadow-workloads, vector stores not in registry
- **Processes**, business workflows embedding AI output without governance checkpoint

### 5.3 AUP Attestation Coverage (all PC and EG cells)

Every PC cell at L1 publishes an AI Acceptable Use Policy and tracks acknowledgment. Every EG cell tracks practitioner literacy.

- **PC metric:** `% in-scope population covered by a current, acknowledged AI Acceptable Use Policy`
  - L1 target: ≥95% of in-scope population; source: HR / LMS attestation records
- **EG metric:** `% practitioners passing role-based AI-security literacy assessment`
  - L1 target: ≥80% of designated practitioners; source: LMS completion records + assessment scores

### 5.4 Intake SLA (all DR cells)

Every DR cell at L1 establishes a two-lane intake model and measures SLA adherence. The family pattern:

- **Fast-lane SLA:** written decision within 5 business days for low/medium-risk archetypes using a standard checklist
- **Full-lane SLA:** written decision within 15 business days for high/critical-risk or deviation cases requiring architect review
- **L1 target:** ≥90% of intake submissions receiving a written decision within the applicable lane SLA
- **Source:** DR decision log with timestamps

### 5.5 Drift Detection Cadence (all IR cells)

Every IR cell at L2 establishes continuous configuration-drift detection for high-tier artifacts. The family pattern:

- **Metric:** `% high/critical-tier AI/HAI [domain] artifacts with configuration-drift detection running continuously`
- **L2 target:** ≥90%
- **Source:** IR tooling telemetry (vendor API polling, IaC drift detection, log-integrity checks)
- **Leading indicator:** drift detection freshness, last check timestamp within SLA for each covered artifact

### 5.6 Test-Corpus Completeness (all ST cells)

Every ST cell establishes a foundational test battery per archetype and tracks its completeness. The family pattern:

- **Metric:** `% AI/HAI [domain] archetypes with a baselined foundational test battery (data-egress, no-train, prompt-injection, tool-scope, logging-completeness, kill-switch)`
- **L1 target:** ≥80% of archetypes
- **Metric:** `% prompt-injection regression corpus entries with last-run timestamp within 90 days`
- **L1 target:** 100%
- **Source:** ST test registry and CI/CD test-run logs

### 5.7 Detection-Set Coverage (all ML cells)

Every ML cell at L1 publishes a detection set targeted at the top threats from TA. The family pattern:

- **Metric:** `% TA top-threat items with at least one active detection in the ML detection set`
- **L1 target:** ≥80%
- **Metric:** `% AI/HAI [domain] archetypes with a logging baseline and defined retention`
- **L1 target:** ≥80%
- **Source:** ML detection registry, logging-baseline registry

### 5.8 Per-Tier SLA Adherence (all L2+ cells)

Once SM L2 establishes the risk-tier rubric, every practice's L2 cell measures SLA adherence per tier. The family pattern:

- **Metric:** `Per-tier SLA adherence across [practice] activities`
- **L2 target:** ≥90% per tier
- **Source:** practice telemetry (DR decision log, IR finding log, ST test-run log, IM backlog report, ML detection log)
- **Critical tier exception:** any Critical-tier artifact missing a required activity is a program-level finding, not just a metric miss

### 5.9 Industry Contribution Count (all L3 cells)

Every practice at L3 contributes back to the AI/HAI ecosystem. The family pattern:

- **Metric:** `Substantive industry contributions per year`
- **L3 target:** ≥4 per year (aggregate across practices; individual practice cells specify their contribution channels)
- **Source:** contribution log (MITRE ATLAS submissions, OWASP LLM/Agentic Top 10, NIST AI RMF Playbook, AVID, OpenSSF AI, sector ISACs, ISO/IEC 42001 community)
- **Quality gate:** conference talks and press releases do not count; technical artifacts that land in the external repository do

---

## 6. Per-Level Metric Expectations

### L1, Foundational

L1 metrics establish baselines. Most L1 outcome metric tables instruct the organization to "measure" as the baseline requirement, the first task is to instrument the measurement, not to hit a target that cannot yet be calibrated. The targets at L1 are program-establishment thresholds (≥80–90% coverage, ≤15% shadow AI, ≥90% SLA adherence on a small set of activities). L1 process metrics focus on cadence establishment (monthly discovery sweeps, weekly queue reviews, quarterly working-group meetings). L1 effectiveness metrics are often qualitative or early-signal (avoided-incident stories, first cycle-time measurements).

**Minimum L1 metric requirements per cell:**
- Outcome metrics table: at least 3 rows with baselines stated and L1 targets defined
- Process metrics: at least 2 leading-indicator bullets
- Effectiveness metrics: at least 2 business-value bullets

### L2, Comprehensive

L2 metrics add tier-calibration. Every outcome metric at L2 is split or qualified by risk tier where meaningful (Critical-tier shadow AI = 0 is a harder target than Medium-tier). L2 baselines are the established measurements from L1; the L2 targets are higher thresholds or tighter SLAs. L2 process metrics add tier-aware queue monitoring and continuous validation for high-tier artifacts. L2 effectiveness metrics include effort-allocation ratios (% of reviewer hours on Critical+High vs. Medium+Low), engineering-throughput improvements enabled by sanctioned-archetype reuse, and the first ROI data points.

**Minimum L2 metric requirements per cell:**
- Outcome metrics table: at least 4 rows; at least one explicitly tier-calibrated
- Process metrics: at least 3 leading-indicator bullets; at least one tier-aware cadence check
- Effectiveness metrics: at least 2 business-value bullets; at least one quantitative or semi-quantitative

### L3, Industry-Leading

L3 metrics add automation, external benchmarks, and contribution tracking. Outcome metrics at L3 include automation-level metrics (% of curation handled automatically, SLO latency for inventory updates), external-benchmark comparisons (≥5 peer-comparable metrics semi-annually), and contribution counts (≥4 substantive industry contributions per year). L3 process metrics monitor automation-pipeline health (signal-feed freshness, error rates) and benchmark cadence. L3 effectiveness metrics include sponsor decisions citing benchmark data, industry recognition, and ROI narratives with external validation.

**Minimum L3 metric requirements per cell:**
- Outcome metrics table: at least 4 rows; at least one automation metric and one external-benchmark or contribution metric
- Process metrics: at least 3 bullets; at least one automation-health check
- Effectiveness metrics: at least 2 bullets; at least one business-impact metric with an external reference

---

## 7. Anti-Patterns

The following metric patterns are rejected in HAIAMM v3.0 content. Any cell containing them should be flagged for revision.

### 7.1 Activity-Count Metrics in the Outcome Table

**Anti-pattern:** "Reviews completed this quarter: target ≥12" in the outcome metrics table.

**Why it fails.** Reviews completed is an activity count, not an outcome. It says nothing about what the reviews found, whether findings were resolved, or whether the program achieved its objective. Twelve reviews that all produce no-action decisions may indicate rubber-stamping, not good coverage.

**Correct form.** Move the count to process metrics if it predicts an outcome. Add an outcome metric that measures what the reviews accomplished: "% intake submissions receiving a written DR decision within the applicable lane SLA" or "% DR decisions identifying a condition that was subsequently resolved before go-live."

### 7.2 Unmeasurable Claims

**Anti-pattern:** "Improved security posture," "enhanced visibility," "stronger governance."

**Why it fails.** These cannot be measured. An auditor cannot read a number from any system that confirms or denies the claim.

**Correct form.** Decompose into specific, measurable outcomes. "Improved security posture" in the SM context becomes "shadow-AI ratio ≤15% and trending down" plus "% artifacts with a named owning team = 100%."

### 7.3 Metrics Without a Source

**Anti-pattern:** Metric row with the Source column blank or filled with "internal review."

**Why it fails.** If the source is not named, the metric cannot be audited, reproduced, or automated. "Internal review" is a process, not a source, it describes how the number is generated, but not from what system.

**Correct form.** Name the specific system: "Inventory status field," "HR/LMS attestation records," "DR decision log with timestamps," "SIEM query tag:ai-detection," "IM backlog export."

### 7.4 Metrics Without a Baseline

**Anti-pattern:** Target defined but Baseline column blank.

**Why it fails.** Without a baseline, there is no way to establish whether the target is achievable or whether progress is being made. A target of "≥90%" with no baseline could mean the program started at 0% and has a long way to go, or started at 88% and is nearly there.

**Correct form.** At L1, "measure" is a valid baseline, it explicitly instructs the program to establish the baseline in the first cycle. At L2+, reference the achieved L1 level as the baseline (e.g., "L1 achieved: 87% coverage; L2 target: ≥95%").

### 7.5 Metrics That Measure the Tool, Not the Outcome

**Anti-pattern:** "Detection tool running: yes/no" as an outcome metric.

**Why it fails.** A running tool does not mean the tool is detecting anything meaningful or that the detections are being acted on.

**Correct form.** "% TA top-threat items with at least one active detection" measures coverage. "% detections with a response action taken within 24h" measures efficacy. "% AI/HAI archetypes with a logging baseline meeting the longest applicable regulation's retention requirement" measures compliance.

---

## 8. Practitioner Tips

### How to Baseline at L1

1. Run the discovery mechanism once. Count what you find. That is the denominator.
2. Classify each discovered item (sanctioned, provisional, prohibited, awaiting intake). The unsanctioned count divided by the denominator is the starting shadow-AI ratio.
3. Run the AUP attestation once. The completion rate at the first run is the baseline.
4. Record baselines with a timestamp. Baselines are not targets, they are the starting point from which targets are measured.
5. Do not wait for a complete count to start measuring. A partial baseline with a documented uncertainty range is better than no baseline.

### How to Set Targets

1. Start from the level's stated objective and work backward: what measurable state would prove the objective is achieved?
2. Use the family norms in §5 as starting points: ≥90% inventory coverage, ≤15% shadow-AI ratio, ≥95% AUP attestation.
3. Adjust for domain-specific constraints: the Processes domain may need 24 months to map all business workflows; the Vendors domain may achieve 90% coverage faster because procurement records already exist.
4. Make targets achievable within the level's typical time horizon (L1 = 6–18 months, L2 = 12–24 months, L3 = ongoing).
5. Do not set targets that require perfect data. "≥80%" leaves room for edge cases; "100%" should be reserved for binary-compliance situations (e.g., "% critical-tier artifacts with a named owner = 100%").

### How to Choose Sources

1. Prefer systems that generate the data automatically without human judgment: inventory exports, LMS completion APIs, CI/CD logs, SIEM queries.
2. Avoid sources that require manual aggregation across multiple people: "team estimated," "program manager counted," "quarterly survey."
3. Name the specific table, query, or export path. "Inventory" is acceptable shorthand if the inventory system is named elsewhere in the cell; "the SharePoint spreadsheet" is not an auditable source.
4. For sources that do not yet exist at L1, write "Inventory [to be established per Activity B]", acknowledging the source needs to be built.

---

## 9. Cross-Reference to Canonical

**§10.5 of HAIAMM-v3.0-Framing.md** is the canonical definition of the three metric types. This document expands §10.5 with format specifications, examples, cross-domain families, and anti-patterns.

**§8.2 of HAIAMM-v3.0-Framing.md** is the canonical level block schema. The three metric sections (Outcome Metrics, Process Metrics, Effectiveness Metrics) are structural elements of the schema, they are not optional.

**§8.4 of HAIAMM-v3.0-Framing.md** enforces the four-column outcome metrics table as a structural rule. Deviations are non-conformant.

**§12.3 of HAIAMM-v3.0-Framing.md** is the metric authoring rule: metrics are outcome-first; activity-count-only tables are incomplete.

---

**Document Version:** HAIAMM v3.0 / **Last Updated:** 2026-05-14 / **Author:** Verifhai