diff --git a/01-RESEARCH/012-the-minimum-viable-node/00-overview.md b/01-RESEARCH/012-the-minimum-viable-node/00-overview.md
index 40da774..6b446d0 100644
--- a/01-RESEARCH/012-the-minimum-viable-node/00-overview.md
+++ b/01-RESEARCH/012-the-minimum-viable-node/00-overview.md
@@ -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. |