feat: explain configured institutional architecture

docs/DOCUMENTATION_LAYER_CONCEPT.md

@@ -93,6 +93,25 @@ register durable topics directly in its `ModuleManifest.documentation` tuple.
 Use this for stable explanations such as the module purpose, common workflows,
 policy hierarchy, route meaning, and links to public docs or repository docs.
 
+Every manifest must retain at least one static topic for each of the `user` and
+`admin` projections. A shared topic may serve both only when its language and
+disclosure level are appropriate for both audiences. A module that is still a
+seed should state that limitation plainly rather than documenting an unfinished
+screen as available. `documentation_providers` enrich this baseline; they do
+not replace it because a provider may be unavailable before configuration or
+database access succeeds.
+
+Documentation is part of a behavior change's completion criteria. The owning
+module updates affected workflows, fields and settings, permissions, optional
+integration behavior, failure or limitation explanations, and operator
+consequences in the same change. The workspace manifest-shape check enforces
+the static audience baseline:
+
+```sh
+cd /mnt/DATA/git/govoplan
+./tools/checks/check-manifest-shapes.py
+```
+
 When the text depends on active configuration, a module registers a provider in
 `ModuleManifest.documentation_providers`. The provider receives a
 `DocumentationContext` with the active registry, principal, settings, and a