A policy rule you own blocks another team's deploy at 5pm: who answers, and what must the failure say?

## Two very different failures wearing the same shirt At 5pm a deploy fails on a policy gate. Two causes look identical from the pipeline log: **The engine is the incident.** It cannot be reached, evaluation errors, it times out, or it is denying on rules and teams that have nothing to do with each other. The tell is breadth and irreproducibility: many rule ids, many teams, results that change between runs. This is a platform on-call problem — the decision service is down, and the correct response is an incident response, not a policy discussion. **The rule is working.** One rule id, one resource, one property, and a rerun against the same document produces exactly the same verdict. Nothing is broken. The question is whether the rule *should* say that about this template, and that is a question about the requirement, not about the system — so it belongs to the team named as the rule's owner, who chose the threshold and can judge whether this case is a genuine miss. Getting this triage backwards is expensive in both directions. Treating a working rule as an outage means the on-call is pressured to make a call about a control they did not author. Treating a genuine outage as "the rule blocked you" means an engine failure sits unfixed while a developer edits a template that was never the problem. ## The failure message is the routing mechanism Here is the part candidates miss: **who gets woken is decided by what the output says**, not by an org chart. A blocked engineer at 5pm contacts whoever the message makes it possible to contact. If the output is "policy check failed: 3 denials, exit 1", the only visible party is the platform team who put the gate in the pipeline, and they become the de facto owner of every rule in the estate. Ownership files do not fix this; the message does. A denial should carry, for each finding: - **The rule identifier**, stable and searchable, so the conversation has a subject. - **The exact resource and property.** The logical resource name in the template and the field, not "a resource in this stack". - **What was found and what is required** — retention of 1 day, at least 7 required. The engineer should be able to fix a genuine violation without asking anyone. - **Why the requirement exists**, in one line. "Recovery objective for production data stores" tells a team whether their case is an exception or a mistake. - **The owning team.** A team handle, never a personal name — people move. - **Where the rule's source lives**, so a disagreement can be read rather than argued. - **How to propose a change**, because that is the legitimate route when the rule is wrong: a change to the rule repository carrying a fixture that reproduces this template, reviewed by the owner. That last item is what converts a 5pm argument into a normal engineering workflow. The blocked team's evidence — the exact template — is also the fixture the rule owner needs. ## What the owner owes in return Being named has obligations, or naming is theatre. The owning team should have a stated response window for questions about their rule, and it should be honest: if it is next business day, say so, because a team that expects an answer in ten minutes and waits until morning learns to route around the gate instead. The owner also owes the estate a fix loop: a confirmed false positive becomes a fixture and a rule change, not a note in a chat thread. The platform team, correspondingly, owes a runbook that says how to tell the two failure classes apart, and holds the line that they diagnose the engine rather than adjudicating rules. Their most valuable contribution during a 5pm block is often a single sentence: "the engine is healthy, this denial is reproducible, here is the owning team". ## Measuring whether the routing works Two signals tell you the truth. First, what fraction of blocked builds end in a message to the central security or platform channel rather than in contact with the owning team — if it is most of them, your output is not naming owners usefully. Second, what fraction of disputed denials end in a change to the rule repository. Rules that are never changed after complaints are either perfect or feared, and one of those is far more likely than the other. ## Anti-patterns worth naming in an interview - A generic "failed policy" message with the detail only in a dashboard the blocked engineer cannot reach. - Owner recorded as an individual who has since changed teams. - The on-call being expected to relax the rule to clear the page; that is a decision about a control, made under time pressure, by the person least placed to judge it. - No stated route to change the rule, so the only paths available are argument or avoidance.