Coverage as a Claim: Technique Maps, Evidence Age and Detection Decay

"Covered" is the most used and least examined word in security reporting. A technique map coloured green says that something is covered, and the reader is left to guess what was done, when, in which environment and by whom. This chapter treats coverage as a claim that has to be written down with its evidence, in the way a finding or a control is. It concerns P3 Observe, where a step is compared with its expectation and the result is recorded, and P5 Verify, where re-tests and evidence turn a result into something that can be relied on and that expires. The coverage record, COV-NR-* and COV-HM-*, is the artefact that joins them. Chapter 4 introduced it as derived and not a stage record, and this chapter defines it.

The argument is short. A claim of coverage has five parts: a technique, an environment, a result at a named layer, a date and an expiry. A claim that lacks any of them is a hope. A claim whose evidence has outlived its expiry is a memory. A claim that rests on someone else's statement is an assertion, and a technique that nobody has tested is not covered, whatever the colour of its cell. The chapter shows how to make these distinctions mechanical, so that the status of a technique is computed from records and not decided in a meeting, and how to report coverage so that a board or a supervisor sees the age of what it is told.

Regression cases and evidence manifests, and assertions, feed coverage records; a status rule applies clock and condition to give five statuses, which are counted on the coverage page and declared by a named person.

Figure 17.1: Regression cases and assertions feed coverage records, a status rule gives five statuses, and a named person declares coverage.

The chapter builds on conclusions of the earlier volumes and on the stage chapters of this book. Architecture as Code (Chapter 15A) concluded that evidence is machine-collected, signed and versioned and not assembled in audit season (87, Nordqvist, 2025). AI Governance, Chapter 11, separated attestation, which is a person asserting, from evidence, which the system generates (88, Nordqvist, 2026). AI Red Team, Chapter 25, set the safety boundaries of continuous verification, and Chapter 3 of the same volume introduced the CSF profile kept as code, which Chapter 17 uses below (90, Nordqvist, 2026). AI Threat, Chapter 30, classified controls as verified, declared or failed and required a control-to-threat matrix that counts controls sharing a dependency once, and Chapter 32 fixed the register that reaches the board on one page (91, Nordqvist, 2026). Within this book, Chapters 5, 9, 10, 11 and 15 defined the priority techniques, the outcome taxonomy, the routes for a finding, the regression case and evidence manifest, and the independence principle; none is repeated here.

From heat map to evidence

A technique heat map is the commonest coverage artefact. The ATT&CK Navigator, a widely used open-source tool for such maps, lets a user annotate each cell of the matrix with a colour, a score and a comment (45, MITRE, n.d.). That is a sensible tool for planning, and a poor tool for asserting. A cell has room for a colour, and a colour answers none of the questions a reader needs answered. Green may mean that a detection rule exists, that a rule fired in a test, that the vendor says the product covers the technique, or that someone judged the risk acceptable. The same green may have been set last week or two years ago. It may describe the production estate or a laboratory.

The Center for Threat-Informed Defense makes the same point about the quality of what stands behind a cell. Its Summiting the Pyramid project separates implementation coverage, which counts the behaviourally distinct ways in which an analytic can observe a technique, from detection quality, which assesses the robustness and precision of the signals behind that visibility (44, Center for Threat-Informed Defense, 2026). A cell that says only "detected" merges the two. The book's own addition is the dimension of time. A heat map is a statement about the present written from evidence about the past, and without an age on the evidence the reader cannot tell which part of the map is still true.

Three failures recur when a heat map is the coverage artefact.

  1. It rewards the last pass. A cell turns green when a test passes and stays green until someone changes it. Nothing turns it amber when the detection is edited, the connector is replaced or the model behind a triage agent is updated, so over a year the share of green cells can only rise.
  2. It hides the denominator. "Seventy per cent green" does not say whether the list has 20 techniques or 200, or whether the techniques left out were hard to test (Chapter 5).
  3. It merges unlike things. A technique prevented in a mirror, one detected in production, one the managed provider says it handles and one nobody has examined can share a colour, and the reader decides on the wrong one.

A map that is reported to a board as a measure of security will be improved, because improving its colours is cheaper than improving the defence (the mechanism is Goodhart's law, which Chapter 18 explains). The remedy is not a different colour scheme. It is a record behind each cell that cannot be improved without doing the work.

What covered means

The book uses the word "covered" for one condition only: a person can show, from records, that a specified technique was exercised in a specified environment inside a window of time, that the defence produced a specified result at a specified layer, and that the evidence has not expired. The definition has three consequences.

The result is stated at a layer. Chapter 9 defined seven outcomes for a step: prevented, detected, alerted but not triaged, triaged but not acted on, missed, no telemetry and not tested. Coverage uses the same taxonomy and reports three levels of defence that are often blurred. A technique is prevented (Chapter 9: prevented) when a control stopped the effect. It is detected (Chapter 9: detected) when the whole chain ran, from the signal through triage to the action, within the bound. It is logged but not detected (Chapter 9: missed, with the telemetry present) when the event is in a store that a query could find but no rule raises it, which is what the event in SCN-NR-0006 looked like in the spring of 2028: the endpoint console recorded the process event, the SIEM held it, and no rule matched. A technique that is logged but not detected is not covered by detection, and it is not nothing: it is a technique for which a detection can be written without new collection, which is a cheaper finding than a missing log source. The record states the highest layer reached and the layer at which the chain broke when it did.

Tested differs from asserted. A test is an exercise the organisation, or a party independent of the defence, ran and whose result it holds. An assertion is a statement by someone else that the defence works: a vendor's mapping of its product to ATT&CK, a managed provider's runbook, a policy that says a control exists, an owner's belief. AI Threat, Chapter 30, called controls that rest on such statements declared, and controls that have passed a recent test verified (91, Nordqvist, 2026). Assertions are useful. They tell the organisation where to test first. They are not evidence, and the record must say so.

Untested is not covered. The rule that AI Blue, Chapter 6, applied to detections and that Chapter 9 applied to steps applies to techniques: a technique with no test, or with a test whose evidence has expired, is reported as not tested, with the date of the last test that did run (94, Nordqvist, 2026). Reporting an expired pass as untested is not harsh. It is the only statement that remains true.

Six values result. A coverage record has exactly one status, derived by rule from its evidence.

Status Meaning Counts as covered
verified A passing result, with its variants, whose evidence has not expired and whose conditions have not changed Yes
expired A passing result whose clock has run out or whose condition has changed No: reported as not tested, with the date of the last pass
implemented-unverified A change was merged for a finding and the re-test has not yet passed (Chapter 10) No
failed The last result was a failure, or the last re-test failed; also shown for a risk-accepted finding, with the acceptance reference No
asserted No test by the organisation or an independent party; a statement by a provider, a vendor or an owner No
untested Nothing is recorded No

The table aligns with the five finding states of Chapter 4 and the verified, declared and failed classes of AI Threat, Chapter 30. Three vocabularies describe the same ground at three levels and are mapped once, here. The finding state belongs to a finding (Chapter 4), the register state to a priority technique in the register (Chapter 11), and the coverage status to a coverage record.

Finding state (Chapter 4) Register state (Chapter 11) Coverage status
Closed and verified, within its age Verified verified
Closed and verified, past its age or condition Not tested expired
Implemented, unverified Implemented, unverified implemented-unverified
Re-test failed; risk accepted Failed failed
No finding, no test by the organisation Not tested asserted or untested

A finding that is risk-accepted keeps its technique at failed, so that a board reading the coverage page cannot mistake an accepted gap for a closed one, as Chapter 10 required.

The coverage record

A coverage record exists for each technique and environment that the priority list names (Chapter 5). The pair matters. A technique passed in the pre-production mirror has said nothing about production, and a technique passed against a test tenant of the identity provider has said nothing about the production tenant's conditional-access policy. One technique therefore has as many records as it has environments that matter, and the report shows them separately or shows the weakest.

The record is derived and is rebuilt whenever a regression case, an evidence manifest or an assertion changes. A person does not edit its status. It holds the following fields.

  • Identity and scope: id, the technique (an ATT&CK or ATLAS identifier and the knowledge-base version, as Chapter 5 required), the environment, the service and the priority tier.
  • What was tested: the scenario or scenarios (SCN-*), the regression case (REG-*), the variants run and whether one was held out, and the safety class of the run.
  • When and how: the date of the last run, who or what ran it (a person, a pipeline runner, a provider's injected test), and the emulation plan.
  • Result: the outcome for each layer, with times to detect and to triage where they exist, and the reference of any finding.
  • Evidence: the evidence manifest (EVD-*), signed, as Chapter 11 described.
  • Expiry: the clock, the date on which it runs out, and the conditions that end the evidence earlier.
  • Independence: independence: shown | limited | not-assessed, with the statement of Chapter 15 that applies and its own expiry, where AI took part on both sides of the check.
  • Declaration: the person who declares the technique covered, and the date. The field is empty unless the status is verified.

The sections below treat three of these fields that carry most of the weight: the expiry, the environment and variants, and the declaration. First, one complete record.

Worked example: A Hansa Mutual coverage record COV-HM-0112

The illustrative record below follows the detection DET-HM-0561, which watches the claims-triage agent for actions outside its manifest (Chapter 12, AIDR-0862). The scenario SCN-HM-0058 was written by the group red team in the autumn 2027 round of HM-SEC-003. The detection was drafted by HM-SEC-002 and reviewed by a detection engineer who had not chosen the scenario. The simulation of 2028-02-09 prevented the action and detected it in four minutes. Because the claim concerns a priority agent, its clock is 90 days.

# Illustrative: Hansa Mutual, coverage record
kind: CoverageRecord
id: COV-HM-0112
technique: {atlas: AML.T0053, note: family of SCN-HM-0058, knowledge_base: ATLAS-current-at-signature}
environment: claims-triage-agent/production-replay
tier: 1
tested:
  scenario: SCN-HM-0058                     # authored by the group red team
  regression_case: REG-HM-0112
  variants: [{id: v1-other-market, held_out: false}, {id: h1-tool-chain, held_out: true}]
  safety_class: S1
  run_by: HM-SEC-004                        # MND-HM-EMU-06, Level 3 for S1 regression cases
last_tested: 2028-02-09
result:
  prevented: true
  detected: {by: DET-HM-0561, minutes: 4, triaged_by: person}
  weakest_layer: none
  findings: [FND-HM-2027-031]               # closed and verified
evidence: {manifest: EVD-HM-2028-0121, signed: true, reproduced_by: person}
expiry:
  clock_days: 90
  expires: 2028-05-09
  conditions: [model_change, prompt_template_change, manifest_change, DET-HM-0561_edit]
independence: {statement: IND-HM-2028-Q1, valid_to: 2028-05-22, drafter_checker_family: separate}
status: verified                            # computed from the fields above, never edited
declared_by: lena-vogel                     # head of detection engineering
declared_on: 2028-02-12

Three features matter. The status is a consequence of the fields: if the clock runs out on 2028-05-09, or the manifest of the agent changes before then, the same rule gives expired without anyone deciding it. The record says which layer failed when a layer did, and here none did, which is itself a statement and not an absence. And the declaration is a person's act, made after the status was computed; the status says that the claim may be made, and the declaration is the moment someone makes it and is accountable for it. The independence statement IND-HM-2028-Q1 expires on 2028-05-22, after the coverage clock, so it is the coverage clock that binds here. Had the order been the reverse, the shorter of the two would govern.

Evidence age and expiry

Chapter 11 introduced the two parts of an expiry: a clock that sets a number of days after the last full pass, and conditions that end the evidence earlier. The coverage record carries both, and this chapter's addition is that the age of the evidence is a reported quantity and not only an internal rule.

The defaults of the two organisations are fixed. Hansa Mutual's evidence for a priority technique expires after 90 days and for any other technique after 180 days; independence statements and coverage claims for priority agents also expire after 90 days. Nordvik Region applies 180 days to every technique on its list, in keeping with a quarterly cadence and the decision of AIDR-0801. The numbers are choices. What matters is that they are written down, that the pipeline applies them, and that an extension is a recorded decision with a name and a reason; an expiry that is silently extended is the same as none.

Age is reported in three ways, and a coverage page that shows only one invites a wrong decision.

  • Age at the report date. For each technique, the days since the last passing run and the days remaining.
  • Distribution. The share of priority techniques in each age band: for Hansa, 0 to 30, 31 to 60, 61 to 90 and past expiry. A distribution crowded against the right-hand edge says the pipeline is behind, whatever the headline figure says.
  • The oldest unexpired claim and the oldest expired one. Two numbers that a reader can compare from one report to the next.

A pipeline that runs priority techniques at least every 30 days, as HM-SEC-004 does, produces evidence younger than the 90-day clock by construction. That is a strength, and the reason to report the distribution: a runner that has stopped silently for a month shows nothing on a status count until the clocks begin to run out.

Decay

Evidence expires on a clock because the thing it describes changes. The word used here for the process is decay: a detection that worked when it was tested and that no longer works, without any person having decided to break it. Two sources of change are distinguished, and they call for different conditions in the record.

Change in the estate. A log source is replaced and the field names change. A connector is moved to a new region and its filter drops a type of event. A parser is updated and no longer extracts the account name. A baseline against which the detection compares behaviour drifts, as the baseline of DET-HM-0561 does when the model or the prompt template of the agent changes; that detection lists rebaseline_on conditions for exactly that reason (Chapter 12). A detection is edited to reduce noise and the edit narrows what it sees. A managed provider changes the model that closes alerts, and the closure behaviour that a test measured is no longer the behaviour in force; annex MS-2 requires 20 working days' notice of a model change at Nordvik Region so that the Region can re-test (AI Blue, Chapter 16). None of these changes announces itself as a coverage change. Each is a condition in the record, and the pipeline compares the dependencies listed in the evidence manifest with the current state.

Change in the adversary and in the variant. A detection is written for the form of a technique that the scenario used. The adversary does not need to change tools to change the form. Chapter 8 reported the effect in Hansa Mutual's first quarter of 2028: detections fired on 37 of 41 scenarios in known form, 90 per cent, and on 10 of 14 held-out variants, 71 per cent, a generalisation gap of 19 points. The figures are the group's own and illustrative, and the pattern is the point. Coverage measured on the form the detection was built for overstates coverage of the technique. That is why the record names its variants and flags the held-out one, and why a pass of the exact scenario alone supports no more than "verified for this form" (Chapter 11). The knowledge bases change too. A technique is added, merged or deprecated in a new ATT&CK release, so a coverage record written against one release is reviewed when the release changes, as Chapter 5 required of the scenario library.

Decay is observable in practice: every operational detection team has met a rule that stopped firing after a platform change, and the closing-of-the-loop rule of this book exists for that reason. What the book does not offer is a rate of decay. It found no published measure of how fast detections degrade in European public authorities or insurers, and the 90 and 180 days are management choices, not measured half-lives. The right response to that gap is the conditions in the record, which end the evidence at the moment of a change and make the clock a backstop and not the only guard.

Environments and variants

The record names its environment because the same technique has different answers in different places. Four environments recur in the two organisations. Production, for scenarios of safety class S1 run by the pipeline or by a person with the white team's approval. A pre-production mirror, which is where Nordvik Region runs the scenarios that need realistic state, such as the exploitation of a public-facing application. A test tenant or test host, which is where the spring catalogue of 2028 ran. A range, which is where Hansa Mutual plans the techniques it cannot run in production in a reversible form. The record says which, and the rule that follows is blunt: a pass in a mirror or range supports a claim about the mirror or range. It supports a claim about production only to the extent that the record shows the production control and telemetry to be the same ones, and a gap between them is a finding.

This matters most for prevention. A technique prevented in a mirror that runs a hardened image says nothing about production hosts built from an older one. The record handles this with two entries: a mirror record with its result, and a production record that stays untested or asserted until the same control is shown to be present. A reader who wants one number gets the weaker.

Variants are handled as Chapter 11 handled them, and the record carries three of their properties: which variants ran, which was held out from the author of the fix, and whether a negative control passed. A record whose only test is the exact scenario states that fact in its variants field, and the declaration then reads "verified for the catalogued form". Where AI drafted the variants, the record notes it and the independence statement applies.

Honest "not tested"

The most valuable line on a coverage page is the one that says "not tested", because it is the one that is hardest to write. Four rules keep it honest.

  1. Count it in the denominator. The page reports verified techniques out of all priority techniques, and the others by reason: expired, failed, implemented but unverified, asserted, untested. Hansa Mutual's nine unverified priority techniques at BTP-HM-2027-Q3 split into four with evidence past its expiry, three that failed a re-test and two that had never been tested, which needed three different actions (Chapter 11).
  2. Say why it is not tested. Some techniques cannot be run in production in a reversible form. T1486 data encrypted for impact and T1490 inhibit system recovery are the two at Hansa Mutual; they are planned for the red-team range, and until the range runs them they are untested. Some are out of scope of the current rules of engagement. Some belong to a provider's boundary that the organisation has not been allowed to test. The reason points to the owner who must change something.
  3. Show the last test that did run. An expired claim shows its date and its result. A reader sees "last passed 390 days ago" and understands without a legend.
  4. Never turn an assertion into a test by repetition. A provider's statement that it handles a technique, repeated in four documents, is one assertion. It becomes evidence when the Region or an independent party runs a catalogued scenario or an injected test and holds the result. Annex MS-2 at Nordvik Region exists to convert the provider's assertions into tests: the five seeded incidents per class per quarter are the Region's evidence, and the provider's runbook is a claim until they have passed.

The gap list that results is a map of what the defence does not do. Chapter 16 classified it as FC-4 Exploitable while any technique on it is untested or failed, and the full coverage page carries that classification; the board summary is a different artefact in a lower handling class.

Practical guide: Replacing a technique heat map with coverage records that carry age and expiry

Purpose. Replace a colour map with records from which the status of each priority technique is computed, so that the first report shows verified, expired, failed, asserted and untested honestly.

Roles. The coverage owner (at Nordvik Region the detection owner, Karin Lund, in her role as purple team coordinator; at Hansa Mutual the head of detection engineering), the red-team lead or contracted tester, a detection engineer who did not choose the scenarios, the white-team lead for the independence check, and the CISO or delegate who accepts the page. The detection owner declares coverage and does not tune the status rule; a change to the rule is a pull request that the white team reviews.

Steps.

  1. Take the priority list (Chapter 5). One record per technique and environment that the list names. For a first conversion, use production and the one mirror, if there is one.
  2. For each existing green cell, find the evidence. Link the scenario, the last run, the result and the manifest. If the cell cannot be linked to any of them, it is asserted or untested, whatever its colour.
  3. Set the clock: 90 days for priority techniques and 180 for the rest, or the organisation's own figures. List the conditions: the detection, the connector, the parser, the model or manifest of any agent involved, the provider's model.
  4. Write the status rule as code (the excerpt below) and run it. Nobody sets a status by hand.
  5. Read the output as a list of work: expired goes to a re-run, failed back to P4 Improve, asserted to a test request or an injected test, untested to a scenario or a mirror. Record the owner and date for each.
  6. Put the coverage page in front of the CISO with the denominator, the reasons and the age distribution, and retire the heat map for reporting. Keep it, if wanted, as a planning view.
  7. Review the rule and the defaults at each priority-list review, every six months, and after any finding that coverage should have predicted.

Definition of done. Every priority technique has a record per relevant environment; no status was set by hand; the page shows the denominator, the reasons and the age distribution; the first report was declared by a named person; and the gap list is held in the handling class of Chapter 16.

# Illustrative: status rule, evaluated by the pipeline on every change to a REG, EVD or assertion
statusRule: coverage-status v1.0.0
order:                                   # first match wins
  - {when: no_record_or_no_run,                       status: untested}
  - {when: last_result == fail,                       status: failed}
  - {when: finding_open and change_merged,            status: implemented-unverified}
  - {when: tested_by == assertion_only,               status: asserted}
  - {when: age_days > clock_days or condition_changed, status: expired}
  - {when: pass and variants_run and negative_control, status: verified}
  - {when: otherwise,                                    status: failed}
reportAs:
  verified_count: all records with status verified
  of_which_independence_shown: verified records whose independence field reads shown
  covered: [verified]
  notCovered: [expired, implemented-unverified, failed, asserted, untested]
override: {allowed: false, extension: "recorded decision, named person, reason, new date"}

Reporting

Coverage reaches three readers: the management of the loop, the board or audit committee and the supervisor. They need the same facts at different heights, and the page is built once and summarised.

For the management of the loop, the full page: each technique and environment, status, layer, age, days remaining, owner of the next action.

For the board, one page with the denominator, the six counts, the age distribution, the oldest expired claim and at most three decisions, in the manner AI Threat, Chapter 32, set for the register (91, Nordqvist, 2026). The board does not need the technique list. It needs to know that 25 of 34 priority techniques are verified, that nine are not and why, and which decision would change the figure. Chapter 18 develops the measures that go beside it, and the way in which they mislead when they reward activity.

For the supervisor, the records, on request, in the form from which the page was computed. Two European instruments make coverage evidence relevant to the supervisors of the two organisations, each to be read as an architectural implication and not as legal advice. Under DORA, Article 24(1), financial entities other than microenterprises establish, maintain and review a digital operational resilience testing programme in order to assess preparedness, identify weaknesses, deficiencies and gaps and promptly implement corrective measures, and Article 25(1) lists the tests the programme provides for, among them scenario-based tests and penetration testing (2, European Union, 2022). The delegated regulation on threat-led penetration testing also provides for the remediation stage that follows the test (Delegated Regulation (EU) 2025/1190) (8, European Commission, 2025). Hansa Mutual, as an insurance group, falls within DORA. Under NIS 2, Article 21(2)(f), entities within scope maintain policies and procedures to assess the effectiveness of cybersecurity risk-management measures (3, European Union, 2022); whether Nordvik Region falls within scope depends on national transposition, and where it does, a coverage page is the kind of record that answers the provision. In both cases the architectural point is the same: a testing programme is shown by its results and their dates, and a coverage record is the compact form of that.

A CSF profile kept as code

AI Red Team, Chapter 3, described a NIST CSF 2.0 profile kept as code, in which each Function and Category maps to the obligations it helps to meet (90, Nordqvist, 2026) (24, NIST, 2024). Coverage records give the profile a source of evidence that is not a questionnaire. The Category for risk assessment and the one for improvement draw on the coverage page for the techniques the register names, and the Categories for detection and for response draw on the layers reached. The mapping is one-directional and by reference: the profile cites record identifiers and a computed status, and does not copy them. A profile entry that reads "covered" while the records beneath it read expired is detected by the same pipeline that computes the status. A supervisor or an auditor then asks one question of the profile, which is where the evidence is, and gets a link.

AI in coverage

AI helps to compile coverage and must not be the party that declares it. The usage modes differ in what they can do, and the degrees of delegation set the ceiling.

Across the usage modes

Usage mode What it does for coverage Level Who decides
Mode 1 Conversational assistants Help a coverage owner draft the reasons for a gap or summarise a page Level 0 Advisory The coverage owner
Mode 2 Embedded workplace assistants Suggest ATT&CK tags for an existing detection or a provider statement Level 0 Advisory to Level 1 Assisted The detection engineer
Mode 3 Agentic work tools Assemble candidate records from the repository, linking runs and manifests Level 1 Assisted The coverage owner
Mode 4 Built AI applications A coverage agent proposes a status and flags records whose conditions changed Level 2 Supervised A person reviews the proposal; the status rule decides the status
Mode 5 Autonomous production agents The re-test runner (MND-HM-EMU-06) writes the result of a codified re-test; no agent computes or declares coverage Level 3 Bounded for the re-test only The re-test runner records a result; a person declares

Two points follow. The status is not an AI judgement: it is computed by a deterministic rule from records, so the coverage agent cannot raise a technique to verified by proposing it. And the ceiling for declaring is a person, because the declaration is an accountability and not a computation. The ceiling for a re-test is the one of Chapter 4: a passing codified re-test may be recorded at Level 3 Bounded, the person who owns the closure signs it (Chapter 11), and Level 4 Autonomous is never used for an emulation action that is irreversible, that leaves the signed scope, that touches personal data beyond the authorisation or that targets a named person.

The independence principle (Chapter 15) applies to the coverage chain itself. If the agent that drafted a detection also computes the coverage of that detection, or the model that wrote the scenario also reviews the result, the record is accurate about what ran and may be wrong about what it means. Chapter 15 called that inflated coverage. The record therefore carries its independence statement and the status rule reads it: a priority-agent claim whose independence statement has expired is expired, whatever its clock says; one whose statement says limited stays verified and is reported with that qualifier beside the count.

Observable, expected, speculation

Observable. Evidence age, expiry on a clock and on conditions, and the practice of reporting by denominator and reason are in use in threat-led testing and in continuous monitoring programmes; the supervisory frameworks cited above require testing programmes, remediation and review, and the book found no instrument that prescribes an age for evidence.

Expected. Coverage records kept as code and drawn on by a CSF profile follow from the direction of travel in evidence as code (87, Nordqvist, 2025) and from continuous emulation (Chapter 8); no source states that a supervisor will require them.

Speculation. Coverage that is continuous and never expires, because a pipeline runs everything all the time: the costs of realism in Chapter 8, the limits on production emulation in Chapter 6 and the decay of detections with change all argue against it, and the techniques that cannot run in production in a reversible form are never continuously covered by that route. This is a reading of the evidence, not a measured result.

Nordvik Region and Hansa Mutual

Nordvik Region buys the loop, and its leverage in coverage is the contract. It has nine priority techniques for the benefits-triage service (PRI-NR-2028-01) and reports them to the audit committee in three states and not in a colour: tested, asserted by the provider and not tested. AIDR-0814 (2028-03-07) adopts the coverage record and the status rule, and AIDR-0815 (2028-04-12) places the coverage page first in the report pack for AIDR-0800, due on 2028-04-30. The page as of 2028-04-26 reads as follows. It has no pipeline, so every date on it is the date of a person's or a provider's run, and its 180-day clock is a deliberate match for a quarterly cadence.

# Illustrative: Nordvik Region, coverage page for PRI-NR-2028-01, as of 2028-04-26 (AIDR-0815)
kind: CoveragePage
priority_list: PRI-NR-2028-01
status_rule: coverage-status v1.0.0
clock_days: 180
reported_as: {tested: 5, asserted_by_provider: 2, not_tested: 2, of: 9}
declared_by: karin-lund
rows:   # technique, record, status, layer, last_tested, expires, note
  - {t: T1110.003, cov: COV-NR-0001, status: verified, layer: detected-and-triaged, last: 2028-02-09, exp: 2028-08-07, ev: EVD-NR-2028-0003}
  - {t: T1078,     cov: COV-NR-0002, status: verified, layer: detected-and-triaged, last: 2028-02-09, exp: 2028-08-07, ev: EVD-NR-2028-0003}
  - {t: T1566.002, cov: COV-NR-0003, status: failed,   layer: triaged-not-acted-on, last: 2028-02-20, note: "MS-2 round 2028-Q1, one escape in class MS2-C1 (AIDR-0813)"}
  - {t: T1053.005, cov: COV-NR-0004, status: failed,   layer: logged-only, last: 2028-03-22, note: "FND-NR-2028-003 open; DET-NR-0012 and REG-NR-0006 pending"}
  - {t: T1059.001, cov: COV-NR-0005, status: failed,   layer: logged-only, last: 2028-03-22, note: "declared gap before the run; routed in PRP-NR-2028-01, recorded in the session as a declared gap, no finding opened"}
  - {t: T1685,     cov: COV-NR-0006, status: asserted, basis: "MS-1 runbook statement", last: none, note: "injected test requested for MS-2"}
  - {t: T1098,     cov: COV-NR-0007, status: asserted, basis: "MS-1 runbook statement", last: none}
  - {t: T1190,     cov: COV-NR-0008, status: untested, last_pass: 2027-04-02, expired: 2027-09-29, env: preprod-mirror}
  - {t: T1486,     cov: COV-NR-0009, status: untested, last_pass: 2027-03-30, expired: 2027-09-26, env: preprod-mirror}
oldest_unexpired_claim_days: 77
oldest_expired_claim_days: 393

Two of the nine are the techniques whose spring 2027 mirror evidence had passed its expiry by the autumn, T1190 and T1486; the page reports them as not tested, with the date of the last pass, which is the honest statement. The two asserted techniques are the provider's statements under annex MS-1, and the Region's request is that they become injected tests under MS-2. Karin Lund declares the page, and Elin Berglund reproduces the verified rows; the contracted tester is not the detection owner, which gives the page independence by role.

Hansa Mutual runs the loop, and its leverage is the pipeline. In March 2028 AIDR-0864 (2028-03-14) converts the 34-technique heat map behind BTP-HM-2027-Q3 into coverage records and retires the colour map for reporting, and AIDR-0865 (2028-03-28) confirms in the status rule the 90-day expiry of coverage claims for priority agents and their independence statements, which COV-HM-0112 and IND-HM-2028-Q1 already ran on in February. The conversion reproduces the board's figure of 25 verified out of 34 and shows what the colours hid: four of the nine cells that now read as not verified were green on the old map, because their last result was a pass and the map had no age, and their evidence was past its expiry. The other five were already visible as failed or never tested. The nine are the gap list of Chapter 16, held in the handling class FC-4. The pipeline's rolling schedule exercised 31 of the 34 priority techniques within 30 days in the first quarter of 2028, and the page does not count that as coverage: running a technique is activity, and the record counts a technique only when the result, the layer and the variants are on file. The independence statement IND-HM-2028-Q1 covers seven of the 25, so the board figure is reported with that qualifier and the other eighteen are marked not-assessed until the next review extends the statement (Chapter 15). The COV-HM-0112 record above is one of the 25, with 13 days of its clock left on 2028-04-26.

The difference between the two is that Nordvik's risk is a page that is accurate on the day it is declared and not refreshed, so the expiry clock and the reproduction by the tester are its guards. Hansa's risk is a page that is refreshed so often that nobody reads its age. For Hansa the guard is the distribution of ages in the report, the independence check on the chain that built the record, and a named person who declares.

Summary

This chapter concerned P3 Observe and P5 Verify. It argued that coverage is a claim with five parts, a technique, an environment, a result at a named layer, a date and an expiry, and that a heat map with no age and no evidence is not a coverage statement. It defined the coverage record as the derived artefact that joins the outcome of a step to the regression case and the evidence manifest, with six values of status computed by rule: verified, expired, implemented but unverified, failed, asserted and untested. Only a verified record counts as covered, and the declaration is a person's act.

Evidence is a photograph, and decay is the process by which the photograph stops describing the estate. The record guards against decay with a clock and with conditions that end the evidence at the moment of a change in a log source, a connector, a parser, an agent's model or manifest, or a provider's model. It guards against overstated coverage by naming the environment, the variants and the held-out case, and by distinguishing prevented, detected and logged but not detected. It keeps "not tested" honest by counting it in the denominator, giving its reason and showing the last test that ran.

Reporting follows the same discipline. The board sees the denominator, the six counts, the age distribution and at most three decisions; the supervisor sees the records; a CSF profile kept as code refers to them. AI compiles and proposes, a deterministic rule decides the status, and a person declares. The independence principle of Chapter 15 applies to the chain that builds the record. Nordvik Region reports nine techniques in three states and Hansa Mutual finds, by converting its heat map, what the colours hid. Chapter 18 turns from the claim to the measures that sit beside it, and shows how to measure the loop without rewarding activity in place of yield.

Sources

  1. Nordqvist, G. (2025). Architecture as Code. The Transformed Architecture, Book 1. (87, Nordqvist, 2025)
  2. Nordqvist, G. (2026). AI Governance. The Transformed Architecture, Book 2. (88, Nordqvist, 2026)
  3. Nordqvist, G. (2026). AI Red Team. The Transformed Architecture, Book 4. (90, Nordqvist, 2026)
  4. Nordqvist, G. (2026). AI Threat. The Transformed Architecture, Book 5. (91, Nordqvist, 2026)
  5. Nordqvist, G. (2026). AI Blue. The Transformed Architecture, Book 8. (94, Nordqvist, 2026)
  6. European Parliament and Council of the European Union. Regulation (EU) 2022/2554 (DORA). (2, European Union, 2022)
  7. European Parliament and Council of the European Union. Directive (EU) 2022/2555 (NIS 2). (3, European Union, 2022)
  8. NIST. The NIST Cybersecurity Framework (CSF) 2.0. (24, NIST, 2024)
  9. European Commission (2025). Commission Delegated Regulation (EU) 2025/1190. (8, European Commission, 2025)
  10. Center for Threat-Informed Defense (2026). Summiting the Pyramid. (44, Center for Threat-Informed Defense, 2026)
  11. MITRE Corporation. ATT&CK Navigator. (45, MITRE, n.d.)