Confirmation Gates

The examples and outputs below are independently authored teaching materials, not measured model results. No real alert system is operated.

Use case

Prepare a production alert for checkout-api: notify the payments-oncall group when the error rate exceeds 2% for five minutes. The system supports disabled rules and configuration previews. The user authorized preparation but has not authorized activation; activation may immediately notify the on-call group.

Mechanism

1. Record the service, threshold, duration, recipients and notification channel, and save a disabled rule.
2. Check configuration and preview results: the service and recipient group exist, the condition is correct, and preview sends no real notifications. Fix failures while keeping the rule disabled.
3. Present the exact rule and notification consequences, then check whether existing authorization already covers this rule and its activation.
4. Continue under valid existing authorization. Otherwise ask once for approval of this concrete activation. Rejection or no answer leaves the rule disabled.
5. After approval, activate and read the final state. Record which rule version was authorized and what actually happened. Report an unknown result as unknown.

Bad example

Both instructions prepare the same rule with the same service, threshold and recipients:

Create an alert for checkout-api: error rate above 2% for five minutes, notifying payments-oncall. Activate it first, then send me the rule to see whether it is appropriate.

This puts activation before review. Notifications may already have been sent when the user sees the rule.

Good example

Prepare an alert for checkout-api: error rate above 2% for five minutes, notifying payments-oncall.
Save it disabled. Check the target, threshold and recipient group using a preview that sends no real notifications.
Present its version, configuration and the possibility of immediate notification. Check whether existing authorization in this conversation covers activation of this rule.
Continue if valid authorization exists and configuration is unchanged. Otherwise ask: “Activate this rule and allow on-call notifications to payments-oncall?”
Keep it disabled if rejected or unanswered. After approval, activate and query the actual state; report unknown if the result cannot be confirmed.

Replace the service, threshold, duration, recipients and notification channel. Confirm that the system really supports validation without notification. An illustrative pending output is:

Rule: checkout-errors-v1
Condition: checkout-api error rate > 2% for five minutes
Recipients: payments-oncall
Validation: configuration checks passed; no notification sent
State: disabled, awaiting activation authorization

Why the change matters

Preparation, validation and presentation make a concrete operation reviewable. Authorization before activation gives rejection and silence a defined outcome: the rule remains disabled. Checking existing authorization avoids interrupting an already authorized operation repeatedly.

Observable expectation

Inspect configuration, state queries and operation records. Before authorization, the rule is disabled and no real notifications occur. The approval matches the configuration activated and predates activation. Exercise approval, rejection, no answer and valid existing authorization separately.

A changed configuration cannot automatically borrow approval for new targets or notification behavior. Failed queries, timeouts and missing records must produce an explicit uncertain state rather than “complete.”

Limits

Place the checkpoint before the operation that needs authorization, not before every routine preparation step. If creating a disabled rule itself incurs charges or external effects, check authorization for that action too. A preview is safe only if it actually avoids real notifications. Prompt instructions do not replace access control.