to-be 55: a failed whole-set rule is a warning to the operator and leaves the module healthy, and cited is judged in the review (issue 504)

The operator decided on 2026-10-12, on issue 504, that a rule of the
record set that fails is a fault of the records, not the module failing:
health says only whether the module works (issue 508's principle), so a
finding must not hold a walk at the module's first-node gate.

03-DESIGN/01-to-be/55-the-knowledge-base.md

@@ -2,7 +2,7 @@
 layer: to-be
 status: designed
 code: []
-updated: 2026-10-11
+updated: 2026-10-12
 decisions:
   - "ADR 0290"
 ---
@@ -125,8 +125,17 @@ approval. On `approve`:
 
 On acceptance the record and its clauses move to `accepted` and `in force`, every clause its `changes` and
 `supersedes` name moves to `changed` or `superseded`, and `accepted` and `changed` events are emitted. Then the 4
-rules that judge the whole record set run (an accepted decision cited by nothing, and the like); a failure raises a
-condition naming the rule and the records, and does not undo the acceptance.
+rules that judge the whole record set run (an accepted decision cited by nothing, and the like). A failure does not
+undo the acceptance. It is a fault of the records, which their authors repair, not of the module: it is told to the
+operator once, as a warning naming the rule and the records, and cleared once the rule holds again. The module's
+health names it and stays healthy, because health says only whether the module works, and a finding never holds a
+walk at the module's first-node gate (the operator's decision of 2026-10-12 on issue 504, as issue 508 decided for a proposal never
+reviewed).
+
+The rule `cited` is also judged ahead, in the review, before the judgement: a decision that names no home and that no
+accepted record links is not accepted. Its review, by the knowledge base itself, asks changes naming the rule (issue
+504). It is not refused at `propose`, because no record can link a number only reserved: a record that cites a new
+decision is proposed after it and accepted, and the new decision is proposed again.
 
 An accepted record is changed only by a new record, or by a progressive insight: a new version marked as one, which
 is reviewed like a proposal.
@@ -184,7 +193,8 @@ repository keeps no copy of the records, generated or otherwise (issue 435, answ
 |---|---|
 | A proposal that breaks a per-record rule is refused, naming every reason | the module's table test, one case per rule of § 4 |
 | A record is accepted only after the knowledge base's own judgement approves it, and, when it needs the operator, only on the warrant | the module's tests: a proposal whose judgement answers changes, or cannot be had, stays proposed; a `needs operator` record unaccepted without the warrant, accepted with it |
-| A whole-set rule that fails is loud | the module's test: an acceptance that leaves a decision cited by nothing raises the condition |
+| A decision is not accepted cited by nothing | the module's test: a decision with no home and no record linking it gets changes from the review, with no judgement asked; with a home, or once a record citing it is accepted, it is accepted |
+| A whole-set rule that fails is loud, and leaves the module healthy | the module's test: a correction that leaves a decision cited by nothing tells the operator once, as a warning naming the rule and the record, not again after a restart, and clears it once a record cites it; the module's health stays healthy throughout |
 | Every version is kept and comparable | the module's test: three versions, `history` lists them, the difference of the first and third is exact |
 | The import changes nothing on a second run, and loses nothing | the module's test over a fixture repository; and the comparison of § 8 on issue 426 |
 | A drafted clause is never served as in force | the module's test: `holds` over a record with only drafted clauses answers none, and `ask` marks them |