Status

Every status in BreezeBlock is worked out from the rows of completed runs, and from reviews of those rows after a requirement changed. A status itself is never typed in. This page says how each status is derived, with examples drawn the way the workspace draws them. Reading a cite covers what the shapes and fills mean.

Where each status comes from

The examples below use one list, HW, and two verifications: VERIF-PWR, a bench test of the power supply, and VERIF-HEAT, a test of the heater controller.

A run's result

A run's result comes from its rows:

A failed row decides the result at once, so a run in progress shows Fail as soon as any row fails. Otherwise it stays grey, and the page calls it in progress, until it is completed. A run cannot be completed while a row is unset, or when every row is didn't cover.

Requirements on a run's page

On a run's page each row is one requirement. Its cite is drawn neutral: a requirement's status is about every verification mapped to it, and this page is about one run. What the run recorded for the requirement is the row's choice.

A verification's result

A run in progress does not count.

The verification's page gives that run beside the result: Pass in RUN-3, its latest completed run. The run's cite carries the run's own result, which is the verification's.

A mapping's outcome

Each mapping has an outcome, taken from the latest completed run of its verification that included it, unless that result has since been reviewed:

A review recorded after that run is the outcome instead, whatever the run's row says: Passed, Failed or Untested. The next completed run that includes the mapping replaces it.

A requirement's pane lists its mappings with these outcomes, each with the run it came from: VERIF-PWR Passed in RUN-3. The outcome is about this pair only, so the cites beside it are neutral: here RUN-3 may have failed overall because of another requirement, while this one passed. Hover over the verification's name to see its own result. When a review is the outcome, the run is named on the line under it: Reviewed Oct 12, 2026 by sam@example.com, against RUN-3.

A requirement's status

A requirement's status takes in every open mapping on it and on every requirement below it. Each mapping contributes its outcome: Passed, Failed, or one of Didn't cover and Untested, which count the same.

A requirement with no children is Pass when every outcome is Passed. One with no mappings of its own takes its status from its children. The Pass row is the parent rule: a child that is not Pass keeps its parent from passing.

The parent rule

A requirement is Pass only if all its children are Pass as well. A child that is Untested, No coverage or Partial pass keeps its parent at Partial pass, even when every mapping on the parent and below it passed. Otherwise a parent could pass while part of what it asks for has never been checked.

Mapping HW-12 to a verification does not make HW-10 Pass straight away. HW-12 becomes Untested (HW-12), which is still not Pass. HW-10 turns Pass once a completed run passes HW-12.

Untested and No coverage

Both are Untested; the workspace draws them differently because they need different work.

• HW-12 No coverage: nothing on this requirement or below it is mapped. It needs a mapping.
• HW-12 Untested: something is mapped, but no completed run has passed or failed any of it. It needs a run.

A parent with no mappings of its own but a mapped child is not No coverage: it shows the status that comes from its children.

Later runs replace earlier ones

Only the latest completed run of each verification counts. When a run completes, the run before it is faded, along with every requirement cite on its page, and its page says A later completed run replaces this one.

1. RUN-2

   Passed. Replaced.

2. →
3. RUN-3

   Failed HW-4. Replaced.

4. →
5. RUN-4

   Latest. The only one that counts.

A run in progress never fades the completed run before it. If the latest completed run is deleted, the one before it counts again and is no longer faded. A review of the latest run's result can stand in for that result until the next run completes.

A new version that has not been run

Committing a new version of a verification changes no status. Statuses keep coming from the last completed run, which used the old version, until a run on the new version completes.

Needs review

A pass or fail was recorded against the statement as it was then. When you save a change to the statement of a requirement that has one, BreezeBlock lists the results recorded against the old wording and asks Does this change what HW-12 requires?

• No, keep these results. They stay as they are, with no flag. Use it for a typo or a clearer sentence.
• Yes, mark them Needs review. Each of them is marked Needs review until someone reviews it, a run records a new result, or the wording goes back.

Needs review does not change any status. A requirement that passed still shows Pass, and counts as Pass in the tallies and the status filter. Its cite gets a notch in the top right corner:

• The notch is paler on a parent when the change is below it, as on HW-1 here.
• Only requirement cites carry it. A mapping's outcome in the requirement pane, and on a verification's page, carries it too, with a Changed since link to what changed; that verification's page also names the requirements that changed since its latest run.
• Didn't cover is never marked: it already counts as untested.
• Putting back the wording a result was judged against clears the mark: the wording the run recorded against, or, once the result has been reviewed, the wording the review assessed. Putting back the run's older wording after a review does not clear it. A change to the body is asked about as a change to the statement is, and both must be back for the mark to clear. Changes to the title, and white space at the end of a line or the text, are never asked about.
• The question is not asked when every result is already marked, or when nothing has a pass or fail yet. The pane says which.

On a run still in progress, a row whose status was set before the change shows Changed in meaning after this status was set. Click Passed again if it still passes. Clicking the status again records it against the current statement and clears the mark. The run cannot be completed while any row is marked: Complete run is refused, and the refusal links to each marked row. On a completed run, a marked row links to what changed, and a line counts the rows that changed after the run.

Reviewing a result

A marked result does not always need the test run again. Someone who knows the test can look at what changed and decide what the evidence already recorded shows against the new wording. That is a review.

Review appears on a marked mapping, in the requirement pane and on the verification's page. It opens under the mapping and shows:

• the result and its run, for example VERIF-HW:RUN-3 passed HW-12 at revision 2;
• what changed since the wording that result was judged against, with a link to the change since the run's own wording when a review came in between;
• a warning when a run in progress has a status set for this requirement: completing it replaces this result anyway;
• a warning when an earlier review of this mapping stopped counting because its run was deleted.

You choose what the evidence shows now and write a note saying why. The note is required.

• Pass: it still meets the requirement as it now reads. You are asked again before it is recorded, because the test has not been run against this wording.
• Fail: it does not meet the new wording.
• Untested: it does not show either way, and a new run is needed. The mapping counts as untested, not as the run before.

A review becomes the mapping's outcome and clears the mark. A reviewed pass is a pass like any other: same cite, same tallies, same filter. The mapping says who reviewed it, when, and against which run (Reviewed Oct 12, 2026 by sam@example.com, against RUN-3), and links to the review in the requirement's history. The run itself is not changed: its page keeps what the test recorded, with a line on the row saying how it was reviewed.

• A later change answered Yes marks the result again, measured from the wording the review assessed. Putting that wording back clears it; putting back the run's older wording does not, unless it is the same text.
• The next completed run of the verification replaces the review.
• Deleting the run takes its reviews with it. The mapping goes back to what it would have been without them: usually an earlier run's result, marked again, or untested if there is none. The delete confirmation says which, for each requirement. The reviews stay in the history, marked as relying on a deleted run.
• Each mapping is reviewed on its own. A closed mapping cannot be reviewed, and mapping the same pair again starts with no result.

Status in the filtered tree

The status filter shows only requirements with the statuses you pick (see Filtering). A parent's status takes in its children's, so a parent can match because of a child. With only Fail shown, after RUN-3, HW-1 is shown because HW-4 failed. Hover over HW-1's cite, or select it, to see that its own verifications did not fail.