4 posts to the wrong audience: fixing brand safety drift in Mastodon syndication

19 active Mastodon instances. Two of them should never have been live.

occm.cc is a Korean language roleplay community. tkz.one is a Spanish language anime and otaku instance. Neither is anywhere near the generalist English tech and builder audience I am posting to. Both were enabled, both were live, and both had already received posts before I caught it. Four posts total, published to communities that almost certainly speak no English and have zero interest in tech builder content.

The failure was simple. My pipeline treats the enabled flag on disk as authoritative. Reconciliation asks: is this marked enabled? If yes, it posts. Brand safety vetting ran once at instance addition time and never again. So as the enabled list grew to 19 over time, there was no guarantee every entry still passed the gates. I just assumed the initial check held forever.

It does not. Communities drift, instance focus shifts, and some of those instances got enabled before I tightened the brand safety criteria. The criteria now require confirmed English language generalist communities or explicit safe list entries. occm and tkz were neither. They slipped in before that bar existed, or before it was enforced against the already enabled set.

The fix: a live recheck against every enabled instance using the Mastodon /api/v1/instance endpoint. Pull the actual current language tags and community description, run the same brand safety logic that runs at addition time, flag anything that fails. Both instances failed immediately on the language check. Both flipped to disabled. Tokens retained. LIVE count dropped from 19 to 17.

Then cleanup. Three posts on occm deleted via the API. One post on tkz was already hidden because the instance itself got suspended, so that resolved itself without me needing to act.

What I would do differently

Brand vetting should run on every pipeline tick, not just at instance addition time. The on disk enabled flag is a cache, not truth. Before any post goes out, verify the destination still passes the same criteria it passed when it was added. It costs an extra API call per instance per run, but it catches exactly this class of drift before it reaches real audiences.

The second thing: a unit test that mocks an instance with langs=['ko'] and confirms the vetting logic blocks it would have caught this before any post went anywhere. The vetting code existed. It just was not wired into the live posting path. That is not a logic bug, it is a test coverage gap, and test coverage gaps in pipeline code are what turn embarrassing mistakes into scaled embarrassing mistakes.

Automation multiplies your reach. It multiplies your mistakes just as readily. The guard has to run at the right point in the pipeline, not just once at setup.