02 - Policy and promotion boundary

The promotion boundary is the public control pattern that sits between operator intent and agent execution. It is not a live deployment runbook. Its job is to make mutation reviewable, reversible, and tied to evidence before stronger claims are made.

Control objectives

• Dry-run first: mutation tools print what they would change before any apply path exists.
• Exact revision or artifact: the promoted thing is named precisely by commit, version, digest, or equivalent immutable identifier.
• Rollback target captured first: the previous known-good target is recorded before a change is applied.
• State re-derived: status tools re-read current state instead of trusting the last deployment note.
• Fail closed: missing policy, unknown tools, broken provider routing, or failed verification stops the claim from advancing.

Read the flow as approval before mutation and observation before success. A failed verification stops promotion and invokes the previously reviewed recovery decision; it must not produce a success receipt simply because the workload process started.

Public case-study usage

One reported implementation places operator-controlled policy above an operator-core VM, with logical realms grouping workloads and OpenShell sandboxes providing the intended execution boundary. Here “realm” is an operator grouping label, not an asserted OpenShell object. Ansible configuration as code is one choice for repeatable configuration and recovery workflows; neither tool is required by the framework, and configuration alone does not prove successful recovery.

The public docs intentionally avoid live hostnames, release paths, VM names, SSH aliases, key names, service names, and incident-specific recovery details.

Historical acceptance-design lessons

Retired host-side scripts illustrated default-review mutation, exact release identity, state re-derivation, and rollback targeting with fictional values. They are no longer runnable or maintained as a public lab. This history does not validate a private deployment.

Evidence expected before stronger claims

A promotion or policy-change receipt should name:

• the revision, version, digest, or policy identifier;
• the dry-run output reviewed before apply;
• the rollback target captured before apply;
• the post-change boundary checks;
• the non-claims and remaining pending boundaries.

Without that evidence, the public wording should stay at design or static-validation level.