Skip to content
Product Lifecycle Templates

Test Summary Report

beta  ·  Family qa-docs  ·  Phase develop  ·  Sizes lean, full  ·  ~4,300 tokens

The retrospective document that closes a testing effort: what was tested and on which build, what the testing found, what was deliberately or accidentally not tested, and whether the result clears the bar the test plan set. The closing bookend to the test plan, and the artifact a dashboard cannot produce, because the counts are computed and the judgement is not. Whether the genre should exist at all is contested: a named school of practitioners petitioned to have the international standard that defines it withdrawn, and this bundle teaches that dispute rather than settling it.

The short card. Why the document is shaped this way, and the argument behind every rule here, is in test-summary-report_companion.md. A fully worked instance is test-summary-report_example.md.

When to use

Section titled “When to use”

Read this first, because it changes what the card is claiming. The international standard that defines this document type is one a named school of practitioners campaigned to have withdrawn. In 2014 a petition organised by the International Society for Software Testing,, asked ISO to suspend publication of Parts 4 and 5 of ISO/IEC/IEEE 29119 and to withdraw Parts 1 to 3 - which includes the part that defines this report. Michael Bolton, a leading voice of the opposition, described that standard as an “overstructured process model, focused on relentless, ponderous, wasteful bureaucracy and paperwork, with negligible content on actual testing”. So nothing on this card says the test report is settled practice. It says how to write one worth reading if you are writing one, and it takes the opposition’s sharpest charge as the thing to design against rather than the thing to ignore. Both camps: companion section 6.

And one thing about where the section list came from. That standard is sold, not published. What this bundle read of it is its Clause 3 definition and its table of contents, which is a list of subclause headings and not the requirements underneath them. The sections you are about to fill come from ISTQB’s freely published foundation-level syllabus, from real filled reports, and from published templates - not from the standard’s unread text. The full retrieval position is companion section 1, and it is worth two minutes before you cite anything from this bundle to anyone.

Write one when:

  • A testing effort has ended - a release, a cycle, a level, a milestone - and someone has to say whether the bar the test plan set was cleared.
  • The result has to travel past the people who watched it happen: to another team, to a sponsor, to a customer, to the version of your own team that exists in six months.
  • A sign-off, an audit, a certification or a regulatory submission is downstream, and this report is part of the evidence rather than a courtesy.
  • Something was not tested, and a reader who is not told will assume it passed.
  • Residual risk is going to production and somebody needs to be on record accepting it, by name.
  • The engagement is closing or the team is dispersing, so this is the durable record of what was actually verified and on which build.

When NOT to use

Section titled “When NOT to use”

Write something else if:

You actually need Because
a test plan the testing has not happened yet. The plan is prospective: scope, approach, entry and exit criteria, agreed before the work starts. This report is its closing bookend and is retrospective. The dependency runs one way and it is structural: this report’s Evaluation Against Exit Criteria section has content only because a plan wrote criteria. Reaching for this template before the cycle means you wanted that one
a bug report one verification failed and an engineer needs to reproduce it. That is one document per defect, carrying steps, environment, and expected against actual. This report counts and characterizes defects by severity and says which remain open; it links to them and never accumulates their reproductions
a test status or progress report testing is still running. A progress report is produced at regular intervals against the plan’s baseline so that somebody can intervene while intervening is still possible; this document is produced once, at the end, and judges. If you are writing the same document every Friday you are writing progress reports, and the completion report is still owed at the end. This library ships no template for one, and its status-report is not it: that is the project-level periodic update for a different reader
nothing a pipeline already publishes the numbers and nobody needs a judgment on top of them. If the dashboard is live, the readers watched it all cycle, and nobody will be asked later to defend the release decision, then a message carrying the exit-criteria call and the residual-risk list does the entire job. A report that only restates the dashboard is strictly worse than the dashboard, because it is also out of date the moment you send it

The threshold, stated plainly. A tool vendor’s own framing of when the formal document earns its cost is the one this bundle adopts: it becomes useful when results need to be shared “beyond a single iteration or the immediate team”, or to support an audit, a customer sign-off, a regulatory review or a contract. Below that line, do not write one. Writing it anyway is how the document type earned its reputation.

The ship call has no section of its own

Section titled “The ship call has no section of its own”

If you are looking for a Release Recommendation heading, it is deliberately not here, and knowing where the call went is the difference between filling this template correctly and thinking a section is missing.

The ship sentence goes at the end of Evaluation Against Exit Criteria, underneath the criteria it rests on, in this shape: which criteria were met, which were not, and therefore ship, do not ship, or ship with these named conditions carried by this named person. One line on why: a recommendation with nothing above it is an opinion, and the same sentence under a graded criteria table is a conclusion.

This library considered a standalone section, tested the idea against its own research, and dropped it - neither readable structural source carries one, and the real filled reports in the corpus do not either, with one certification-lab exception the companion explains. The evidence and the change of mind are in companion section 3.

What this does not change: the test plan card promises that what you found and whether you are shipping belong in a report written afterwards. They do. The verdict simply does not get a heading of its own.

Pick a variant

Section titled “Pick a variant”

Lean (six sections) is the default: Scope and What Was Tested, Execution Summary, Defects, Deviations from Planned Testing, Evaluation Against Exit Criteria, and Residual Risk and What Was Not Tested. That is what closing a release actually takes - what it was, what ran, what broke, what did not happen as planned, whether the bar was cleared, and what is being carried forward.

Full (nine sections) adds Impediments and Blocked Progress, Test Deliverables and Reusable Assets, and Lessons Learned. Reach for it when at least one of these is true:

  • the reader is an auditor, a regulator, a customer or an accreditation body, and completeness is part of the evidence rather than a style preference;
  • testing was done by a vendor, a lab, or more than one team, so who tested what belongs in the record;
  • the assets outlive the release and the next team inherits the suites, harnesses, fixtures and environments;
  • the reader was not there, and this report is the durable record rather than a step in a conversation that continues;
  • no retrospective is going to happen, so this is the only place the learning survives.

Nesting is strict: every lean heading appears in the full variant with the same name in the same order, and full only adds. A lean report grows into a full one without rewriting a line of what is already there.

Two sections are never the ones you cut, whichever variant you pick: Evaluation Against Exit Criteria and Residual Risk and What Was Not Tested. Those are the two your tooling cannot produce, and they are the reason the document exists at all. If the whole budget is one paragraph, write those two and link the dashboard for the rest.

Quality rubric (self-grade before you send it)

Section titled “Quality rubric (self-grade before you send it)”

Score each 0, 1 or 2. Under 13 out of 18 and what you have is a dashboard with a cover page: the reader gets counts they already had, and none of the three judgments only a person can make - what was not tested, what risk is being accepted, and whether the bar was cleared.

# Criterion 0 1 2
1 Build is named No version, build or commit anywhere in the document A version, but no environment and no reference to the plan it answers A reader six months from now can name the build, the environment and configuration, the period tested, and the plan whose criteria this grades
2 Claim is bounded Nothing says what the result does not cover A scope line that restates the feature name and stops The report says what configuration and version the result applies to, and names at least one thing a reader must not read it as covering
3 Coverage claim honest “Coverage” is a pass percentage wearing a different word Coverage is stated, but only against the cases in your own suite Coverage is stated against something outside the suite - risks, requirements, areas, code - and where breadth was traded for depth, the report says which
4 Defects are summarized A tracker export pasted in, or a single total Counts by severity Severity and pattern, what is still open, who owns each open item, and links out to the reports rather than their reproductions retyped here
5 Deviations are filled Empty, or “none” on a cycle that visibly slipped Says the plan changed Names what was planned and not done, what was done instead, and why - enough that the counts above can be read correctly rather than taken at face value
6 Criteria graded individually Prose about how the cycle went One summary judgment covering all criteria at once Every exit criterion the plan set appears with met or not met and the evidence for it, including the ones that were not met
7 Conclusion follows criteria No conclusion, or one that contradicts the grades above it A conclusion is stated, with nothing tying it to any criterion The ship sentence sits under the graded criteria, names its conditions and who is accepting them, and a reader can point at the grade that would flip it
8 Residual risk owned Not mentioned, or written as an apology for running out of time Untested areas listed, with no consequence attached Each item says what could go wrong, who is accepting it and on what basis, and Undetermined appears wherever that is the honest answer
9 Adds beyond the dashboard Everything here was already in the tool One section carries something the tool could not compute A reader who had the dashboard open all cycle still learns something, and could point at where

The test behind every cell above: could someone satisfy it without improving the report? A row that counted defects, or counted exclusions, would reward padding, and a forty-row defect table nobody triaged would score the same as one honest paragraph. Every cell instead asks whether a specific piece of evidence is there and whether a second person, not the author, could find it.

Named anti-patterns (the usual wrecks)

Section titled “Named anti-patterns (the usual wrecks)”
  1. The dashboard with a cover page. Execution Summary filled in, everything else thin or absent. The tell is that a reader could have learned more by opening the tool, and that your document was out of date before it was sent. This is the failure the whole document type stands accused of, so it is the one to check for first. Fix: write only what the tool cannot compute, and if that leaves nothing, do not write the report.
  2. Coverage claimed, pass rate measured. “96 percent coverage” where what was measured is the proportion of executed tests that passed. These are two different claims about two different things: pass rate is a property of the tests you chose to run, and coverage is a claim about the system, stated against risks, requirements, areas or code. A suite exercising a tenth of the product can post a perfect pass rate, and a reader who reads that as coverage treats untested ground as cleared. The security assessment in this bundle’s research shows the honest form: it discloses that “codebase coverage emphasized breadth instead of depth” and that portions outside the control areas received minimal to no coverage. Fix: name the denominator, and where the denominator is your own suite, say so in the same sentence.
  3. Silence read as coverage. Areas nobody tested go unmentioned, so a reader assumes they passed. Related to the one above and not the same: that one overclaims, this one omits, and omission is the easier of the two to commit by accident. Fix: an explicit not-tested list with a reason against each item, sitting in the same section as the residual risk it creates.
  4. Complete and empty. Every heading present, nothing decided, because the template asked for a heading. James Christie’s critique aimed squarely at this document type describes the result as “a collection of metrics that say nothing about the quality of the product”, and he is describing reports that complied with the standard rather than reports that ignored it. Fix: delete any section that decides nothing, and make the exit-criteria evaluation carry an actual “therefore”.
  5. The verdict with nothing above it. A confident release call resting on numbers that do not support it, or on no criteria at all. This is exactly the failure that the missing Release Recommendation heading is designed to prevent, and moving the sentence does not prevent it by itself. Fix: grade the criteria first; the call is the last line of that section, never the first line of the report.
  6. Residual risk written as apology. “Unfortunately we ran out of time for the migration path.” That is a schedule confession, not a risk statement: it explains why a gap exists and says nothing about what the gap could cost or who is carrying it. Fix: name the exposure, the person accepting it, and the basis for accepting it. The regulated form of this is a written risk-based rationale for every defect left unfixed, and it is a good shape to borrow even when nobody is making you use it.

Pairing with a skill

Section titled “Pairing with a skill”

pairs_with: [], and the empty list is a finding rather than an omission. There is no testing or QA skill in the pm-skills library: none of its tracked skills produces a test plan, a test case, a bug report or a test report, recorded as finding EC-4 (pm-skills covers no testing or QA work) in this repository’s STATE.md. The test plan bundle can honestly claim deliver-edge-cases, because an edge-case catalog is an input to planning coverage. A report of testing already finished has no such input to take, so this bundle declines the pairing rather than borrowing its sibling’s. Everything here is filled by hand, from your test plan, your defect tracker and your tool’s run data.

The artifacts

Section titled “The artifacts”

test-summary-report_template-lean.md · ~4,300 tokens

---
title: "{{release_or_feature}} Test Summary Report"
release_or_feature: "{{release_or_feature}}"
build_or_version: "{{build_or_version}}"
test_plan_ref: "{{test_plan_ref}}"
report_author: "{{report_author}}"
test_period: "{{test_period}}"
status: "{{status}}"
last_updated: "{{date}}"
doc_type: test-summary-report
size: lean
source_template: test-summary-report
source_template_version: 0.1.0
---


<!--
LEAN TEST SUMMARY REPORT. The smallest report that is still a real report: what was tested and on which
build, what ran, what broke, what did not happen as planned, whether the bar the test plan set was cleared,
and what is being carried forward untested or unfixed. Use it to close a release or a test cycle for readers
who were broadly in the room. To grow it into the accountability-grade report (see
test-summary-report_template-full.md), ADD sections; never rename or reorder the ones below, because the full
variant is a strict superset of this one.


IF THE DASHBOARD ALREADY SAYS IT, DO NOT RETYPE IT. The criticism this document type has never fully answered
is that it can satisfy every heading and still say nothing about the quality of the product. Your test tool
computes the counts better than this page can. What it cannot do is say what was not tested and why, what
residual risk somebody is accepting, and whether the result clears the bar. Spend your time there; where a
section adds nothing to the tool, keep it to a line and a link. See test-summary-report_companion.md
sections 6 and 7.


SOMETIMES THE HONEST ANSWER IS NOT TO WRITE ONE. If everyone who would read this sat in the same standup all
cycle, a short message carrying the exit-criteria call and the residual-risk list does the whole job. Write
the document when the result has to travel: beyond one iteration, beyond the immediate team, or into an
audit, a sign-off or a contract.


WHAT A TEST SUMMARY REPORT IS, AND IS NOT
It is the retrospective document that closes a testing effort: what was tested, what the testing found, what
was deliberately or accidentally not tested, and whether the result clears the bar the test plan set. It is
NOT a test plan (that is prospective, written before), NOT a test status or progress report (that is produced
at intervals while testing is still running), NOT your test tool's exported run or your CI dashboard (those
compute the counts; this document carries the judgment), and NOT a bug tracker (one failing verification is
one bug report). See test-summary-report_companion.md section 8.


IF YOU ARE LOOKING FOR A "RELEASE RECOMMENDATION" SECTION, IT IS DELIBERATELY NOT HERE. The ship call belongs
at the end of Evaluation Against Exit Criteria, underneath the criteria that justify it. A recommendation
with nothing above it is an opinion; the same sentence under a graded criteria table is a conclusion. This
library considered a standalone section and dropped it for want of evidence; the reasoning is in
test-summary-report_companion.md section 3.


HOW TO FILL THIS IN
1. Read the comment under each heading: WHAT it wants, WHY it matters (with a pointer into
   test-summary-report_companion.md), guiding questions to ASK, a GOOD and a WEAK example, and the TRAP to
   avoid. For tables, PRIORITY explains the ordering rule and ROW HINT says what a good row contains.
2. Replace each {{placeholder}} with your content. Fill Scope and What Was Tested first, then Evaluation
   Against Exit Criteria; everything else exists to make that evaluation readable.
3. If a section does not apply, write "N/A" and one line of why, rather than deleting it silently.
4. Before you share it: self-grade against test-summary-report_guide.md, then DELETE every HTML comment.
   They are guidance, not content.
-->


# {{release_or_feature}} Test Summary Report


## Scope and What Was Tested


<!-- WHAT  What this report covers: the build or version under test, the environment and configuration, the
           test plan it answers to, the period it covers, and the boundary of the claim.
     WHY   Every number below is meaningless without the version that produced it, and the version is the
           field the one filled report in this bundle's research omits, which names
           no build anywhere, so nobody reading it later can tell what it was about. Bounding the claim is
           the other half: a report that does not say what it does not cover gets read as covering
           everything. Deep dive: test-summary-report_companion.md section 3 (Anatomy > Scope and What Was
           Tested).
     ASK   Which build, version or commit was tested, in which environment and configuration? Which test
           plan, and which of its criteria, does this report answer? What period does it cover, and who
           tested? What does the result explicitly not apply to?
     GOOD  "Covers Claims Intake R7.2, build 7.2.14, on pre-production with the fnol_v4 flag on, tested
           2026-03-02 to 2026-03-13 by Nadia Okonkwo and Fabiola Reyes against the R7.2 test plan. Results
           apply to that build and configuration only. The broker portal integration runs on its own release
           train and was not exercised here."
     WEAK  "Testing of the claims release. Ran on staging." (no build, no dates, no plan reference and no
           boundary, so a reader can tell neither what the report is about nor what it leaves out)
     TRAP  Omitting the build or version because everyone currently knows which one it was. In six months
           this report is the only record, and nobody will. -->


{{scope_and_what_was_tested}}


## Execution Summary


<!-- WHAT  The counts - planned, executed, passed, failed, blocked, not run - per area or suite, with
           coverage stated against something meaningful, and a line below the table saying when the
           counts were taken and where the live results live.
     WHY   This is the section your tooling can fill, and the only one. Test management tools and CI plugins
           compute exactly these numbers and draw them better than a document can, so a report that is
           mostly this section is a dashboard with a cover page, and out of date the moment it is written.
           Put the counts here so the judgment below has something to stand on, and put the judgment where
           the criteria are. Deep dive: test-summary-report_companion.md section 3 (Execution Summary) and
           section 6.
     ASK   How many cases were planned, and how many actually ran? What failed, what was blocked, what never
           ran at all? What is coverage a fraction of - risk areas, requirements, the plan's own priorities?
           When were these counts taken, and where does a reader go for the detail?
     PRIORITY  Order rows by the plan's own risk ranking, highest risk first, so a reader scanning the top of
           the table is reading about the areas that mattered most. Counts are a snapshot: state the date and
           time they were taken, because they moved the day after.
     ROW HINT  A good row names an area the plan recognizes, gives every count including the ones that did
           not run, and says what the coverage figure is a fraction of. A weak row is a suite name and a pass
           percentage.
     GOOD  | Payout calculation (High risk) | 48 | 46 | 42 | 3 | 1 | 2 | 46 of 48 planned cases; all 9
           High-risk scenarios executed |
     WEAK  | Regression | | | | | | | 97 percent |
     TRAP  Leading with a pass rate. "97 percent passed" hides whether the 3 percent was a cosmetic label or
           the permission check, and a percentage is an input to the exit-criteria evaluation below, never a
           substitute for it. -->


| Area or suite | Planned | Executed | Passed | Failed | Blocked | Not run | Coverage and notes |
|---|---|---|---|---|---|---|---|
| {{area}} | {{planned}} | {{executed}} | {{passed}} | {{failed}} | {{blocked}} | {{not_run}} | {{coverage_note}} |


{{execution_summary_notes}}


## Defects


<!-- WHAT  What was found, at what severity, what is fixed, and what is still open at the moment of writing -
           summarized and linked, never transcribed.
     WHY   Open defects are the content here; a list of what you fixed is history. The strongest real reports
           break the found defects down by something a team can act on, such as root cause or component, and
           give every open one a severity and a stated reason it is not being fixed. Deep dive:
           test-summary-report_companion.md section 3 (Defects).
     ASK   How many defects were found, at what severities, and what pattern do they show? How many remain
           open, and which are in scope for the release decision? For each open defect, what would a user
           experience, why is it not fixed, and who accepted that? What is fixed but not yet verified?
     PRIORITY  Severity first, highest first, and open before closed within a severity. Closed defects are a
           summary line above the table; every open defect in scope gets a row of its own.
     ROW HINT  A good row identifies the defect, gives severity and status, says what a user would
           experience, and names both the reason it stands and the person who accepted it. A weak row is a
           ticket number and a title.
     GOOD  | CLM-4471 | Sev-2 | Open | Payout total rounds down by one cent on multi-currency claims | Fix
           lands in 7.2.15; Ellen Wray accepted the cent-level variance for the two-week window and finance
           was notified 2026-03-11 |
     WEAK  | CLM-4471 | High | Open | Rounding bug | Will fix |
     TRAP  Pasting the tracker in. Forty rows of reproduction steps make a worse defect list than the tracker
           itself and bury the three that matter. Summarize, link out, and spend the words on the open
           ones. -->


{{defect_summary}}


| Defect | Severity | Status | Impact if it ships | Disposition: why it is open, who accepted it |
|---|---|---|---|---|
| {{defect_id}} | {{severity}} | {{defect_status}} | {{defect_impact}} | {{defect_disposition}} |


## Deviations from Planned Testing


<!-- WHAT  What the plan said would happen, what actually happened, and why the difference - in scope,
           schedule, depth, environment or data.
     WHY   Deviations are what make the numbers above interpretable: a 98 percent pass rate over half the
           planned depth is a different result from the same rate over all of it. The evidence for keeping
           this section is one-sided - both structural sources this bundle could read carry it, both real
           templates ask for it, and the one real filled report gives it a named subsection - which is why it
           is in the lean variant, against this library's own earlier internal spec. Deep dive:
           test-summary-report_companion.md section 3 (Deviations from Planned Testing) and section 4.
     ASK   What did the plan say, and what actually happened? Which areas were tested less deeply than
           planned, or not at all? What changed in scope, schedule, environment or data mid-effort, and who
           agreed it? Who knew at the time, and who is finding out from this document?
     GOOD  "The plan scheduled two full regression passes; one ran, because pre-production was rebuilt in
           week two. Fraud-scoring cases were executed against synthetic data rather than the anonymized
           production extract, which never arrived. Both were raised with Ellen Wray on 2026-03-06; neither
           changed the agreed exit criteria."
     WEAK  "Some testing was descoped due to time." (which testing, how much, whose decision, and what does
           it do to the counts above)
     TRAP  Writing this section after the release decision is made. A deviation that surfaces for the first
           time in the report is news, and news arriving this late damages trust in everything else on the
           page. Raise them as they happen and record them here. -->


{{deviations_from_planned_testing}}


## Evaluation Against Exit Criteria


<!-- WHAT  Each exit criterion the test plan set, whether it is met, and on what evidence - then the
           conclusion the testing reaches about releasing.
     WHY   This is the load-bearing section, and the evaluation against agreed criteria is the act that makes
           this a report rather than an export. Neither readable structural source gives the release call a
           heading of its own, and neither does this template: a recommendation with nothing above it is an
           opinion, while the same sentence underneath a graded criteria table is a conclusion. Write the
           table, then write the sentence: met, not met, and therefore. Deep dive:
           test-summary-report_companion.md section 3 (Evaluation Against Exit Criteria), which records why
           this library considered a standalone Release Recommendation section and dropped it for want of
           evidence.
     ASK   What exactly were the exit criteria, and who agreed them and when? Is each met, partially met or
           not met, and on what evidence? Where one is not met, what does releasing anyway cost? What does
           the testing therefore conclude, and who owns the decision this conclusion feeds?
     PRIORITY  One row per criterion, in the plan's own words and the plan's own order. Never rewrite a
           criterion to match the result. If the plan set no exit criteria, do not invent them after the
           fact: say so plainly in the conclusion and state the bar you are applying instead.
     ROW HINT  A good row quotes the criterion, gives a plain verdict (met, partially met, not met), points
           at the evidence, and where it is not met says what that costs. A weak row is a criterion and a
           tick.
     GOOD  | All 9 High-risk payout scenarios executed with no Sev-2 or worse left open | Not met |
           CLM-4471 (Sev-2) open, see Defects | Multi-currency claims round down by one cent until
           7.2.15 |
     WEAK  | Quality is acceptable | Met | Testing complete | |
     TRAP  The verdict with nothing above it. A confident release sentence sitting on ungraded criteria, or
           on no criteria at all, is exactly the failure this section's shape exists to prevent. -->


| Exit criterion (as the plan wrote it) | Verdict | Evidence | Consequence if released as is |
|---|---|---|---|
| {{exit_criterion}} | {{criterion_verdict}} | {{criterion_evidence}} | {{criterion_consequence}} |


{{conclusion_and_release_call}}


## Residual Risk and What Was Not Tested


<!-- WHAT  What remains untested, what remains unfixed, and what that exposes - written as risk somebody is
           accepting, not as a gap somebody forgot.
     WHY   This is the section a generated report cannot produce, and the one downstream readers thank you
           for. Silence gets read as coverage: an area nobody tested and nobody mentioned reads, later,
           exactly like an area that passed, which is why the sharpest assessments in this bundle's research
           warn their readers not to treat unexamined areas as cleared. Naming the untested area, the unfixed
           defect and the person carrying the consequence is what turns an omission into a decision. Deep
           dive: test-summary-report_companion.md section 3 (Residual Risk and What Was Not Tested) and
           section 7.
     ASK   What was not tested at all, and what was tested more shallowly than its risk deserved? What ships
           unfixed? For each item, what could go wrong, who is accepting it, and how would you find out in
           production? What is genuinely undetermined, as opposed to fine?
     PRIORITY  Order by what it would cost if it went wrong, worst first. Every row needs a named person
           accepting it; a residual risk with no name on it has been accepted by nobody. "Undetermined" is a
           legitimate entry and a better one than a confident guess.
     ROW HINT  A good row names the untested area or unfixed defect, states the exposure as a consequence to
           someone, names the person accepting it, and says what would detect it in production. A weak row is
           a topic with the word "risk" next to it.
     GOOD  | Fraud scoring exercised on synthetic data only | A rule tuned on real distributions could
           misfire on live claims; false declines reach customers | Tomas Brenner | Decline-rate alert on the
           R7.2 dashboard, reviewed daily for two weeks |
     WEAK  | Fraud scoring | Some risk | QA | Monitor |
     TRAP  Writing residual risk as an apology. "Unfortunately we ran out of time for the migration path" is
           a schedule confession. "An unmigrated legacy claim opens read-only and the adjuster cannot
           progress it; accepted by Ellen Wray for the 40 affected claims" is a risk statement. -->


| Untested area or unfixed defect | Exposure: what could go wrong, and to whom | Accepted by | How it surfaces |
|---|---|---|---|
| {{residual_item}} | {{residual_exposure}} | {{residual_accepted_by}} | {{residual_detection}} |

Provenance

Section titled “Provenance”

The reasoning, the history and every source, in the repository:

  • Companion - the long-form argument: why these sections, where the sources disagree, and what the bundle refuses to claim
  • History - what changed in this bundle, and when
  • Research log - every source consulted, with what each one actually supports
  • Catalog metadata - the machine-readable record this page is generated from

Catalog record: 9 sections across 1 format(s).