intermittent commit

docs/DOCUMENTATION_LAYER_CONCEPT.md

@@ -210,7 +210,50 @@ The UI should make the current context explicit enough to avoid confusion, but i
 
 ## Governance
 
-Durable context belongs in repository docs and synced wiki pages. Active work belongs in Gitea issues. Runtime documentation should link both where helpful, but it should distinguish stable explanation from changing backlog state.
+### Source Ownership
+
+Documentation ownership follows behavior ownership:
+
+- runtime documentation topics belong to the module that owns the route,
+  policy, workflow, capability, or data model being explained
+- repository docs belong to the repository that owns the implementation or
+  durable architecture decision
+- synced Gitea wiki pages are a publication surface for durable context, not a
+  separate source of truth
+- active Gitea issues are the source of truth for current work state,
+  acceptance criteria, blockers, and triage decisions
+
+The docs module renders and classifies documentation. It should not become the
+owner of feature-module explanations, and it should not copy backlog state into
+runtime documentation as if it were stable product behavior. When runtime docs
+link to an issue, they must present it as changing work state. When runtime docs
+link to repository docs or wiki pages, they may present the linked material as
+durable context if the owning repository treats it that way.
+
+Durable context belongs in repository docs and synced wiki pages. Active work
+belongs in Gitea issues. Runtime documentation should link both where helpful,
+but it should distinguish stable explanation from changing backlog state.
+
+### Privacy And Permission Boundaries
+
+Documentation is still a governed interface. Role-aware documentation must never
+use help text as a side channel for data, configuration, or capability details
+that the actor could not otherwise see.
+
+User-facing topics may explain that a feature is unavailable and identify the
+kind of blocker, such as missing permission, disabled module, locked policy, or
+administrator configuration. They should not expose internal module ids, raw
+scope names, policy payloads, hostnames, tenant identifiers, profile ids, or
+other operational details unless the actor is already allowed to inspect that
+information.
+
+Admin-facing topics may expose technical provenance, route ids, API paths,
+capabilities, configuration keys, policy source chains, and migration notes when
+the actor has the relevant administrative permission. Even then, runtime
+providers must summarize secrets and sensitive values as posture, counts, or
+source provenance. Credentials, tokens, private keys, raw payloads, and
+person-specific data stay out of documentation responses unless a dedicated
+audited administration route explicitly provides them.
 
 Documentation sources should be auditable when they affect compliance, operator procedure, or policy explanation. Configuration-derived documentation should identify the source configuration package or policy source where possible.