Security and publication boundary

Governance and evidence records can expose customer identity, infrastructure, security posture, findings, residual risks, exceptions, or proof that assists an attacker. Public summaries and protected working evidence therefore have separate ownership, storage, access, review, and retention.

Public content

Public documentation may explain the product purpose, conceptual model, bounded lifecycle, claim limitations, and sanitized aggregate process. A public claim must have an approved authority and must remain within the authority's exact scope.

Protected content

Do not publish:

• customer identities, inventories, controls, findings, risks, delivery records, or acceptance evidence;
• original or private evidence and source-to-output mappings;
• internal repositories, knowledge-system locations, hostnames, addresses, topology, infrastructure details, credentials, or secrets;
• protected audit, incident, vulnerability, recovery, or exception records; or
• unapproved prices, service levels, technologies, roadmaps, commercial terms, certification claims, or effectiveness claims.

Protected records remain in the system authorized for their classification. Public documentation links only to approved public material and never requires runtime access to a protected source.

Safe review rule

Review the source name, content, metadata, links, assets, generated HTML, search index, sitemap, build artifacts, and change history. Uncertainty is private. Sanitization removes protected details but does not turn an unsupported claim into an approved one.

No production documentation URL is claimed before deployment. The approved route becomes publicly accepted only after exact-document approval, protected merge, deployment, and route-level production verification.