When approval adds bureaucracy — the scenarios where a gate is theatre

LVII-01 covered the cases where the gate catches a category of failure automated checks cannot. This lesson covers the inverse: a gate that adds latency without adding the human judgement that catches those failures. Ceremony is not free. The discipline is to recognise the ceremony and remove the rule, not to bypass it.

The four conditions that produce ceremony

A gate becomes ceremony when one or more of four conditions hold:

• Single rubber-stamp approver. One person on the list approves every deploy within seconds, never rejects.
• No information to decide. The approver has the deploy request but no production context - no dashboards, no view of the on-call rotation.
• Approval after the fact. The deploy has already run by the time the approver is notified. The approval records what already happened.
• Disconnected from the change. A security team approving a feature change, a manager approving a migration.

flowchart LR
    A["Gate exists"] --> B{"Information available?"}
    B -- "no" --> Z["Ceremony"]
    B -- "yes" --> C{"Approver qualified?"}
    C -- "no" --> Z
    C -- "yes" --> D{"Decision before apply?"}
    D -- "no" --> Z
    D -- "yes" --> E{"Multiple rejections over time?"}
    E -- "no" --> Z
    E -- "yes" --> F["Substantive gate"]

A gate that survives all four questions is substantive; a gate that fails any one is ceremony.

The cost of ceremony

Ceremony has a cost paid every deploy the gate touches:

• Latency. Seven minutes for a rubber-stamp approval is seven minutes of pipeline time for zero safety value.
• Bypass pressure. A gate that adds latency without value creates pressure to bypass it. Engineers start with I’ll approve in the morning; managers start with skip the gate for hotfixes. The bypass becomes normalised.
• Erosion of discipline. A gate that is routinely ignored teaches the team that gates are optional. The next substantive gate inherits the same disregard.

A gate ignored in January is bypassed in March and treated as an obstacle in June.

When to tighten versus when to remove

A gate fails in two distinct ways: the configuration is correct but humans do not honour it, or the configuration is wrong for the workload.

• Tighten. A gate rubber-stamped by a single approver can be tightened by expanding the pool, adding a wait timer, and requiring a comment on approval. Configuration was right; humans were not.
• Remove. A gate that adds latency to a workload with no meaningful risk - a documentation deploy, an internal tool - should be removed. The configuration was wrong.

The diagnostic for remove: zero rejections in a year, low-risk change type, good observability. The diagnostic for tighten: the gate occasionally catches bad deploys but is rubber-stamped the rest of the time.

Recognising theatre from the audit log

Three patterns to look for:

• Approval latency under ten seconds for every deploy. The approver is not reading the change.
• Same approver for every deploy. The pool is too small.
• Zero rejection comments. The approval is a click, not a decision.

A team that audits its gates quarterly catches the drift before it becomes a bypass culture.

Production discipline

1. A gate with zero rejections over a year is ceremony. Either tighten or delete.
2. Removing ceremony means deleting the rule, not bypassing it. The audit trail must show the gate is gone.
3. Audit the gate quarterly. Latency, rejection rate, approval comments.
4. Differentiate tighten from remove. Tighten when configuration was right but humans were not; remove when the gate was wrong for the workload.

Cross-course references

• This course, Part LVII-01 (When approval adds safety) covers the substantive side of the gate.
• This course, Part LVII-06 (Approval fatigue and bypass) covers the failure mode ceremony produces when left unaddressed.
• This course, Part LVII-03 (Protected environments) covers the platform-side configuration.

Quiz