Under pull-based delivery, a merged manifest is denied by cluster policy - where does that denial surface, and who sees it?

## The failure has a distinctive shape A change merges. Every check is green. The pull request closes. Then nothing happens, or something halfway happens, and hours later someone in a different team notices a red condition on a dashboard and starts asking whose change this was. That is the signature of a policy denial in a pull-based pipeline, and it is worth being able to describe precisely, because the diagnosis is entirely about *where signals live*. ## Where the denial actually appears The reconciler attempted a write to the API server. That write was refused, and the refusal came back to the caller. The caller is the agent, so the agent is where the information now lives, in three places: - **A sync or apply failure condition** on whatever unit the agent tracks (an application, a set, a namespace bundle), usually carrying the rejection text verbatim. - **A health status** that stops being healthy, because part of the desired state is not present. - **The agent logs**, which have the full detail and the timestamps. All three belong to the delivery system. None of them belong to the change. ## Why nothing reaches the author Three separate reasons stack up, and naming all three is what separates a good answer from a partial one. 1. **Time.** The pull request closed before the write was attempted. The reconciler picks the commit up on its own schedule, so by the time the API server refuses anything, the change is history. 2. **Direction.** The signal flows from the API server back to the agent. There is no channel from the agent to the forge unless someone built one. 3. **Correlation.** The failing unit is keyed to an application or a namespace, not to a commit author. Even if you did push a notification, something has to map the failing unit back to the commit and the commit back to a person. That mapping does not exist by default. ## Who is first to know, and why that is a problem The platform team, because they own the reconciler and its alerts. So the first responder to a violation is someone who did not write it, cannot judge whether the workload really needs those limits, and has no context on the change. They become a routing layer: read the condition, find the commit, find the author, ping them. That human relay is the real cost of the broken loop, and it scales badly across many teams. ## Rolling back is a commit, not a button One more consequence that catches people out. The merge succeeded, so the branch still describes the non-compliant state. Nothing about the denial undoes that. Until a corrective commit lands, the desired state and the live state disagree, and the cluster may sit in a partly-applied condition where some objects from the change went in and one did not. The way back is another change through the same path, which is a slower rollback than a pipeline that simply failed before applying anything. ## What to fix, in order of value **Invest in the denial message first.** It is the only text that travels with the failure to whoever reads it hours later, and that reader is almost never the person who wrote the rule. A message that names the rule, the offending field, the object, and the concrete fix turns a red condition into a self-service correction. A message that says the request was rejected by policy turns it into a support ticket. **Then build the correlation.** Route the agent failure events into the owning team channel, keyed by the path or namespace that team owns, so the platform team is not a pager relay. Carrying the commit in the event makes the mapping from failure to author mechanical. **Then reduce the volume that gets this far.** Keep the pre-merge check running so most violations are caught while the author is still holding the change, and reserve the late path for the residue that only the cluster can decide. ## The claims that are wrong That the failed apply turns the pull request red: nothing writes back to a closed change. That the denial rolls back the merge: the branch is untouched. That the author is alerted by default: nothing correlates the failing unit to a person. And that the change was never merged because it never deployed: merging and applying are separate events, and only the second one failed.