02-DECISIONS/0042-approval-is-the-checkpoint.md

@@ -28,25 +28,24 @@ approval."*
    which is worse, because the record then claims a review that did not happen.
 2. **Drop the rule for agents.** Rejected: the rule is right, and the failure it prevents —
    work merged with nobody having looked — is not one an agent is less prone to.
-3. **Name what the checkpoint actually is.** Chosen.
+3. **Require notification and approval, and stop there.** Chosen. Who performs the merge is
+   not the thing worth constraining.
 
 ## Decision
 
-**The checkpoint is a person deciding, not a person clicking.**
+**Every merge into the main branch is notified and approved.** Stated by the operator in
+exactly those terms, and the whole of the rule.
 
-An agent may merge its own work **when a human has explicitly approved that merge**. The
+Notified: the merge is proposed and said out loud, not performed and mentioned. Approved: a
-approval is the review; the merge is bookkeeping that follows it.
+person says yes to *that merge*. Who then performs it does not matter, which is what makes an
+agent merging its own work unremarkable — the checkpoint already happened.
 
-Without an explicit approval, nothing changes: the agent does not merge, and
+**What approval is not**, because this is the half that can rot:
-[§2](../00-META/how-we-build.md)'s *never open a pull request unprompted* continues to mean
-that a permissions list is not a request.
-
-**What "explicit" excludes**, because this is the half that can rot:
 
 - A standing permission granted once and cited forever.
 - An instruction to do the work, read as approval to merge it.
 - Silence.
-- The agent's own judgement that the work is ready.
+- The author's own judgement that the work is ready.
 
 ## Consequences
 

02-DECISIONS/0043-a-declaration-is-an-ordered-list-of-owned-resources.md

@@ -85,6 +85,33 @@ A declaration names who it is for. A host that has an identity refuses one addre
 A host that has no identity yet — the first node, applying the bundle it carries — has nothing
 to check against and applies it.
 
+## Where the list comes from
+
+This record specifies what the host **accepts**. What produces a declaration is deliberately
+not settled here, and the reason is worth stating rather than leaving as an omission.
+
+**Today, and at stage 2: by hand.** `substrate.lock` is authored and pinned — a person writes
+the resources and writes the order. That is the first node's path, where there is no control
+plane to derive anything from.
+
+**Afterwards: the control plane derives it**, from three things it already holds — which
+modules are assigned to this node, what those modules' configuration resolves to, and what each
+module declares it needs.
+
+**And the order comes from the graph.** Each module expands to resources; the modules are
+ordered by their declared dependencies on one another. That is
+[research 011](../01-RESEARCH/011-the-module-graph/00-overview.md) — `requires`, `provides`,
+`excludes` — and a declaration is the graph's output, flattened for one node.
+
+So this record is complete on the consumer side and silent on the producer side, because the
+producer does not exist and its shape is what 011 is investigating. The consumer can be settled
+first because the host must refuse what it does not understand whoever wrote it.
+
+**What this means for ordering.** [ADR 0037](0037-the-host-applies-it-does-not-decide.md) puts
+the ordering decision in the control plane; 011 decides how the control plane makes it. If the
+graph turns out not to determine a total order, that is 011's problem to solve and not the
+host's — the host will still be handed a list, and will still apply it as given.
+
 ## Consequences
 
 - **Ordering is now a control-plane responsibility**, and getting it wrong is a class of bug