Route correlations through intelligence facade

docs/release-control/v6/internal/subsystems/agent-lifecycle.md

@@ -171,6 +171,9 @@ That same boundary now also assumes the Patrol-backed recent-changes API
 surface reads through the canonical intelligence facade first, so adjacent
 fleet and install surfaces do not bypass the shared unified timeline through
 the old detector-only handler path.
+The Patrol-backed correlation API surface must follow the same canonical
+intelligence-facade path, so fleet and install surfaces do not need to know
+about the detector directly when they render learned relationship context.
 That same canonical /api/auto-register response must stay on one completion
 truth: caller-supplied Proxmox credentials complete registration with a
 direct-use action, and the runtime no longer preserves a dead pending-secret

docs/release-control/v6/internal/subsystems/ai-runtime.md

@@ -161,6 +161,11 @@ The AI correlation root-cause engine also consumes the canonical unified-
 resource relationship model directly, so cross-resource reasoning stays aligned
 with the same graph edges that back the resource API instead of maintaining a
 parallel relationship vocabulary inside AI correlation.
+The Patrol-backed correlation endpoint, resource-intelligence payload, and
+seed prompt correlations now flow through the shared AI intelligence facade
+first, so the detector remains an implementation detail behind one canonical
+correlation access path instead of being routed directly by handlers or prompt
+builders.
 AI-facing policy metadata must also be cloned through the shared unified-
 resource policy helper so chat and tools consumers do not maintain their own
 policy copy logic. Chat mention prefetch now calls that shared helper directly

docs/release-control/v6/internal/subsystems/api-contracts.md

@@ -195,6 +195,10 @@ through the shared `frontend-modern/src/stores/aiIntelligence.ts` store for
 the Patrol intelligence page and the AI summary page, so the
 learned-correlation list is governed by the same API contract that backs the
 resource drawer's graph evidence instead of being fetched as page-local state.
+That correlations route now reads through the canonical AI intelligence
+facade first, so the handler and its payload keep the detector behind one
+shared access layer instead of routing directly to Patrol-local correlation
+state.
 That store now also owns the dashboard load bundle used by the Patrol page,
 so the page refresh path stays aligned on one store-owned orchestration layer
 instead of re-encoding the AI bundle inline.

docs/release-control/v6/internal/subsystems/patrol-intelligence.md

@@ -100,6 +100,11 @@ That graph section is now rendered by the shared
 `internal/unifiedresources.FormatResourceGraphContext` helper, so the Patrol
 runtime only resolves the canonical resource graph rather than formatting the
 relationship section itself.
+Patrol-owned correlation context now also comes through the shared AI
+intelligence facade before reaching the detector, so the learned correlation
+surface is routed through the same canonical AI ownership boundary as recent
+changes and resource graph data instead of being pulled from the detector
+directly in each caller.
 The Patrol seed context and AI runtime prompt path now also share the same
 correlation summary formatter from `internal/ai/correlation`, so learned-edge
 wording and confidence/count annotations stay canonical across the prompt

docs/release-control/v6/internal/subsystems/storage-recovery.md

@@ -113,6 +113,9 @@ That same shared dependency also assumes the Patrol-backed recent-changes
 API surface reads through the canonical intelligence facade first, so
 storage and recovery handlers do not bypass the shared unified timeline
 through the older detector-only path.
+The same shared boundary applies to the Patrol-backed correlation API
+surface, which must read through the canonical intelligence facade before it
+exposes learned relationship context to adjacent storage and recovery flows.
 The same shared API runtime also exposes unified-resource action, lifecycle,
 and export audit reads, but storage and recovery must continue to treat that
 as adjacent governed API ownership rather than timeline-store ownership. The