diff --git a/docs/review-2026-10-dev-scenarios.md b/docs/review-2026-10-dev-scenarios.md
index 67b9bdb..a6a6950 100644
--- a/docs/review-2026-10-dev-scenarios.md
+++ b/docs/review-2026-10-dev-scenarios.md
@@ -135,4 +135,7 @@ Answers (2026-10-16):
 
 | Ticket | Finding | Change | Branch |
 |--------|---------|--------|--------|
-|        |         |        |        |
+| 14 (#36) Number of parallel units on a treatment step in the configurator | F2 (D7) | C1 | `c1-failure-inputs` |
+| 15 (#37) Personal treatment steps store the number of parallel units | F2 (D7) | C1 | `c1-failure-inputs` |
+| 16 (#38) Both cases use the daily LRV of each failing step | F1 (D6) | C2 | `c2-failure-calculation` |
+| 17 (#39) The failure LRV follows from the number of parallel units | F2 (D7) | C2 | `c2-failure-calculation` |
diff --git a/docs/specs/c1-failure-inputs.md b/docs/specs/c1-failure-inputs.md
index c8e50af..f609f0e 100644
--- a/docs/specs/c1-failure-inputs.md
+++ b/docs/specs/c1-failure-inputs.md
@@ -1,32 +1,47 @@
 # Spec C1: Failure inputs
 
-Status: draft, 2026-09-24. Change C1 in `docs/failure_roadmap.md` (Large). Spec issue: #___
-Sources: `docs/vision.md` (MVP item 1 and 2), `CONTEXT.md`, ADR-0001, roadmap decisions D4
-and D5.
+Status: draft, 2026-09-24, revised 2026-10-16 for D7 (number of parallel units). Change C1
+in `docs/failure_roadmap.md` (Large). Spec issue: #___
+Sources: `docs/vision.md` (MVP item 1 and 2), `CONTEXT.md`, ADR-0001, ADR-0002, roadmap
+decisions D4, D5 and D7.
+
+The first version (failure frequency and failure duration) is built and was tested on the
+dev environment (tickets 04–06). This revision adds the third failure input, the number of
+parallel units, and keeps everything else. Requirements that are new in this revision are
+marked *(D7)*.
 
 ## Problem Statement
 
 A utility operator or engineer who wants to know how failures of their treatment steps
-affect the yearly risk has nowhere to say how often a step fails and for how long. The
-assessment configurator only knows LRVs, and a personal treatment step only stores a name
-and LRVs. Before the calculation can include treatment failures (C2), users need a place to
-enter a failure frequency and a failure duration for each treatment step, and the
-application needs to keep those values with the scenario.
+affect the yearly risk has nowhere to say how often a step fails, for how long, and how much
+of the step stops when it fails. The assessment configurator only knew LRVs, and a personal
+treatment step only stored a name and LRVs. Before the calculation can include treatment
+failures (C2), users need a place to enter a failure frequency, a failure duration and a
+number of parallel units for each treatment step, and the application needs to keep those
+values with the scenario.
+
+In most plants the LRV of a step does not drop to 0 during a failure: a step often has
+several parallel units, and a failure event stops only one of them (D7, ADR-0002). Without
+the number of parallel units, every failure would be counted as a complete loss of the
+step's positive LRVs.
 
 ## Solution
 
-Every treatment step in the assessment configurator gets two more fields next to its LRVs:
-**failure frequency** (failure days per year) and **failure duration** (minutes). They
-start at 0 days per year and 30 minutes, so a step does not fail unless the user says so.
-The application checks the values when the assessment is run or saved and explains what is
-wrong. A step can only have a failure frequency above 0 if at least one of its LRVs is
-positive, since a failure removes only positive LRVs (D4).
+Every treatment step in the assessment configurator has three failure fields next to its
+LRVs: **failure frequency** (failure days per year), **failure duration** (minutes) and
+**number of parallel units** *(D7)*. They start at 0 days per year, 30 minutes and 1 unit,
+so a step does not fail unless the user says so, and a step with one unit loses all its
+positive LRVs when it fails, as before. The application checks the values when the
+assessment is run or saved and explains what is wrong. A step can only have a failure
+frequency above 0 if at least one of its LRVs is positive, since a failure removes only
+positive LRVs (D4).
 
-Registered users can also store both values on a personal treatment step. When they add
-that step to an assessment, its failure frequency and failure duration are copied in like
-its LRVs. Saved assessments keep the values, and reopening or editing an assessment shows
-them again. Assessments saved before this change reopen with failure frequency 0 and
-failure duration 30, so nothing about them changes.
+Registered users can also store the three values on a personal treatment step. When they
+add that step to an assessment, its failure inputs are copied in like its LRVs. Saved
+assessments keep the values, and reopening or editing an assessment shows them again.
+Assessments and personal treatment steps saved before a failure input existed read back its
+default: failure frequency 0, failure duration 30 and 1 parallel unit, so nothing about
+them changes.
 
 In this Change the values do not yet affect the result. The calculation follows in C2, and
 nothing reaches production before C1–C5 are released together (D5).
@@ -37,109 +52,142 @@ nothing reaches production before C1–C5 are released together (D5).
    assessment, so that the assessment reflects how often each step fails at my plant.
 2. As a utility operator, I want to enter a failure duration for each treatment step, so
    that the assessment reflects how long a typical failure event lasts.
-3. As a user, I want the failure frequency to be given in failure days per year, so that I
+3. As a utility operator, I want to enter the number of parallel units of each treatment
+   step, so that a failure of one unit is not counted as a failure of the whole step.
+   *(D7)*
+4. As a user, I want the failure frequency to be given in failure days per year, so that I
    can use the numbers from my plant's operating records directly.
-4. As a user, I want the failure duration to be given in minutes, so that short failure
+5. As a user, I want the failure duration to be given in minutes, so that short failure
    events can be expressed without fractions.
-5. As a user, I want the unit of each failure field shown next to it, so that I do not
-   enter hours instead of minutes or events instead of days.
-6. As a user, I want every treatment step to start with failure frequency 0, so that an
+6. As a user, I want the number of parallel units to be a plain count of units, so that I
+   can take it from the plant layout. *(D7)*
+7. As a user, I want the unit or meaning of each failure field shown in its label, so that I
+   do not enter hours instead of minutes, events instead of days, or a percentage instead of
+   a count of units.
+8. As a user, I want every treatment step to start with failure frequency 0, so that an
    assessment without failure information behaves as before.
-7. As a user, I want every treatment step to start with failure duration 30 minutes, so
+9. As a user, I want every treatment step to start with failure duration 30 minutes, so
    that I only change the duration when I know a better value.
-8. As a user, I want to enter a fractional failure frequency such as 0.5 days per year, so
-   that I can describe a step that fails once every two years.
-9. As a user, I want a failure frequency below 0 or above 365 to be rejected with a clear
-   message, so that I notice a typing mistake.
-10. As a user, I want a failure duration below 1 or above 1440 minutes, or a non-whole
+10. As a user, I want every treatment step to start with 1 parallel unit, so that a step I do
+    not describe further loses all its positive LRVs during a failure, as before. *(D7)*
+11. As a user, I want to enter a fractional failure frequency such as 0.5 days per year, so
+    that I can describe a step that fails once every two years.
+12. As a user, I want a failure frequency below 0 or above 365 to be rejected with a clear
+    message, so that I notice a typing mistake.
+13. As a user, I want a failure duration below 1 or above 1440 minutes, or a non-whole
     number of minutes, to be rejected with a clear message, so that I notice a typing
     mistake or a wrong unit.
-11. As a user, I want to be told when I give a failure frequency above 0 to a step that has
+14. As a user, I want a number of parallel units below 1, or one that is not a whole number,
+    to be rejected with a clear message, so that I notice a typing mistake. *(D7)*
+15. As a user of a large plant, I want to enter any number of parallel units, however large,
+    so that the application does not stop me from describing my plant. *(D7)*
+16. As a user, I want to be told when I give a failure frequency above 0 to a step that has
     no positive LRV, so that I understand that such a step cannot fail.
-12. As a user modelling recontamination with a negative LRV, I want that step to keep
+17. As a user modelling recontamination with a negative LRV, I want that step to keep
     failure frequency 0, so that recontamination is never treated as a failing step.
-13. As a user, I want a step with a positive LRV for one pathogen group and a zero or
+18. As a user, I want a step with a positive LRV for one pathogen group and a zero or
     negative LRV for another to accept failure inputs, so that steps like chlorination
     (protozoa minimum 0) or a storage tank with regrowth can fail.
-14. As a user, I want the failure fields to appear in the same card as the step's LRVs, so
+19. As a user, I want the number of parallel units shown for every treatment step, next to
+    failure frequency and failure duration, so that I see all failure inputs of a step
+    together and the form does not change shape while I type. *(D7)*
+20. As a user describing a non-technical measure such as a hygiene practice, I want the same
+    three failure fields, so that I can leave the number of units at 1 and the measure is
+    lost completely during a failure. *(D7)*
+21. As a user whose units fail together, for example through a shared power supply, I want
+    to enter 1 unit, so that such a failure is counted as a loss of the whole step. *(D7)*
+22. As a user, I want the failure fields to appear in the same card as the step's LRVs, so
     that I see all values of a step together.
-15. As a user, I want the failure values of each step to stay with that step when I
-    reorder or remove other steps, so that values do not move to the wrong step.
-16. As a user adding the same bundled step twice, I want to give each copy its own failure
-    values, so that two parallel units can have different failure records.
-17. As a guest, I want to enter failure inputs and run an assessment, so that I can try the
-    feature without an account.
-18. As a guest, I want invalid failure inputs to be rejected in the same way as for
+23. As a user, I want the failure values of each step to stay with that step when I reorder
+    or remove other steps, so that values do not move to the wrong step.
+24. As a user adding the same bundled step twice, I want to give each copy its own failure
+    values, so that I can describe two separate installations of the same technology.
+25. As a guest, I want to enter all three failure inputs and run an assessment, so that I
+    can try the feature without an account.
+26. As a guest, I want invalid failure inputs to be rejected in the same way as for
     registered users, so that the rules do not depend on having an account.
-19. As a registered user, I want the failure values of each step saved with my assessment,
+27. As a registered user, I want the failure values of each step saved with my assessment,
     so that I do not have to enter them again.
-20. As a registered user, I want to see the saved failure values when I reopen an
+28. As a registered user, I want to see the saved failure values when I reopen an
     assessment, so that I can check what the assessment is based on.
-21. As a registered user, I want to change failure values when I edit an assessment and
+29. As a registered user, I want to change failure values when I edit an assessment and
     have the new values saved, so that I can correct or update them.
-22. As a registered user, I want assessments I saved before this change to reopen with
-    failure frequency 0 and failure duration 30, so that their results do not change.
-23. As a registered user, I want to store a failure frequency and failure duration on a
-    personal treatment step, so that my plant's failure record is reused in every
-    assessment that uses the step.
-24. As a registered user, I want the same checks on a personal treatment step as in the
+30. As a registered user, I want assessments I saved before a failure input existed to
+    reopen with its default (failure frequency 0, failure duration 30, 1 parallel unit), so
+    that their results do not change.
+31. As a registered user, I want to store all three failure inputs on a personal treatment
+    step, so that my plant's failure record is reused in every assessment that uses the
+    step.
+32. As a registered user, I want the same checks on a personal treatment step as in the
     configurator, so that a personal step never carries values an assessment would reject.
-25. As a registered user, I want a personal treatment step's failure values copied into the
-    assessment when I add the step, so that I do not type them again.
-26. As a registered user, I want to change the copied failure values in one assessment
+33. As a registered user, I want a personal treatment step's failure values, including its
+    number of parallel units, copied into the assessment when I add the step, so that I do
+    not type them again.
+34. As a registered user, I want to change the copied failure values in one assessment
     without changing the personal treatment step, so that I can try other values in one
     scenario.
-27. As a registered user, I want personal treatment steps I created before this change to
-    offer failure frequency 0 and failure duration 30, so that they keep working.
-28. As a registered user, I want my personal treatment steps and their failure values to be
+35. As a registered user, I want personal treatment steps I created before a failure input
+    existed to offer its default, so that they keep working.
+36. As a registered user, I want my personal treatment steps and their failure values to be
     visible only to me, so that my plant's failure record stays private.
-29. As a user comparing scenarios, I want two saved assessments to differ only in their
-    failure inputs, so that I can later compare the effect of different failure
-    frequencies.
-30. As a user, I want bundled treatment steps to come without failure values, so that I am
+37. As a user comparing scenarios, I want two saved assessments to differ only in their
+    failure inputs, for example only in the number of parallel units of one step, so that I
+    can later compare the effect of that input.
+38. As a user, I want bundled treatment steps to come without failure values, so that I am
     not given literature failure data the application does not have.
-31. As a developer of C2, I want the failure frequency and failure duration of every step in
-    an assessment to be available where the calculation reads the treatment train, so that
-    C2 only has to change the calculation.
-32. As a developer of C3, I want the stored failure values to be readable from a saved
-    assessment, so that C3 can add them to the export package and report.
+39. As a developer of C2, I want the failure frequency, failure duration and number of
+    parallel units of every step in an assessment to be available where the calculation
+    reads the treatment train, so that C2 only has to change the calculation.
+40. As a developer of C3, I want the stored failure values to be readable from a saved
+    assessment, so that C3 can add them to the export package.
 
 ## Implementation Decisions
 
-- **Two new attributes on two kinds of treatment step.** The treatment step of an
-  assessment and the personal treatment step each get *failure frequency* (a decimal
-  number of failure days per year) and *failure duration* (a whole number of minutes).
-  Both are required, with defaults 0 and 30. A schema migration adds them to both, and
-  existing rows receive the defaults.
+- **Three attributes on two kinds of treatment step.** The treatment step of an assessment
+  and the personal treatment step each carry *failure frequency* (a decimal number of
+  failure days per year), *failure duration* (a whole number of minutes) and *number of
+  parallel units* (a whole number) *(D7)*. All three are required, with defaults 0, 30 and
+  1. Failure frequency and failure duration exist since tickets 04–06. A new schema
+  migration adds the number of parallel units to both kinds of step, and existing rows
+  receive 1.
 - **Bundled treatment steps are unchanged.** They carry no failure data (failure inputs are
   user input only). A bundled step added to an assessment starts at the defaults.
 - **One validation rule, used by both forms.** The treatment step form of the configurator
-  and the personal treatment step form apply the same rule, defined once:
+  and the personal treatment step form apply the same shared rule, which already checks
+  minimum ≤ maximum LRV and the first two failure inputs. It is extended, not duplicated:
   - failure frequency from 0 to 365 inclusive, decimals allowed;
   - failure duration a whole number from 1 to 1440 inclusive;
+  - number of parallel units a whole number of 1 or more, with no upper limit *(D7)*;
   - failure frequency above 0 only if at least one of the step's six LRVs (minimum and
     maximum for bacteria, viruses and protozoa) is above 0; an empty LRV counts as 0 (D4).
     The error is attached to the failure frequency field.
-  The duration range is checked even when the frequency is 0, so stored values are always
-  valid. The existing minimum ≤ maximum LRV check, which both forms currently duplicate,
-  may move into the same shared rule.
-- **Configurator.** Each treatment step card shows the two fields below its LRV rows,
-  labelled with their units ("Failure frequency (days per year)", "Failure duration
-  (minutes)"). The fields are always shown; the D4 rule is enforced by validation, since the
-  user can change LRVs after entering a frequency. Guests see and use the same fields.
-- **Saving and reopening.** The treatment step formset saves the two values with each step,
-  and reopening an assessment fills them in again. Each value belongs to its step, not to a
-  position in the train.
-- **Personal treatment steps.** The personal treatment step form gets the two fields. The
-  list of personal treatment steps that the configurator loads includes both values, and
-  the configurator copies them into a newly added step together with its LRVs. The copy is
-  independent: editing it in an assessment leaves the personal treatment step unchanged.
+  The ranges are checked even when the frequency is 0, so stored values are always valid.
+  The messages follow the existing pattern and name the field and its range, for example
+  "number of parallel units must be a whole number of 1 or more".
+- **Configurator.** Each treatment step card shows the three failure fields below its LRV
+  rows, labelled "Failure frequency (days per year)", "Failure duration (minutes)" and
+  "Number of parallel units". The fields are always shown, also when the failure frequency
+  is 0; the D4 rule is enforced by validation, since the user can change LRVs after
+  entering a frequency. Guests see and use the same fields. The labels say nothing more;
+  what a parallel unit is, that the failure duration affects both best-case and
+  worst-case, and that units failing together are entered as 1 unit are explained in C4.
+- **Saving and reopening.** The treatment step formset saves the three values with each
+  step, and reopening an assessment fills them in again. Each value belongs to its step,
+  not to a position in the train.
+- **Personal treatment steps.** The personal treatment step form gets the number of
+  parallel units next to the two existing failure fields. The list of personal treatment
+  steps that the configurator loads includes all three values, and the configurator copies
+  them into a newly added step together with its LRVs. The copy is independent: editing it
+  in an assessment leaves the personal treatment step unchanged.
 - **Guest path.** The guest result submits the same treatment step formset. Failure values
   are validated there too and are not stored.
 - **No effect on results.** The calculation, the result page and the export package are not
-  changed in C1. The values are stored so that C2 and C3 can use them.
-- **Delivery.** C1 stays an open pull request and is tested on the dev environment; it is
-  not merged into `main` before the release (D5). C2 and C3 build on it.
+  changed in C1. The values are stored so that C2 and C3 can use them; C2 reads the number
+  of parallel units to calculate the failure LRV (ADR-0002).
+- **Delivery.** The number of parallel units is added in new tickets on the existing C1 pull
+  request (roadmap decision "Rework of C1–C3"). C1 stays an open pull request and is tested
+  on the dev environment again; it is not merged into `main` before the release (D5). C2
+  and C3 build on it.
 
 ## Testing Decisions
 
@@ -150,71 +198,94 @@ nothing reaches production before C1–C5 are released together (D5).
 - **One seam: HTTP through the Django test client.** Tests post the configurator form (save
   and guest result) and the personal treatment step form, then read the saved assessment,
   the reopened configurator or the personal treatment step list. This covers form
-  validation, saving, reopening and ownership without a separate form-level seam.
-- **Behaviour covered at that seam:**
-  - saving an assessment with failure inputs and reopening it returns the same values;
-    editing and saving again stores the new values;
+  validation, saving, reopening and ownership without a separate form-level seam. The
+  number of parallel units is tested at the same seam as the other two failure inputs.
+- **Behaviour covered at that seam** (cases new in this revision marked *(D7)*):
+  - a new step card, the guest form and the personal treatment step form show all three
+    failure fields with their labels and defaults 0, 30 and 1 *(D7: the third field)*;
+  - saving an assessment with failure inputs and reopening it returns the same values,
+    including the number of parallel units; editing and saving again stores the new values,
+    per step *(D7)*;
   - out-of-range frequency or duration, a non-whole duration, and a frequency above 0 on a
     step without a positive LRV are rejected with a message, on the saved configurator, on
     the guest result and on the personal treatment step form;
+  - a number of parallel units of 0, a negative number or a fraction such as 1.5 is rejected
+    with a message on all three forms; 1, 2 and a large value such as 1000 are accepted
+    *(D7)*;
   - a step whose only positive LRV is one maximum (for example protozoa 0–2) accepts a
     frequency above 0; a step with only negative or empty LRVs does not;
   - a guest result with valid failure inputs is accepted;
-  - a personal treatment step saved with failure inputs appears with them in its owner's
-    list; another user's list does not contain it;
-  - an assessment and a personal treatment step created without failure values (as before
-    the migration) come back with frequency 0 and duration 30;
-  - the result of an assessment is identical with and without failure inputs (C1 does not
-    change the calculation).
-- **Prior art.** The form tests in the risk-assessment test module (min ≤ max, negative LRVs
-  allowed) show the validation cases to extend; the calculation regression test shows how
-  fixed results are compared. There are no HTTP-level tests yet; C1 adds the first ones,
-  using Django's test client and a logged-in test user.
+  - a personal treatment step saved with failure inputs appears with all three in its
+    owner's list; another user's list does not contain it *(D7: the third value)*;
+  - an assessment and a personal treatment step created without the number of parallel
+    units (as before its migration) come back with 1 *(D7)*, and without any failure values
+    with frequency 0, duration 30 and 1 unit;
+  - the result and the export package of an assessment are identical with and without
+    failure inputs, including a number of parallel units above 1 (C1 does not change the
+    calculation) *(D7)*.
+- **Prior art.** The C1 HTTP tests in the risk-assessment test package (failure inputs on
+  the configurator, guest result and personal treatment steps, with a logged-in test user
+  and a parser for the configurator form) are extended with the cases above. The form tests
+  in the same package show the minimum ≤ maximum LRV cases; the calculation regression test
+  shows how fixed results are compared.
 - **Manual check on the dev environment.** Copying a personal treatment step's failure
   values into the configurator happens in the browser and is not covered by the HTTP seam.
-  Before C1 is done, a tester on the dev environment creates a personal treatment step with
-  failure inputs, adds it to an assessment, sees the copied values, changes them, saves,
-  reopens, and confirms the personal treatment step itself is unchanged.
+  Before C1 is done again, a tester on the dev environment creates a personal treatment step
+  with all three failure inputs (including a number of parallel units above 1), adds it to
+  an assessment, sees the copied values, changes them, saves, reopens, and confirms the
+  personal treatment step itself is unchanged.
 - The existing test suite passes unchanged.
 
 ## Acceptance criteria
 
 1. Each treatment step in the configurator, for guests and registered users, shows failure
-   frequency and failure duration with their units, starting at 0 and 30.
+   frequency, failure duration and number of parallel units with their labels, starting at
+   0, 30 and 1.
 2. The validation rules above reject invalid values with a message on the configurator,
    the guest result and the personal treatment step form, and accept every valid
-   combination, including the D4 cases.
-3. Failure values survive save, reopen and edit of an assessment, per step.
-4. Personal treatment steps store failure values, the configurator copies them into an
-   added step, and the copy can be changed independently (manual check on the dev
+   combination, including the D4 cases and any whole number of parallel units of 1 or more.
+3. All three failure values survive save, reopen and edit of an assessment, per step.
+4. Personal treatment steps store all three failure values, the configurator copies them
+   into an added step, and the copy can be changed independently (manual check on the dev
    environment).
-5. Assessments and personal treatment steps that existed before C1 read back failure
-   frequency 0 and failure duration 30.
-6. Results and export packages are the same as before C1 for every assessment.
+5. Assessments and personal treatment steps that existed before a failure input read back
+   its default: failure frequency 0, failure duration 30, 1 parallel unit.
+6. Results and export packages are the same as before C1 for every assessment, whatever its
+   failure inputs.
 7. All HTTP-level tests listed above pass, and the existing suite passes unchanged.
 
 Quality goals from `docs/vision.md`, one criterion each:
 
 | Quality goal | Criterion in C1 |
 |---|---|
-| Input validity | Every failure input shows its unit, and a value outside 0–365 days per year or 1–1440 whole minutes, or a frequency above 0 on a step without a positive LRV, is rejected with a message (criteria 1–2). |
-| Reproducibility | Reopening a saved assessment returns exactly the stored failure values, and assessments from before C1 keep their results, since they read back frequency 0 (criteria 3, 5, 6). |
+| Input validity | Every failure input shows its unit or meaning in its label; a value outside 0–365 days per year or 1–1440 whole minutes, a number of parallel units that is not a whole number of 1 or more, or a frequency above 0 on a step without a positive LRV is rejected with a message (criteria 1–2). |
+| Reproducibility | Reopening a saved assessment returns exactly the stored failure values, and assessments from before C1 or before the number of parallel units keep their results, since they read back the defaults (criteria 3, 5, 6). |
 | Export stability | The export package of any assessment is unchanged by C1 (criterion 6); adding failure values to it is C3's job. |
 | Privacy of registered-user data | A personal treatment step and its failure values appear only in its owner's list; a test requests the list as another user and finds nothing of it (criterion 7). |
 
+The number of parallel units has a lower bound but no upper bound (D7), although the Input
+validity goal asks for a plausible range. That is intended: a mistyped large value can only
+raise the failure LRV towards log10 of the number of units, at most to the step's normal
+LRV (ADR-0002), so it cannot produce an implausible result. ADR-0002 is not reopened.
+
 Not relevant to C1: *Scientific correctness* (the calculation is untouched; C2 and C5) and
-*Traceability* (showing failure inputs in the export package and report is C3).
+*Traceability* (showing failure inputs in the export package is C3).
 
 ## Out of Scope
 
 - Any effect of failure inputs on the calculation, the result page or the reference-level
-  exceedance (C2).
-- Failure inputs in the export package and the HTML report (C3).
-- Explanations of failure frequency, failure duration and the two cases beyond field
-  labels and units: FAQ, guided tour, Sphinx documentation (C4).
+  exceedance, including the failure LRV and the daily LRV (C2, ADR-0002).
+- Failure inputs in the export package (C3). The HTML report shows no inputs and does not
+  get failure inputs either (decided 2026-09-25).
+- Explanations beyond field labels and units: what a parallel unit is, that the failure
+  duration affects both cases, that units failing together are entered as 1 unit, and the
+  rest of the FAQ, guided tour and Sphinx documentation (C4).
 - Benchmark scenarios (C5).
-- Failure data for bundled treatment steps.
-- Partial loss of removal (not planned).
+- Failure data for bundled treatment steps, including a number of parallel units.
+- Units of one step that fail together; such a step is entered with 1 unit (D7).
+- A failure frequency per unit; it stays per step (D7).
+- Marking treatment steps as non-technical measures; every step that accepts failure
+  inputs gets the same three fields (D7).
 - Hiding the failure fields in production; D5 keeps C1 out of `main` instead.
 - A browser test setup; the one browser-only behaviour is checked manually.
 - The naming follow-ups in `docs/domain-model-open-questions.md` and the deferred UI
@@ -222,9 +293,12 @@ Not relevant to C1: *Scientific correctness* (the calculation is untouched; C2 a
 
 ## Further Notes
 
-- Until C2 is done, failure inputs have no effect on results. That is acceptable only
-  because of D5: C1 stays out of `main` and production until the release.
-- While exploring: saving a personal treatment step checks the name for uniqueness against
-  the user's personal *exposures*, not their personal treatment steps. That is an existing
-  bug outside this Change; it is noted here so it is not mistaken for C1 behaviour.
+- Until C2 is reworked, the number of parallel units has no effect on results, and C2's
+  current code still uses the rules ADR-0002 replaces. That is acceptable only because of
+  D5: C1–C3 stay out of `main` and production until the release.
+- The default failure duration stays 30 minutes (roadmap, "Rework of C1–C3"). Since
+  ADR-0002 it affects worst-case too; C4 explains this, the configurator label does not.
+- Saving a personal treatment step still checks the name for uniqueness against the user's
+  personal *exposures*, not their personal treatment steps. That is an existing bug outside
+  this Change; it is noted here so it is not mistaken for C1 behaviour.
 - The open roadmap decisions D1–D3 do not affect C1.
diff --git a/docs/specs/c2-failure-calculation.md b/docs/specs/c2-failure-calculation.md
index 093203e..b8f46a8 100644
--- a/docs/specs/c2-failure-calculation.md
+++ b/docs/specs/c2-failure-calculation.md
@@ -1,31 +1,53 @@
 # Spec C2: Failure calculation
 
-Status: draft, 2026-09-24. Change C2 in `docs/failure_roadmap.md` (Large). Spec issue: #___
-Sources: `docs/vision.md` (MVP item 3 and 4), `CONTEXT.md`, ADR-0001, the decisions in
-`docs/QMRA_Failure_Approach.md`, roadmap decisions D4 and D5. Builds on C1
-(`docs/specs/c1-failure-inputs.md`).
+Status: draft, 2026-09-24, revised 2026-10-17 for D6 (one daily LRV rule for both cases)
+and D7 (number of parallel units). Change C2 in `docs/failure_roadmap.md` (Large). Spec
+issue: #___
+Sources: `docs/vision.md` (MVP item 3 and 4), `CONTEXT.md`, ADR-0001, ADR-0002, the
+decisions in `docs/QMRA_Failure_Approach.md`, roadmap decisions D4–D7. Builds on C1
+(`docs/specs/c1-failure-inputs.md`, revised for D7). Worked example:
+`docs/failure-daily-lrv-example.md`.
+
+The first version is built and was tested on the dev environment (tickets 07–09). It drew
+failure days per exposure event, lost a failing step's positive minimum LRVs for the whole
+day in worst-case, and applied the mixed-water assumption with overlap rules in best-case.
+This revision keeps the failure-day draws and replaces the rule for the LRV on a failure
+day: both cases now use the daily LRV of each failing step, and a step with several
+parallel units loses only the share of the failing unit (ADR-0002). Requirements that are
+new or changed in this revision are marked *(D6)* or *(D7)*.
 
 ## Problem Statement
 
-After C1, users can enter a failure frequency and a failure duration for each treatment
-step, but the result ignores them: an assessment with a UV unit failing 10 days per year
-gives the same annual probability of infection as one where it never fails. A utility
-operator therefore still cannot see how failures of their treatment steps affect the
-yearly risk, whether the reference level is still met, or how two failure scenarios
-compare.
+After C1, users enter a failure frequency, a failure duration and a number of parallel
+units for each treatment step. A utility operator wants the result to show how these
+failures affect the yearly risk, whether the reference level is still met, and how two
+failure scenarios compare.
+
+The first version of C2 answers this with two different rules. Worst-case ignores the
+failure duration, so a one-minute and a full-day failure give the same worst-case risk.
+Best-case needs special overlap rules for failures of several steps on one day. Neither
+case knows parallel units, so every failure is counted as a complete loss of the step's
+positive LRVs, although a step often has several units that do not fail at the same time.
+The review on dev in October 2026 found these results implausible (findings F1 and F2 in
+`docs/review-2026-10-dev-scenarios.md`).
 
 ## Solution
 
-The risk calculation takes treatment failures into account as decided in ADR-0001. In the
-Monte Carlo simulation, every simulated exposure event falls on a failure day of each
-treatment step with probability failure frequency / 365. On a failure day:
+The risk calculation takes treatment failures into account as decided in ADR-0001 and
+ADR-0002. In the Monte Carlo simulation, every simulated exposure event falls on a failure
+day of each treatment step with probability failure frequency / 365 (ADR-0001, unchanged).
+On a failure day, best-case and worst-case use the same rule *(D6)*:
 
-- **worst-case** calculates the event with the failing steps' positive LRVs removed for the
-  whole day, whatever the failure duration;
-- **best-case** applies the mixed-water assumption: the consumed water is a mixture of water
-  treated during the failure events and water treated in normal operation, in proportion to
-  the failure durations, with the failure events arranged within the day so that the mixed
-  water has the lowest pathogen concentration.
+- each failing step gets a **daily LRV**: the water consumed that day is a mixture of water
+  treated during the failure event and water treated in normal operation, in proportion to
+  the failure duration (the mixed-water assumption), averaged by concentration;
+- during the failure event the step has its **failure LRV**: with N parallel units, one
+  unit stops and the others keep working, so 1/N of the water is not treated *(D7)*. With
+  one unit the failure LRV is 0;
+- the treatment train's LRV that day is the sum of the failing steps' daily LRVs and the
+  other steps' normal LRVs, so combined failures need no overlap rules *(D6)*;
+- the only difference between the two cases is the LRV each step starts from: its maximum
+  LRV in best-case and its minimum LRV in worst-case.
 
 LRVs of 0 or below are never affected (D4). The result page, the reference-level
 exceedance, the saved results and the result table in the export package all show the
@@ -42,88 +64,108 @@ failure frequency is 0 gives exactly the same results as before C2.
 3. As a utility operator, I want both risk measures (annual probability of infection and
    DALYs per person per year) to include failures, so that I can judge the health burden as
    well as the infection risk.
-4. As a user, I want worst-case to assume that all water consumed on a failure day was
-   treated during the failure, so that worst-case stays the cautious estimate.
-5. As a user, I want best-case to assume mixed water on a failure day, weighted by the
-   failure duration, so that best-case reflects storage that dilutes failure water.
-6. As a user, I want a longer failure duration to raise the best-case risk and leave the
-   worst-case risk unchanged, so that the two cases behave as documented.
-7. As a user, I want a higher failure frequency never to lower the risk, so that the results
-   make sense when I try different values.
-8. As a user, I want worst-case risk never to be below best-case risk, so that the two cases
-   keep their meaning with failures.
-9. As a user, I want the number of failure days to vary between simulated years, so that
-   the risk distribution shows years with more or fewer failures, as real years do.
-10. As a user with an exposure of few events per year, I want a low failure frequency to
+4. As a user, I want best-case and worst-case to use the same failure rule, so that the
+   difference between the two cases comes only from the minimum and maximum LRVs. *(D6)*
+5. As a user, I want the failure duration to count in both cases, so that a one-minute
+   failure and a full-day failure give different results in worst-case too. *(D6)*
+6. As a user, I want a longer failure duration never to lower the risk, in either case, so
+   that the results make sense when I try different values. *(D6)*
+7. As a user, I want a failure lasting the whole day (1,440 minutes) of a step with one
+   unit to remove that step's positive LRVs for the day, so that the extreme case matches
+   the obvious expectation. *(D6)*
+8. As a user, I want a step with several parallel units to lose only the share of the
+   failing unit, so that a failure of one of four filters is not counted as a failure of
+   all four. *(D7)*
+9. As a user, I want the LRV of a step during a failure to follow from the share of
+   untreated water, so that two units keep about 0.3 log and ten units about 1 log during a
+   failure, whatever the step's normal LRV. *(D7)*
+10. As a user, I want more parallel units never to raise the risk, so that describing my
+    plant more precisely never makes it look worse. *(D7)*
+11. As a user, I want a step with one parallel unit to lose all its positive LRVs during the
+    failure, so that the default behaves as before. *(D7)*
+12. As a user, I want a higher failure frequency never to lower the risk, so that the
+    results make sense when I try different values.
+13. As a user, I want worst-case risk never to be below best-case risk, so that the two
+    cases keep their meaning with failures.
+14. As a user, I want the number of failure days to vary between simulated years, so that
+    the risk distribution shows years with more or fewer failures, as real years do.
+15. As a user with an exposure of few events per year, I want a low failure frequency to
     show up as an upper tail of the risk distribution, so that I see the rare bad years.
-11. As a user with several failing steps, I want failures of different steps on the same
+16. As a user with several failing steps, I want failures of different steps on the same
     day to be combined, so that combined failures are not missed.
-12. As a user, I want a combined failure in best-case to assume that failure events do not
-    overlap when they fit into one day, so that best-case stays the favourable assumption.
-13. As a user, I want combined failure events longer than a day in total to overlap only as
-    much as necessary, on the steps whose joint loss matters least, so that best-case stays
-    favourable without a jump at 24 hours.
-14. As a user, I want a failure to remove only the positive LRVs of a step, so that a step
+17. As a user, I want combined failures to be calculated as if each failure event happened
+    at a random time of day, independently of the others, so that the result is neither
+    the most favourable nor the least favourable arrangement. *(D6)*
+18. As a user, I want two steps failing on the same day for a long time each to be
+    calculated without a special rule for durations that add up to more than a day, so
+    that there is no jump in the result at 24 hours. *(D6)*
+19. As a user, I want a failure to remove only the positive LRVs of a step, so that a step
     with regrowth (a negative LRV) in one pathogen group does not improve during a failure.
-15. As a user, I want a pathogen group whose LRV at a step is 0 or empty to be unaffected by
+20. As a user, I want a pathogen group whose LRV at a step is 0 or empty to be unaffected by
     that step's failure, so that failures only matter where the step removes pathogens.
-16. As a user, I want every failure frequency at 0 to give exactly the results I got before,
+21. As a user, I want a step with a minimum LRV of 0 and a positive maximum LRV to affect
+    only best-case when it fails, so that each case loses only what it counted.
+22. As a user, I want every failure frequency at 0 to give exactly the results I got before,
     so that existing assessments and comparisons keep their numbers.
-17. As a registered user, I want saved assessments to store the result including failures,
+23. As a registered user, I want saved assessments to store the result including failures,
     so that the saved-assessments page and the assessment comparison show it.
-18. As a user comparing two saved assessments that differ only in their failure inputs, I
-    want the comparison to show different infection risks, so that I see what the failures
-    cost.
-19. As a registered user, I want the export package's result table to contain the result
+24. As a user comparing two saved assessments that differ only in their failure inputs, for
+    example only in the number of parallel units, I want the comparison to show different
+    infection risks, so that I see what the failures cost.
+25. As a registered user, I want the export package's result table to contain the result
     including failures, so that my report matches the result page.
-20. As a guest, I want the unsaved result to include failures in the same way, so that the
+26. As a guest, I want the unsaved result to include failures in the same way, so that the
     result does not depend on having an account.
-21. As a user, I want the same assessment to give the same result every time it is
+27. As a user, I want the same assessment to give the same result every time it is
     calculated, so that I can reproduce and discuss a result.
-22. As a reviewer, I want the calculation to follow ADR-0001 and the documented decisions,
-    so that the result can be checked against an independent calculation (C5).
-23. As a user, I want the result page to look as before, so that I do not need to learn a
+28. As a reviewer, I want the calculation to follow ADR-0001, ADR-0002 and the worked
+    example, so that the result can be checked against an independent calculation (C5).
+29. As a user, I want the result page to look as before, so that I do not need to learn a
     new layout.
-24. As a user, I want the calculation with failures to finish in about the same time as
+30. As a user, I want the calculation with failures to finish in about the same time as
     before, so that running an assessment stays quick.
-25. As a developer of C5, I want the calculation to be deterministic for a given scenario,
+31. As a developer of C5, I want the calculation to be deterministic for a given scenario,
     so that benchmark comparisons are stable.
-26. As a developer of C4, I want the calculation's rules to be stated in the Spec in plain
+32. As a developer of C4, I want the calculation's rules to be stated in the Spec in plain
     terms, so that the explanations for users can be written from it.
 
 ## Implementation Decisions
 
 - **Only the calculation module changes.** Its public entry point keeps its interface: it
   receives an assessment, its inflow concentrations and its treatment steps, and returns one
-  result per reference pathogen. It now reads each treatment step's failure frequency and
-  failure duration (stored by C1). The result record, the result page, saving and the export
-  are not changed; they show whatever the calculation returns.
-- **What a failure removes (D4).** For each treatment step and pathogen group, worst-case
-  can lose the step's minimum LRV and best-case its maximum LRV, each only if it is above 0.
-  LRVs of 0, below 0 or empty stay in place during a failure.
-- **Failure days per exposure event (ADR-0001).** For every simulated exposure event of every
-  simulated year, and for every treatment step with failure frequency above 0, the step
-  fails that day if a uniform random number is below failure frequency / 365. The same
-  random numbers are used for both cases and all reference pathogens. As a consequence,
-  raising a failure frequency only ever adds failure days, and worst-case and best-case see
-  the same failure days.
-- **Worst-case on a failure day.** The event's LRV is the worst-case LRV of the train minus
-  the removable minimum LRVs of all steps failing that day. The failure duration is not
-  used.
-- **Best-case on a failure day (mixed-water assumption).** The day is split into time
-  segments by which failing steps are down. The event's LRV is −log₁₀ of the time-weighted
-  average of 10^(−LRV of each segment), where a segment's LRV is the best-case LRV of the
-  train minus the removable maximum LRVs of the steps down in it. The failure events of the
-  day are arranged within 1,440 minutes so that this average concentration is lowest. This
-  gives no overlap when the durations fit into one day and otherwise the minimal overlap,
-  placed on the steps whose joint loss matters least (`CONTEXT.md`, *Combined failure*). For
-  a single failing step it equals Eq. 5 of the failure approach. With the few failing steps
-  per day that occur in practice, the arrangement can be found exactly, for example by
-  choosing the time share of each combination of failing steps.
+  result per reference pathogen. It reads each treatment step's failure frequency, failure
+  duration and number of parallel units (stored by C1). The result record, the result page,
+  saving and the export are not changed; they show whatever the calculation returns.
+- **What a failure can affect (D4).** For each treatment step and pathogen group, worst-case
+  starts from the step's minimum LRV and best-case from its maximum LRV. Only an LRV above
+  0 is affected by a failure; LRVs of 0, below 0 or empty stay in place.
+- **Failure days per exposure event (ADR-0001, unchanged).** For every simulated exposure
+  event of every simulated year, and for every treatment step with failure frequency above
+  0, the step fails that day if a uniform random number is below failure frequency / 365.
+  The same random numbers are used for both cases and all reference pathogens. Each step
+  draws from its own stream, keyed by its position in the train, from a fixed seed. As a
+  consequence, raising a failure frequency only ever adds failure days, and worst-case and
+  best-case see the same failure days.
+- **Failure LRV of a step (D7, ADR-0002).** For a positive LRV of a step with N parallel
+  units, the failure LRV is −log₁₀((N − 1)/N · 10^(−LRV) + 1/N): the untreated and the
+  treated water are mixed by concentration. It is 0 for one unit and at most log₁₀ N.
+- **Daily LRV of a failing step (D6, ADR-0002).** With d = failure duration / 1,440, the
+  daily LRV is −log₁₀(d · 10^(−failure LRV) + (1 − d) · 10^(−LRV)), averaged by
+  concentration, never by LRV. LRV is the step's maximum LRV in best-case and its minimum
+  LRV in worst-case.
+- **LRV of an exposure event on a failure day (D6).** The event's LRV is the case's LRV of
+  the train minus, for every step failing that day, the difference between that step's LRV
+  and its daily LRV. The two cases use the same rule. Combined failures need no further
+  rule: summing the steps' daily LRVs equals placing each failure event at a random time of
+  day, independently of the other steps.
+- **Rules that are removed (D6).** The worst-case loss of the failing steps' positive
+  minimum LRVs for the whole day regardless of the duration, the best-case arrangement of
+  combined failures without overlap, the overlap by the minutes beyond a day, and the rule
+  that three or more steps longer than a day in total count like worst-case.
 - **Concentration sampling unchanged.** The sampled inflow concentrations and the choice of
   which sample each simulated event uses stay exactly as today, including the fixed seed.
-  The failure draws come from their own fixed-seed random generator. When all failure
-  frequencies are 0, no failure draws are made and the results are identical to today's.
+  When all failure frequencies are 0, no failure draws are made and the results are
+  identical to today's.
 - **Dose and yearly risk.** Each event's dose follows from its sampled concentration, its
   LRV (normal, or reduced as above) and the volume per event, and the yearly risk combines
   the events of a simulated year as today. The summary statistics and the reference-level
@@ -131,14 +173,18 @@ failure frequency is 0 gives exactly the same results as before C2.
 - **Saved results.** Saving an assessment recalculates and stores its results as today.
   Results stored before C2 stay valid: every assessment in production has failure frequency
   0 at the release, so its stored results equal what C2 calculates.
-- **Speed.** When failures are present, the dose-response is evaluated per simulated event
-  instead of per concentration sample. The work per failure day depends only on which steps
-  fail, so repeated combinations can be reused. The calculation time for a drinking-water
-  scenario (365 events per year) with failures is measured on the dev environment and
-  recorded in the pull request; the vision sets no response-time target yet.
+- **Speed.** The dose-response is evaluated once per distinct event LRV and concentration
+  sample, as in the first version. Each failing step contributes one fixed LRV difference
+  per case and pathogen group, so the number of distinct event LRVs is bounded by the
+  combinations of failing steps. The calculation time for a drinking-water scenario (365
+  events per year) with failures is measured and recorded in the pull request; the first
+  version took 0.13–0.19 s locally against 0.07 s without failures. The vision sets no
+  response-time target yet.
 - **Unchanged warnings.** The warning for a maximum LRV above 6 is not changed.
-- **Delivery.** C2 is built on C1's pull request, stays open and is tested on the dev
-  environment; it is not merged into `main` before the release (D5).
+- **Delivery.** The rework is done in new tickets on the existing C2 pull request (#29),
+  which builds on C1's pull request (roadmap decision "Rework of C1–C3"). Tickets 08 and 09
+  get a note naming the tickets that partly replace them. C2 stays open and is tested on the
+  dev environment again; it is not merged into `main` before the release (D5).
 
 ## Testing Decisions
 
@@ -146,47 +192,70 @@ failure frequency is 0 gives exactly the same results as before C2.
   concentrations, treatment steps with failure inputs, exposure) and checks the returned
   results: mean, median, quartiles, minimum and maximum per reference pathogen, for both
   cases and both risk measures, and the reference-level exceedance. It does not inspect
-  intermediate arrays or random draws.
+  intermediate arrays or random draws. Expected values come from an independent source:
+  the results of a scenario without failures that has the expected constant LRV, the
+  worked example, or the failure LRV table of D7; never from the formula the code uses.
+  The worked example and the D7 table give LRVs rounded to two decimals, so comparisons
+  with them allow for that rounding.
 - **One seam: the calculation's public entry point**, called the way the existing
   calculation tests call it. The result page, saving and export only pass results through,
-  and C1's HTTP tests already show that failure inputs arrive at the calculation. C2 adds no
-  HTTP tests.
+  and C1's HTTP tests show that the three failure inputs arrive at the calculation. C2 adds
+  no HTTP tests.
 - **Behaviour covered at that seam** (internal checks; the independent benchmark is C5):
   - **No failures:** with every failure frequency at 0, all results equal today's exactly,
     including the existing regression test's numbers.
-  - **Always failing, worst-case:** a step with failure frequency 365 gives the same
-    worst-case results as the scenario without that step's positive minimum LRVs.
-  - **Always failing, full day, best-case:** failure frequency 365 and duration 1,440 give
-    the same best-case results as the scenario without that step's positive maximum LRVs.
-  - **Always failing, part of the day, best-case:** failure frequency 365 and duration 60
-    give the same best-case results as the scenario with the train's best-case LRV replaced
-    by the constant mixed LRV from Eq. 5, computed by hand in the test.
-  - **Combined failures:** two steps always failing with 900 + 900 minutes equal the
-    hand-computed constant LRV with 360 minutes of overlap; three steps always failing with
-    durations above a day in total equal the hand-computed lowest-concentration arrangement.
+  - **Always failing, full day, one unit** *(D6)*: a step with failure frequency 365,
+    duration 1,440 and one unit gives the same results in both cases as the scenario
+    without that step's positive LRVs (daily LRV 0).
+  - **Always failing, part of the day** *(D6)*: failure frequency 365 and duration 60 give,
+    in both cases, the same results as a scenario whose train has the hand-computed constant
+    daily LRV; for the worked example's step with LRV 4 next to a step with LRV 3, the train
+    LRV of the day is 4.38.
+  - **Combined failures, worked example** *(D6)*: two steps with LRV 4 and 3, both always
+    failing for 60 minutes with one unit, give the same results as a train with constant
+    LRV 2.75; for 4 h, 12 h and 16 h each, 1.55, 0.60 and 0.35. These values come from
+    `docs/failure-daily-lrv-example.md`.
+  - **Average by concentration** *(D6)*: in the 60-minute combined case the result differs
+    clearly from a train with the plain LRV average of 6.71.
+  - **Parallel units** *(D7)*: a step with LRV 4 always failing for the whole day with 2,
+    4 or 10 units gives the same results as a train in which that step has LRV 0.30, 0.60
+    or 1.00 (the D7 table); with one unit, LRV 0.
   - **Monotonicity:** raising a failure frequency never lowers any mean; raising a failure
-    duration never lowers a best-case mean and leaves worst-case unchanged.
+    duration never lowers any mean, in either case *(D6)*; raising the number of parallel
+    units never raises any mean *(D7)*.
   - **Case order:** worst-case mean ≥ best-case mean for every pathogen and risk measure,
     with and without failures.
   - **D4:** a step with a negative LRV for one pathogen group and a positive LRV for another
     leaves the first group's results unchanged when it fails; a group with LRV 0 is
-    unaffected.
+    unaffected; a step with minimum LRV 0 and a positive maximum LRV changes only
+    best-case when it fails.
   - **Reproducibility:** calculating the same scenario twice gives identical results.
+- **Tests of the first version that change.** The worst-case tests for a full-day loss
+  regardless of the duration, and for the duration not changing worst-case, are replaced
+  by the full-day and monotonicity checks above. The best-case tests for overlap beyond a
+  day, three steps within a day, three steps over a day counting like worst-case and three
+  steps crossing a day are removed with their rules.
 - **Prior art.** The existing calculation tests: a scenario built from bundled data and
-  passed to the calculation, and the regression test comparing fixed numbers.
-- **Manual check on the dev environment.** Enter a scenario with failures in the
-  configurator, run it as a guest and as a registered user, and confirm the result page,
-  the saved-assessments page and the export's result table show the changed results. Record
-  the calculation time.
-- The existing test suite passes unchanged.
+  passed to the calculation, the regression test comparing fixed numbers, and the C2 tests
+  that compare an always-failing scenario with a scenario of constant LRV.
+- **Export.** C1's HTTP test that the export package keeps its files and columns with
+  failures, and the reference export test of C3, keep passing; only result values of
+  assessments with failures change.
+- **Manual check on the dev environment.** Enter the worked example's two steps with
+  failures in the configurator, run it as a guest and as a registered user, change the
+  failure duration and the number of parallel units, and confirm that both cases react and
+  that the result page, the saved-assessments page and the export's result table show the
+  changed results. Record the calculation time.
+- The existing test suite passes, apart from the first-version tests named above.
 
 ## Acceptance criteria
 
-1. The calculation follows the rules above: failure days per exposure event, worst-case
-   full loss, best-case mixed-water assumption with the lowest-concentration arrangement,
-   and only positive LRVs lost.
+1. The calculation follows the rules above: failure days per exposure event, the failure
+   LRV from the number of parallel units, the daily LRV of each failing step in both cases,
+   summed over the train, and only positive LRVs affected.
 2. With every failure frequency at 0, all results equal today's exactly.
-3. All tests listed above pass, and the existing suite passes unchanged.
+3. The results match the worked example and the D7 failure LRV table in the tests listed
+   above, and all other listed tests pass.
 4. The result page, the reference-level exceedance, saved results, the assessment comparison
    and the export's result table show the result including failures, with unchanged
    layout (manual check on the dev environment).
@@ -197,7 +266,7 @@ Quality goals from `docs/vision.md`, one criterion each:
 
 | Quality goal | Criterion in C2 |
 |---|---|
-| Scientific correctness | The internal checks pass, including the closed-form cases (always failing steps compared with hand-computed LRVs) and the frequency-0 regression (criteria 2–3). Agreement with an independent calculation is C5. |
+| Scientific correctness | The internal checks pass, with expected values from the worked example and the D7 table rather than from the code, and the frequency-0 regression holds (criteria 2–3). Agreement with an independent calculation is C5. |
 | Reproducibility | A scenario gives identical results on every calculation because the failure draws use their own fixed seed, and assessments without failures keep their exact results (criteria 2, 5). |
 | Export stability | The export package keeps its files and columns; only the result values of assessments with failures change (criterion 4). |
 
@@ -206,26 +275,32 @@ data* (no change to access).
 
 ## Out of Scope
 
-- Failure inputs, their validation and storage (C1).
-- Failure inputs in the export package and the HTML report (C3).
+- Failure inputs, their validation and storage, including the number of parallel units
+  (C1).
+- Failure inputs in the export package, including a column for the number of parallel
+  units (C3).
 - Explanations for users in the FAQ, guided tour and documentation (C4).
 - Comparison with an independent calculation and the benchmark scenarios (C5); the
   tolerance (D1) is not needed here.
+- A draw per exposure event of whether it falls inside the failure event, instead of the
+  average concentration (ADR-0002, Consequences).
+- Units of one step that fail together, and a failure frequency per unit (D7).
 - Showing normal operation next to the result with failures (decided against).
 - DALYs or inputs in the assessment comparison (later).
-- Partial loss of removal (not planned).
 - Recording the model version and simulation settings with results (reproducible assessment
   snapshots, later).
 - A response-time target (open question in the vision).
 
 ## Further Notes
 
-- The rule for arranging three or more failure events of one day in best-case was decided
-  on 2026-09-24 while writing this Spec and added to `CONTEXT.md` (*Combined failure*) and
-  to decision 6 in `docs/QMRA_Failure_Approach.md`. Overlapping two failure events never
-  lowers the mixed concentration, so the lowest-concentration arrangement always has
-  minimal overlap and agrees with the rule for two steps.
-- No contradiction with ADR-0001 was found. ADR-0001 notes that two exposure events on the
-  same calendar day need not share a failure state; this Spec keeps that.
-- Results with failures will differ from a hand calculation with Eq. 6 of the failure
-  approach, as ADR-0001 explains; they agree on average.
+- No contradiction with an accepted ADR was found. ADR-0002 replaces ADR-0001's rule for the
+  LRV on a failure day; the per-event draw of failure days and the note that two exposure
+  events on the same calendar day need not share a failure state stay.
+- With the default failure duration of 30 minutes, worst-case results with failures are
+  much less conservative than in the first version (ADR-0002, Consequences). This is
+  intended; C4 explains that the duration affects both cases.
+- Results with failures still differ from a hand calculation with Eq. 6 of the failure
+  approach, as ADR-0001 explains, and now also in worst-case, which the source calculates
+  without the duration (ADR-0002).
+- Assessments saved on the dev environment with the first version keep their stored
+  results until they are saved again. Production has no assessments with failures.
diff --git a/docs/tickets/04-c1-failure-inputs-in-configurator.md b/docs/tickets/04-c1-failure-inputs-in-configurator.md
new file mode 100644
index 0000000..eaa2ee0
--- /dev/null
+++ b/docs/tickets/04-c1-failure-inputs-in-configurator.md
@@ -0,0 +1,24 @@
+# 04: Failure inputs on a treatment step in the configurator: enter, check ranges, save, reopen, edit
+
+**What to build:** Every treatment step in the assessment configurator gets two more fields: **failure frequency** (failure days per year) and **failure duration** (minutes). Registered users can save an assessment with these values, and when they reopen or edit it they see the same values again. The values do not change the result yet; the calculation follows in C2.
+
+Tidy-up comes first. The configurator's treatment step form and the personal treatment step form both contain the same minimum ≤ maximum LRV check. It becomes one shared rule that both forms use, and the failure rules are added to it later. This Ticket also adds the first HTTP-level tests. They use Django's test client and a logged-in test user, and they check what a browser or a later request can see.
+
+Delivered on branch `c1-failure-inputs` as part of the single C1 pull request. The pull request stays open until the release (D5).
+
+Source: Spec C1 Failure inputs (`docs/specs/c1-failure-inputs.md`), Change C1 in `docs/failure_roadmap.md`. The Spec issue does not exist yet. GitHub issue #21.
+
+**Blocked by:** None (can start immediately)
+
+**Status:** review
+
+- [x] The minimum ≤ maximum LRV check is defined once and used by both treatment step forms. Nothing changes that a user can notice, and the existing test suite passes unchanged.
+- [x] A schema migration adds failure frequency (a decimal number) and failure duration (a whole number) to the treatment steps of an assessment. Existing rows get failure frequency 0 and failure duration 30.
+- [x] Each treatment step card in the configurator shows both fields below its LRV rows, labelled "Failure frequency (days per year)" and "Failure duration (minutes)". New steps start at 0 and 30, bundled steps included.
+- [x] Failure frequency outside 0–365, and failure duration outside 1–1440 or not a whole number, are rejected with a message on the saved configurator. The duration range is checked even when the frequency is 0.
+- [x] A fractional failure frequency such as 0.5 is accepted.
+- [x] Saving an assessment and reopening it gives back the same failure values for each step. Editing them and saving again stores the new values.
+- [x] Each value stays with its own step when other steps are removed. Two copies of the same bundled step can have different values.
+- [x] An assessment created without failure values, as before the migration, reopens with failure frequency 0 and failure duration 30.
+- [x] An assessment's result and export package are the same with and without failure inputs.
+- [x] All of the above is covered by HTTP-level tests through Django's test client, and the existing test suite passes unchanged.
diff --git a/docs/tickets/05-c1-failure-frequency-needs-positive-lrv-and-guest-messages.md b/docs/tickets/05-c1-failure-frequency-needs-positive-lrv-and-guest-messages.md
new file mode 100644
index 0000000..ddcc45f
--- /dev/null
+++ b/docs/tickets/05-c1-failure-frequency-needs-positive-lrv-and-guest-messages.md
@@ -0,0 +1,20 @@
+# 05: Failure frequency only on steps with a positive LRV (D4), with messages for guests too
+
+**What to build:** A treatment step can only have a failure frequency above 0 if at least one of its LRVs is positive, because a failure removes only positive LRVs (D4). The configurator checks this when the assessment is run or saved, and the error appears on the failure frequency field.
+
+Guests can use the failure fields too, and the same rules apply to them. Today, when a guest runs an assessment with invalid input, the guest result sends back an empty error and nothing appears on the page. With this Ticket, the guest result sends back the error messages and the configurator shows them on the affected treatment step, as it does for registered users. This also makes the existing LRV errors, such as minimum above maximum, visible to guests.
+
+Delivered on branch `c1-failure-inputs` as part of the single C1 pull request.
+
+Source: Spec C1 Failure inputs (`docs/specs/c1-failure-inputs.md`), roadmap decision D4. The Spec issue does not exist yet. GitHub issue #22.
+
+**Blocked by:** 04 (#21)
+
+**Status:** review
+
+- [x] A failure frequency above 0 is rejected, with a message on the failure frequency field, if none of the step's six LRVs (minimum and maximum for bacteria, viruses and protozoa) is above 0. An empty LRV counts as 0.
+- [x] A step whose only positive LRV is one maximum (for example protozoa 0–2) accepts a failure frequency above 0.
+- [x] A step with only negative LRVs (recontamination) or only empty LRVs keeps failure frequency 0. A higher value is rejected.
+- [x] A guest sees the failure fields, can run an assessment with valid failure inputs, and nothing is stored.
+- [x] When a guest's input is invalid, whether a failure input or an LRV, the guest result sends back the error messages and the configurator shows them on the affected step. The rules are the same as for registered users.
+- [x] HTTP-level tests cover the D4 cases on the saved configurator and on the guest result, and cover rejection with a message on the guest result. The existing test suite passes unchanged.
diff --git a/docs/tickets/06-c1-personal-treatment-step-failure-inputs.md b/docs/tickets/06-c1-personal-treatment-step-failure-inputs.md
new file mode 100644
index 0000000..9fdc4d8
--- /dev/null
+++ b/docs/tickets/06-c1-personal-treatment-step-failure-inputs.md
@@ -0,0 +1,24 @@
+# 06: Personal treatment steps store failure inputs and the configurator copies them in
+
+**What to build:** A registered user can store a failure frequency and a failure duration on a personal treatment step, with the same rules as in the configurator. When they add the step to an assessment, its failure values are copied in together with its LRVs. The copy can then be changed in that one assessment without changing the personal treatment step.
+
+Today the personal treatment step form sends back an empty error for invalid input, so the user sees nothing. With this Ticket it shows the messages, the same way it already does for a duplicate name.
+
+Delivered on branch `c1-failure-inputs` and closes the C1 pull request. The pull request is tested on the dev environment and not merged before the release (D5).
+
+Source: Spec C1 Failure inputs (`docs/specs/c1-failure-inputs.md`). The Spec issue does not exist yet. GitHub issue #23.
+
+**Blocked by:** 04 (#21), 05 (#22)
+
+**Status:** review
+
+- [x] A schema migration adds failure frequency and failure duration to personal treatment steps. Existing personal treatment steps get failure frequency 0 and failure duration 30.
+- [x] The personal treatment step form shows both fields with their units and applies the same shared rule as the configurator: the ranges, whole minutes, D4 and minimum ≤ maximum LRV. Invalid input is rejected and the message is shown in the form.
+- [x] A personal treatment step saved with failure inputs appears with them in its owner's list of personal treatment steps. Another user's list does not contain it.
+- [x] Adding a personal treatment step to an assessment copies its failure frequency and failure duration into the new step. Bundled steps still start at 0 and 30.
+- [x] Changing the copied values in an assessment and saving leaves the personal treatment step unchanged.
+- [x] HTTP-level tests cover the form rules, old personal treatment steps reading back 0 and 30, and owner-only visibility. The existing test suite passes unchanged.
+- [x] Manual check on the dev environment, announced to the team first:
+  - Create a personal treatment step with failure inputs and add it to an assessment.
+  - See the copied values, change them, save and reopen.
+  - Confirm that the personal treatment step itself is unchanged.
diff --git a/docs/tickets/07-c2-calculation-per-exposure-event.md b/docs/tickets/07-c2-calculation-per-exposure-event.md
new file mode 100644
index 0000000..52c966f
--- /dev/null
+++ b/docs/tickets/07-c2-calculation-per-exposure-event.md
@@ -0,0 +1,18 @@
+# 07: Tidy-up: the calculation works per exposure event, with results unchanged
+
+**What to build:** Tidy-up before failures enter the calculation. No result changes.
+
+The Monte Carlo simulation is reorganised to work per simulated exposure event. Each event picks its concentration sample by position instead of by value, which uses exactly the same random numbers as today, and each event gets its own LRV. For now every event still gets the same LRV. Best-case and worst-case use the same building blocks, and the summary statistics (mean, minimum, quartiles, median, maximum) and the reference-level exceedance are computed in one place for both cases and both risk measures. The calculation's public entry point keeps its interface.
+
+Delivered on branch `c2-failure-calculation`, based on `c1-failure-inputs`, as part of the single C2 pull request. The pull request stays open until the release (D5).
+
+Source: Spec C2 Failure calculation (`docs/specs/c2-failure-calculation.md`), Change C2 in `docs/failure_roadmap.md`. The Spec issue does not exist yet. GitHub issue #24.
+
+**Blocked by:** None (can start immediately)
+
+**Status:** review (built in pull request #29; CI green on `a8a1972`; the pull request stays open until the release, D5)
+
+- [x] Every simulated exposure event has its own concentration sample, picked by position, and its own LRV. The random numbers are the same as today's.
+- [x] Best-case and worst-case share the same calculation steps. Summary statistics and the reference-level exceedance are computed in one place.
+- [x] The existing regression test passes with exactly the same numbers, and the existing test suite passes unchanged.
+- [x] A new test at the calculation's public entry point shows that calculating the same scenario twice gives identical results.
diff --git a/docs/tickets/08-c2-failure-days-and-worst-case.md b/docs/tickets/08-c2-failure-days-and-worst-case.md
new file mode 100644
index 0000000..1ed87e5
--- /dev/null
+++ b/docs/tickets/08-c2-failure-days-and-worst-case.md
@@ -0,0 +1,23 @@
+# 08: Failure days drawn per exposure event; worst-case loses the positive LRVs of failing steps
+
+**What to build:** The worst-case result includes treatment failures. For every simulated exposure event, and for every treatment step with a failure frequency above 0, the step fails that day with probability failure frequency / 365 (ADR-0001). On a failure day, worst-case calculates the event with the positive minimum LRVs of every failing step removed, whatever the failure duration. LRVs of 0, below 0 or empty stay in place (D4).
+
+The failure draws come from their own fixed-seed random generator and are shared by both cases and all reference pathogens. Raising a failure frequency therefore only adds failure days. If every failure frequency is 0, no failure draws are made and the results are exactly today's. Best-case does not change in this Ticket; the mixed-water assumption follows in the next one.
+
+The result page, the reference-level exceedance, saved results and the export's result table show whatever the calculation returns. Their layout does not change.
+
+Source: Spec C2 Failure calculation (`docs/specs/c2-failure-calculation.md`), ADR-0001, roadmap decision D4. The Spec issue does not exist yet. GitHub issue #25.
+
+**Blocked by:** 07 (#24), 04 (#21, C1 stored failure inputs)
+
+**Status:** review (built in pull request #29; CI green on `a8a1972`; the pull request stays open until the release, D5)
+
+**Partly replaced (2026-10-17):** The worst-case loss for the whole day regardless of the failure duration is replaced by the daily LRV of Ticket 16 (D6, ADR-0002); the failure-day draws stay.
+
+- [x] With every failure frequency at 0, all results equal today's exactly, including the existing regression test's numbers.
+- [x] A step with failure frequency 365 gives the same worst-case results as the same scenario without that step's positive minimum LRVs.
+- [x] Raising a failure frequency never lowers any mean. Changing a failure duration leaves worst-case unchanged.
+- [x] Worst-case mean ≥ best-case mean for every reference pathogen and risk measure, with and without failures.
+- [x] D4: a failing step with a negative LRV in one pathogen group and a positive LRV in another leaves the first group's results unchanged. A group with LRV 0 is unaffected.
+- [x] Calculating the same scenario with failures twice gives identical results.
+- [x] All tests go through the calculation's public entry point and check only the returned results. The existing test suite passes unchanged.
diff --git a/docs/tickets/09-c2-best-case-mixed-water.md b/docs/tickets/09-c2-best-case-mixed-water.md
new file mode 100644
index 0000000..bf42edf
--- /dev/null
+++ b/docs/tickets/09-c2-best-case-mixed-water.md
@@ -0,0 +1,42 @@
+# 09: Best-case applies the mixed-water assumption, including combined failures
+
+**What to build:** The best-case result includes treatment failures under the mixed-water assumption. On a failure day, the consumed water is a mixture of water treated during the failure events and water treated in normal operation, in proportion to the failure durations. The event's LRV is −log₁₀ of the time-weighted average of 10^(−LRV) over the segments of the day, where a segment's LRV is the best-case LRV of the train minus the positive maximum LRVs of the steps down in that segment.
+
+Combined failures of one day:
+- if their durations fit into one day, they do not overlap;
+- two failure events longer than a day in total overlap only by the minutes beyond the day;
+- three or more failure events longer than a day in total count like worst-case: all these steps are down for the whole day (changed on 2026-09-25 from the lowest-concentration arrangement, which needed a numerical solver for a rare exception). Only steps that lose LRV for the pathogen group count.
+
+For a single failing step, the result equals Eq. 5 of the failure approach. Work per failure day is reused for repeated combinations of failing steps.
+
+This Ticket closes C2: it includes the manual check on the dev environment and the time measurement.
+
+Source: Spec C2 Failure calculation (`docs/specs/c2-failure-calculation.md`), ADR-0001, `CONTEXT.md` (*Mixed-water assumption*, *Combined failure*), decision 6 in `docs/QMRA_Failure_Approach.md`. The Spec issue does not exist yet. GitHub issue #26.
+
+**Blocked by:** 08 (#25)
+
+**Status:** review (built in pull request #29; CI green on `a8a1972`; the pull request stays open until the release, D5)
+
+**Partly replaced (2026-10-17):** The overlap rules for combined failures are replaced by the daily LRV of Ticket 16 (D6, ADR-0002), and the failure LRV of Ticket 17 replaces the full loss of a failing step (D7).
+
+- [x] A step with failure frequency 365 and failure duration 1,440 gives the same best-case results as the same scenario without that step's positive maximum LRVs.
+- [x] A step with failure frequency 365 and failure duration 60 gives the same best-case results as the scenario with the train's best-case LRV replaced by the Eq. 5 mixed LRV, computed by hand in the test.
+- [x] Two steps always failing with 900 + 900 minutes equal the hand-computed result with 360 minutes of overlap.
+- [x] Three steps always failing within a day in total equal the hand-computed result without overlap.
+- [x] Three steps always failing with more than a day in total equal the scenario without their positive maximum LRVs.
+- [x] A failing step without removal for one pathogen group does not count for that group.
+- [x] Raising a failure duration never lowers a best-case mean, and raising a failure frequency never lowers any mean.
+- [x] Worst-case mean ≥ best-case mean for every reference pathogen and risk measure, with failures.
+- [x] With every failure frequency at 0, all results equal today's exactly. The same scenario gives identical results every time. The existing test suite passes unchanged.
+- [x] Manual check on the dev environment, announced to the team first:
+  - Enter a scenario with failures and run it as a guest and as a registered user.
+  - Confirm that the result page, the saved-assessments page, the assessment comparison and the export's result table show the changed results, with unchanged layout.
+- [ ] The calculation time for a drinking-water scenario (365 events per year) with failures is measured on the dev environment and recorded in the pull request.
+
+Review on 2026-09-28 (against the Spec, ADR-0001 and the code of the three C2 commits):
+
+- [x] The calculation matches the Spec: failure days per exposure event from a fixed-seed generator shared by both cases and all pathogens; worst-case loses only positive minimum LRVs; best-case follows the mixed-water rules including the three-or-more exception; LRVs of 0 or below are untouched. The hand-computed examples of decision 6 (mixed LRV about 6.9 and about 2.6) agree with the code's formula.
+- [x] The concentration samples are picked by position with the same generator calls as before, so results without failures stay bit-identical. The PR records a 28-scenario check of this.
+- [x] Wording left over from before D4 (fixed 2026-09-28): `CONTEXT.md` (*Combined failure*: "loses all their LRVs"), `docs/vision.md` MVP item 3 and the C2 scope in `docs/failure_roadmap.md` still say worst-case loses the *full* LRV of a failing step. It should say every *positive* LRV.
+- [ ] Decide whether it is acceptable that the failure draws of a step depend on its position in the train. Two scenarios that differ only by an extra non-failing step placed *before* a failing one give slightly different results, because the later step's random stream changes. The difference is sampling noise, but it can surprise a user comparing two saved assessments, and C5's independent script must use the same keying to match.
+- [ ] The Spec still says "Status: draft" and "Spec issue: #___". Set it to implemented and create the Spec issue, or record that C2 has none.
diff --git a/docs/tickets/14-c1-parallel-units-in-configurator.md b/docs/tickets/14-c1-parallel-units-in-configurator.md
new file mode 100644
index 0000000..340f459
--- /dev/null
+++ b/docs/tickets/14-c1-parallel-units-in-configurator.md
@@ -0,0 +1,24 @@
+# 14: Number of parallel units on a treatment step in the configurator: enter, check, save, reopen, edit
+
+**What to build:** Every treatment step in the assessment configurator gets a third failure input next to failure frequency and failure duration: the **number of parallel units**, starting at 1. Guests and registered users see and use it. Registered users can save an assessment with it, and when they reopen or edit the assessment they see the same value again, for each step. The value does not change the result yet; the failure LRV follows in C2 (ADR-0002).
+
+The shared validation rule that both treatment step forms use is extended with the new input, not duplicated. A number of parallel units is a whole number of 1 or more, with no upper limit (D7).
+
+Delivered on branch `c1-failure-inputs` as part of the C1 pull request (#28). The pull request is tested on the dev environment again and not merged before the release (D5).
+
+Source: Spec C1 Failure inputs, revision for D7 (`docs/specs/c1-failure-inputs.md`), Change C1 in `docs/failure_roadmap.md`, roadmap decision D7, ADR-0002. The Spec issue does not exist yet. GitHub issue #36.
+
+**Blocked by:** None (can start immediately)
+
+**Status:** ready-for-agent
+
+- [x] A schema migration adds the number of parallel units to the treatment steps of assessments. Existing treatment steps get 1.
+- [x] Each treatment step card in the configurator shows the field "Number of parallel units" below the LRV rows, next to failure frequency and failure duration, starting at 1. It is always shown, also when the failure frequency is 0. Guests see the same field.
+- [x] A bundled treatment step added to an assessment starts at 1 parallel unit.
+- [x] The shared rule rejects a number of parallel units of 0, a negative number or a fraction such as 1.5 with a message that names the field and its range, on the saved configurator and on the guest result. 1, 2 and a large value such as 1000 are accepted.
+- [x] Saving an assessment and reopening it returns the same number of parallel units per step. Editing and saving again stores the new value, and values stay with their step when other steps are reordered or removed.
+- [x] An assessment saved before this Ticket reopens with 1 parallel unit, failure frequency 0 and failure duration 30, and its result is unchanged.
+- [x] The result and the export package of an assessment are identical with and without failure inputs, including a number of parallel units above 1.
+- [x] HTTP-level tests through Django's test client cover the cases above, extending the existing C1 failure input tests. The existing test suite passes unchanged.
+
+Quality goals (`docs/vision.md`): Input validity (label and checked range), Reproducibility (saved values and old assessments read back unchanged), Export stability (export package unchanged by C1).
diff --git a/docs/tickets/15-c1-personal-treatment-step-parallel-units.md b/docs/tickets/15-c1-personal-treatment-step-parallel-units.md
new file mode 100644
index 0000000..879848e
--- /dev/null
+++ b/docs/tickets/15-c1-personal-treatment-step-parallel-units.md
@@ -0,0 +1,24 @@
+# 15: Personal treatment steps store the number of parallel units and the configurator copies it in
+
+**What to build:** A registered user can store a number of parallel units on a personal treatment step, next to its failure frequency and failure duration, with the same rule as in the configurator. When they add the step to an assessment, its number of parallel units is copied in together with its other failure inputs and its LRVs. The copy can then be changed in that one assessment without changing the personal treatment step.
+
+Delivered on branch `c1-failure-inputs` and completes the D7 rework of the C1 pull request (#28). The pull request is tested on the dev environment again and not merged before the release (D5).
+
+Source: Spec C1 Failure inputs, revision for D7 (`docs/specs/c1-failure-inputs.md`), roadmap decision D7, ADR-0002. The Spec issue does not exist yet. GitHub issue #37.
+
+**Blocked by:** 14 (#36)
+
+**Status:** ready-for-agent
+
+- [x] A schema migration adds the number of parallel units to personal treatment steps. Existing personal treatment steps get 1.
+- [x] The personal treatment step form shows "Number of parallel units", starting at 1, next to the two other failure fields, and applies the same shared rule as the configurator. Invalid input is rejected and the message is shown in the form.
+- [x] A personal treatment step saved with a number of parallel units appears with it in its owner's list of personal treatment steps. Another user's list does not contain it.
+- [x] Adding a personal treatment step to an assessment copies its number of parallel units into the new step, together with its failure frequency, failure duration and LRVs. Bundled steps still start at 1.
+- [x] Changing the copied value in an assessment and saving leaves the personal treatment step unchanged.
+- [x] HTTP-level tests cover the form rule, personal treatment steps from before this Ticket reading back 1, and owner-only visibility. The existing test suite passes unchanged.
+- [x] Manual check on the dev environment, announced to the team first (2026-10-17, passed):
+  - Create a personal treatment step with all three failure inputs, including a number of parallel units above 1, and add it to an assessment.
+  - See the copied values, change them, save and reopen.
+  - Confirm that the personal treatment step itself is unchanged.
+
+Quality goals (`docs/vision.md`): Input validity (the same rule as the configurator), Privacy of registered-user data (the step and its failure inputs appear only in its owner's list).
diff --git a/docs/tickets/16-c2-daily-lrv-in-both-cases.md b/docs/tickets/16-c2-daily-lrv-in-both-cases.md
new file mode 100644
index 0000000..7e6deca
--- /dev/null
+++ b/docs/tickets/16-c2-daily-lrv-in-both-cases.md
@@ -0,0 +1,30 @@
+# 16: Both cases use the daily LRV of each failing step
+
+**What to build:** On a failure day, best-case and worst-case use the same rule (D6, ADR-0002). Each failing treatment step gets a **daily LRV** under the mixed-water assumption: the water consumed that day is a mixture of water treated during the failure event and water treated in normal operation, in proportion to the failure duration, averaged by concentration and never by LRV. The step starts from its maximum LRV in best-case and from its minimum LRV in worst-case. The LRV of an exposure event on a failure day is the case's LRV of the train minus, for every step failing that day, the difference between its LRV and its daily LRV. Combined failures need no further rule.
+
+In this Ticket a failing step has LRV 0 during the failure event, which is the failure LRV of one parallel unit. The number of parallel units follows in Ticket 17.
+
+The rules of the first version are removed: the worst-case loss of the failing steps' positive minimum LRVs for the whole day regardless of the failure duration, the best-case arrangement of combined failures without overlap, the overlap by the minutes beyond a day, and the rule that three or more steps longer than a day in total count like worst-case. The failure-day draws per exposure event (ADR-0001), the concentration sampling and the fixed seeds stay as they are. LRVs of 0, below 0 or empty are not affected by a failure (D4).
+
+The result page, the reference-level exceedance, saved results and the export's result table show whatever the calculation returns. Their layout does not change.
+
+Delivered on branch `c2-failure-calculation` as part of the C2 pull request (#29). The pull request is not merged before the release (D5).
+
+Source: Spec C2 Failure calculation, revision for D6 and D7 (`docs/specs/c2-failure-calculation.md`), roadmap decision D6, ADR-0002, worked example `docs/failure-daily-lrv-example.md`. The Spec issue does not exist yet. GitHub issue #38.
+
+**Blocked by:** None (can start immediately)
+
+**Status:** ready-for-agent
+
+- [x] Both cases calculate a failing step's daily LRV from its failure duration, starting from the step's maximum LRV in best-case and its minimum LRV in worst-case, and sum the daily LRVs of all steps failing that day over the train.
+- [x] The worst-case full-day loss and the best-case overlap rules are removed from the calculation.
+- [x] With every failure frequency at 0, all results equal today's exactly, including the existing regression test's numbers.
+- [x] A step always failing for 1,440 minutes gives the same results in both cases as the scenario without that step's positive LRVs.
+- [x] The results match the worked example (`docs/failure-daily-lrv-example.md`), allowing for its two-decimal rounding: one step with LRV 4 failing 60 minutes next to a step with LRV 3 gives the results of a train with constant LRV 4.38; both steps failing 60 minutes, 4 h, 12 h and 16 h each give those of 2.75, 1.55, 0.60 and 0.35.
+- [x] In the 60-minute combined case, the result differs clearly from a train with the plain LRV average of 6.71.
+- [x] Raising a failure duration never lowers any mean, in either case; raising a failure frequency never lowers any mean; worst-case mean is never below best-case mean.
+- [x] D4: a negative LRV of one pathogen group stays unchanged when the step fails, a group with LRV 0 is unaffected, and a step with minimum LRV 0 and a positive maximum LRV changes only best-case when it fails.
+- [x] The same scenario gives identical results on every calculation.
+- [x] The first-version tests for the worst-case full-day loss, the duration not changing worst-case, and the best-case overlap rules are replaced or removed as the Spec names them. All other tests pass.
+
+Quality goals (`docs/vision.md`): Scientific correctness (expected values from the worked example, not from the code), Reproducibility (fixed seeds, frequency 0 unchanged).
diff --git a/docs/tickets/17-c2-failure-lrv-from-parallel-units.md b/docs/tickets/17-c2-failure-lrv-from-parallel-units.md
new file mode 100644
index 0000000..89535ca
--- /dev/null
+++ b/docs/tickets/17-c2-failure-lrv-from-parallel-units.md
@@ -0,0 +1,26 @@
+# 17: The failure LRV follows from the number of parallel units, and C2 is checked on dev
+
+**What to build:** A failing treatment step with N parallel units keeps the share of water treated by the other units during the failure event (D7, ADR-0002). For each positive LRV, its failure LRV is the LRV of the mixture of untreated water (1/N) and water treated with the step's LRV ((N − 1)/N), mixed by concentration. It is 0 for one unit, as in Ticket 16, and at most log₁₀ N. The daily LRV of Ticket 16 uses this failure LRV in both cases. Failure frequency stays per step, and LRVs of 0 or below are not affected (D4).
+
+This Ticket closes the D6/D7 rework of C2: it includes the manual check on the dev environment and the time measurement.
+
+Delivered on branch `c2-failure-calculation` as part of the C2 pull request (#29). The pull request is tested on the dev environment again and not merged before the release (D5).
+
+Source: Spec C2 Failure calculation, revision for D6 and D7 (`docs/specs/c2-failure-calculation.md`), roadmap decision D7, ADR-0002. The Spec issue does not exist yet. GitHub issue #39.
+
+**Blocked by:** 16 (#38)
+
+**Status:** ready-for-agent
+
+- [x] The calculation reads each treatment step's number of parallel units and uses the failure LRV in the daily LRV of both cases.
+- [x] A step with one parallel unit gives the same results as in Ticket 16.
+- [x] A step with LRV 4 always failing for the whole day with 2, 4 or 10 parallel units gives the same results as a train in which that step has LRV 0.30, 0.60 or 1.00 (the D7 table, allowing for its two-decimal rounding).
+- [x] Raising the number of parallel units never raises any mean.
+- [x] All tests pass, and the export package keeps its files and columns with failures.
+- [ ] The calculation time of a drinking-water scenario (365 events per year) with failures is measured and recorded in the C2 pull request.
+- [x] Manual check on the dev environment, announced to the team first (2026-10-17, passed):
+  - Enter the worked example's two steps with failures and run them as a guest and as a registered user.
+  - Change the failure duration and the number of parallel units, and see both cases react.
+  - Confirm that the result page, the saved-assessments page and the export's result table show the changed results.
+
+Quality goals (`docs/vision.md`): Scientific correctness (expected values from the D7 table, not from the code), Export stability (files and columns unchanged).
diff --git a/docs/vision.md b/docs/vision.md
index 84a6b3c..f3f3d5f 100644
--- a/docs/vision.md
+++ b/docs/vision.md
@@ -77,7 +77,7 @@ Functionalities, each one Change:
 
 1. **Failure inputs per treatment step.** In the assessment configurator, each treatment step with at least one positive LRV gets a failure frequency (failure days per year, 0–365, default 0) and a failure duration (minutes, 1–1440, default 30). The inputs belong to the scenario.
 2. **Failure inputs on personal treatment steps.** A personal treatment step can store its failure frequency and failure duration for reuse.
-3. **Calculation with failure days.** Inside the Monte Carlo simulation, each exposure event falls on a failure day of each step with probability failure frequency / 365. Worst-case loses the full LRV of every failing step; best-case applies the mixed-water assumption, with combined failures overlapping as little as possible.
+3. **Calculation with failure days.** Inside the Monte Carlo simulation, each exposure event falls on a failure day of each step with probability failure frequency / 365. Worst-case loses every positive LRV of every failing step; best-case applies the mixed-water assumption: combined failures that fit into a day do not overlap, two steps longer than a day overlap only by the extra minutes, and three or more steps longer than a day in total count like worst-case.
 4. **Results and export including failures.** The result page, the reference-level exceedance and the export package show the result including failures, and the export records the failure inputs of each step.
 
 Waits until later:
diff --git a/qmra/risk_assessment/forms.py b/qmra/risk_assessment/forms.py
index 57b1bc7..a648fc7 100644
--- a/qmra/risk_assessment/forms.py
+++ b/qmra/risk_assessment/forms.py
@@ -14,6 +14,42 @@
 def _zero_if_none(x): return x if x is not None else 0
 
 
+LRV_FIELDS = [
+    ("bacteria_min", "bacteria_max"),
+    ("viruses_min", "viruses_max"),
+    ("protozoa_min", "protozoa_max"),
+]
+FAILURE_INPUT_RANGES = {
+    "failure_frequency": (0, 365, "days per year"),
+    "failure_duration": (1, 1440, "minutes"),
+}
+PARALLEL_UNITS_MESSAGE = "number of parallel units must be a whole number of 1 or more"
+
+
+def check_treatment_step(form, cleaned_data):
+    """Minimum LRV at most maximum LRV per pathogen group, failure inputs within their ranges,
+    at least one parallel unit, and a failure frequency above 0 only for a step with a positive LRV.
+
+    Shared by the configurator and the personal treatment step form. Whole minutes are enforced
+    by the failure duration's field type; failure inputs a form does not have are skipped.
+    """
+    for min_field, max_field in LRV_FIELDS:
+        if _zero_if_none(cleaned_data.get(min_field, 0)) > _zero_if_none(cleaned_data.get(max_field, 0)):
+            form.add_error(min_field, "min. must be less than max")
+    for field, (low, high, unit) in FAILURE_INPUT_RANGES.items():
+        value = cleaned_data.get(field)
+        if value is not None and not low <= value <= high:
+            form.add_error(field, f"{field.replace('_', ' ')} must be between {low} and {high} {unit}")
+    # no upper limit: more units only raise the LRV during a failure (D7)
+    parallel_units = cleaned_data.get("parallel_units")
+    if parallel_units is not None and parallel_units < 1:
+        form.add_error("parallel_units", PARALLEL_UNITS_MESSAGE)
+    # a failure removes only positive LRVs, so a step without one cannot fail (D4)
+    has_positive_lrv = any(_zero_if_none(cleaned_data.get(field)) > 0 for pair in LRV_FIELDS for field in pair)
+    if _zero_if_none(cleaned_data.get("failure_frequency")) > 0 and not has_positive_lrv:
+        form.add_error("failure_frequency", "failure frequency must be 0 for a treatment step without a positive LRV")
+
+
 class RiskAssessmentForm(forms.ModelForm):
     source_name = forms.ChoiceField()
     exposure_name = forms.ChoiceField()
@@ -150,7 +186,10 @@ class Meta:
             'viruses_min',
             'viruses_max',
             "protozoa_min",
-            "protozoa_max"
+            "protozoa_max",
+            "failure_frequency",
+            "failure_duration",
+            "parallel_units",
         ]
 
     def __init__(self, *args, **kwargs):
@@ -167,6 +206,13 @@ def __init__(self, *args, **kwargs):
         self.fields['viruses_max'].label = ""
         self.fields['protozoa_min'].label = ""
         self.fields['protozoa_max'].label = ""
+        self.fields['failure_frequency'].label = "Failure frequency (days per year)"
+        self.fields['failure_duration'].label = "Failure duration (minutes)"
+        self.fields['parallel_units'].label = "Number of parallel units"
+        # leave whole numbers to the server check: the browser blocks hidden step cards without a message
+        self.fields['failure_duration'].widget.attrs['step'] = "any"
+        self.fields['parallel_units'].widget.attrs['step'] = "any"
+        self.fields['parallel_units'].error_messages['invalid'] = PARALLEL_UNITS_MESSAGE
         label_style = "class='text-muted text-center w-100' style='margin-top: .4em;'"
         self.helper.layout = Layout(
             Field("name", css_class="disabled-input d-none"),
@@ -179,24 +225,13 @@ def __init__(self, *args, **kwargs):
                 Column("viruses_min"), Column("viruses_max")),
             Row(Column(HTML(f"<label {label_style}>Protozoa LRV:</label>")),
                 Column("protozoa_min"), Column("protozoa_max")),
+            Row(Column("failure_frequency"), Column("failure_duration"), Column("parallel_units")),
             # Row(Column("DELETE"))
         )
 
     def clean(self):
         cleaned_data = super().clean()
-        b_min = _zero_if_none(cleaned_data.get("bacteria_min", 0))
-        b_max = _zero_if_none(cleaned_data.get("bacteria_max", 0))
-        v_min = _zero_if_none(cleaned_data.get("viruses_min", 0))
-        v_max = _zero_if_none(cleaned_data.get("viruses_max", 0))
-        p_min = _zero_if_none(cleaned_data.get("protozoa_min", 0))
-        p_max = _zero_if_none(cleaned_data.get("protozoa_max", 0))
-        msg = "min. must be less than max"
-        if b_min > b_max:
-            self.add_error("bacteria_min", msg)
-        if v_min > v_max:
-            self.add_error("viruses_min", msg)
-        if p_min > p_max:
-            self.add_error("protozoa_min", msg)
+        check_treatment_step(self, cleaned_data)
         return cleaned_data
 
 
diff --git a/qmra/risk_assessment/migrations/0011_treatment_failure_inputs.py b/qmra/risk_assessment/migrations/0011_treatment_failure_inputs.py
new file mode 100644
index 0000000..b05f235
--- /dev/null
+++ b/qmra/risk_assessment/migrations/0011_treatment_failure_inputs.py
@@ -0,0 +1,23 @@
+# Generated by Django 5.0.14 on 2026-09-25 10:10
+
+from django.db import migrations, models
+
+
+class Migration(migrations.Migration):
+
+    dependencies = [
+        ('risk_assessment', '0010_remove_qmratreatment_bacteria_reference_and_more'),
+    ]
+
+    operations = [
+        migrations.AddField(
+            model_name='treatment',
+            name='failure_duration',
+            field=models.IntegerField(default=30),
+        ),
+        migrations.AddField(
+            model_name='treatment',
+            name='failure_frequency',
+            field=models.FloatField(default=0),
+        ),
+    ]
diff --git a/qmra/risk_assessment/migrations/0012_usertreatment_failure_inputs.py b/qmra/risk_assessment/migrations/0012_usertreatment_failure_inputs.py
new file mode 100644
index 0000000..56c0ebd
--- /dev/null
+++ b/qmra/risk_assessment/migrations/0012_usertreatment_failure_inputs.py
@@ -0,0 +1,23 @@
+# Generated by Django 5.0.14 on 2026-09-25 10:34
+
+from django.db import migrations, models
+
+
+class Migration(migrations.Migration):
+
+    dependencies = [
+        ('risk_assessment', '0011_treatment_failure_inputs'),
+    ]
+
+    operations = [
+        migrations.AddField(
+            model_name='usertreatment',
+            name='failure_duration',
+            field=models.IntegerField(default=30),
+        ),
+        migrations.AddField(
+            model_name='usertreatment',
+            name='failure_frequency',
+            field=models.FloatField(default=0),
+        ),
+    ]
diff --git a/qmra/risk_assessment/migrations/0013_treatment_parallel_units.py b/qmra/risk_assessment/migrations/0013_treatment_parallel_units.py
new file mode 100644
index 0000000..92657c9
--- /dev/null
+++ b/qmra/risk_assessment/migrations/0013_treatment_parallel_units.py
@@ -0,0 +1,18 @@
+# Generated by Django 5.0.14 on 2026-10-16 16:11
+
+from django.db import migrations, models
+
+
+class Migration(migrations.Migration):
+
+    dependencies = [
+        ('risk_assessment', '0012_usertreatment_failure_inputs'),
+    ]
+
+    operations = [
+        migrations.AddField(
+            model_name='treatment',
+            name='parallel_units',
+            field=models.IntegerField(default=1),
+        ),
+    ]
diff --git a/qmra/risk_assessment/migrations/0014_usertreatment_parallel_units.py b/qmra/risk_assessment/migrations/0014_usertreatment_parallel_units.py
new file mode 100644
index 0000000..7b23805
--- /dev/null
+++ b/qmra/risk_assessment/migrations/0014_usertreatment_parallel_units.py
@@ -0,0 +1,18 @@
+# Generated by Django 5.0.14 on 2026-10-16 16:43
+
+from django.db import migrations, models
+
+
+class Migration(migrations.Migration):
+
+    dependencies = [
+        ('risk_assessment', '0013_treatment_parallel_units'),
+    ]
+
+    operations = [
+        migrations.AddField(
+            model_name='usertreatment',
+            name='parallel_units',
+            field=models.IntegerField(default=1),
+        ),
+    ]
diff --git a/qmra/risk_assessment/models.py b/qmra/risk_assessment/models.py
index 030def7..70a6918 100644
--- a/qmra/risk_assessment/models.py
+++ b/qmra/risk_assessment/models.py
@@ -35,6 +35,9 @@ class Treatment(models.Model):
     viruses_max = models.FloatField(blank=True, null=True)
     protozoa_min = models.FloatField(blank=True, null=True)
     protozoa_max = models.FloatField(blank=True, null=True)
+    failure_frequency = models.FloatField(default=0)  # failure days per year
+    failure_duration = models.IntegerField(default=30)  # minutes
+    parallel_units = models.IntegerField(default=1)  # a failure event stops one of them (D7)
 
     @classmethod
     def from_default(cls, default: QMRATreatment, risk_assessment):
diff --git a/qmra/risk_assessment/risk.py b/qmra/risk_assessment/risk.py
index eaf888b..2b5a258 100644
--- a/qmra/risk_assessment/risk.py
+++ b/qmra/risk_assessment/risk.py
@@ -6,51 +6,139 @@
 from qmra.risk_assessment.qmra_models import PathogenGroup, QMRAPathogens
 
 
-def get_annual_risk(
-        inflow_min: float, inflow_max: float,
-        log_removal: float,
-        volume_per_event: float,
-        events_per_year: int,
-        distribution,
-        n_events: int = 10_000,
-        n_years: int = 1000,
-):
+N_SAMPLES = 10_000  # inflow concentration samples per reference pathogen
+N_YEARS = 1000  # simulated years
+BEST_CASE = "maximum_lrv"  # result fields of best-case, which uses every step's maximum LRV
+WORST_CASE = "minimum_lrv"  # result fields of worst-case, which uses every step's minimum LRV
+MINUTES_PER_DAY = 1440  # failure durations are given in minutes within one day
+FAILURE_SEED = 2019  # failure days have their own generator, independent of the concentration samples
+INFECTION_REFERENCE_LEVEL = 10 ** -4  # annual probability of infection
+DALYS_REFERENCE_LEVEL = 10 ** -6  # DALYs per person per year
+
+
+def sample_exposure_events(inflow_min: float, inflow_max: float, events_per_year: int,
+                           n_samples: int = N_SAMPLES, n_years: int = N_YEARS):
+    """Log10 inflow concentration samples, and for each simulated exposure event the position of the sample it uses.
+
+    Both cases of a scenario use the same samples and events, so they differ only by their LRVs.
+    """
     generator = np.random.default_rng(seed=42)
-    inflow = generator.normal(
+    log_concentrations = generator.normal(
         loc=(np.log10(inflow_min + 10 ** (-8)) + np.log10(inflow_max)) / 2,
         scale=(np.log10(inflow_max) - np.log10(inflow_min + 10 ** (-8))) / 4,
-        size=n_events
+        size=n_samples
     )
-    lrv = np.ones((n_events,)) * log_removal
-    outflow = inflow - lrv
-    dose = (10 ** outflow) * volume_per_event
-    event_probs = distribution.pdf(dose)
-    event_samples = generator.choice(event_probs, size=(n_years, events_per_year), replace=True)
-    return 1 - np.prod(1 - event_samples, axis=1)
+    sample_positions = generator.choice(n_samples, size=(n_years, events_per_year), replace=True)
+    return log_concentrations, sample_positions
 
 
-def lrv_by_pathogen_group(treatments: Iterable[Treatment]) -> dict:
-    lrvs = {
-        PathogenGroup.Bacteria: dict(min=0, max=0),
-        PathogenGroup.Viruses: dict(min=0, max=0),
-        PathogenGroup.Protozoa: dict(min=0, max=0)
-    }
+def draw_failing_events(treatments: list[Treatment], events_per_year: int,
+                        n_years: int = N_YEARS) -> list[np.ndarray | None]:
+    """For each treatment step, a mask of the simulated exposure events that fall on one of its failure days.
+
+    An event falls on a failure day with probability failure frequency / 365, independently per step (ADR-0001).
+    A step without failures gets None and no draws. Each step draws from its own stream, keyed by its position in
+    the train, so raising one step's failure frequency only adds failure days and leaves the other steps' as they are.
+    """
+    failing_events = []
+    for position, t in enumerate(treatments):
+        if t.failure_frequency > 0:
+            draws = np.random.default_rng([FAILURE_SEED, position]).random((n_years, events_per_year))
+            failing_events.append(draws < t.failure_frequency / 365)
+        else:
+            failing_events.append(None)
+    return failing_events
+
+
+def failing_steps(treatments: list[Treatment], failing_events: list[np.ndarray | None], group: PathogenGroup,
+                  bound: str) -> list[tuple[np.ndarray, float, int, int]]:
+    """The steps that fail on some days and then lose LRV for this pathogen group, as (their failing events, their
+    minimum or maximum LRV, failure duration, number of parallel units). A step whose LRV is 0 or below loses nothing
+    when it fails (D4)."""
+    steps = []
+    for t, failing in zip(treatments, failing_events):
+        lrv = step_lrv(t, group, bound)
+        if failing is not None and lrv > 0:
+            steps.append((failing, lrv, t.failure_duration, t.parallel_units))
+    return steps
+
+
+def failure_lrv(lrv: float, parallel_units: int) -> float:
+    """LRV of a step while one of its parallel units is down (D7, ADR-0002): that unit's share of the water is not
+    treated, the others' is treated with the step's LRV, mixed by concentration. 0 for one unit, at most log10 of the
+    number of units."""
+    return -np.log10((parallel_units - 1) / parallel_units * 10 ** -lrv + 1 / parallel_units)
+
+
+def daily_lrv_loss(lrv: float, failure_duration: int, parallel_units: int) -> float:
+    """How much LRV a failing step loses on a failure day under the mixed-water assumption (ADR-0002).
+
+    The consumed water mixes water treated during the failure event, with the failure LRV, and water treated in
+    normal operation, in proportion to the failure duration. The mixture is averaged by concentration, never by LRV.
+    """
+    failing_share = failure_duration / MINUTES_PER_DAY
+    daily_lrv = -np.log10(failing_share * 10 ** -failure_lrv(lrv, parallel_units)
+                          + (1 - failing_share) * 10 ** -lrv)
+    return lrv - daily_lrv
+
 
-    def zero_if_none(x): return x if x is not None else 0
+def event_lrvs_of_case(train_lrv: float, treatments: list[Treatment], failing_events: list[np.ndarray | None],
+                       group: PathogenGroup, bound: str, shape: tuple) -> np.ndarray:
+    """LRV of each exposure event in one case: best-case starts from every step's maximum LRV, worst-case from its
+    minimum LRV. On a failure day each failing step loses what its daily LRV lacks, so combined failures add up
+    without further rules (D6)."""
+    event_lrvs = np.full(shape, train_lrv, dtype=float)
+    for failing, lrv, failure_duration, parallel_units in failing_steps(treatments, failing_events, group, bound):
+        event_lrvs[failing] -= daily_lrv_loss(lrv, failure_duration, parallel_units)
+    return event_lrvs
 
+
+def get_annual_risk(log_concentrations: np.ndarray, sample_positions: np.ndarray, event_lrvs: np.ndarray,
+                    volume_per_event: float, distribution) -> np.ndarray:
+    """Annual probability of infection of each simulated year; event_lrvs holds the LRV of each exposure event."""
+    # the dose-response is evaluated once per distinct LRV and concentration sample, then looked up per event
+    lrvs, lrv_positions = np.unique(event_lrvs, return_inverse=True)
+    dose = (10 ** (log_concentrations[np.newaxis, :] - lrvs[:, np.newaxis])) * volume_per_event
+    event_probs = distribution.pdf(dose)[lrv_positions.reshape(sample_positions.shape), sample_positions]
+    return 1 - np.prod(1 - event_probs, axis=1)
+
+
+def summarize(annual_risks: np.ndarray) -> dict:
+    return dict(
+        min=annual_risks.min(),
+        max=annual_risks.max(),
+        q1=np.percentile(annual_risks, 25),
+        q3=np.percentile(annual_risks, 75),
+        median=np.median(annual_risks),
+    )
+
+
+def reference_level_exceedance(best_case_mean: float, worst_case_mean: float, reference_level: float) -> str:
+    """'max' if even best-case exceeds the health-based reference level, 'min' if only worst-case does."""
+    return "max" if best_case_mean > reference_level else ("min" if worst_case_mean > reference_level else "none")
+
+
+def step_lrv(treatment: Treatment, group: PathogenGroup, bound: str) -> float:
+    """A step's minimum or maximum LRV for a pathogen group; an empty LRV counts as 0."""
+    lrv = getattr(treatment, f"{group.lower()}_{bound}")
+    return lrv if lrv is not None else 0
+
+
+def lrv_by_pathogen_group(treatments: Iterable[Treatment]) -> dict:
+    lrvs = {group: dict(min=0, max=0) for group in PathogenGroup}
     for t in treatments:
-        lrvs[PathogenGroup.Bacteria]["min"] += zero_if_none(t.bacteria_min)
-        lrvs[PathogenGroup.Bacteria]["max"] += zero_if_none(t.bacteria_max)
-        lrvs[PathogenGroup.Viruses]["min"] += zero_if_none(t.viruses_min)
-        lrvs[PathogenGroup.Viruses]["max"] += zero_if_none(t.viruses_max)
-        lrvs[PathogenGroup.Protozoa]["min"] += zero_if_none(t.protozoa_min)
-        lrvs[PathogenGroup.Protozoa]["max"] += zero_if_none(t.protozoa_max)
+        for group in PathogenGroup:
+            for bound in ["min", "max"]:
+                lrvs[group][bound] += step_lrv(t, group, bound)
     return lrvs
 
 
 def assess_risk(risk_assessment: RiskAssessment, inflows, treatments, save=True) -> dict[str, RiskAssessmentResult]:
     # assuming the model has been already validated
+    treatments = list(treatments)
     lrvs = lrv_by_pathogen_group(treatments)
+    # the same failure days for both cases and all reference pathogens
+    failing_events = draw_failing_events(treatments, risk_assessment.events_per_year)
     results = {}
 
     for inflow in inflows:
@@ -62,59 +150,31 @@ def assess_risk(risk_assessment: RiskAssessment, inflows, treatments, save=True)
         def to_dalys(pr, pat=pathogen):
             return pr * pat.infection_to_illness * pat.dalys_per_case
 
-        # min / max probs
-        min_prob = get_annual_risk(
-            inflow.min, inflow.max,
-            lrvs[group]["max"],
-            risk_assessment.volume_per_event, risk_assessment.events_per_year,
-            dist
-        )
-        max_prob = get_annual_risk(
-            inflow.min, inflow.max,
-            lrvs[group]["min"],
-            risk_assessment.volume_per_event, risk_assessment.events_per_year,
-            dist
-        )
-        # get the stats
-        min_prob_mean = min_prob.mean()
-        max_prob_mean = max_prob.mean()
-        maximum_lrv_min = min_prob.min()
-        maximum_lrv_max = min_prob.max()
-        maximum_lrv_q1 = np.percentile(min_prob, 25)
-        maximum_lrv_q3 = np.percentile(min_prob, 75)
-        maximum_lrv_median = np.median(min_prob)
-        minimum_lrv_min = max_prob.min()
-        minimum_lrv_max = max_prob.max()
-        minimum_lrv_q1 = np.percentile(max_prob, 25)
-        minimum_lrv_q3 = np.percentile(max_prob, 75)
-        minimum_lrv_median = np.median(max_prob)
-        # make result
+        log_concentrations, sample_positions = sample_exposure_events(
+            inflow.min, inflow.max, risk_assessment.events_per_year)
+        event_lrvs = {
+            BEST_CASE: event_lrvs_of_case(lrvs[group]["max"], treatments, failing_events, group, "max",
+                                          sample_positions.shape),
+            WORST_CASE: event_lrvs_of_case(lrvs[group]["min"], treatments, failing_events, group, "min",
+                                           sample_positions.shape),
+        }
+        cases = {case: get_annual_risk(log_concentrations, sample_positions, lrvs_of_case,
+                                       risk_assessment.volume_per_event, dist)
+                 for case, lrvs_of_case in event_lrvs.items()}
+        stats = {}
+        for case, annual_risks in cases.items():
+            for stat, value in summarize(annual_risks).items():
+                stats[f"infection_{case}_{stat}"] = value
+                stats[f"dalys_{case}_{stat}"] = to_dalys(value)
+        best_case_mean = cases[BEST_CASE].mean()
+        worst_case_mean = cases[WORST_CASE].mean()
         results[inflow.pathogen] = RiskAssessmentResult(
             risk_assessment=risk_assessment,
-            infection_risk="max" if min_prob_mean > (10 ** -4) else ("min" if max_prob_mean > (10 ** -4) else "none"),
-            dalys_risk="max" if to_dalys(min_prob_mean) > (10 ** -6) else (
-                "min" if to_dalys(max_prob_mean) > (10 ** -6) else "none"),
+            infection_risk=reference_level_exceedance(best_case_mean, worst_case_mean, INFECTION_REFERENCE_LEVEL),
+            dalys_risk=reference_level_exceedance(to_dalys(best_case_mean), to_dalys(worst_case_mean),
+                                                  DALYS_REFERENCE_LEVEL),
             pathogen=inflow.pathogen,
-            infection_maximum_lrv_min=maximum_lrv_min,
-            infection_maximum_lrv_max=maximum_lrv_max,
-            infection_maximum_lrv_q1=maximum_lrv_q1,
-            infection_maximum_lrv_q3=maximum_lrv_q3,
-            infection_maximum_lrv_median=maximum_lrv_median,
-            infection_minimum_lrv_min=minimum_lrv_min,
-            infection_minimum_lrv_max=minimum_lrv_max,
-            infection_minimum_lrv_q1=minimum_lrv_q1,
-            infection_minimum_lrv_q3=minimum_lrv_q3,
-            infection_minimum_lrv_median=minimum_lrv_median,
-            dalys_maximum_lrv_min=to_dalys(maximum_lrv_min),
-            dalys_maximum_lrv_max=to_dalys(maximum_lrv_max),
-            dalys_maximum_lrv_q1=to_dalys(maximum_lrv_q1),
-            dalys_maximum_lrv_q3=to_dalys(maximum_lrv_q3),
-            dalys_maximum_lrv_median=to_dalys(maximum_lrv_median),
-            dalys_minimum_lrv_min=to_dalys(minimum_lrv_min),
-            dalys_minimum_lrv_max=to_dalys(minimum_lrv_max),
-            dalys_minimum_lrv_q1=to_dalys(minimum_lrv_q1),
-            dalys_minimum_lrv_q3=to_dalys(minimum_lrv_q3),
-            dalys_minimum_lrv_median=to_dalys(minimum_lrv_median),
+            **stats,
         )
         if save:
             results[inflow.pathogen].save()
diff --git a/qmra/risk_assessment/templates/risk-assessment-form-js.html b/qmra/risk_assessment/templates/risk-assessment-form-js.html
index c414676..403bc5f 100644
--- a/qmra/risk_assessment/templates/risk-assessment-form-js.html
+++ b/qmra/risk_assessment/templates/risk-assessment-form-js.html
@@ -1,6 +1,57 @@
 {% load static %}
 <script type="text/javascript">
+    // guests have no save button to re-render the configurator with errors, so their messages are placed here
+    function clearFormErrors() {
+        const formElement = document.querySelector("form[id=configurator]");
+        document.querySelectorAll(".guest-error").forEach(e => e.remove());
+        formElement.querySelectorAll("[aria-invalid][data-guest-error]").forEach(input => {
+            input.classList.remove("is-invalid");
+            input.removeAttribute("aria-invalid");
+            input.removeAttribute("data-guest-error");
+        });
+        document.querySelectorAll("[data-guest-error-step]").forEach(summary => {
+            summary.style.border = "";
+            summary.removeAttribute("data-guest-error-step");
+        });
+    }
+    function errorElement(tag, className, text) {
+        const elem = document.createElement(tag);
+        elem.className = `${className} guest-error`;
+        elem.textContent = text;
+        return elem;
+    }
+    function showFormErrors(errors) {
+        const formElement = document.querySelector("form[id=configurator]");
+        const unplaced = [];
+        let firstStepButton = null;
+        for (const [name, messages] of Object.entries(errors)) {
+            const input = formElement.querySelector(`[name="${name}"]`);
+            if (input === null) {
+                unplaced.push(...messages);
+                continue;
+            }
+            input.classList.add("is-invalid");
+            input.setAttribute("aria-invalid", "true");
+            input.setAttribute("data-guest-error", "");
+            input.after(errorElement("span", "invalid-feedback d-block", messages.join(" ")));
+            const step = input.closest("div[id^='treatments-n-']");
+            const summary = step && document.querySelector(`#summary-${step.id}`);
+            if (summary && !summary.hasAttribute("data-guest-error-step")) {
+                summary.style.border = "solid 2px var(--danger)";
+                summary.setAttribute("data-guest-error-step", "");
+                summary.after(errorElement("span", "invalid-feedback d-block", "contains errors"));
+                firstStepButton = firstStepButton || summary.querySelector("button[id^=focus-]");
+            }
+        }
+        if (firstStepButton) firstStepButton.click();
+        const result = document.querySelector("#assessment-result");
+        result.innerHTML = "";
+        result.append(errorElement("div", "alert alert-danger m-3", "The assessment could not be run. Please correct the marked inputs."));
+        unplaced.forEach(message => result.append(errorElement("div", "alert alert-danger mx-3", message)));
+    }
     function getResultsNoSave() {
+            clearFormErrors();
+            const saveButton = document.querySelector("#save-risk-assessment-btn");  // only registered users have it
             const showResult = document.querySelector("#show-result");
             showResult.setAttribute("hidden", "");
             document.querySelector("main").appendChild(showResult);
@@ -14,14 +65,18 @@
                 body: frm
                 }).then(r => {
                     if (r.ok) return r.text();
+                    if (r.status === 422 && saveButton === null) {
+                        return r.json().then(body => { showFormErrors(body.errors); return null; });
+                    }
                     throw new Error("422");
                 }).then(html => {
+                    if (html === null) return false;  // no result: the guest's errors are shown instead
                     document.querySelector("#assessment-result").innerHTML = html;
                     document.querySelector("#assessment-result").querySelectorAll("script").forEach(s => eval(s.innerHTML));
                     document.querySelector("#assessment-result").classList.add("up-to-date");
                     return true;
                 }).catch(err => {
-                    document.querySelector("#save-risk-assessment-btn").click();
+                    saveButton.click();
                     return false;
                 });
         }
diff --git a/qmra/risk_assessment/templates/treatments-form-fieldset.html b/qmra/risk_assessment/templates/treatments-form-fieldset.html
index 4262736..1acd6de 100644
--- a/qmra/risk_assessment/templates/treatments-form-fieldset.html
+++ b/qmra/risk_assessment/templates/treatments-form-fieldset.html
@@ -16,7 +16,7 @@
 
     <fieldset id="treatments-formset-fieldset" class="col-8 mb-4"
               role="tabpanel"
-              style="height: 360px;"
+              style="min-height: 360px;"
               aria-labelledby="nav-treatments-params-tab">
 
         <div id="treatments-management">
diff --git a/qmra/risk_assessment/templates/treatments-form-js.html b/qmra/risk_assessment/templates/treatments-form-js.html
index 2f0902b..cd26e91 100644
--- a/qmra/risk_assessment/templates/treatments-form-js.html
+++ b/qmra/risk_assessment/templates/treatments-form-js.html
@@ -19,6 +19,9 @@
             viruses_max: { selector: "input[id*='viruses_max']", getter: (elem) => elem.value, setter: (elem, x) => { elem.value = x } },
             protozoa_min: { selector: "input[id*='protozoa_min']", getter: (elem) => elem.value, setter: (elem, x) => { elem.value = x } },
             protozoa_max: { selector: "input[id*='protozoa_max']", getter: (elem) => elem.value, setter: (elem, x) => { elem.value = x } },
+            failure_frequency: { selector: "input[id*='failure_frequency']", getter: (elem) => elem.value, setter: (elem, x) => { elem.value = x } },
+            failure_duration: { selector: "input[id*='failure_duration']", getter: (elem) => elem.value, setter: (elem, x) => { elem.value = x } },
+            parallel_units: { selector: "input[id*='parallel_units']", getter: (elem) => elem.value, setter: (elem, x) => { elem.value = x } },
         }
         constructor(div) {
             this.$form = div
@@ -31,6 +34,8 @@
         setValues(values) {
             for (let k of Object.keys(this.fields)) {
                 const v = values[k];
+                // bundled steps carry no failure inputs, so their new card keeps the form's defaults
+                if (v === undefined) continue;
                 this.fields[k].setter(this.$inputs[k], v);
                 this.$inputs[k].dispatchEvent(new Event("change"));
             }
@@ -374,7 +379,7 @@
             )
             this.plot.traces[formValues.id] = trace;
             this.plot.data.push(...Object.values(this.plot.traces[formValues.id].data))
-            for (let field of Object.keys(form.fields)) {
+            for (let field of Object.keys(form.fields).filter(name => name in trace.updates)) {
                 form.bindCallback(field, newValue => {
                     this.plot.traces[formValues.id].updates[field](newValue);
                     this.plot.update()
diff --git a/qmra/risk_assessment/tests/test_assess_risk.py b/qmra/risk_assessment/tests/test_assess_risk.py
index 7ea5848..8cd800a 100644
--- a/qmra/risk_assessment/tests/test_assess_risk.py
+++ b/qmra/risk_assessment/tests/test_assess_risk.py
@@ -1,6 +1,8 @@
 """test computation of risk assessment"""
 import warnings
 
+import numpy as np
+
 from django.core.management import call_command
 from django.test import TestCase
 from assertpy import assert_that
@@ -238,4 +240,245 @@ def test_regression_test(self):
                         .is_close_to(getattr(expected_parvum, attr), tolerance=accepted_tolerance)
                 except AssertionError as e:
                     failed += str(e) + "\n"
-        warnings.warn(failed)
\ No newline at end of file
+        warnings.warn(failed)
+
+    def test_same_scenario_gives_identical_results(self):
+        given_ra = RiskAssessment(events_per_year=365, volume_per_event=1)
+        given_inflows = [
+            Inflow(risk_assessment=given_ra, pathogen=inflow.pathogen.name, min=inflow.min, max=inflow.max)
+            for inflow in QMRAInflows.get("groundwater")
+        ]
+        given_treatments = [
+            Treatment(risk_assessment=given_ra, name="Primary treatment",
+                      bacteria_min=0, bacteria_max=0.5, viruses_min=0, viruses_max=0.1, protozoa_min=0, protozoa_max=1)
+        ]
+
+        def calculate():
+            results = assess_risk(given_ra, given_inflows, given_treatments, save=False)
+            return {pathogen: r.as_dict() for pathogen, r in results.items()}
+
+        assert_that(calculate()).is_equal_to(calculate())
+
+
+STATISTICS = ["min", "q1", "median", "q3", "max"]
+EXCEEDANCE_ORDER = ["none", "min", "max"]
+PATHOGENS = ["Rotavirus", "Campylobacter jejuni", "Cryptosporidium parvum"]
+
+
+def calculate(steps: list[dict], events_per_year=365) -> dict[str, dict]:
+    """The results of a scenario with these treatment steps, as returned by the calculation."""
+    given_ra = RiskAssessment(events_per_year=events_per_year, volume_per_event=1)
+    given_inflows = [Inflow(risk_assessment=given_ra, pathogen=p, min=0.1, max=10) for p in PATHOGENS]
+    given_treatments = [Treatment(risk_assessment=given_ra, name=f"step {i}", **step) for i, step in enumerate(steps)]
+    results = assess_risk(given_ra, given_inflows, given_treatments, save=False)
+    return {pathogen: r.as_dict() for pathogen, r in results.items()}
+
+
+def case_statistics(result: dict, case: str) -> list[float]:
+    """Both risk measures of one case: 'minimum_lrv' is worst-case, 'maximum_lrv' is best-case."""
+    return [result[f"{measure}_{case}_{stat}"] for measure in ["infection", "dalys"] for stat in STATISTICS]
+
+
+# made-up steps whose LRVs keep the risk well below 1, so failures change the results visibly
+STRONG_STEP = dict(bacteria_min=3, bacteria_max=4, viruses_min=3, viruses_max=4, protozoa_min=3, protozoa_max=4)
+WEAK_STEP = dict(bacteria_min=2, bacteria_max=3, viruses_min=2, viruses_max=3, protozoa_min=2, protozoa_max=3)
+
+
+class TestFailureDays(TestCase):
+
+    def test_failure_frequency_0_gives_the_results_without_failure_inputs(self):
+        without = calculate([STRONG_STEP, WEAK_STEP])
+        with_zero = calculate([dict(STRONG_STEP, failure_frequency=0, failure_duration=600),
+                               dict(WEAK_STEP, failure_frequency=0, failure_duration=1)])
+
+        assert_that(with_zero).is_equal_to(without)
+
+    def test_higher_failure_frequency_never_lowers_the_risk(self):
+        results = [calculate([dict(STRONG_STEP, failure_frequency=f), WEAK_STEP]) for f in [0, 1, 10, 100, 365]]
+
+        for pathogen in PATHOGENS:
+            for step, (lower, higher) in enumerate(zip(results, results[1:])):
+                with self.subTest(pathogen=pathogen, step=step):
+                    for case in ["minimum_lrv", "maximum_lrv"]:
+                        for low, high in zip(case_statistics(lower[pathogen], case),
+                                             case_statistics(higher[pathogen], case)):
+                            assert_that(high).is_greater_than_or_equal_to(low)
+                    for exceedance in ["infection_risk", "dalys_risk"]:
+                        assert_that(EXCEEDANCE_ORDER.index(higher[pathogen][exceedance])).is_greater_than_or_equal_to(
+                            EXCEEDANCE_ORDER.index(lower[pathogen][exceedance]))
+        worst_median = [r["Rotavirus"]["infection_minimum_lrv_median"] for r in results]
+        assert_that(worst_median[-1]).is_greater_than(worst_median[0])
+
+    def test_worst_case_is_never_below_best_case(self):
+        for frequencies in [(0, 0), (0, 5), (20, 5), (365, 5)]:
+            results = calculate([dict(STRONG_STEP, failure_frequency=frequencies[0]),
+                                 dict(WEAK_STEP, failure_frequency=frequencies[1])])
+            for pathogen in PATHOGENS:
+                with self.subTest(frequencies=frequencies, pathogen=pathogen):
+                    for worst, best in zip(case_statistics(results[pathogen], "minimum_lrv"),
+                                           case_statistics(results[pathogen], "maximum_lrv")):
+                        assert_that(worst).is_greater_than_or_equal_to(best)
+
+    def test_failure_removes_only_positive_lrvs(self):
+        # bacteria regrow at this step, viruses are removed, protozoa pass unchanged
+        step = dict(bacteria_min=-1, bacteria_max=-0.5, viruses_min=3, viruses_max=4, protozoa_min=0, protozoa_max=0)
+        normal = calculate([step, WEAK_STEP])
+        failing = calculate([dict(step, failure_frequency=365), WEAK_STEP])
+
+        assert_that(failing["Campylobacter jejuni"]).is_equal_to(normal["Campylobacter jejuni"])
+        assert_that(failing["Cryptosporidium parvum"]).is_equal_to(normal["Cryptosporidium parvum"])
+        assert_that(failing["Rotavirus"]["infection_minimum_lrv_median"]).is_greater_than(
+            normal["Rotavirus"]["infection_minimum_lrv_median"])
+
+    def test_same_scenario_with_failures_gives_identical_results(self):
+        steps = [dict(STRONG_STEP, failure_frequency=12.5), dict(WEAK_STEP, failure_frequency=40)]
+
+        assert_that(calculate(steps, events_per_year=20)).is_equal_to(calculate(steps, events_per_year=20))
+
+
+def all_groups(lrv_min: float, lrv_max: float) -> dict:
+    return dict(bacteria_min=lrv_min, bacteria_max=lrv_max, viruses_min=lrv_min, viruses_max=lrv_max,
+                protozoa_min=lrv_min, protozoa_max=lrv_max)
+
+
+def mixed_lrv(best_case_lrv: float, segments: list[tuple[float, float]]) -> float:
+    """By hand: -log10 of the time-weighted mixed concentration, from (minutes, LRV lost) segments of one day."""
+    idle = 1440 - sum(minutes for minutes, _ in segments)
+    concentration = idle * 10 ** -best_case_lrv + sum(minutes * 10 ** -(best_case_lrv - lost)
+                                                      for minutes, lost in segments)
+    return -np.log10(concentration / 1440)
+
+
+def assert_best_case_close(results: dict, reference: dict, pathogens: list[str]):
+    for pathogen in pathogens:
+        for value, expected in zip(case_statistics(results[pathogen], "maximum_lrv"),
+                                   case_statistics(reference[pathogen], "maximum_lrv")):
+            assert_that(value).described_as(pathogen).is_close_to(expected, abs(expected) * 1e-9)
+
+
+# a step that never fails, so that the train keeps some removal on every failure day
+BASE_STEP = all_groups(3, 4)
+
+
+class TestMixedWaterEq5(TestCase):
+
+    def test_always_failing_part_of_the_day_gives_the_mixed_lrv_of_eq_5(self):
+        failing = calculate([dict(all_groups(0, 4), failure_frequency=365, failure_duration=60), BASE_STEP])
+        eq_5 = mixed_lrv(8, [(60, 4)])
+        reference = calculate([all_groups(0, eq_5)])
+
+        assert_best_case_close(failing, reference, PATHOGENS)
+
+
+# the two steps of docs/failure-daily-lrv-example.md, with the same LRV in both cases
+EXAMPLE_STEP_A = all_groups(4, 4)
+EXAMPLE_STEP_B = all_groups(3, 3)
+# never fails and keeps the risk below saturation, where a wrong train LRV would hardly change the results
+NEVER_FAILING_LRV = 5
+# the worked example gives LRVs to two decimals: at most 0.005 log, a factor of 10 ** 0.005 on the concentration
+ROUNDING = 10 ** 0.005 - 1
+
+
+def assert_both_cases_close(results: dict, reference: dict, relative: float):
+    for pathogen in PATHOGENS:
+        for case in ["minimum_lrv", "maximum_lrv"]:
+            for value, expected in zip(case_statistics(results[pathogen], case),
+                                       case_statistics(reference[pathogen], case)):
+                assert_that(value).described_as(f"{pathogen}, {case}").is_close_to(expected, abs(expected) * relative)
+
+
+class TestDailyLrv(TestCase):
+
+    def test_combined_failures_match_the_worked_example_in_both_cases(self):
+        for minutes, train_lrv_of_the_day in [(60, 2.75), (240, 1.55), (720, 0.60), (960, 0.35)]:
+            with self.subTest(minutes=minutes):
+                failing = calculate([dict(EXAMPLE_STEP_A, failure_frequency=365, failure_duration=minutes),
+                                     dict(EXAMPLE_STEP_B, failure_frequency=365, failure_duration=minutes),
+                                     all_groups(NEVER_FAILING_LRV, NEVER_FAILING_LRV)])
+                train_lrv = NEVER_FAILING_LRV + train_lrv_of_the_day
+                reference = calculate([all_groups(train_lrv, train_lrv)])
+
+                assert_both_cases_close(failing, reference, ROUNDING)
+
+    def test_one_failing_step_matches_the_worked_example_in_both_cases(self):
+        failing = calculate([dict(EXAMPLE_STEP_A, failure_frequency=365, failure_duration=60), EXAMPLE_STEP_B])
+        reference = calculate([all_groups(4.38, 4.38)])
+
+        assert_both_cases_close(failing, reference, ROUNDING)
+
+    def test_always_failing_full_day_loses_the_positive_lrvs_in_both_cases(self):
+        failing = calculate([dict(STRONG_STEP, failure_frequency=365, failure_duration=1440), WEAK_STEP])
+        without_the_step = calculate([WEAK_STEP])
+
+        assert_both_cases_close(failing, without_the_step, 1e-9)
+
+    def test_longer_failure_duration_never_lowers_either_case(self):
+        results = [calculate([dict(STRONG_STEP, failure_frequency=100, failure_duration=duration),
+                              dict(WEAK_STEP, failure_frequency=100, failure_duration=duration)])
+                   for duration in [1, 60, 600, 1000, 1440]]
+
+        for pathogen in PATHOGENS:
+            for case in ["minimum_lrv", "maximum_lrv"]:
+                for pair, (shorter, longer) in enumerate(zip(results, results[1:])):
+                    with self.subTest(pathogen=pathogen, case=case, pair=pair):
+                        for short, long in zip(case_statistics(shorter[pathogen], case),
+                                               case_statistics(longer[pathogen], case)):
+                            assert_that(long).is_greater_than_or_equal_to(short)
+        for case in ["minimum_lrv", "maximum_lrv"]:
+            median = [r["Rotavirus"][f"infection_{case}_median"] for r in results]
+            assert_that(median[-1]).described_as(case).is_greater_than(median[0])
+
+    def test_the_daily_lrv_is_averaged_by_concentration_not_by_lrv(self):
+        failing = calculate([dict(EXAMPLE_STEP_A, failure_frequency=365, failure_duration=60),
+                             dict(EXAMPLE_STEP_B, failure_frequency=365, failure_duration=60)])
+        # the plain average of the LRVs over the day, which the worked example rejects
+        lrv_average = calculate([all_groups(6.71, 6.71)])
+
+        for pathogen in PATHOGENS:
+            for case in ["minimum_lrv", "maximum_lrv"]:
+                assert_that(failing[pathogen][f"infection_{case}_median"]).described_as(
+                    f"{pathogen}, {case}").is_greater_than(100 * lrv_average[pathogen][f"infection_{case}_median"])
+
+    def test_step_with_minimum_lrv_0_changes_only_best_case_when_it_fails(self):
+        step = all_groups(0, 4)
+        normal = calculate([step, WEAK_STEP])
+        failing = calculate([dict(step, failure_frequency=365, failure_duration=600), WEAK_STEP])
+
+        for pathogen in PATHOGENS:
+            with self.subTest(pathogen):
+                assert_that(case_statistics(failing[pathogen], "minimum_lrv")).is_equal_to(
+                    case_statistics(normal[pathogen], "minimum_lrv"))
+                assert_that(failing[pathogen]["infection_maximum_lrv_median"]).is_greater_than(
+                    normal[pathogen]["infection_maximum_lrv_median"])
+
+
+class TestParallelUnits(TestCase):
+
+    def test_failure_lrv_matches_the_d7_table(self):
+        # docs/review-2026-10-dev-scenarios.md, F2: the LRV a step keeps while one of its units is down
+        for normal_lrv, units, expected_lrv in [(4, 2, 0.30), (4, 4, 0.60), (4, 10, 1.00),
+                                                (1, 2, 0.26), (1, 4, 0.49), (1, 10, 0.72)]:
+            with self.subTest(normal_lrv=normal_lrv, units=units):
+                failing = calculate([dict(all_groups(normal_lrv, normal_lrv), failure_frequency=365,
+                                          failure_duration=1440, parallel_units=units),
+                                     all_groups(NEVER_FAILING_LRV, NEVER_FAILING_LRV)])
+                train_lrv = NEVER_FAILING_LRV + expected_lrv
+                reference = calculate([all_groups(train_lrv, train_lrv)])
+
+                assert_both_cases_close(failing, reference, ROUNDING)
+
+    def test_more_parallel_units_never_raise_the_risk(self):
+        results = [calculate([dict(STRONG_STEP, failure_frequency=100, failure_duration=600, parallel_units=units),
+                              dict(WEAK_STEP, failure_frequency=100, failure_duration=600, parallel_units=units)])
+                   for units in [1, 2, 4, 10, 1000]]
+
+        for pathogen in PATHOGENS:
+            for case in ["minimum_lrv", "maximum_lrv"]:
+                for pair, (fewer, more) in enumerate(zip(results, results[1:])):
+                    with self.subTest(pathogen=pathogen, case=case, pair=pair):
+                        for with_fewer, with_more in zip(case_statistics(fewer[pathogen], case),
+                                                         case_statistics(more[pathogen], case)):
+                            assert_that(with_more).is_less_than_or_equal_to(with_fewer)
+        for case in ["minimum_lrv", "maximum_lrv"]:
+            median = [r["Rotavirus"][f"infection_{case}_median"] for r in results]
+            assert_that(median[-1]).described_as(case).is_less_than(median[0])
diff --git a/qmra/risk_assessment/tests/test_failure_inputs.py b/qmra/risk_assessment/tests/test_failure_inputs.py
new file mode 100644
index 0000000..2abe851
--- /dev/null
+++ b/qmra/risk_assessment/tests/test_failure_inputs.py
@@ -0,0 +1,534 @@
+"""failure inputs of treatment steps, tested over HTTP like a browser uses the configurator"""
+import io
+import re
+from html.parser import HTMLParser
+from zipfile import ZipFile
+
+from assertpy import assert_that
+from django.test import TestCase
+from django.urls import reverse
+
+from qmra.risk_assessment.models import RiskAssessment, Inflow, Treatment
+from qmra.risk_assessment.user_models import UserTreatment
+from qmra.user.models import User
+
+
+class ConfiguratorFormParser(HTMLParser):
+    """Collects what a browser would submit from the configurator form."""
+
+    def __init__(self):
+        super().__init__()
+        self.data = {}
+        self.in_configurator = False
+        self.select_name = None
+        self.first_option = None
+
+    def handle_starttag(self, tag, attrs):
+        attrs = dict(attrs)
+        if tag == "form":
+            self.in_configurator = attrs.get("id") == "configurator"
+        if not self.in_configurator:
+            return
+        if tag == "input" and attrs.get("name"):
+            if attrs.get("type") in ("submit", "button"):
+                return
+            if attrs.get("type") == "checkbox" and "checked" not in attrs:
+                return
+            self.data[attrs["name"]] = attrs.get("value", "")
+        elif tag == "select":
+            self.select_name = attrs.get("name")
+            self.first_option = None
+        elif tag == "option" and self.select_name:
+            if self.first_option is None:
+                self.first_option = attrs.get("value", "")
+                self.data.setdefault(self.select_name, self.first_option)
+            if "selected" in attrs:
+                self.data[self.select_name] = attrs.get("value", "")
+
+    def handle_endtag(self, tag):
+        if tag == "form":
+            self.in_configurator = False
+        elif tag == "select":
+            self.select_name = None
+
+
+def configurator_data(response) -> dict:
+    parser = ConfiguratorFormParser()
+    parser.feed(response.content.decode())
+    return parser.data
+
+
+def field_errors(response, name: str) -> list[str]:
+    """The error messages the configurator shows below the input with this name."""
+    return re.findall(rf'<span id="error_\d+_id_{re.escape(name)}"><strong>(.*?)</strong></span>',
+                      response.content.decode())
+
+
+def add_step(data: dict, name: str, **values):
+    """Add a treatment step card the way the configurator's script does: copy the empty form."""
+    n = int(data["treatments-TOTAL_FORMS"])
+    for key, value in list(data.items()):
+        if key.startswith("treatments-__prefix__-") and not key.endswith("-DELETE"):
+            data[key.replace("__prefix__", str(n))] = value
+    data[f"treatments-{n}-name"] = name
+    for field, value in values.items():
+        data[f"treatments-{n}-{field}"] = value
+    data["treatments-TOTAL_FORMS"] = str(n + 1)
+
+
+def failure_inputs_per_step(data: dict) -> list[dict]:
+    """The treatment step cards of a configurator, in order, with their failure inputs."""
+    return [
+        dict(name=data[f"treatments-{i}-name"],
+             failure_frequency=float(data[f"treatments-{i}-failure_frequency"]),
+             failure_duration=int(data[f"treatments-{i}-failure_duration"]),
+             parallel_units=int(data[f"treatments-{i}-parallel_units"]))
+        for i in range(int(data["treatments-TOTAL_FORMS"]))
+    ]
+
+
+def new_configurator(client) -> dict:
+    """A new configurator with groundwater, drinking water and no treatment steps yet."""
+    data = configurator_data(client.get(reverse("assessment")))
+    for i in range(3):
+        data[f"inflow-{i}-min"] = "10"
+        data[f"inflow-{i}-max"] = "100"
+    data["ra-source_name"] = "groundwater"
+    data["ra-exposure_name"] = "drinking water"
+    data["ra-events_per_year"] = "365"
+    data["ra-volume_per_event"] = "1"
+    return data
+
+
+def layout(csv: bytes) -> list[str]:
+    """The lines of an exported table with every number replaced, so only its rows and columns remain."""
+    return [re.sub(r"-?\d+(\.\d+)?(e[-+]?\d+)?", "#", line) for line in csv.decode().splitlines()]
+
+
+# high enough that failures change the results visibly instead of leaving them at a risk of 1
+HIGH_LRVS = dict(bacteria_min=3, bacteria_max=4, viruses_min=3, viruses_max=4, protozoa_min=3, protozoa_max=4)
+PARALLEL_UNITS_MESSAGE = "number of parallel units must be a whole number of 1 or more"
+LRVS = dict(bacteria_min=1, bacteria_max=2, viruses_min=1, viruses_max=2, protozoa_min=1, protozoa_max=2)
+
+
+class LoggedInTestCase(TestCase):
+
+    def setUp(self):
+        self.user = User.objects.create_user("test-user", "test-user@test.com", "password")
+        self.client.force_login(self.user)
+
+    def save_new(self, data: dict) -> RiskAssessment:
+        response = self.client.post(reverse("assessment"), data)
+        assert_that(response.status_code).is_equal_to(302)
+        return RiskAssessment.objects.get(user=self.user)
+
+
+class TestFailureInputs(LoggedInTestCase):
+
+    def post_configurator(self, data: dict, assessment: RiskAssessment = None):
+        url = reverse("assessment") if assessment is None else reverse("assessment", args=[assessment.id])
+        return self.client.post(url, data)
+
+    def reopen(self, assessment: RiskAssessment) -> dict:
+        return configurator_data(self.client.get(reverse("assessment", args=[assessment.id])))
+
+    def results(self, assessment: RiskAssessment) -> dict:
+        return {r.pathogen: r.as_dict() for r in RiskAssessment.objects.get(id=assessment.id).results.all()}
+
+    def export(self, assessment: RiskAssessment) -> dict:
+        response = self.client.get(reverse("assessment-export", args=[assessment.id]))
+        with ZipFile(io.BytesIO(response.content)) as archive:
+            return {name: archive.read(name) for name in archive.namelist()}
+
+    def test_new_step_card_shows_failure_fields_with_units_and_defaults(self):
+        response = self.client.get(reverse("assessment"))
+
+        assert_that(response.content.decode()).contains(
+            "Failure frequency (days per year)", "Failure duration (minutes)")
+        data = configurator_data(response)
+        assert_that(float(data["treatments-__prefix__-failure_frequency"])).is_equal_to(0)
+        assert_that(int(data["treatments-__prefix__-failure_duration"])).is_equal_to(30)
+
+    def test_new_step_card_shows_number_of_parallel_units_starting_at_1(self):
+        response = self.client.get(reverse("assessment"))
+
+        assert_that(response.content.decode()).contains("Number of parallel units")
+        data = configurator_data(response)
+        assert_that(int(data["treatments-__prefix__-parallel_units"])).is_equal_to(1)
+
+    def test_bundled_step_starts_at_defaults(self):
+        data = new_configurator(self.client)
+        add_step(data, "Primary treatment", **LRVS)
+
+        assessment = self.save_new(data)
+
+        assert_that(failure_inputs_per_step(self.reopen(assessment))).is_equal_to([
+            dict(name="Primary treatment", failure_frequency=0, failure_duration=30, parallel_units=1)
+        ])
+
+    def test_failure_inputs_survive_save_and_reopen_per_step(self):
+        data = new_configurator(self.client)
+        add_step(data, "Primary treatment", **LRVS, failure_frequency="0.5", failure_duration="15")
+        add_step(data, "Primary treatment", **LRVS, failure_frequency="12", failure_duration="600",
+                 parallel_units="4")
+        add_step(data, "Slow sand filtration", **LRVS, failure_frequency="365", failure_duration="1440",
+                 parallel_units="2")
+
+        assessment = self.save_new(data)
+
+        assert_that(failure_inputs_per_step(self.reopen(assessment))).is_equal_to([
+            dict(name="Primary treatment", failure_frequency=0.5, failure_duration=15, parallel_units=1),
+            dict(name="Primary treatment", failure_frequency=12, failure_duration=600, parallel_units=4),
+            dict(name="Slow sand filtration", failure_frequency=365, failure_duration=1440, parallel_units=2),
+        ])
+
+    def test_editing_stores_new_values_and_values_stay_with_their_step(self):
+        data = new_configurator(self.client)
+        add_step(data, "Primary treatment", **LRVS, failure_frequency="1", failure_duration="10",
+                 parallel_units="3")
+        add_step(data, "Slow sand filtration", **LRVS, failure_frequency="2", failure_duration="20",
+                 parallel_units="2")
+        add_step(data, "Primary treatment", **LRVS, failure_frequency="3", failure_duration="30")
+        assessment = self.save_new(data)
+
+        data = self.reopen(assessment)
+        data["treatments-0-DELETE"] = "on"
+        data["treatments-2-failure_frequency"] = "4.5"
+        data["treatments-2-failure_duration"] = "45"
+        data["treatments-2-parallel_units"] = "5"
+        response = self.post_configurator(data, assessment)
+
+        assert_that(response.status_code).is_equal_to(302)
+        assert_that(failure_inputs_per_step(self.reopen(assessment))).is_equal_to([
+            dict(name="Slow sand filtration", failure_frequency=2, failure_duration=20, parallel_units=2),
+            dict(name="Primary treatment", failure_frequency=4.5, failure_duration=45, parallel_units=5),
+        ])
+
+    def test_out_of_range_or_fractional_values_are_rejected_with_a_message(self):
+        cases = [
+            ("-1", "30", "failure frequency must be between 0 and 365 days per year"),
+            ("365.5", "30", "failure frequency must be between 0 and 365 days per year"),
+            ("0", "0", "failure duration must be between 1 and 1440 minutes"),
+            ("0", "1441", "failure duration must be between 1 and 1440 minutes"),
+            ("1", "2.5", "Enter a whole number."),
+            ("1", "", "This field is required."),
+            ("", "30", "This field is required."),
+        ]
+        for frequency, duration, message in cases:
+            with self.subTest(frequency=frequency, duration=duration):
+                data = new_configurator(self.client)
+                add_step(data, "Primary treatment", **LRVS,
+                         failure_frequency=frequency, failure_duration=duration)
+
+                response = self.post_configurator(data)
+
+                assert_that(response.status_code).is_equal_to(200)
+                assert_that(response.content.decode()).contains(message)
+                assert_that(RiskAssessment.objects.filter(user=self.user).count()).is_equal_to(0)
+
+    def test_range_bounds_are_accepted(self):
+        for frequency, duration in [("0", "1"), ("365", "1440"), ("0.5", "30")]:
+            with self.subTest(frequency=frequency, duration=duration):
+                data = new_configurator(self.client)
+                add_step(data, "Primary treatment", **LRVS,
+                         failure_frequency=frequency, failure_duration=duration)
+
+                response = self.post_configurator(data)
+
+                assert_that(response.status_code).is_equal_to(302)
+
+    def test_number_of_parallel_units_below_1_or_fractional_is_rejected_with_a_message(self):
+        for units in ["0", "-1", "1.5"]:
+            with self.subTest(units=units):
+                data = new_configurator(self.client)
+                add_step(data, "Primary treatment", **LRVS, parallel_units=units)
+
+                response = self.post_configurator(data)
+
+                assert_that(response.status_code).is_equal_to(200)
+                assert_that(field_errors(response, "treatments-0-parallel_units")).is_equal_to([PARALLEL_UNITS_MESSAGE])
+                assert_that(RiskAssessment.objects.filter(user=self.user).count()).is_equal_to(0)
+
+    def test_any_whole_number_of_parallel_units_of_1_or_more_is_accepted(self):
+        for units in ["1", "2", "1000"]:
+            with self.subTest(units=units):
+                data = new_configurator(self.client)
+                add_step(data, "Primary treatment", **LRVS, parallel_units=units)
+
+                response = self.post_configurator(data)
+
+                assert_that(response.status_code).is_equal_to(302)
+
+    def test_assessment_from_before_failure_inputs_reopens_with_defaults(self):
+        assessment = RiskAssessment.objects.create(user=self.user, events_per_year=365, volume_per_event=1)
+        for pathogen in ["Rotavirus", "Campylobacter jejuni", "Cryptosporidium parvum"]:
+            Inflow.objects.create(risk_assessment=assessment, pathogen=pathogen, min=10, max=100)
+        Treatment.objects.create(risk_assessment=assessment, name="Primary treatment", **LRVS)
+
+        assert_that(failure_inputs_per_step(self.reopen(assessment))).is_equal_to([
+            dict(name="Primary treatment", failure_frequency=0, failure_duration=30, parallel_units=1)
+        ])
+
+    def saved_assessment_with_two_steps(self) -> RiskAssessment:
+        data = new_configurator(self.client)
+        add_step(data, "Primary treatment", **HIGH_LRVS)
+        add_step(data, "Slow sand filtration", **HIGH_LRVS)
+        return self.save_new(data)
+
+    def test_result_and_export_do_not_change_with_failure_frequency_0(self):
+        assessment = self.saved_assessment_with_two_steps()
+        results_before = self.results(assessment)
+        export_before = self.export(assessment)
+
+        data = self.reopen(assessment)
+        data["treatments-0-failure_duration"] = "120"
+        data["treatments-1-failure_duration"] = "1440"
+        self.post_configurator(data, assessment)
+
+        assert_that(failure_inputs_per_step(self.reopen(assessment))[0]["failure_duration"]).is_equal_to(120)
+        assert_that(self.results(assessment)).is_equal_to(results_before)
+        assert_that(self.export(assessment)).is_equal_to(export_before)
+
+    def test_export_keeps_its_files_and_columns_with_failures(self):
+        assessment = self.saved_assessment_with_two_steps()
+        results_before = self.results(assessment)
+        export_before = self.export(assessment)
+
+        data = self.reopen(assessment)
+        data["treatments-0-failure_frequency"] = "20"
+        data["treatments-1-failure_frequency"] = "365"
+        data["treatments-1-parallel_units"] = "4"
+        self.post_configurator(data, assessment)
+
+        steps = failure_inputs_per_step(self.reopen(assessment))
+        assert_that(steps[0]["failure_frequency"]).is_equal_to(20)
+        assert_that(steps[1]["parallel_units"]).is_equal_to(4)
+        assert_that(self.results(assessment)).is_not_equal_to(results_before)
+        export_after = self.export(assessment)
+        assert_that(sorted(export_after)).is_equal_to(sorted(export_before))
+        for name in export_before:
+            if name.endswith(".csv"):
+                assert_that(layout(export_after[name])).described_as(name).is_equal_to(layout(export_before[name]))
+
+
+NO_LRVS = dict(bacteria_min="", bacteria_max="", viruses_min="", viruses_max="", protozoa_min="", protozoa_max="")
+D4_REJECTED = {
+    "empty LRVs": NO_LRVS,
+    "zero LRVs": dict(NO_LRVS, bacteria_min=0, bacteria_max=0, viruses_min=0, viruses_max=0),
+    "recontamination": dict(bacteria_min=-1, bacteria_max=-0.5, viruses_min=-1, viruses_max=-0.5,
+                            protozoa_min=-1, protozoa_max=-0.5),
+}
+D4_ACCEPTED = {
+    "one positive maximum": dict(NO_LRVS, protozoa_min=0, protozoa_max=2),
+    "regrowth in one group": dict(bacteria_min=-1, bacteria_max=-0.5, viruses_min=1, viruses_max=2,
+                                  protozoa_min=1, protozoa_max=2),
+}
+D4_MESSAGE = "failure frequency must be 0 for a treatment step without a positive LRV"
+
+
+class TestFailureOnlyWithPositiveLrv(LoggedInTestCase):
+
+    def save_with_step(self, lrvs: dict, failure_frequency: str):
+        data = new_configurator(self.client)
+        add_step(data, "Primary treatment", **lrvs, failure_frequency=failure_frequency, failure_duration="30")
+        return self.client.post(reverse("assessment"), data)
+
+    def test_step_without_positive_lrv_cannot_fail(self):
+        for case, lrvs in D4_REJECTED.items():
+            with self.subTest(case):
+                response = self.save_with_step(lrvs, failure_frequency="1")
+
+                assert_that(response.status_code).is_equal_to(200)
+                assert_that(field_errors(response, "treatments-0-failure_frequency")).is_equal_to([D4_MESSAGE])
+                assert_that(RiskAssessment.objects.filter(user=self.user).count()).is_equal_to(0)
+
+    def test_step_without_positive_lrv_keeps_failure_frequency_0(self):
+        for case, lrvs in D4_REJECTED.items():
+            with self.subTest(case):
+                response = self.save_with_step(lrvs, failure_frequency="0")
+
+                assert_that(response.status_code).is_equal_to(302)
+
+    def test_step_with_one_positive_lrv_can_fail(self):
+        for case, lrvs in D4_ACCEPTED.items():
+            with self.subTest(case):
+                response = self.save_with_step(lrvs, failure_frequency="1")
+
+                assert_that(response.status_code).is_equal_to(302)
+
+
+class TestGuestFailureInputs(TestCase):
+
+    def guest_result(self, **step_values):
+        data = new_configurator(self.client)
+        add_step(data, "Primary treatment", **{**LRVS, **step_values})
+        return self.client.post(reverse("assessment-result"), data)
+
+    def test_guest_sees_failure_fields(self):
+        response = self.client.get(reverse("assessment"))
+
+        assert_that(response.content.decode()).contains(
+            "Failure frequency (days per year)", "Failure duration (minutes)", "Number of parallel units")
+
+    def test_guest_step_card_starts_at_1_parallel_unit(self):
+        data = configurator_data(self.client.get(reverse("assessment")))
+
+        assert_that(int(data["treatments-__prefix__-parallel_units"])).is_equal_to(1)
+
+    def test_guest_result_accepts_any_whole_number_of_parallel_units_of_1_or_more(self):
+        for units in ["1", "2", "1000"]:
+            with self.subTest(units=units):
+                response = self.guest_result(parallel_units=units)
+
+                assert_that(response.status_code).is_equal_to(200)
+
+    def test_guest_result_with_failure_inputs_is_shown_and_not_stored(self):
+        response = self.guest_result(failure_frequency="12", failure_duration="60")
+
+        assert_that(response.status_code).is_equal_to(200)
+        assert_that(RiskAssessment.objects.count()).is_equal_to(0)
+        assert_that(Treatment.objects.count()).is_equal_to(0)
+
+    def test_guest_result_sends_back_messages_of_invalid_inputs(self):
+        cases = [
+            (dict(failure_frequency="366"), "treatments-0-failure_frequency",
+             "failure frequency must be between 0 and 365 days per year"),
+            (dict(failure_duration="2.5"), "treatments-0-failure_duration", "Enter a whole number."),
+            (dict(bacteria_min="3", bacteria_max="1"), "treatments-0-bacteria_min", "min. must be less than max"),
+            (dict(parallel_units="0"), "treatments-0-parallel_units", PARALLEL_UNITS_MESSAGE),
+            (dict(parallel_units="-1"), "treatments-0-parallel_units", PARALLEL_UNITS_MESSAGE),
+            (dict(parallel_units="1.5"), "treatments-0-parallel_units", PARALLEL_UNITS_MESSAGE),
+        ]
+        for step_values, field, message in cases:
+            with self.subTest(field=field, message=message):
+                response = self.guest_result(**step_values)
+
+                assert_that(response.status_code).is_equal_to(422)
+                assert_that(response.json()["errors"]).contains_entry({field: [message]})
+                assert_that(RiskAssessment.objects.count()).is_equal_to(0)
+
+    def test_guest_result_rejects_failing_step_without_positive_lrv(self):
+        for case, lrvs in D4_REJECTED.items():
+            with self.subTest(case):
+                response = self.guest_result(**lrvs, failure_frequency="1")
+
+                assert_that(response.status_code).is_equal_to(422)
+                assert_that(response.json()["errors"]).contains_entry(
+                    {"treatments-0-failure_frequency": [D4_MESSAGE]})
+
+    def test_guest_result_accepts_step_without_positive_lrv_and_failure_frequency_0(self):
+        for case, lrvs in D4_REJECTED.items():
+            with self.subTest(case):
+                response = self.guest_result(**lrvs, failure_frequency="0")
+
+                assert_that(response.status_code).is_equal_to(200)
+
+    def test_guest_result_accepts_failing_step_with_one_positive_lrv(self):
+        for case, lrvs in D4_ACCEPTED.items():
+            with self.subTest(case):
+                response = self.guest_result(**lrvs, failure_frequency="1")
+
+                assert_that(response.status_code).is_equal_to(200)
+
+
+def personal_step_form(response) -> str:
+    """The HTML of the personal treatment step form on the configurator page."""
+    html = response.content.decode()
+    start = html.index('id="user-treatment-form"')
+    return html[start:html.index("</form>", start)]
+
+
+class TestPersonalTreatmentStepFailureInputs(LoggedInTestCase):
+
+    def create_personal_step(self, name="Plant UV", **values):
+        data = dict(name=name, **LRVS, failure_frequency="0", failure_duration="30", parallel_units="1")
+        data.update(values)
+        return self.client.post(reverse("treatment"), data, HTTP_REFERER=reverse("assessment"))
+
+    def personal_steps(self, client=None) -> dict:
+        return (client or self.client).get(reverse("treatments")).json()
+
+    def failure_inputs(self, name: str) -> tuple:
+        step = self.personal_steps()[name]
+        return step["failure_frequency"], step["failure_duration"], step["parallel_units"]
+
+    def test_form_shows_failure_fields_with_units_and_defaults(self):
+        form = personal_step_form(self.client.get(reverse("assessment")))
+
+        assert_that(form).contains("Failure frequency (days per year)", "Failure duration (minutes)")
+        assert_that(form).matches(r'name="failure_frequency" value="0"')
+        assert_that(form).matches(r'name="failure_duration" value="30"')
+
+    def test_form_shows_number_of_parallel_units_starting_at_1(self):
+        form = personal_step_form(self.client.get(reverse("assessment")))
+
+        assert_that(form).contains("Number of parallel units")
+        assert_that(form).matches(r'name="parallel_units" value="1"')
+
+    def test_failure_inputs_appear_in_the_owners_list(self):
+        response = self.create_personal_step(failure_frequency="2.5", failure_duration="90", parallel_units="3")
+
+        assert_that(response.status_code).is_equal_to(302)
+        assert_that(self.failure_inputs("Plant UV")).is_equal_to((2.5, 90, 3))
+
+    def test_other_users_do_not_see_the_personal_step(self):
+        self.create_personal_step(failure_frequency="2.5", failure_duration="90")
+        other = User.objects.create_user("other-user", "other-user@test.com", "password")
+        other_client = self.client_class()
+        other_client.force_login(other)
+
+        assert_that(self.personal_steps(other_client)).does_not_contain_key("Plant UV")
+
+    def test_invalid_values_are_rejected_with_a_message(self):
+        cases = [
+            (dict(failure_frequency="366"), "failure frequency must be between 0 and 365 days per year"),
+            (dict(failure_duration="0"), "failure duration must be between 1 and 1440 minutes"),
+            (dict(failure_duration="2.5"), "Enter a whole number."),
+            (dict(failure_duration=""), "This field is required."),
+            (dict(NO_LRVS, failure_frequency="1"), D4_MESSAGE),
+            (dict(bacteria_min="3", bacteria_max="1"), "min. must be less than max"),
+            (dict(parallel_units="0"), PARALLEL_UNITS_MESSAGE),
+            (dict(parallel_units="-1"), PARALLEL_UNITS_MESSAGE),
+            (dict(parallel_units="1.5"), PARALLEL_UNITS_MESSAGE),
+            (dict(parallel_units=""), "This field is required."),
+        ]
+        for values, message in cases:
+            with self.subTest(message=message, values=values):
+                response = self.create_personal_step(**values)
+
+                assert_that(response.status_code).is_equal_to(422)
+                assert_that(response.content.decode()).contains(message)
+                assert_that(self.personal_steps()).is_empty()
+
+    def test_valid_values_including_d4_cases_are_accepted(self):
+        cases = {
+            "bounds low": dict(failure_frequency="0", failure_duration="1"),
+            "bounds high": dict(failure_frequency="365", failure_duration="1440"),
+            "2 parallel units": dict(parallel_units="2"),
+            "1000 parallel units": dict(parallel_units="1000"),
+            "no positive LRV, frequency 0": dict(NO_LRVS, failure_frequency="0"),
+            **{case: dict(lrvs, failure_frequency="1") for case, lrvs in D4_ACCEPTED.items()},
+        }
+        for case, values in cases.items():
+            with self.subTest(case):
+                response = self.create_personal_step(name=case, **values)
+
+                assert_that(response.status_code).is_equal_to(302)
+                assert_that(self.personal_steps()).contains_key(case)
+
+    def test_personal_step_from_before_failure_inputs_offers_defaults(self):
+        UserTreatment.objects.create(user=self.user, name="Old step", **LRVS)
+
+        assert_that(self.failure_inputs("Old step")).is_equal_to((0, 30, 1))
+
+    def test_changing_the_copy_in_an_assessment_leaves_the_personal_step_unchanged(self):
+        self.create_personal_step(failure_frequency="2.5", failure_duration="90", parallel_units="3")
+        data = new_configurator(self.client)
+        add_step(data, "Plant UV", **LRVS, failure_frequency="10", failure_duration="15", parallel_units="5")
+
+        assessment = self.save_new(data)
+
+        assert_that(failure_inputs_per_step(configurator_data(
+            self.client.get(reverse("assessment", args=[assessment.id]))))).is_equal_to([
+                dict(name="Plant UV", failure_frequency=10, failure_duration=15, parallel_units=5)])
+        assert_that(self.failure_inputs("Plant UV")).is_equal_to((2.5, 90, 3))
diff --git a/qmra/risk_assessment/tests/test_risk_assessment_form.py b/qmra/risk_assessment/tests/test_risk_assessment_form.py
index e28527d..e3d6fd6 100644
--- a/qmra/risk_assessment/tests/test_risk_assessment_form.py
+++ b/qmra/risk_assessment/tests/test_risk_assessment_form.py
@@ -87,7 +87,10 @@ def test_that_negative_are_allowed(self):
             viruses_min=-2,
             viruses_max=-1,
             protozoa_min=-2,
-            protozoa_max=-1
+            protozoa_max=-1,
+            failure_frequency=0,
+            failure_duration=30,
+            parallel_units=1,
         )
         given_form = TreatmentForm(data=data)
         # ugly hack to work around dynamic choices...
@@ -104,7 +107,10 @@ def test_that_min_needs_to_be_less_than_max(self):
             viruses_min=0,
             viruses_max=0,
             protozoa_min=0,
-            protozoa_max=0
+            protozoa_max=0,
+            failure_frequency=0,
+            failure_duration=30,
+            parallel_units=1,
         )
         for prfx in ["bacteria", "viruses", "protozoa"]:
             mn = prfx + "_min"
diff --git a/qmra/risk_assessment/user_models.py b/qmra/risk_assessment/user_models.py
index 3b5f481..f969160 100644
--- a/qmra/risk_assessment/user_models.py
+++ b/qmra/risk_assessment/user_models.py
@@ -6,7 +6,7 @@
 from crispy_forms.helper import FormHelper
 from crispy_forms.layout import Layout, Field, Row, Column, HTML, Submit
 
-from qmra.risk_assessment.forms import _zero_if_none
+from qmra.risk_assessment.forms import check_treatment_step, PARALLEL_UNITS_MESSAGE
 from qmra.user.models import User
 
 
@@ -138,6 +138,9 @@ class UserTreatment(models.Model):
     viruses_max = models.FloatField(blank=True, null=True)
     protozoa_min = models.FloatField(blank=True, null=True)
     protozoa_max = models.FloatField(blank=True, null=True)
+    failure_frequency = models.FloatField(default=0)  # failure days per year
+    failure_duration = models.IntegerField(default=30)  # minutes
+    parallel_units = models.IntegerField(default=1)  # a failure event stops one of them (D7)
 
 
 class UserTreatmentForm(forms.ModelForm):
@@ -150,7 +153,10 @@ class Meta:
             'viruses_min',
             'viruses_max',
             "protozoa_min",
-            "protozoa_max"
+            "protozoa_max",
+            "failure_frequency",
+            "failure_duration",
+            "parallel_units",
         ]
 
     def __init__(self, *args, **kwargs):
@@ -167,6 +173,10 @@ def __init__(self, *args, **kwargs):
         self.fields['viruses_max'].label = ""
         self.fields['protozoa_min'].label = ""
         self.fields['protozoa_max'].label = ""
+        self.fields['failure_frequency'].label = "Failure frequency (days per year)"
+        self.fields['failure_duration'].label = "Failure duration (minutes)"
+        self.fields['parallel_units'].label = "Number of parallel units"
+        self.fields['parallel_units'].error_messages['invalid'] = PARALLEL_UNITS_MESSAGE
         label_style = "class='text-muted text-center w-100' style='margin-top: .4em;'"
         self.helper.layout = Layout(
             Field("name"),
@@ -179,22 +189,11 @@ def __init__(self, *args, **kwargs):
                 Column("viruses_min"), Column("viruses_max")),
             Row(Column(HTML(f"<label {label_style}>Protozoa LRV:</label>")),
                 Column("protozoa_min"), Column("protozoa_max")),
+            Row(Column("failure_frequency"), Column("failure_duration"), Column("parallel_units")),
             Submit('submit', 'Submit')
         )
 
     def clean(self):
         cleaned_data = super().clean()
-        b_min = _zero_if_none(cleaned_data.get("bacteria_min", 0))
-        b_max = _zero_if_none(cleaned_data.get("bacteria_max", 0))
-        v_min = _zero_if_none(cleaned_data.get("viruses_min", 0))
-        v_max = _zero_if_none(cleaned_data.get("viruses_max", 0))
-        p_min = _zero_if_none(cleaned_data.get("protozoa_min", 0))
-        p_max = _zero_if_none(cleaned_data.get("protozoa_max", 0))
-        msg = "min. must be less than max"
-        if b_min > b_max:
-            self.add_error("bacteria_min", msg)
-        if v_min > v_max:
-            self.add_error("viruses_min", msg)
-        if p_min > p_max:
-            self.add_error("protozoa_min", msg)
+        check_treatment_step(self, cleaned_data)
         return cleaned_data
diff --git a/qmra/risk_assessment/views.py b/qmra/risk_assessment/views.py
index 2e4122e..c0babaa 100644
--- a/qmra/risk_assessment/views.py
+++ b/qmra/risk_assessment/views.py
@@ -2,6 +2,7 @@
 
 from crispy_forms.utils import render_crispy_form
 from django.contrib.auth.decorators import login_required
+from django.core.exceptions import NON_FIELD_ERRORS
 from django.http import HttpResponseRedirect, HttpResponse, JsonResponse
 from django.shortcuts import render
 from django.template.context_processors import csrf
@@ -55,6 +56,24 @@ def assess_and_save_results(risk_assessment: RiskAssessment) -> RiskAssessment:
     return RiskAssessment.objects.get(id=risk_assessment.id)
 
 
+def errors_by_field_name(risk_assessment_form, inflow_form, treatment_form) -> dict[str, list[str]]:
+    """Error messages keyed by the name of the input they belong to; the rest under NON_FIELD_ERRORS."""
+    errors = {}
+
+    def add(key, messages):
+        errors.setdefault(key, []).extend(messages)
+
+    for field, messages in risk_assessment_form.errors.items():
+        add(field if field == NON_FIELD_ERRORS else risk_assessment_form.add_prefix(field), messages)
+    for formset in [inflow_form, treatment_form]:
+        # formset.deleted_forms is empty for an invalid formset, so removed steps are filtered here
+        for form in [f for f in formset.forms if not formset._should_delete_form(f)]:
+            for field, messages in form.errors.items():
+                add(field if field == NON_FIELD_ERRORS else form.add_prefix(field), messages)
+        add(NON_FIELD_ERRORS, formset.non_form_errors())
+    return {key: messages for key, messages in errors.items() if messages}
+
+
 @login_required(login_url="/login")
 def list_risk_assessment_view(request):
     return render(request, "risk-assessment-list.html",
@@ -181,9 +200,8 @@ def risk_assessment_result(request):
                                                             for t in treatments
                                                             if len(t.above_max_lrv())}))
         else:
-            # print(inflow_form.errors)
-            # print(treatment_form.errors)
-            return HttpResponse(status=422)
+            return JsonResponse(dict(errors=errors_by_field_name(risk_assessment_form, inflow_form, treatment_form)),
+                                status=422)
 
     elif request.method == "GET":
         risk_assessment_id = request.GET.get("id")
@@ -292,13 +310,13 @@ def create_treatment(request):
             # handle duplicate names
             if any(UserExposure.objects.filter(name=treatment_form.instance.name, user=request.user).all()):
                 treatment_form.add_error("name", "'name' must be unique. You already have a treatment with this name")
-                ctx = {}
-                ctx.update(csrf(request))
-                return HttpResponse(render_crispy_form(treatment_form, context=ctx), status=422)
-            treatment_form.instance.user = request.user
-            treatment_form.save(commit=True)
-            return HttpResponseRedirect(request.META["HTTP_REFERER"])
-        return HttpResponse(status=422)
+            else:
+                treatment_form.instance.user = request.user
+                treatment_form.save(commit=True)
+                return HttpResponseRedirect(request.META["HTTP_REFERER"])
+        ctx = {}
+        ctx.update(csrf(request))
+        return HttpResponse(render_crispy_form(treatment_form, context=ctx), status=422)
     return HttpResponse(status=404)