Strategy & Metrics (SM) - Software Domain

HAIAMM Assessment Questionnaire v3.5

Generated from cells/SM-Software-L*.cell.json. Do not edit by hand. Canonical model: HAIAMM-v3.5-Framing.md · Handbook: HAIAMM-v3.5-Handbook.md.

---

Practice: Strategy & Metrics (SM) Domain: Software Business Function: Governance Purpose: Stand up the AI/HAI Software Assurance program, inventory everything the organization ships with AI in it, and baseline the metrics that prove shadow AI in engineering is decreasing. Scoring Model: Evidence + Outcome Metrics (see Scoring Methodology below)

---

Instructions

• Answer from current, implemented practice, not plans or aspirations.
• Each question has two components: Evidence (what you did) and Outcome Metrics (how well it worked).
• Levels are derived, never self-assigned. Record evidence and metric values; the level falls out of the scoring below.
• Silence is not a pass. A metric you cannot produce is left blank and counts as not met. Do not estimate.
• Answer progressively. Complete all Level 1 questions before Level 2.

Evidence grade

Record how each answer is known, not only what is claimed (v3.5 framing §6). A level claim is graded at its weakest field.

Grade	Meaning
E0	Asserted by a practitioner, unevidenced
E1	Asserted, with a link to a named artifact
E2	Emitted by a system as telemetry
E3	Machine-attested and independently checkable

---

Scoring Methodology

Tier	Score	Criteria
Fully Mature	1.0	Evidence complete + ≥3 outcome metrics meet targets
Implemented	0.67	Evidence complete + 2 outcome metrics meet targets
Partial	0.33	Evidence partially complete + <2 outcome metrics meet targets
Not Implemented	0.0	No substantive evidence of practice

Practice maturity level achieved = the highest level where all 3 questions score ≥ 0.67.

---

Maturity Level 1, Foundational

Objective: Stand up the AI/HAI Software Assurance program, inventory everything the organization ships with AI in it, and baseline the metrics that prove shadow AI in engineering is decreasing.

Question L1.1: Charter the AI/HAI Software Assurance program

Q1.1: Is there a published AI/HAI Software Assurance charter, jointly sponsored by the CISO and the CTO or Head of Engineering, naming a cross-functional working group, four explicit decision rights, a published intake service-level agreement and a numeric year-one target for each L1 outcome metric?

Evidence Required:

• [ ] Publish a program charter of no more than four pages, signed by the CISO jointly with the CTO or Head of Engineering, within the first 30 days
• [ ] The charter states the problem in first-party terms: the organization ships AI features and therefore carries deployer duties, regardless of whose model is behind them
• [ ] It enumerates the seven in-scope archetypes, being LLM-integrated application or feature, autonomous agent, RAG pipeline, fine-tuning or training workload, evaluation harness, model-serving service, and classical ML integrated into a product surface
• [ ] It names a cross-functional working group with one engineering representative per product line that ships AI, plus Data/ML platform, Privacy/Legal, Product and Platform/SRE
• [ ] It assigns four decision rights explicitly, being who approves an artifact for production, who can block one, who grants exceptions and who owns the go-live gate
• [ ] It commits to a published intake service-level agreement, because a program without one becomes a queue teams learn to bypass
• [ ] And it sets a numeric year-one target for each L1 outcome metric rather than a statement of intent
• [ ] The working group meets monthly and publishes minutes

Evidence grade for this question: ☐ E0 ☐ E1 ☐ E2 ☐ E3

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)

Evidence Location: _________________________________

Notes: ___________________________________________

Question L1.2: Build the inventory and run monthly shadow-AI discovery

Q1.2: Does one AI/HAI software inventory exist covering all seven archetypes, reconciled at least monthly against source-code imports, dependency manifests, CI/CD telemetry, runtime egress, the model registry and tagged cloud spend, reaching ≥90% coverage of discovered artifacts within 12 months?

Evidence Required:

• [ ] Stand up one AI/HAI software inventory as the program's source of truth, with a record per artifact carrying name, owning team, archetype, production status, exposure (customer-facing, internal, developer-only), AI capabilities (tool use, autonomy, multi-turn memory, retrieval sources, training-data sources), data classes processed, model provider and version at both inference and fine-tuning, approval status, and links to the TA snapshot, SR evidence map, SA pattern, latest DR decision and ML logging baseline
• [ ] Seed it from engineering records, then reconcile monthly against six discovery signals that platform and security teams already have: source-code scanning for LLM SDK, vector-store and ML-framework imports
• [ ] Dependency manifests across every package ecosystem in use
• [ ] CI/CD job telemetry flagging training, fine-tuning and evaluation runs
• [ ] Runtime egress to model-provider domains from internal services
• [ ] The internal model registry
• [ ] And cloud and provider spend broken out by cost-allocation tag
• [ ] Run a self-attestation campaign with a published amnesty window, because engineers who fear consequences hide unsanctioned AI rather than surface it
• [ ] Any artifact appearing in a discovery signal but not the inventory is shadow AI until attributed

Evidence grade for this question: ☐ E0 ☐ E1 ☐ E2 ☐ E3

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)

Evidence Location: _________________________________

Notes: ___________________________________________

Question L1.3: Baseline the scoreboard and open the consumption ledger

Q1.3: Are the five L1 outcome metrics baselined and reported quarterly to the sponsor by archetype, and is a consumption ledger open and joined to the inventory with a declared denominator, or explicitly recorded as blocked on FinOps allocation?

Evidence Required:

• [ ] Instrument five outcome metrics in the first quarter and report them to the executive sponsor quarterly, broken out by archetype: inventory coverage against discovery reconciliation, the shadow-AI-in-engineering ratio, acceptable-use attestation across engineering headcount, the share of production artifacts with a named owning team, and known data-exposure events originating from AI features
• [ ] Alongside the inventory, open a consumption ledger joined on the artifact key, recording tokens and calls per artifact with the owning team and, critically, the denominator, being the unit of business work that artifact delivers
• [ ] Baseline the Assured Spend Ratio, which is the share of AI consumption flowing through inventoried, owner-attributed artifacts, and report it beside the artifact-count shadow-AI ratio rather than instead of it, because the two diverging is the finding
• [ ] Where AI spend is not allocated to an owning team, record the ledger as blocked on allocation and raise a tagging request with the FinOps practice
• [ ] Do not estimate the number, and do not score the program down for a gap it cannot close from the security side

Evidence grade for this question: ☐ E0 ☐ E1 ☐ E2 ☐ E3

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)

Evidence Location: _________________________________

Notes: ___________________________________________

Level 1 Outcome Metrics

Metric	Baseline	Current	Target	Met?	Notes
AI/HAI software inventory coverage (discovered artifacts present in the inventory)	___	___	≥90% within 12 months	☐
Shadow-AI-in-engineering ratio (unsanctioned artifacts in production ÷ total artifacts in production)	___	___	≤15% and falling for two consecutive quarters	☐
Engineering headcount with an acknowledged AI Acceptable Use and Engineering Standards Policy	___	___	≥95% of engineering headcount	☐
Production AI/HAI artifacts carrying a named owning team	___	___	100%	☐
Assured Spend Ratio (AI consumption through inventoried, owner-attributed artifacts)	___	___	≥60% baselined and reported quarterly	☐

Where each number is read from:

• AI/HAI software inventory coverage (discovered artifacts present in the inventory) — Inventory reconciled against the six discovery signals
• Shadow-AI-in-engineering ratio (unsanctioned artifacts in production ÷ total artifacts in production) — Inventory approval-status field
• Engineering headcount with an acknowledged AI Acceptable Use and Engineering Standards Policy — HR / LMS attestation records
• Production AI/HAI artifacts carrying a named owning team — Inventory owner field
• Assured Spend Ratio (AI consumption through inventoried, owner-attributed artifacts) — Consumption ledger joined to inventory on artifact key

Level 1 Consumption Metrics

Absolute spend is a ledger input, never a metric. Every row is divided by a unit of business work. If AI spend is not allocated to an owning team, record this level as blocked on allocation rather than scoring it down (v3.5 framing §12).

Metric	Denominator	Current	Economic failure it detects	Met?
Token and call cost per completed task, by archetype	per completed task	___	loop burn and retry storms (RA), and silent scope creep where an artifact quietly acquires authority its use case never justified (EA)	☐
Assured Spend Ratio: AI consumption through inventoried, owner-attributed artifacts	per dollar of AI consumption across the estate	___	artifact-count coverage reads healthy while the load-bearing production systems sit outside the program, because counting prototypes is easy and money follows load	☐
Unattributed AI consumption, as a share of the ledger	per dollar of AI consumption across the estate	___	shadow AI that discovery sweeps missed but the invoice did not, and allocation gaps that make every other consumption metric uncomputable	☐

Level 1 30-second check (E0)

• ☐ Yes ☐ No — Can you name one person accountable for AI risk in the software your engineers ship?
• ☐ Yes ☐ No — Is there a single list of every AI feature currently in production?
• ☐ Yes ☐ No — Do you know what your AI features cost per unit of work they deliver?

---

Maturity Level 2, Comprehensive

Objective: Risk-tier the AI/HAI software inventory and calibrate program intensity per tier, establishing the rubric and treatment matrix every other Software-domain L2 practice inherits.

Prerequisite cells: SM-Software-L1, PC-Software-L1, TA-Software-L1

Question L2.1: Publish the risk-tier rubric

Q2.1: Is every AI/HAI software artifact assigned a risk tier from a published rubric covering data sensitivity, decision-affecting use under GDPR Art. 22 or EU AI Act Annex III, agentic capability, user exposure, training-data posture, production load-bearing status and concentration, with overrides recorded and reviewed?

Evidence Required:

• [ ] Define four tiers, Critical, High, Medium and Low, derived deterministically from seven auditable dimensions, each of which a reviewer can evidence rather than assert
• [ ] The dimensions are: data sensitivity processed at inference or training, where regulated data elevates to Critical or High
• [ ] Decision-affecting use, where output materially drives a decision with legal or significant effect on a person under GDPR Art. 22, or falls in an EU AI Act Annex III high-risk category, elevating to Critical
• [ ] Agentic capability, where a tool surface acting on organizational or customer systems elevates, with tool count and scope as inputs
• [ ] User exposure, where customer-facing elevates, partner-facing elevates less, and developer-only lowers
• [ ] Training-data posture, where fine-tuning on customer or regulated data elevates
• [ ] Production load-bearing status, where sitting on a revenue path, a customer-onboarding flow or an authentication decision elevates
• [ ] And concentration, where being the sole AI capability behind a product elevates
• [ ] Publish the rubric as a short table with the derivation rule written out
• [ ] Human override is permitted but must be recorded with rationale and reviewed by the working group, because an override nobody sees is a rubric nobody trusts

Evidence grade for this question: ☐ E0 ☐ E1 ☐ E2 ☐ E3

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)

Evidence Location: _________________________________

Notes: ___________________________________________

Question L2.2: Calibrate program intensity and spend caps per tier

Q2.2: Is there a published tier-treatment matrix driving differential intensity across PC, TA, SR, SA, DR, IR, ST, EH, ML and IM, with at least 95% of Critical-tier artifacts having received full-scope treatment in the last 12 months, and are cost-driven changes treated as material changes?

Evidence Required:

• [ ] Publish a tier-treatment matrix stating what each tier receives across intake depth, threat-modeling depth, pattern adherence, design review lane, implementation-review cadence, security-test battery, environment hardening, monitoring detections, issue-management service levels and re-review triggers on material change
• [ ] Every downstream Software-domain L2 practice inherits this matrix and defines its own tier-specific activities against it
• [ ] The matrix is authored here and changes flow through the working group, so the tiers cannot drift apart practice by practice
• [ ] Extend the matrix with a consumption row: every Critical- and High-tier artifact carries a spend cap proportionate to its tier and a declared behaviour when the cap is reached, being degrade, queue or refuse, and never silently continue
• [ ] Treat a cost-driven change to a Critical- or High-tier artifact as a material change that triggers the tier's re-review obligation, because switching to a cheaper model, shortening log retention, sampling telemetry or extending a cache time-to-live each alters the security profile that testing baselined
• [ ] Thrift is not an exemption from change governance

Evidence grade for this question: ☐ E0 ☐ E1 ☐ E2 ☐ E3

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)

Evidence Location: _________________________________

Notes: ___________________________________________

Question L2.3: Report the scoreboard per tier and govern tier movement

Q2.3: Does the quarterly scoreboard report per tier and per archetype with unsanctioned Critical-tier artifacts explicitly tracked at zero, is the Assured Spend Ratio reported per tier, and is tier movement logged with rationale and reviewed by the sponsor?

Evidence Required:

• [ ] Convert the L1 scoreboard to a tier-aware one reported quarterly to the sponsor and monthly to the working group
• [ ] Report inventory state by tier and archetype, with every Critical-tier artifact as its own row rather than aggregated away
• [ ] Report the shadow-AI ratio per tier, where a Critical-tier unsanctioned artifact in production is a headline finding and a Low-tier one is a line item
• [ ] Report service-level adherence per tier across intake, design review, implementation review, testing, monitoring and issue management
• [ ] And report the Assured Spend Ratio per tier, targeting full attribution of Critical-tier consumption
• [ ] Maintain a tier-movement log recording every artifact that moved up a tier, which tightens its treatment, and every artifact that moved down, with rationale, and review it quarterly with the sponsor
• [ ] The quarterly review asks one question explicitly: is the program's effort distribution matching the program's risk distribution, or is reviewer time going where the work is easiest rather than where the risk is

Evidence grade for this question: ☐ E0 ☐ E1 ☐ E2 ☐ E3

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)

Evidence Location: _________________________________

Notes: ___________________________________________

Level 2 Outcome Metrics

Metric	Baseline	Current	Target	Met?	Notes
Inventory carrying a current tier assignment	___	___	100% of the inventory, with tier age under 12 months	☐
Critical-tier artifacts receiving full-scope treatment in the last 12 months	___	___	≥95%	☐
Tier-weighted shadow AI: unsanctioned Critical-tier artifacts in production	___	___	0 at Critical, and falling at every other tier	☐
Per-tier service-level adherence across intake, DR, IR, ST, ML and IM	___	___	≥90% per tier	☐
Critical- and High-tier artifacts operating under a spend cap with declared at-cap behaviour	___	___	100% of Critical, ≥90% of High	☐
Assured Spend Ratio at Critical tier	___	___	100% of Critical-tier consumption attributed, ≥90% estate-wide	☐

Where each number is read from:

• Inventory carrying a current tier assignment — Inventory tier field
• Critical-tier artifacts receiving full-scope treatment in the last 12 months — Cross-practice artifact records joined to inventory tier
• Tier-weighted shadow AI: unsanctioned Critical-tier artifacts in production — Inventory status and tier fields
• Per-tier service-level adherence across intake, DR, IR, ST, ML and IM — Program telemetry from each practice's decision log
• Critical- and High-tier artifacts operating under a spend cap with declared at-cap behaviour — AI gateway budget configuration reconciled against inventory; where no AI gateway is deployed, provider-side usage and limit configuration read per provider account, recorded at E1
• Assured Spend Ratio at Critical tier — Consumption ledger joined to inventory tier field

Level 2 Consumption Metrics

Absolute spend is a ledger input, never a metric. Every row is divided by a unit of business work. If AI spend is not allocated to an owning team, record this level as blocked on allocation rather than scoring it down (v3.5 framing §12).

Metric	Denominator	Current	Economic failure it detects	Met?
Cost per completed task at Critical tier against the archetype median	per completed task	___	excessive agency showing up economically before it shows up behaviourally, where an artifact does more work than its declared scope implies	☐
Spend-cap breach rate and at-cap behaviour conformance, per tier	per artifact-quarter	___	denial-of-wallet, and caps that are configured but silently continue past the limit rather than degrading, queueing or refusing	☐
Assurance premium: assured unit cost over ungoverned unit cost	per completed task	___	the governed path costing materially more than the ungoverned one, which is the mechanism by which engineering teams route around an assurance program regardless of policy	☐
Assured Spend Ratio per tier	per dollar of AI consumption within the tier	___	aggregate coverage masking that Critical-tier consumption is flowing through artifacts the program does not govern	☐

Level 2 30-second check (E0)

• ☐ Yes ☐ No — Does every AI feature in your inventory carry a risk tier?
• ☐ Yes ☐ No — Would a Critical-tier AI feature get more security review than a Low-tier one?
• ☐ Yes ☐ No — Does any AI feature have a spend cap that actually stops it?

---

Maturity Level 3, Industry-Leading

Objective: Drive inventory, tiering and the consumption ledger from live build and runtime signals, benchmark externally, and compute the program's return rather than narrating it.

Prerequisite cells: SM-Software-L2, ML-Software-L2, EG-Software-L2

Question L3.1: Automate inventory, tiering and ledger attribution from live signals

Q3.1: Do inventory and tier assignment auto-update from CI/CD, model-registry, dependency-manifest, runtime-egress, gateway and billing signals against a published data-quality service-level objective, with at least 80% of curation automated and human review reserved for exceptions?

Evidence Required:

• [ ] Drive the inventory from authoritative engineering feeds rather than from tickets: CI/CD events tagged by job type for training, fine-tuning, evaluation and deploy
• [ ] Model-registry events for registration, version promotion and deprecation
• [ ] Dependency-manifest scanning on every commit
• [ ] Runtime egress showing a new outbound flow to a model-provider domain
• [ ] Gateway telemetry where a previously unseen artifact begins emitting prompts
• [ ] And provider billing feeds where a new cost-allocation tag appears
• [ ] Implement tier assignment as a versioned, replayable rule set over the L2 rubric inputs, so a tier change is reproducible and auditable, and wire tier changes to trigger downstream obligations automatically, where a Medium-to-Critical promotion opens the design-review, testing and monitoring work items without anyone remembering to
• [ ] Automate ledger attribution from billing and gateway feeds against cost-allocation tags
• [ ] Reserve human curation for three cases: genuinely new archetypes that do not fit the existing seven, ambiguous discoveries such as a shared library that may or may not be in production, and conflicting dimensional inputs
• [ ] Publish a data-quality service-level objective covering tier correctness within 48 hours of a material change and inventory completeness against reconciliation

Evidence grade for this question: ☐ E0 ☐ E1 ☐ E2 ☐ E3

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)

Evidence Location: _________________________________

Notes: ___________________________________________

Question L3.2: Benchmark externally and publish the comparison

Q3.2: Do you publish a semi-annual external benchmarking brief comparing the program against at least five peer-comparable metrics through named channels, with the peer cohort selected to stretch rather than flatter the program, and does it drive investment decisions?

Evidence Required:

• [ ] Compare program metrics against peer data twice a year through named channels rather than impressions: OWASP SAMM AI extensions and OpenSSF AI working groups, CSA AI Safety Initiative working groups, MITRE ATLAS practitioner exchanges, sector information-sharing bodies with AI working groups, the FinOps Foundation AI scope for unit-economics comparison, and formal peer roundtables
• [ ] Publish a brief covering at least five peer-comparable metrics, being inventory coverage, shadow-AI ratio, per-tier service-level adherence, automation level, and denominated unit cost per completed task by archetype
• [ ] Choose peers who stretch the program rather than flatter it
• [ ] An organization shipping customer-facing agents does not benchmark against internal-tool builders, and the brief should state who was chosen and why
• [ ] Feed benchmark deltas into the next year's investment priorities and into the board narrative, and record where the program is behind as explicitly as where it leads, because a benchmarking brief that only finds good news stops being read

Evidence grade for this question: ☐ E0 ☐ E1 ☐ E2 ☐ E3

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)

Evidence Location: _________________________________

Notes: ___________________________________________

Question L3.3: Compute the program's return and contribute back

Q3.3: Is the program's return computed from consumption-ledger arithmetic covering contained denial-of-wallet events, reclaimed loop burn, reclaimed waste and avoided overage, reconciled with Finance, and published alongside the Assurance Cost Ratio?

Evidence Required:

• [ ] Replace the asserted return narrative with arithmetic over the consumption ledger, refreshed at least annually and reconciled with Finance
• [ ] Compute four components from meters rather than models: contained denial-of-wallet and loop-burn events, valued as the mean burn rate multiplied by the mean time to detect, multiplied by the events contained
• [ ] Reclaimed loop burn, being spend on non-completing tasks before and after cap enforcement
• [ ] Reclaimed licence and capacity waste
• [ ] And avoided provider overage under committed-spend governance
• [ ] Publish the Assurance Cost Ratio, being program spend over AI consumption spend, and defend the band rather than the number, because a program consuming a large share of the AI budget is over-built and one consuming almost nothing is theatre
• [ ] Separately, contribute at least four substantive artifacts per year to the ecosystem, targeting MITRE ATLAS for techniques observed in first-party software, OWASP LLM and Agentic Top 10 reviews backed by real telemetry, NIST AI RMF Playbook contributions, AI Vulnerability Database submissions for responsibly disclosed findings, and OpenSSF AI supply-chain work
• [ ] Conference talks and press releases do not count, because the quality gate is whether a technical artifact lands in the external repository

Evidence grade for this question: ☐ E0 ☐ E1 ☐ E2 ☐ E3

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)

Evidence Location: _________________________________

Notes: ___________________________________________

Level 3 Outcome Metrics

Metric	Baseline	Current	Target	Met?	Notes
Inventory and tier auto-update latency after a material change	___	___	≤48 hours for 99% of material changes	☐
Inventory entries auto-curated rather than human-curated	___	___	≥80% auto-curated	☐
Inventory completeness against discovery-source reconciliation	___	___	≥99%	☐
Tier changes auto-triggering downstream practice obligations	___	___	100% within 24 hours of the tier change	☐
Peer-comparable metrics tracked in the semi-annual benchmarking brief	___	___	≥5 metrics, with named peer cohort and stated selection rationale	☐
Substantive ecosystem contributions accepted per year	___	___	≥4 accepted technical artifacts, excluding talks and press	☐

Where each number is read from:

• Inventory and tier auto-update latency after a material change — Inventory event telemetry with change timestamps
• Inventory entries auto-curated rather than human-curated — Curation telemetry from the inventory pipeline
• Inventory completeness against discovery-source reconciliation — Automated reconciliation report
• Tier changes auto-triggering downstream practice obligations — Workflow automation telemetry
• Peer-comparable metrics tracked in the semi-annual benchmarking brief — Published benchmarking brief
• Substantive ecosystem contributions accepted per year — Contribution log with external acceptance references

Level 3 Consumption Metrics

Absolute spend is a ledger input, never a metric. Every row is divided by a unit of business work. If AI spend is not allocated to an owning team, record this level as blocked on allocation rather than scoring it down (v3.5 framing §12).

Metric	Denominator	Current	Economic failure it detects	Met?
Denominated unit cost per completed task, benchmarked against the external peer cohort	per completed task	___	the program optimising against its own history while drifting away from what comparable organizations achieve, which internal trend lines cannot reveal	☐
Assurance Cost Ratio: assurance program spend over AI consumption spend	per dollar of AI consumption across the estate	___	a program that is over-built relative to the estate it governs, or one small enough to be theatre, neither of which is visible without the ratio	☐
Reclaimed loop burn: spend on non-completing tasks, before and after cap enforcement	per completed task	___	rogue-agent reflective loops and retry storms burning budget with no delivered output, which absolute spend reporting cannot distinguish from growth	☐
Ledger attribution latency after a new artifact begins consuming	per newly observed artifact	___	shadow AI visible on the invoice days or weeks before it is visible to the program, which is the gap denial-of-wallet exploits	☐

Level 3 30-second check (E0)

• ☐ Yes ☐ No — Does your AI inventory update itself, or does someone update it?
• ☐ Yes ☐ No — Can you say how your AI assurance metrics compare with peer organizations?
• ☐ Yes ☐ No — Is your AI assurance return computed from real spend data?

---

Summary Scorecard

Level	Q1	Q2	Q3	Level score	Weakest evidence grade	Achieved?
L1	___	___	___	___	___	☐
L2	___	___	___	___	___	☐
L3	___	___	___	___	___	☐

Strategy & Metrics (SM) maturity in the Software domain: ____________

---

Document Version: HAIAMM v3.5 (generated)