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.
 

docs/INSTANCE_AWARE_DOCUMENTATION.md

@@ -68,3 +68,32 @@ should contribute conditional topics such as:
 
 The docs module remains the renderer. Feature modules own their subject matter
 and describe unlocks through manifest metadata.
+
+## Ownership And Disclosure Rules
+
+The ownership rule is the same for all documentation layers: the module or
+repository that owns the behavior owns the durable explanation. The docs module
+owns classification, filtering, search, route contribution, and rendering. It
+does not own feature-module business rules, policy semantics, or current issue
+state.
+
+Use these sources for these purposes:
+
+| Source | Purpose |
+| --- | --- |
+| Runtime docs providers | Effective, actor-aware explanation of the configured system. |
+| Repository docs | Durable architecture, module contracts, runbooks, and governance decisions. |
+| Synced Gitea wiki pages | Published copy of durable documentation for browsing and linking. |
+| Gitea issues | Active backlog state, acceptance criteria, blockers, and closure evidence. |
+
+Runtime docs may link to issues when an unavailable feature is planned or a
+known limitation is relevant, but the UI must label that link as active work.
+It must not treat open issues as shipped behavior.
+
+Safe disclosure is evaluated before a topic is returned. Missing permission,
+missing module, and missing capability explanations should be useful but
+minimal. User docs explain the blocker and who can resolve it. Admin docs can
+include route ids, scopes, capability names, configuration keys, and policy
+provenance only when the actor has permission to inspect those details. Secrets,
+tokens, private keys, credentials, raw policy payloads, and unrelated personal
+data are never returned as documentation content.