A rule in warn mode fires on every namespace apply, yet violations keep landing - who is reading the warning?

## Where a warning is addressed Warn mode has a delivery channel, and the channel decides everything about whether the mode works. When a policy evaluation on an admission request produces a warning, the request is **allowed** and the message travels back on the response to that request. In Kubernetes this is a `warnings` list on the admission response; the API server surfaces those to the caller as warning headers on the HTTP response. An interactive CLI prints them to the terminal. A client library hands them to whatever code asked for them - which, in most controllers, is nothing. So the warning is addressed to the *client that issued the call*. Not to the author of the change, not to the namespace owner, not to a team channel. To the caller. ## Why that matters in a real cluster Ask who actually calls the API in your environment. Very often it is not a person: - a **continuous-delivery job** applying rendered manifests, whose output is a build log read only when the build is red; - a **reconciliation controller** syncing a Git repository, which re-applies the same manifest every few minutes and would emit the same warning every few minutes; - an **operator** creating namespaces on behalf of a self-service request, several layers removed from the person who filled in the form. In all three cases the warning is technically delivered and practically invisible. The engineer who wrote the offending manifest was never on the other end of the call - they merged a change, and a machine applied it hours later. Worse, when a reconciler re-applies continuously, the warning count in the log stops meaning anything at all: it counts *reconciliations*, not violating namespaces. ## Emitted is not received The useful mental habit is to treat a warning as a message with a *recipient*, and to ask three questions before deploying a rule in warn mode: 1. **Who makes the request?** If it is a human at a terminal or a person watching a pipeline that fails loudly, warn can land. If it is an unattended reconciler, it cannot. 2. **Does that client surface warnings?** Interactive clients print them. Many client libraries drop them silently unless the caller opts in. 3. **Is the recipient the person who can fix it?** A platform engineer who runs the apply is not the team that owns the workload; a message they see is not a message the owner sees. If the answer to any of these is wrong, warn mode is producing the *feeling* of feedback without the feedback. That is a worse position than plain recording, because a report at least has a location that an owner can be pointed at, while a warning that has scrolled past in a build log is gone. ## What warn mode structurally cannot see Warn sits on the request path, so it only evaluates what passes through. Namespaces that already exist issue no requests. A rule that has warned on every apply for a month has said nothing whatsoever about the namespaces created before the rule was deployed, or about ones that simply have not been touched since. If you want a number for the standing population, you need an evaluation over current state, not over traffic. Confusing the two - reading "we get twelve warnings a week" as "we have twelve violations" - is the classic misread. ## Making warn actually land Without changing the rule's decision at all, the fixes are about the recipient: - **Move the evaluation to where a human is present.** The same decision applied at change-review time puts the message in front of the author, attached to the change that causes it, while they are still working on it. (Choosing the point at which a check runs is a design decision of its own, but the delivery consequence is the reason it exists.) - **Give the finding a durable home.** A message that persists somewhere addressable, with the offending namespace named, can be handed to an owner. A line in a rotated log cannot. - **Attribute the finding to an owner rather than to the caller.** The request identity tells you which service account applied the manifest; the resource's own ownership metadata tells you which team should hear about it. They are frequently different, and only the second is actionable. - **Decide whether the message is even wanted.** Some warnings are genuinely informational and nobody should be interrupted by them. That is a legitimate choice - just make it deliberately, rather than discovering it by finding that nothing ever changed. ## The interview point Strong answers reframe the question from "is the rule firing?" to "who receives what it emits, and can they act on it?". Weak answers assume that because the engine produced a message, the organisation received it.