When a safeguard stops working

A required check that couldn’t run has not passed. The people responsible for a workflow need to preserve that distinction when it can release information, spend money or change a live service.

The principle is trying to prevent a particular failure: the system looks protected while the protection is unavailable. Its wording needs more care about what should stop.

The check timed out

Consider an illustrative document-sharing workflow. An assistant has prepared an export for an external collaborator. Before release, the workflow requires a check that restricted fields have been removed. The checking service is unavailable.

A dangerous implementation catches the timeout, writes a warning to a log and continues sending the export. The person receiving the completion notice sees a successful delivery. The distinction between “examined and passed” and “not examined” has disappeared at the point where it matters.

In the sound implementation, the export remains unreleased. The status names the missing check and shows what is needed to resolve it. People can still correct the document, investigate the outage or prepare unrelated work. None of those activities depends on this export having passed its release check.

The boundary is the action the safeguard protects. A failed release check doesn’t, by itself, justify stopping the existing service or preventing the team from investigating the failure. The instruction to “stop the work” is too broad for that job.

Continuing can be the designed response

Now imagine a public catalog whose freshness check stops responding. The team has chosen a fallback in advance: continue showing the last verified catalog, display its age and disable reservations until current availability can be checked. The fallback is limited to information the team has judged suitable for that use.

Taking the whole catalog offline would remove useful information without doing more to prevent an incorrect reservation. Continuing in the defined, read-only mode is the better choice in this example. That is a real exception to a literal instruction to stop all work whenever a safeguard cannot run.

A fallback has its own conditions. Someone needs to decide how old the catalog may become, which functions remain available and when the fallback itself must end. An agent inventing those terms after a failure is making a new risk decision. That requires the authority to make it.

Decide what the check means

Some checks are advisory. A spelling suggestion needn’t block a draft from reaching its editor. A required privacy check has a different job. Calling everything a safeguard, then stopping whenever any tool is unavailable, makes the workflow harder to operate without clarifying what it protects.

Define the distinction while designing the workflow. Don’t quietly reclassify a required check as optional because it is inconvenient today. If a check regularly blocks useful work, investigate its reliability, its scope and the available alternatives with the responsible owner. That may lead to a better design. It doesn’t turn an unperformed check into evidence of success.

Proposed wording

I would change this principle to make the protected action and the authority for exceptions explicit:

When a required safeguard cannot run, stop the action it protects and say why. Any fallback must be deliberately designed and authorized.

This is a proposed revision, not a change to the signed manifesto.

For any required check, write down the action it protects and what happens if it is unavailable. Include who can authorize a fallback and what evidence that person needs. Those decisions belong in the workflow before a failure puts pressure on someone to improvise them.