Skip to content

There is no break-glass force-publish of a validation-failed state


There is no break-glass force-publish of a validation-failed state

Section titled “There is no break-glass force-publish of a validation-failed state”

Date: 2026-08-18 Status: open Supersedes: none Superseded-by: none — current Upholds: MR-10

The admin surface needs a failure policy, and the obvious ask is an operator override that publishes a state document which failed validation.

a4_validate.js already states the estate’s position in its own header: ‘A failed validation aborts the run. An unvalidated bundle must never reach the Project pane: a plausible-looking bundle that is 40% fiction is worse than no bundle at all.’

The operational pressure a break-glass would relieve is real: an operator wants the tenant’s HUD to keep working during an incident.

No break-glass. No force-publish path exists.

Extending a break-glass to state.v1 would contradict, in the most-consumed artefact, a rule already enforced on the least-consumed ones. And a break-glass exists precisely for the moment when someone is under pressure and the artefact looks nearly right — the worst possible moment to relax an integrity check.

The operational need is met three other ways, so this is a refusal with a replacement rather than a bare refusal:

  1. Quarantine publishing keeps a failing tenant’s surface alive and truthful: derived content unchanged from last-good, a health block naming the reason, and generated_at LEFT AT the last-good value so the HUD’s staleness arithmetic keeps working and STALE mode fires on real age.
  2. Narrowing, not overriding. If one artefact fails V3 on one bad ref=, the lever is to fix the source or exclude the failing repo via tenants.yaml — a versioned, reviewable change producing a CORRECT derivation over a smaller set. a4_validate.js already has the vocabulary: omitted[] with a stated reason (‘Omitted rather than half-filled — an inferred service inventory drifts fastest’). Partial-but-validated is not break-glass; it is the omission register applied to a new artefact.
  3. Every failed run is recorded verbatim in the failures view, so nothing is lost by not publishing.

Force-publish with validation: FAILED recorded in the provenance block

Section titled “Force-publish with validation: FAILED recorded in the provenance block”

Rejected: The alternative that sounds most reasonable and is most dangerous. The marker lives in the document, the renderer is downstream, the HUD spec has no rule for it, and every incentive at that moment is to render the action and not the marking. INSTRUCTIONS.md already warns that such a HUD looks identical to a real one.

Per-check, time-boxed waivers recorded as a decision doc

Section titled “Per-check, time-boxed waivers recorded as a decision doc”

Rejected: The closest call. It is versioned, time-boxed and check-specific, which answers most objections. It loses because V1-V4 are all integrity checks — well-formedness, provenance, cross-reference, hallucination — with no legitimate waiver case: a bundle failing V4 names a repo that does not exist. Real reopening condition: if V5-V7 ship and one develops a legitimate false-positive class, revisit waivers for that check alone.

Rejected: Leaves the last-good document served indefinitely, ageing quietly with no explanation — the exact worst outcome the failure policy targets.

  • docs/panto/a4_validate.js
  • panto-cloud/INSTRUCTIONS.md

Human merge required — this PR is opened with the awaiting-human-merge label and does not auto-merge.