feedback_source_verified_security_pages

---

name: feedback-source-verified-security-pages description: for security/isolation/architecture wiki pages that feed the RAG assistant, verify every claim against infra-osaas/osaas-deploy-manager/osaas-lib-orchestrator source with file:line citations, and hold the page unpushed for security review metadata: type: feedback

When a wiki page makes claims about the platform's security posture, network isolation, or resource isolation between tenants (not a how-to-use-a-service page, but an architecture/trust-boundary page), the ground rule is: every factual claim must cite a specific file and line in infra-osaas, osaas-deploy-manager, or osaas-lib-orchestrator (or whichever repo is authoritative for the claim), or be marked **TBD, unverified** inline. Do not extrapolate absence-of-evidence into a security conclusion in either direction, for example "no NetworkPolicy exists" must not become "therefore no isolation exists" without also checking (and reporting on, even if inconclusive) the CNI/cluster-provider layer, which usually is NOT configured inside these repos and has to be flagged TBD.

Why: Eyevinn/osaas-ai#1543 asked for a networking/isolation page for the RAG index that the AI assistant quotes to prospective customers evaluating OSC's security posture. An invented or overclaimed isolation fact here is materially worse than a normal doc error, it's a trust/compliance claim that gets repeated by the assistant. The task explicitly required holding the page unpushed pending human security review of the isolation findings before it goes live or gets wired into instructions.ts.

How to apply: For this class of page: (1) grep the actual repos for the claim before writing the sentence, never write from platform "general Kubernetes" assumptions; (2) cite file:line inline in the page itself, not just in your own scratch notes, so a future reader can re-verify without re-doing the research; (3) explicitly separate "OSC's own K8s objects don't implement X" from "X definitely doesn't happen" when the missing piece (CNI config, managed-cluster network policy) lives outside the repos you have access to; (4) do not push or wire the page into instructions.ts until told the review is cleared, per reference_changelog_pages pattern of holding things back when explicitly asked.

Key finding worth remembering for next time this page is revisited: osaas-lib-orchestrator uses one Kubernetes namespace per service, shared by every tenant of that service, never torn down (src/instance_service/k8s.ts:1414, an explicit code comment). No NetworkPolicy object exists anywhere in infra-osaas. No CPU/memory resources.limits are set on the main service/My-App container. See ~/Code/eyevinnosc/community.wiki/OSC-Platform-Networking-and-Isolation-Model.md (committed locally as of 2026-08-27, not yet pushed) for the full sourced writeup.