The Rule You Can't Flag Your Way Past

I built the override flag myself. Then a reviewer made me delete it.

The flag was small. One switch to skip a warning. It felt reasonable when I wrote it. It turned out to be the most dangerous line in the change.

This is a story about a boundary that should not have a way around it, and about learning that the safe version of a feature is sometimes the one where the switch does not exist.

Two commands over a real-estate ad account

I had built a pair of audience-targeting tools on top of our Google Ads control CLI, for accounts that run real-estate campaigns.

The first is read-only. It mines a client’s actual search terms and proposes a custom audience, grouped into seller intent, buyer intent, brand and competitor terms, and low-quality noise. Ten to fifteen terms a segment, picked by a plain deterministic heuristic, no model in the loop. It writes nothing. It just hands you a payload you could create.

The second one writes. It points a custom audience at ad delivery: an ad_group_criterion.custom_audience at minimum, a campaign_criterion.custom_audience where the campaign type supports one. Where the type does not support it, the command refuses out loud instead of failing quietly. It runs dry by default, shows you the before and after attachment sets, reads the criterion back live to prove it exists, and writes an audit row on every path.

Both of them live in a lane that is real estate, top to bottom. That detail matters more than it looks.

Warn, or refuse

Google runs a housing, employment, and credit ads policy. It restricts the audience targeting you can point at a housing campaign, custom audiences included. The policy exists so advertisers stay on the right side of fair-housing law, which bans discriminatory targeting. The law is the reason. The policy is the hard line, and on a housing campaign you do not get to cross it.

There are two ways to build for a line like that.

You can warn. Print a caution, note the risk, and let the operator proceed if they say so. Or you can refuse. Make the tool decline to do the thing at all, and route any real exception through a human.

I reached for warn first. It is the reasonable-sounding default. It is also wrong here, and it took a reviewer to show me why.

The flag I shipped

The read-only command shipped with a switch, --no-housing, that suppressed the housing caution. My reasoning at the time was ordinary, and I kind of still see the appeal: not every client advertises housing, so let the operator turn off a warning that does not apply to them.

That is the trap. A warning you can turn off is a warning that gets turned off. Probably by me, at six o’clock, on a deadline, when that --no-housing flag is the last thing between me and going home.

The reviewer that wouldn’t let me keep it

Every change I make goes through an automated review gate first: a second model reads the diff and argues with it before I can ship. On this one it came back with a blocker, on housing-law grounds, and it was right.

Its argument was concrete. There is no field anywhere in our client registry that could prove a client is not a housing advertiser. The client table has no vertical column, no industry column, nothing. And the whole lane is real estate by definition. So there is no safe condition to check. If you cannot prove the client is exempt, you cannot offer them the exemption.

So the switch came out completely. The option deleted, the housing field dropped from the parameters and from the builder, the caution on the read-only command made unconditional. That only fixes what you get warned about. The real guarantee is on the write side, and it goes further: attaching a custom audience to a campaign flagged as housing is refused outright, and the only way past that refusal is a documented policy review, not a flag. There is a test whose whole job is to prove the refusal holds with no override available.

Why a flag was the wrong shape

The lesson was not “add a stricter default.” It was that the flag should never have existed.

A default-off switch still assumes there is a safe case to switch it for. Here there was not, because nothing in the system could tell a housing client from any other. When you cannot prove the safe condition, you do not build a control that depends on it. You remove the control.

The rare legitimate exception does not disappear. It moves. Instead of a command-line argument that any tired operator can pass, it becomes a human policy review that someone has to actually do and write down. That is slower on purpose. Slower is correct when the cost of a wrong call is legal, not cosmetic.

This is the same instinct I keep coming back to with agents: a guardrail you can argue your way past is not a guardrail. I usually mean that about prompts. It turns out it is just as true about my own flags.

What it taught

The reviewer was right and I was wrong, and I am glad the disagreement happened before the code shipped instead of after.

The override was not a convenience. It was a liability with a default value. The safest version of that feature was the one where the switch was not there to flip. Some rules you do not get to flag your way past, and the honest thing to do is build the tool so you cannot try.