012: the briefing carries an outcome, derived from its lines

Proposed by the operator: state plainly whether adoption succeeded, partly succeeded or failed, with a severity per line. Taken with one change — the overall is DERIVED as the worst mark present, never written alongside. Two fields maintained independently drift, and a briefing reading "full success" while carrying a failed line is exactly the fault this record keeps cataloguing. An outcome computed from its lines cannot disagree with them. Four marks: ok, kept, unknown, failed. "unknown" is not a shade of success — adoption will meet configuration it cannot parse and state it cannot read, and folding those into "fine" is the same move as reporting an installed package as a capability. And adding severity reopens something the earlier rule did not cover. "Flags inform, they do not block" was decided about CONFLICTS, where the mesh chose deliberately and the machine still works. A failure is not "we chose" but "we could not". Treating both the same makes a node where something the mesh needed never happened indistinguishable from one where a log level differed.
2026-08-26 21:55:08 +02:00
parent 0106318bcb
commit 278f7427ed
1 changed files with 30 additions and 0 deletions
@@ -146,6 +146,35 @@ makes it one more thing the graph would carry
 settings are load-bearing, adoption is choosing a default in the dark, and the default chosen
 here is the one that does not break the machine it is adopting.

+### The briefing carries an outcome, and the outcome is derived
+
+Proposed by the operator: the report states plainly whether adoption succeeded, partly
+succeeded or failed, and each line carries its own severity.
+
+**Each line is marked, and the overall is the worst mark present.** Derived rather than stated
+alongside, because two fields written independently drift — and a briefing reading *full
+success* while carrying a failed line is exactly the fault this record keeps cataloguing. An
+outcome computed from its lines cannot disagree with them.
+
+| Mark | Means |
+|---|---|
+| `ok` | done, and verified |
+| `kept` | a disagreement; the machine's value was kept and somebody should look |
+| `unknown` | could not be determined |
+| `failed` | could not be done — the node is not what was asked for |
+
+**`unknown` is not a shade of success.** Adoption will meet configuration it cannot parse and
+state it cannot read, and folding those into *fine* is the same move as reporting an installed
+package as a capability. A thing nobody could determine is a thing nobody can rely on, and it
+gets its own mark for the same reason a capability detector reports *why*.
+
+**And this opens something the earlier rule did not cover.** *Flags inform, they do not block*
+was decided about **conflicts** — where the mesh chose, deliberately, and the machine still
+works. A **failure** is different in kind: not *we chose* but *we could not*. Treating both the
+same makes a node where something the mesh needed never happened indistinguishable from one
+where a log level differed. Whether a failed line still lets adoption complete is therefore
+reopened by adding severity, and is not decided here.
+
 ## Open questions

 | Question | Why it is open |
@@ -155,6 +184,7 @@ here is the one that does not break the machine it is adopting.
 | ~~What happens when existing configuration contradicts what the mesh needs?~~ | **Answered** — the machine's configuration is kept, the conflict is flagged, and it is reconciled afterwards. |
 | ~~Do flags block, or only inform?~~ | **Answered** — they inform. Adoption always completes, and the node is a node. |
 | Can a module say which of its settings are load-bearing? | The question that dissolves the conflict rule rather than choosing a side. A setting the module *requires* cannot be kept from the machine without producing something installed and broken; a setting it merely *prefers* should always yield. Until a module can say which is which, adoption is defaulting in the dark. Belongs with the graph. |
+| Does a `failed` line still let adoption complete? | *Flags inform, they do not block* was decided about conflicts, where the mesh chose and the machine works. A failure is *we could not*, which is different in kind — and treating them alike hides the worse one behind the commoner one. |
 | How is a flagged conflict reconciled, and by whom? | The briefing hands it to a session. What that session is empowered to change, and whether the resolution is recorded so the next adoption does not re-raise it, is undecided. |
 | Where does the kept original live, and for how long? | Whether it is recorded in the node's state so adoption is visibly reversible, and whether it is returned when the mesh stops managing the thing. |
 | What shape is a briefing? | Structured enough to be acted on, prose enough to be read. It is the first thing a session on a new node sees, which makes it an interface rather than a log. |