ADR 0035 (proposed): a picture is read from what runs

Drawing a scenario forced a choice that looks cosmetic and is not. A diagram
built from the declaration and captioned "as raised" answers "is what is running
what I asked for?" with the request, which always agrees with itself.

So: a picture captioned as raised reads only the running system, and where the
hypervisor does not hold a fact the picture needs, the raise records it on the
resource. With the rule that makes the recording worth anything — a behavioural
tag is written after the behaviour works, never at creation, because a failed
raise leaves wreckage standing and a picture of wreckage must not badge what the
wreckage was supposed to be.

It earned itself on the first comparison: every VM showed no addresses, because
a container's interface carries the device's name and a VM names its own. The
two pictures disagreed, so a whole class of machine silently losing its
addresses was visible in seconds.

§5 of how-we-build gains the general form, marked proposed. The constitution
sync is deliberately NOT done — a rule the mesh enforces before a second person
agreed to it is what §6 exists to prevent.

00-META/how-we-build.md

@@ -172,6 +172,32 @@ quietly stop being true, and nobody will learn that from a document.
 Not test-driven development as a blanket rule — a test written first against undiscovered
 behaviour asserts a guess. The obligation is that every decision has a defender.
 
+### A report is read from the system, never from what asked for it
+
+*Proposed — [ADR 0035](../02-DECISIONS/0035-a-picture-is-read-from-what-runs.md), pending
+review.*
+
+The same rule as the two above, pointed at reporting rather than at verification. **Anything
+that describes the state of the mesh — a status view, an inventory, a diagram, a health
+check — is assembled from the running system.** Assembling it from the intended state produces
+a report that always agrees with itself and can never disagree with reality, which is not a
+report.
+
+Where the system does not natively hold a fact the report needs, **the thing that applied the
+fact records it** — and:
+
+> **A record of behaviour is written after the behaviour works, never when the resource is
+> created.**
+
+Written up front it restates the request in a new place and inherits none of the authority of
+having happened. A failed run leaves its wreckage standing, and a report of that wreckage must
+not describe what the wreckage was supposed to be.
+
+This is the production form of the mesh's most expensive fault: a firewall key declared in five
+manifests and read by no code
+([04-ISSUES/003](../04-ISSUES/003-firewall-scope-is-read-by-no-code/00-report.md)). The
+declaration was never wrong. Nothing ever asked the system.
+
 ### Search the record before forming a hypothesis
 
 The first action on any error message, failing service or unexpected behaviour is to search the