We Had Written the Rule Only for Marketing
The rule about player photos lived in the marketing brief. Meanwhile the product was serving those same photos to every visitor on a public domain.
DUGOUT 9 is a companion web app for watching KBO games — Korea's professional baseball league. It is not an official service; it is the public demo of an independent fan project, and that is the product's current definition rather than a disclaimer. Which means how far it may use somebody else's assets is a permanently open question.
Player photographs are the sharpest version of that question. A photo is simultaneously a work owned by the league or the club and the likeness of the player himself, which makes it a different kind of asset from a statistic or an emblem. So the marketing brief drew a ceiling: do not use captures containing player photos in any content. The rule was clear, and it was being followed.
The rule existed, and the unruled side was bigger
The problem was the product.
At that same moment, the product was pulling player photos straight from the league's image CDN in every game room, on a public domain, and showing them to every visitor. While we were carefully avoiding one photograph in a marketing post, the product was serving the same photographs continuously, to far more people.
The scale of what we were blocking and what we were leaking ran in opposite directions. Marketing posts go out a few times a month and a person hand-picks each image. The product goes out per visitor, per game, automatically. We believed we were managing the risk. We were managing the convenient half of it.
The default was flipped to off
Player photos now sit behind an environment variable, and the default is off. With the flag off, the interface falls back to initials. Only with it on does the app reference the league's official image CDN.
This was not a new idea in the codebase. Matchup data and historical-record providers were already gated the same way. The product already had a pattern — assets whose rights are unsettled live behind a switch — and player photos were simply the one thing still outside it. The most sensitive asset was the last to arrive.
Where the default sits is the entire decision. Build the switch and leave it defaulted on, and nothing has changed. The default is the actual behaviour; everything else is documentation.
A plainer screen is not a cost, it is a status indicator
Without photos the screen is emptier. A circle with initials is not as good-looking as a face.
You could read that as a price paid. I read it as closer to an honest status indicator. This product is a public demo whose rights review is not finished. When the screen looks unlike that fact, both the visitor and the person building it forget the real state. A demo that looks like a finished service only adds pressure you then apply to yourself.
Once the permitted scope is confirmed, the switch gets turned on. The screen improves at that point, and the improvement arrives attached to the fact that the rights were settled. That is a better order.
Put the rule where the leak is
What is worth keeping from this is not about photographs. It is about where a rule gets attached.
Rules gravitate to the places that are easy to write in — a marketing brief, a contributing guide, a review checklist. Documents that people read and people uphold. Those places make a rule easy to state and easy to audit, so that is where rules collect.
The place with the largest exposure, meanwhile, is usually the product itself. It runs automatically, continuously, once per visitor. And it contains no document a person reads. It contains code.
So when setting a risk rule, the first thing to check is whether the rule actually covers the point that leaks most. That point is generally not the promotional channel but the product — and there, a rule has to exist as a default value rather than as a sentence.