diff --git a/04-ISSUES/131-nothing-tells-the-mesh-a-source-moved/00-report.md b/04-ISSUES/131-nothing-tells-the-mesh-a-source-moved/00-report.md
index abd4182..f29ae06 100644
--- a/04-ISSUES/131-nothing-tells-the-mesh-a-source-moved/00-report.md
+++ b/04-ISSUES/131-nothing-tells-the-mesh-a-source-moved/00-report.md
@@ -52,6 +52,24 @@ the forge's business to know.
 
 The forge's module already declares the event. The build machine declares that it consumes nothing.
 
+## What the trigger cannot be
+
+**Not one build per changed module.** The modules form a graph: several are built from one
+repository, and some are the base another is compiled on — a runtime image, a compiler base, a
+repository whose context a second module builds from. Firing a build for each changed module
+independently would start work that cannot succeed yet and produce a failure per dependent, for one
+cause.
+
+Observed while catching the mesh up by hand on 2026-09-27: a compiler base had to move before
+anything compiled against it could build, and when it failed, the right behaviour was for its
+dependents to wait rather than each fail the same way. Fifteen modules shared the cause. A trigger
+that reports it fifteen times has buried it.
+
+So whatever reacts to the forge's event resolves what changed into an order, builds the bases first,
+and holds a dependent while its base is unbuilt or failed. That is a larger thing than "rebuild what
+the commit touched", and knowing it now is cheaper than discovering it from fifteen identical
+failures.
+
 ## Open questions
 
 - Is "the source moved" still a thing a person can assert by hand once the event path exists, or does