Immutable Public Rollback and Route Monitoring

1. Rollback switches a pointer; it does not rewrite a release

Editing the failed release until it resembles an older version destroys exact identity. In this lesson each release is immutable and rollback is a new event that changes the explicit active_release_pointer.

2. CON-010 ownership boundary

CON-010 owns the public rollback event and post-switch evidence. CON-006 owns locale routing, CON-007 workspace versioning, CON-008 forms, and CON-009 canonical/redirect policy. This lesson consumes their evidence without redefining them.

3. Separate release identity from deployment labels

Use an exact release_id plus release_manifest_digest. Labels such as “yesterday,” “last stable,” or a mutable directory name are not sufficient rollback authority.

4. Git is a mental model, not the MAKNOW implementation

Git names objects by object identity and uses named refs as pointers. That separation is a useful analogy for immutable snapshots and movable pointers, but a MAKNOW public release is not literally a Git commit or ref.

5. The rollback target must already be verified

Do not switch to a target whose digest, prior verification, or immutability is unknown. An old-looking release is not automatically safe; unsupported targets produce BLOCK_ROLLBACK.

6. Record authorization and an append-only pointer event

The rollback record must bind the incident, target release/digest, authorization, pointer before/after, pointer_event_id, and decision provenance. Do not overwrite pointer history; append a new event.

7. A successful switch only starts verification

“Deployment succeeded” or a changed pointer proves a control-plane action. Public recovery requires data-plane probes against the actual routes users and crawlers receive.

8. HTTP status is one dimension, not complete health

RFC 9110 defines HTTP status classes and redirect semantics. A route returning 200 can still serve bytes from the wrong release, so status must be evaluated with content identity.

9. Content digest verifies the active release

For critical routes, compare a release-bound digest or fingerprint with the live response. A 200 response whose content matches the failed release remains PARTIAL_RECOVERY.

10. Re-probe canonical and redirect behavior

Google Search Central recommends checking redirects, canonical annotations, and crawl/indexing behavior during site changes. A recovered page with a stale canonical or redirect is not full recovery.

11. Keep locale and form probes in scope

The main page may recover while a locale route or form endpoint remains unhealthy. Declare the required route set explicitly; anything not probed stays outside the confirmed claim.

12. Use typed recovery states

RECOVERY_CONFIRMED requires a verified immutable target, authorized append-only pointer event, correct active pointer, and every required probe passing inside the monitor window. Otherwise preserve PARTIAL_RECOVERY, ROLLBACK_FAILED, or BLOCK_ROLLBACK.

13. Negative case: correct pointer, wrong redirect

Suppose the pointer returns to R41, page status is 200 and the page digest is correct, but /old-pricing still redirects toward the failed release. Do not declare success; retain the exact REDIRECT_MISMATCH reason.

14. Transfer: pages recover, form and one redirect do not

In the second incident, page routes and canonicals recover but the form endpoint is unhealthy and one redirect still targets the failed release. Rebuild the evidence pack and keep PARTIAL_RECOVERY until both failures are cleared.

15. Auditable output

The Evidence Pack records Incident, Failed Release/Digest, Rollback Target/Digest, Pointer Before/After, Authorization/Event, Expected Route Set, status/content/canonical/redirect/locale/form probes, monitor window, recovery state, reason, and provenance. The strongest claim is bounded to that exact scope and evidence.