如果一個產品能生成圖片、影片、音樂、語音與文字，那就必須能檢舉其中任何一樣。不是大部分。任何一樣。
按鈕在某些介面上是有的。這是另一回事，而這個差別很容易被忽略：內容篩檢是按每條管線手工接上的，所以有兩個工作室完全沒有篩檢就上線了，直到一次稽核去看才發現。同樣的形態會把這次修復也一口口吃掉，一次一個被遺忘的介面。
每一個介面，以及一項為此背書的檢查
現在，聊天回覆、圖片、影片、音樂、語音、語音轉文字、文字轉語音、翻譯、畫布產物、工作流程結果、助理泡泡與公開分享頁上都有檢舉入口——網頁端與應用端都是。
更重要的是，每次建置都會跑一項檢查。任何匯入了生成介面的檔案，必須繪製檢舉入口、委派給帶有它的元件，或者持有一條讀者可以核對理由的豁免。它第一次執行就報出了六處真實缺口。這項工作補上的正是那六處。
隨後，負責人開啟正在執行的應用程式，又找到五處檢查看不見的地方，因為它們躺在檢查從不開啟的目錄裡。這是問題裡更糟的那一半——一個從沒讀過某段程式碼卻在它旁邊回報「零」的守衛——也正因如此，檢查現在會寫明自己的掃描根目錄，並在其中任何一個不再解析時失敗。
一個佇列，以及就在這一列上的處理
分享頁上早就有檢舉入口，寫入的卻是一張沒人讀的表：沒有消費者、沒有佇列項目、沒有通知。那些檢舉現在也會開一個真正的案子，旁邊凍結著審核者需要的原文。
而處理動作在另一個頁面上的佇列，就是會被放著不管的佇列。隱藏內容或結案，現在都在這一列上完成，結果會寫回去，於是沒有什麼需要重新爭論。