Implementation Review (IR)

Infrastructure Domain - HAIAMM v3.5

Generated from the canonical cell records in cells/. Do not edit by hand; edit cells/IR-Infrastructure-L*.cell.json and re-run tools/render.py.

---

Practice Overview

Business Function: Verification

Objective: Review what was actually built against what was designed and required for infrastructure AI assets, at go-live, with findings tracked to closure.

Description: A program at this level checks the built system rather than the intended one. Every infrastructure AI asset gets an implementation review before go-live, working from a published checklist that examines network exposure as deployed against what was approved, egress allowlists actually enforced rather than logged, standing access genuinely absent rather than merely discouraged, model provenance verified in the serving path, per-tenant quotas configured, and secrets sourced from the vault rather than from environment variables. The distinction from design review is the entire point: design review assesses what a team intends, implementation review assesses what exists, and the gap between the two is where most AI security failures actually live. Findings carry an owner, a severity and a date, and go-live is conditional on the blocking ones being closed.

---

Maturity Level 1, Foundational

Objective: Review what was actually built against what was designed and required for infrastructure AI assets, at go-live, with findings tracked to closure.

A program at this level checks the built system rather than the intended one. Every infrastructure AI asset gets an implementation review before go-live, working from a published checklist that examines network exposure as deployed against what was approved, egress allowlists actually enforced rather than logged, standing access genuinely absent rather than merely discouraged, model provenance verified in the serving path, per-tenant quotas configured, and secrets sourced from the vault rather than from environment variables. The distinction from design review is the entire point: design review assesses what a team intends, implementation review assesses what exists, and the gap between the two is where most AI security failures actually live. Findings carry an owner, a severity and a date, and go-live is conditional on the blocking ones being closed.

Dependencies

• Required: SM-Infrastructure-L1, SR-Infrastructure-L1, SA-Infrastructure-L1, DR-Infrastructure-L1
• Alignment (not blocking): Existing code and configuration review practice, so AI checks extend an established review rather than adding a separate gate
• Supports / unblocks: ST-Infrastructure-L1; EH-Infrastructure-L1; IM-Infrastructure-L1; ML-Infrastructure-L1; Required by: IR-Infrastructure-L2

Desired Outcomes

• Every infrastructure AI asset has an implementation review before go-live, against what was designed and required.
• Findings carry an owner, a severity and a date, and blocking findings are closed before go-live.
• The gap between the approved design and the built system is measured rather than assumed to be zero.
• Controls are verified as present and effective rather than as documented.
• A finding accepted as residual risk has a named acceptor rather than being quietly absorbed.

Activities

A) Publish the implementation review checklist and run it at go-live

Publish a checklist per archetype that examines the built artifact rather than its documentation. In this domain the review looks at network exposure as deployed against what was approved, egress allowlists actually enforced rather than logged, standing access genuinely absent rather than merely discouraged, model provenance verified in the serving path, per-tenant quotas configured, and secrets sourced from the vault rather than from environment variables. The discipline that makes this practice worth running is verifying presence and effect rather than presence alone: a logging configuration that exists but emits nothing, an allowlist enforced in audit mode, a kill switch wired to nothing, all pass a documentation check and fail a real one. Run the review before go-live for every asset, and make go-live conditional on blocking findings being closed. Where the review cannot verify a control because the environment does not expose it, record that explicitly as unverifiable rather than as passed, since silence is not a pass.

B) Compare the built system against the approved design

Reconcile what was built against the design review decision and the requirements pack: every requirement in scope for the asset's archetype gets a verified, not-verified or unverifiable disposition, and every condition attached to the design approval gets confirmed as met. Record the design-to-implementation gap as a measure in its own right, because a gap that is never measured is assumed to be zero and never is. Where implementation diverges from the approved design, treat it as a finding against the change rather than as a re-opening of the design decision, and route material divergence back to design review rather than absorbing it in the implementation record.

C) Track findings to closure with severity and ownership

Give every finding a severity, an owner, a remediation date and a disposition of remediated, accepted or deferred. An accepted finding requires a named acceptor with authority proportionate to the severity, because a finding that is neither fixed nor formally accepted leaves residual risk that nobody owns, which is the most common way implementation review findings evaporate. Feed all findings into the issue-management backlog rather than maintaining a separate review register, so that AI findings age and escalate on the same rails as everything else. Report finding density by archetype and by checklist item quarterly, which tells the architecture and education practices where implementations systematically diverge rather than where reviewers happened to look.

Outcome Metrics (L1)

Metric	Baseline	L1 Target	Source
Infrastructure AI assets receiving an implementation review before go-live	first quarter of go-live telemetry	100% of assets reaching production	Review records reconciled against the deployment log
Blocking findings closed before go-live	first quarter of finding telemetry	100%	Finding tracker joined to deployment records
Requirements given a verified, not-verified or unverifiable disposition at review	first review round	100% of in-scope requirements, with unverifiable recorded explicitly	Implementation review records
Findings carrying an owner, severity, date and disposition	first finding audit	100%	Issue tracker records
Accepted findings carrying a named acceptor with proportionate authority	first acceptance review	100%	Finding disposition records

Process Metrics (leading)

• Review triggered automatically from the deployment pipeline rather than requested by the team.
• Checklist reviewed quarterly against new findings and updated reference patterns.
• Finding density by checklist item reported quarterly to architecture and education.
• Unverifiable controls reviewed monthly to determine whether the environment can be made observable.

Effectiveness Metrics (business value)

• Findings caught at implementation review rather than in production rise as a share of total findings.
• The design-to-implementation gap narrows over time, which indicates design decisions are reaching the build.
• Repeat findings on the same checklist item fall as architecture and education act on the reported patterns.

Oversight Metrics (the HAI control, measured)

Metric	Oversight failure it detects	Source
Share of implementation reviews recording at least one finding before sign-off	rubber-stamping at implementation review, where sign-off is recorded without the review having examined anything, which is the default outcome when review is a release-checklist item	Implementation review records with finding counts
Findings accepted as risk at sign-off rather than remediated, with a named acceptor	silent acceptance, where a finding is noted and neither fixed nor formally accepted, so nobody owns the residual risk	Implementation review finding disposition records

Level of Effort (incremental over the level below)

• Stand-up: 140 hours · Ongoing: 120 hours/quarter
• AppSec / SecEng — primary, 30 days/year
• Security Architect — regular, 12 days/year
• AI/ML Engineer — regular, 10 days/year
• DevOps / Platform Engineer — low, 8 days/year

Success Criteria

• Every AI asset reaching production has an implementation review against the published per-archetype checklist.
• Controls are verified as present and effective, with controls the environment cannot expose recorded as unverifiable rather than passed.
• Every in-scope requirement receives a verified, not-verified or unverifiable disposition at review.
• Blocking findings are closed before go-live, and every accepted finding has a named acceptor with proportionate authority.
• Findings flow into the shared issue backlog rather than a separate review register.

---

Maturity Level 2, Comprehensive

Objective: Calibrate infrastructure implementation review cadence to asset tier and detect configuration drift continuously, so controls verified at go-live stay verified.

At this level review is periodic and continuous rather than one-off. Critical-tier assets are re-reviewed on a published cadence and on every material change, while drift detection runs continuously against the controls that matter, because a control verified at go-live and never re-checked describes the system as it was on one day. Drift is the defining failure of this practice at scale: implementations do not usually fail at review, they pass and then change. Findings carry tier-proportionate service levels, and deferral requires an authority that rises with tier.

Dependencies

• Required: IR-Infrastructure-L1, SM-Infrastructure-L2, SR-Infrastructure-L2, SA-Infrastructure-L2
• Alignment (not blocking): Change management, so material-change triggers ride existing change records
• Supports / unblocks: ST-Infrastructure-L2; EH-Infrastructure-L2; IM-Infrastructure-L2; ML-Infrastructure-L2; Required by: IR-Infrastructure-L3, SA-Infrastructure-L3, SR-Infrastructure-L3

Desired Outcomes

• Re-review cadence follows asset tier and material change rather than an annual calendar.
• Configuration drift on controls that matter is detected continuously for high-tier assets.
• Findings carry tier-proportionate remediation service levels that are met.
• Deferral of a Critical-tier finding requires an authority proportionate to the risk.
• A control that was verified and later silently disabled is detected in days rather than at the next review.

Activities

A) Set re-review cadence by tier and material change

Publish the re-review cadence per tier: Critical at go-live, semi-annually and on every material change; High at go-live, annually and on material change; Medium at go-live and annually; Low at go-live. Define material change concretely for this domain, being a security group widened for a debugging session and left open, a quota raised under load and never restored, provenance verification bypassed for a hotfix, and a vault integration replaced by an environment variable, and wire the triggers to change records and deployment events so the obligation is raised by the system rather than remembered. The calendar is the weakest trigger available and should be the floor rather than the mechanism, because an asset that changed materially in month two carries a verified-once record for ten months and the record looks identical to an accurate one.

B) Detect configuration drift continuously on high-tier assets

Stand up continuous drift detection for Critical- and High-tier assets covering the controls whose silent disablement would matter most. In this domain the drift that recurs is a security group widened for a debugging session and left open, a quota raised under load and never restored, provenance verification bypassed for a hotfix, and a vault integration replaced by an environment variable. Detect it from configuration state, infrastructure-as-code divergence, policy enforcement mode and runtime telemetry, and alert on change rather than on schedule. Drift detection is what converts implementation review from a point-in-time assertion into a continuing one, and it is the single highest-value activity at this level, because implementations rarely fail review, they pass and then change. Publish a detection service level of 5 business days at Critical tier and route detections into the issue backlog with tier-appropriate severity rather than into a report.

C) Apply tier-proportionate service levels and deferral authority

Set remediation service levels by finding severity and asset tier, tighter at Critical, and report adherence rather than only backlog size. Require deferral authority to rise with tier and severity, so a deferred Critical-tier finding needs an executive acceptance with an expiry and a quarterly review, while a Low-tier one needs the practice lead. Report deferred Critical-tier findings to the sponsor alongside remediated ones, because a practice that reports only closures presents a picture that flatters it. Track findings that were deferred and later implicated in an incident as a distinct measure, since that is the only feedback available on whether deferral judgment is sound rather than merely authorised.

Outcome Metrics (L2)

Metric	Baseline	L2 Target	Source
Critical-tier assets re-reviewed within their cadence and on every material change	first tiered cadence pass	≥95%	Review records joined to change events and inventory tier
Critical- and High-tier assets under continuous drift detection	first drift rollout	≥90% of Critical, ≥75% of High	Drift detection coverage registry
Time to detect configuration drift on a Critical-tier control	first quarter of drift telemetry	≤5 business days at the 90th percentile	Drift detection event log
Findings remediated within the tier and severity service level	first quarter of tiered telemetry	≥90% per tier	Issue tracker with service-level fields
Deferred Critical-tier findings carrying executive acceptance with expiry and quarterly review	first deferral review	100%, with none past expiry	Finding disposition records

Process Metrics (leading)

• Material-change triggers wired to change records and deployment events rather than a calendar.
• Drift detection feed freshness monitored, with alerting when a feed goes stale.
• Deferred Critical findings reviewed quarterly with the sponsor.
• Drift detections routed into the shared backlog with tier-appropriate severity automatically.

Effectiveness Metrics (business value)

• Time between a control being disabled and being restored falls, which is what drift detection exists to compress.
• Incidents attributable to a silently disabled control fall.
• Deferred findings later implicated in incidents fall, which evaluates deferral judgment rather than deferral process.
• Reviewer effort concentrates on Critical and High tiers relative to L1.

Oversight Metrics (the HAI control, measured)

Metric	Oversight failure it detects	Source
Reviewer finding rate per review, compared across reviewers on comparable assets	reviewer drift, where the same implementation would pass with one reviewer and fail with another, making sign-off depend on assignment rather than on the code	Implementation review records segmented by reviewer
Implementation reviews per reviewer per week against the published ceiling	reviewer overload, where depth falls as volume rises and the review continues to be recorded as complete	Review assignment log
Critical-tier findings deferred past their remediation window with a recorded acceptance authority	deferral becoming the default disposition under release pressure, which converts a blocking finding into an advisory one without a decision	Finding disposition records joined to asset tier

Level of Effort (incremental over the level below)

• Stand-up: 160 hours · Ongoing: 180 hours/quarter
• AppSec / SecEng — primary, 36 days/year
• DevOps / Platform Engineer — regular, 18 days/year
• Security Architect — regular, 12 days/year
• Security Analyst / SOC — low, 8 days/year
• Material new tooling: Continuous configuration drift detection against declared control state

Success Criteria

• Re-review cadence is published per tier and driven by material-change triggers wired to change and deployment events.
• At least 90% of Critical-tier assets are under continuous drift detection, with detection within 5 business days.
• Findings carry tier and severity service levels with adherence at or above 90% per tier.
• Deferral authority rises with tier and severity, and deferred Critical findings carry executive acceptance with expiry.
• Deferred findings later implicated in incidents are tracked as a distinct measure of deferral judgment.

---

Maturity Level 3, Industry-Leading

Objective: Verify infrastructure implementation continuously in the pipeline and at runtime, and measure whether review judgment was right rather than only whether review happened.

At this level verification is continuous and mostly automatic. Control assertions run in the pipeline and against the running system, so the question of whether a control is present and effective has a current answer rather than a last-reviewed date. Human review concentrates on what automation cannot assert. The practice measures its own judgment by tracing sign-offs forward to incidents, which is the only way to distinguish a review function that is accurate from one that is merely punctual.

Dependencies

• Required: IR-Infrastructure-L2, SA-Infrastructure-L3, ML-Infrastructure-L2, IM-Infrastructure-L2
• Alignment (not blocking): Platform engineering ownership of the pipeline where assertions execute
• Supports / unblocks: Every other Infrastructure practice at L3, which inherits continuously verified implementations

Desired Outcomes

• Control presence and effectiveness are asserted continuously rather than established at a review date.
• Human review concentrates on what automation cannot assert, and that set is listed explicitly.
• Reviewer judgment is evaluated by tracing sign-offs forward to incidents.
• Assertion failures reach an owner automatically with tier-appropriate severity.
• Verification coverage is known, including where it does not reach.

Activities

A) Assert controls continuously in pipeline and runtime

Express each verifiable control as an assertion that runs both in the delivery pipeline against the change and against the running system on a continuous schedule. Pipeline assertions prevent a regression from merging; runtime assertions catch what was changed outside the pipeline, and both are needed because the second is where drift actually originates. Give each assertion a tier-proportionate severity, block merges on Critical-tier failures, and route runtime failures to the backlog automatically. Publish the list of controls that cannot be asserted and review it quarterly with a reduction target, because that list is the true boundary of the verification and is otherwise assumed to be empty. Assertions in this domain read live cloud configuration, admission policy, network reachability and identity state, and are the closest thing in the model to fully automatable implementation review.

B) Concentrate human review on the unassertable

Reserve human implementation review for the controls automation cannot assert and for the judgment calls automation cannot make, such as whether a control's implementation is adequate to its intent rather than merely present. Retain sampling on automatically verified assets so that the assertions themselves are checked, because an assertion that has silently stopped evaluating reports success indistinguishably from one that is passing. Track the share of reviewer hours spent on unassertable controls, which should rise as automation extends, and use it as the measure that the automation is releasing capacity rather than merely adding a second process alongside the first. What automation cannot assert here is whether a break-glass path is genuinely usable under incident conditions, which only an exercise establishes.

C) Measure review judgment by forward tracing

Trace every sign-off forward. Where a production incident is attributable to something implementation review examined and passed, record it as a review false negative and investigate whether the checklist, the assertion or the judgment was at fault. Report the false-negative rate to the sponsor alongside coverage and throughput, and treat it as the practice's primary quality measure, because coverage and timeliness are both achievable by a review function that examines nothing carefully. Run blind double-review on a sample of Critical-tier implementations quarterly and report the disagreement rate, using disagreements to refine checklists and assertions rather than to rank reviewers. Forward tracing in this domain most often implicates sign-offs taken against an approved plan rather than against the applied state, which diverge more often than teams expect.

Outcome Metrics (L3)

Metric	Baseline	L3 Target	Source
Verifiable controls covered by a continuous assertion in pipeline and runtime	L2 control set	≥80%, with unassertable controls listed explicitly	Assertion registry joined to the control catalogue
Critical-tier assertion failures blocked at merge or routed to an owner within the day	first quarter of assertion telemetry	≥95%	Pipeline and runtime assertion logs
Review false-negative rate: incidents attributable to something review examined and passed	first quarter of forward tracing	tracked and falling year over year, reported to the sponsor	Incident root-cause analysis joined to review records
Share of reviewer hours spent on controls automation cannot assert	first quarter of attention telemetry	≥60% and rising	Review time recording by control classification
Blind double-review disagreement rate on Critical-tier implementations	first calibration round	≤15%, with disagreements used to refine checklists and assertions	Double-review calibration records

Process Metrics (leading)

• Assertion evaluation freshness monitored, with alerting when an assertion stops evaluating.
• Unassertable control list reviewed quarterly with an explicit reduction target.
• Sampling maintained on automatically verified assets so the assertions themselves are checked.
• Blind double-review sampling run quarterly on Critical-tier implementations.

Effectiveness Metrics (business value)

• Reviewer hours per asset fall while false-negative rate holds or improves, which is the level's defining outcome.
• Time between a control regression and its detection falls toward the pipeline cycle time.
• Incidents attributable to silently disabled controls approach zero.
• Verification coverage rises without a corresponding rise in reviewer headcount.

Oversight Metrics (the HAI control, measured)

Metric	Oversight failure it detects	Source
Automated verification failures overridden by a human, with the override sustained across builds	override becoming the routine path around a check that is inconvenient rather than wrong, which is how automated verification quietly becomes advisory	Pipeline verification override log
Sign-offs later contradicted by a production incident attributable to what the review examined	review that is procedurally complete and substantively wrong, which only forward tracing to incidents can reveal	Incident root-cause analysis joined to review records
Blind double-review disagreement rate on Critical-tier implementations	reviewer drift at the tier where it matters most, invisible unless deliberately sampled	Double-review calibration records

Level of Effort (incremental over the level below)

• Stand-up: 220 hours · Ongoing: 140 hours/quarter
• AppSec / SecEng — primary, 30 days/year
• DevOps / Platform Engineer — regular, 26 days/year
• Security Architect — regular, 12 days/year
• Security Analyst / SOC — low, 6 days/year
• Material new tooling: Continuous control assertion framework spanning pipeline and runtime

Success Criteria

• At least 80% of verifiable controls carry continuous assertions in both pipeline and runtime, with unassertable controls listed and shrinking.
• Critical-tier assertion failures block merges or reach an owner within the day.
• Review false-negative rate is measured by forward tracing to incidents and reported to the sponsor as the practice's primary quality measure.
• At least 60% of reviewer hours go to controls automation cannot assert, and rising.
• Sampling continues on automatically verified assets so that a silently stopped assertion is detectable.

---

Key Success Indicators

Level 1:

• Every AI asset reaching production has an implementation review against the published per-archetype checklist.
• Controls are verified as present and effective, with controls the environment cannot expose recorded as unverifiable rather than passed.
• Every in-scope requirement receives a verified, not-verified or unverifiable disposition at review.
• Blocking findings are closed before go-live, and every accepted finding has a named acceptor with proportionate authority.
• Findings flow into the shared issue backlog rather than a separate review register.

Level 2:

• Re-review cadence is published per tier and driven by material-change triggers wired to change and deployment events.
• At least 90% of Critical-tier assets are under continuous drift detection, with detection within 5 business days.
• Findings carry tier and severity service levels with adherence at or above 90% per tier.
• Deferral authority rises with tier and severity, and deferred Critical findings carry executive acceptance with expiry.
• Deferred findings later implicated in incidents are tracked as a distinct measure of deferral judgment.

Level 3:

• At least 80% of verifiable controls carry continuous assertions in both pipeline and runtime, with unassertable controls listed and shrinking.
• Critical-tier assertion failures block merges or reach an owner within the day.
• Review false-negative rate is measured by forward tracing to incidents and reported to the sponsor as the practice's primary quality measure.
• At least 60% of reviewer hours go to controls automation cannot assert, and rising.
• Sampling continues on automatically verified assets so that a silently stopped assertion is detectable.

---

Common Pitfalls

Level 1:

• ❌ Verifying that a control is configured rather than that it works, which passes logging that emits nothing and allowlists running in audit mode.
• ❌ Recording a control the environment cannot expose as passed, which converts an observability gap into a false assurance.
• ❌ Keeping findings in a separate review register, where they age without the escalation the shared backlog would give them.
• ❌ Allowing findings to be neither fixed nor formally accepted, which leaves residual risk owned by nobody.
• ❌ Treating implementation divergence as a chance to re-open the design decision rather than as a finding against the change.

Level 2:

• ❌ Relying on annual re-review, which leaves an asset that changed in month two carrying a record indistinguishable from an accurate one for ten months.
• ❌ Detecting drift on a schedule rather than on change, which reintroduces exactly the point-in-time weakness the activity exists to remove.
• ❌ Routing drift detections into a report rather than the backlog, where they age without escalation and without an owner.
• ❌ Reporting closures to the sponsor without deferrals, which systematically flatters the practice.
• ❌ Authorising deferral without ever checking whether deferred findings later caused incidents, leaving the judgment unevaluated.

Level 3:

• ❌ Asserting only in the pipeline, which misses the drift that originates outside it and is where most silent disablement happens.
• ❌ Assuming a passing assertion is evaluating, when a stopped assertion reports success indistinguishably.
• ❌ Dropping sampling once automation is in place, removing the only check on the checks.
• ❌ Reporting coverage and timeliness as quality, both of which a review function that examines nothing carefully achieves easily.
• ❌ Leaving the unassertable control list unpublished, so the verification boundary is assumed empty and is not.

---

Practice Maturity Questions

Level 1:

1. Does every infrastructure AI asset receive an implementation review before go-live against a published per-archetype checklist that verifies controls are present and effective rather than documented, with controls the environment cannot expose recorded as unverifiable rather than passed?
2. Is the built system reconciled against the approved design and requirements pack, with every in-scope requirement given a verified, not-verified or unverifiable disposition and the design-to-implementation gap measured as a metric in its own right? For Infrastructure, the assessor should be shown the go-live review record showing applied state rather than the approved plan.
3. Do all findings carry an owner, severity, date and disposition in the shared issue backlog, with blocking findings closed before go-live and every accepted finding carrying a named acceptor with proportionate authority? In Infrastructure, ask to see the go-live review record showing applied state rather than the approved plan.

Level 2:

1. Is re-review cadence published per tier and driven by material-change triggers wired to change records and deployment events, with the calendar serving as a floor rather than the mechanism? Evidence this in the Infrastructure domain against the go-live review record showing applied state rather than the approved plan.
2. Are at least 90% of Critical-tier assets under continuous configuration drift detection with a 5 business day detection service level, and are detections routed into the shared backlog with tier-appropriate severity? For Infrastructure, the assessor should be shown the go-live review record showing applied state rather than the approved plan.
3. Do remediation service levels vary by tier and severity with adherence at or above 90% per tier, does deferral authority rise with tier, and are deferred findings later implicated in incidents tracked as a distinct measure? In Infrastructure, ask to see the go-live review record showing applied state rather than the approved plan.

Level 3:

1. Do at least 80% of verifiable controls carry continuous assertions running both in the pipeline and against the running system, with the unassertable remainder listed explicitly and reviewed quarterly for reduction? Evidence this in the Infrastructure domain against the go-live review record showing applied state rather than the approved plan.
2. Is review false-negative rate measured by tracing sign-offs forward to incidents and reported to the sponsor as the primary quality measure, rather than coverage and timeliness which a review examining nothing carefully can also achieve? For Infrastructure, the assessor should be shown the go-live review record showing applied state rather than the approved plan.
3. Is sampling maintained on automatically verified assets so that an assertion which has silently stopped evaluating is detectable, and does at least 60% of reviewer time go to controls automation cannot assert? In Infrastructure, ask to see the go-live review record showing applied state rather than the approved plan.

---

Lightweight Questions (E0 rung)

Answerable yes/no by one person in under 30 seconds, with nothing open.

Level 1:

• Does anyone check the built AI system before it goes live?
• Could you show that a control is working rather than configured?
• Does an accepted security finding have someone's name against it?

Level 2:

• Would you know if a security control on an AI asset was turned off last week?
• Does a high-risk AI asset get re-reviewed more often than a low-risk one?
• Does deferring a critical finding require senior sign-off?

Level 3:

• Is control verification continuous or tied to a review date?
• Do you know which controls your automation cannot check?
• Have you measured whether reviews you passed later caused incidents?

---

Tracking

Level 1 — Jira Epic, labels haiamm-ir-infrastructure-l1, haiamm-verification

• Done when: Every asset reaching production carrying a completed implementation review with zero blocking findings open at go-live and no accepted finding lacking a named acceptor, for two consecutive quarters.
• Git artifacts: security/implementation-reviews/infrastructure/, security/ir-records/index.json, security/ir-checklists/
• Git signal: ir-records/index.json is written by the review tooling at each go-live and reconciled against the deployment log, rather than assembled after the fact.
• CI check: implementation-review-gate

Level 2 — Jira Epic, labels haiamm-ir-infrastructure-l2, haiamm-verification

• Done when: Critical-tier drift detection coverage at or above 90% with detection within 5 business days at the 90th percentile and zero expired Critical-tier deferrals, sustained two consecutive quarters.
• Git artifacts: security/drift-coverage.json, security/ir-records/index.json, security/drift-rules/
• Git signal: drift-coverage.json is regenerated from the detection platform against the inventory rather than maintained by hand, and drift rules are versioned alongside the control definitions they check.
• CI check: drift-detection-coverage

Level 3 — Jira Epic, labels haiamm-ir-infrastructure-l3, haiamm-verification

• Done when: Continuous control assertion coverage at or above 80% across pipeline and runtime with Critical-tier failure routing at or above 95%, sustained across two consecutive quarters.
• Git artifacts: security/assertions/, security/assertions/unassertable.json, security/review-quality.json
• Git signal: review-quality.json is regenerated by joining review records to incident root causes rather than maintained by hand, and assertion freshness is emitted per evaluation so a stopped assertion is visible.
• CI check: assertion-freshness-check

---

Mappings

Level	HAI TTP	ATLAS	OWASP LLM 2025	Compliance
L1	EA, TM	AML.T0010, AML.T0035, AML.T0044, AML.T0049, AML.T0055	LLM03, LLM10	EU AI Act Art. 15; EU AI Act Art. 17; NIST AI RMF MEASURE 2.5; ISO/IEC 42001 8.1; ISO/IEC 27001 A.8.29
L2	EA, TM	AML.T0010, AML.T0035, AML.T0044, AML.T0049, AML.T0055	LLM03, LLM10	EU AI Act Art. 15; EU AI Act Art. 17; EU AI Act Art. 72; NIST AI RMF MEASURE 2.5; ISO/IEC 42001 9.1
L3	EA, TM	AML.T0010, AML.T0035, AML.T0044, AML.T0049, AML.T0055	LLM03, LLM10	EU AI Act Art. 15; EU AI Act Art. 17; EU AI Act Art. 72; NIST AI RMF MEASURE 2.5; ISO/IEC 42001 9.1

---

Document Version: HAIAMM v3.5 (generated) / Practice: Implementation Review (IR) / Domain: Infrastructure