Project: audit incident notification rules and exceptions

Last updated: 6 Oct 20265 min read

project

Build a review ledger for service-degradation notification rules, including effective revision, deadline and maintenance exceptions.

Construct the policy fixture

Create fictional approved and superseded policies for gateway-west, each with an effective interval. One rule requires on-call to page an owner within 47 minutes of verified degradation unless approved maintenance covers the same service and event time. Add an overlapping draft, an archive-east exception and an unknown maintenance approval. Annotate clause spans, rule IDs, actors, actions, deadlines and exception links. Rule extraction creates reviewable candidate frames.

Resolve authority before conditions

Filter by service, approval and effective interval. If multiple active rules survive, stop for policy-owner review. Bind the selected rule to verified observations of degradation and maintenance approval, each with source and timestamp. Never infer that an unmentioned approval is false. Precedence and unknown states prevent a plausible but unsupported notification decision.

Build a non-executing decision ledger

Record whether the trigger is true, false or unknown; whether the exception is true, false or unknown; and which rule revision was selected. The code below returns “page-required-for-review” only when trigger is verified true and exception verified false. It does not send a page. A separate trusted service must validate operator identity, deadline and current incident state before an external action.

Evaluate counterexamples

Report wrong-rule selections, false required pages, false exemptions, unresolved cases correctly held and deadline normalization errors. Test an event just before and after a policy boundary. Review cases where the same word “maintenance” appears without an approved window. Keep all source spans so a policy owner can correct the extraction and invalidate affected decisions.

Implementation

def notification_review_state(rule_id, trigger_state, exception_state):
    if not rule_id:
        return {"state": "hold", "reason": "rule-unresolved"}
    if trigger_state not in {"true", "false"}:
        return {"state": "hold", "reason": "trigger-unknown"}
    if trigger_state == "false":
        return {"state": "not-triggered", "rule_id": rule_id}
    if exception_state not in {"true", "false"}:
        return {"state": "hold", "reason": "exception-unknown"}
    if exception_state == "true":
        return {"state": "exempt-for-review", "rule_id": rule_id}
    return {"state": "page-required-for-review", "rule_id": rule_id}

assert notification_review_state("policy-47", "true", "false") == {
    "state": "page-required-for-review", "rule_id": "policy-47"}
assert notification_review_state("policy-47", "true", "unknown")["state"] ==     "hold"
assert notification_review_state("policy-47", "false", "unknown")["state"] ==     "not-triggered"

Performance and operating cost

The three-state gate takes O(1) time and space. Source retrieval, rule selection and evidence verification dominate system cost. Its output is a review classification only; external paging requires a separate authenticated workflow and a fresh check of the incident and policy state.

Common Mistakes

Paging because a policy sentence was found in search.
Assuming missing maintenance evidence means no exception.
Applying a draft rule to a current incident.
Sending an external notification from a parser’s output.