Operate Foundry

Operate against pinned bundles. Validate the site, inspect compatibility, review migration notes, and promote a Distribution manifest only after its consumer matrix passes.

Public operations cover portable release and upgrade behavior. Identity, permissions, private provider setup, customer evidence, and managed runbooks are restricted to the internal handbook and hosting layer.

For an owner decision, read the derived site status rather than comparing version numbers by eye: Current, Update available, Action required, Review required, or Unsupported. A supported LTS bundle remains current even when a newer standard stable bundle exists.

How to read documentation status

• Current documentation follows Distribution’s stable pointer and names the exact bundle, Core version, Distribution version, and last verification date.
• Preview documentation names the exact Core commit it is based on and is never described as an immutable release.
• Historical documentation is an immutable release snapshot, not an older page silently mixed with current source.
• Deprecated documentation remains readable and links to the replacement.
• Removed documentation becomes a concise migration stub so old links still explain what changed and where to go next.

Control is the managed operations layer

Use Core and Distribution for source checks, compatibility, release identity, and portable hosting. Use Control for the team-facing work around that source: permissions, review and approval records, isolated previews, publishing, provider credentials, and recovery. The boundary keeps an owner’s exit path real even when a team chooses managed operations.

Safety note: A green Control workflow is not a substitute for Core validation, an exact bundle identity, or release evidence. Keep both proofs visible when deciding whether a site is ready to publish.