Operational policy decisions: precedence and unknown conditions

Last updated: 6 Oct 20265 min read

tutorial

Select the applicable policy revision and hold a decision when trigger, exception or rule precedence cannot be verified.

A parsed clause is not the active policy

An organization can retain old runbooks, draft amendments and current approved policies in the same search index. A correct extraction from an obsolete document can still produce the wrong decision. Select policies by trusted effective dates, approval state, scope and revision before evaluating their language. Store the selected rule ID with the result. Rule frames describe what each candidate says, not which candidate is authoritative.

Resolve scope and precedence explicitly

A service-specific rule may override a general one, but only if the policy owner says so. Do not assume that the newest retrieved paragraph wins. If two active rules disagree and no precedence record resolves them, hold the decision and show both sources. Exception scope needs the same discipline: an approved maintenance window for archive-east cannot exempt gateway-west. Entity linking can prevent similar service names from being conflated.

Use three-valued conditions

A trigger or exception can be true, false or unknown. Unknown maintenance approval cannot be treated as false merely because a log entry was absent. Likewise, an unknown degradation state cannot be treated as a definite trigger. Ask for trusted evidence with timestamp and source. The code below chooses a unique active policy revision; it stops before deciding whether a page is required. That later decision must consume verified condition states.

Measure decision failures

Test conflicting active revisions, backdated corrections, service-specific overrides, missing approval evidence and ambiguous exception scope. Report wrong-rule selection, false exemptions, false obligations and held cases. Human review should focus on cases with competing rules or unknown conditions. The notification project keeps the final action outside extracted prose.

Implementation

def select_active_rule(rules, service_id, event_time):
    eligible = [rule for rule in rules
                if rule["service_id"] == service_id
                and rule["approved"]
                and rule["effective_from"] <= event_time
                and (rule["effective_until"] is None
                     or event_time < rule["effective_until"])]
    if len(eligible) != 1:
        return {"state": "review", "candidate_ids":
                [rule["rule_id"] for rule in eligible]}
    return {"state": "selected", "rule_id": eligible[0]["rule_id"]}

rules = [{"rule_id": "policy-47", "service_id": "gateway-west",
          "approved": True, "effective_from": "2026-10-01T00:00:00Z",
          "effective_until": None}]
assert select_active_rule(rules, "gateway-west",
                          "2026-10-06T03:47:00Z")["rule_id"] == "policy-47"
assert select_active_rule(rules + rules, "gateway-west",
                          "2026-10-06T03:47:00Z")["state"] == "review"

Performance and operating cost

Scanning r rules takes O(r) time and O(k) output space for k eligible candidates. An indexed policy store can reduce selection cost. ISO timestamp strings compare lexically only when normalized to the same fixed UTC format; production must parse timestamps and handle version conflicts before relying on this selection.

Common Mistakes

Choosing the newest search hit rather than an approved active rule.
Treating unknown exception evidence as a negative answer.
Applying one service’s exemption to another.
Silently resolving two active conflicting policies by list order.