Repository navigation
Give creators clearer reasons for restrictions and keep post-level restrictions post-level #216
Description
Under the Hood already shows labels such as NSFW_HIGH_PRECISION, but the label alone often doesn’t tell creators what actually caused a restriction.
It would be useful to give creators a simple, high-level reason.
For example:
Label: NSFW_HIGH_PRECISION
Reason: Sexually suggestive pose
Affected media: Image 2
Restriction: Not recommended to non-followers
This doesn’t need to expose model thresholds, confidence scores, or internal classifier details.
It would also be useful to show whether a restriction came from the current post itself or from an account-level signal.
Keep post-level restrictions focused on the post
More generally, I think a restriction caused by one specific post should stay as focused on that post as possible.
This isn’t only about NSFW labels.
If a post receives a content-level label related to adult content, spam, sensitive content, or another policy, that specific post can have its recommendation eligibility reduced when appropriate.
But that shouldn’t automatically mean unrelated future posts from the same creator receive the same recommendation disadvantage.
For example:
Post A → receives a content-level label → Post A is restricted
should not automatically become:
Post A → receives a content-level label → account is broadly penalized → Posts B, C and D also receive less distribution
Otherwise, one false positive can have a much larger effect than the original classification decision.
Historical labels can still be useful as context for detecting repeated patterns, and genuinely account-level behavior such as platform manipulation, coordinated spam, ban evasion, or repeated abuse can still be handled at the account level.
The distinction I would like to see is simply:
Post-level problem → primarily post-level consequence
Account-level behavior → account-level consequence
This isn’t a request to change existing content policies or make moderation less strict.
The goal is to make restrictions more specific, understandable, and recoverable.
Creators should be able to understand:
what was restricted, why it was restricted, which part caused it, which recommendation surfaces are affected, and whether the restriction applies to the post or the account.
And whenever possible, a creator’s next compliant post should get a fresh chance to be evaluated on its own.
Activity
Adityakk9031 commentedon Sep 29, 2026
This is a fantastic and well-timed RFC. Looking directly at the codebase, your observation hits the exact architectural boundary between post classification and account distribution suppression.
Here is how the systems in this repository currently implement this cascade, where the transparency gaps exist in Under the Hood, and how the architecture could be evolved to keep post-level restrictions isolated:
1. Where Post-Level Labels Turn Into Account-Level Penalties
The mechanism you describe—where isolated post labels cascade into broad account penalties—is driven by
safety-label-user-agg/:Event Trigger & Sliding Window Aggregation:
NSFW_HIGH_PRECISIONorNSFW_HIGH_RECALLfrommedia-model-proxy,pnsfwmedia, orgrox),safetyLabelToUserLevelAggregationV2Processor.stratointercepts theTweetSafetyLabelEvent.safety-label-user-agg/postToUserLabelRules.strato. These rules scan the creator's recent post timeline within a configurable window (e.g.,windowSize,minimumMatchingPosts,maxPostAgeDays).POSSIBLY_NSFW_ACCOUNTorNSFW_HIGH_PRECISION—with a time-to-live (userLabelTtlDays) into the account metadata service (Gizmoduck).Downstream Pipeline Cascade:
Once applied at the account level,
home-mixer/candidate_hydrators/gizmoduck_hydrator.rshydrates these flags on every candidate post by that author:nsfw_author: Triggersauthor_rules::oon_nsfw_author_drops()in Visibility Filtering, dropping all out-of-network recommendations for any post from that creator to non-followers.nsfw_author_ads: Triggersads_brand_safety_vf_hydrator.rs, immediately escalating all posts by the author toHighRiskand disqualifying them from ad adjacency.nsfw_author_phoenix: Drops or heavily discounts candidate scoring in the Phoenix neural recommendation model (home-mixer/models/candidate.rs).home-mixer/filters/oon_nsfw_simclusters_filter.rsremoves the creator from collaborative filtering candidate generation.As you noted, a false positive on a single post (or a couple of edge-case posts) crosses the sliding-window threshold in
safety-label-user-aggand suppresses the distribution of subsequent, completely compliant posts.2. The Visibility Gap in "Under the Hood"
Looking at
under-the-hood/strato/lib/underTheHoodLabels.stratoandunder-the-hood/jetfuel/routes/report.tsx:safety-label-user-agg), model scoring (agatha/pnsfwmedia), or administrative review (NsfwAdmin).userLabelTtlDays).3. Concrete Architectural Recommendations
To address the points raised in this RFC:
Context-Rich Diagnostics in Under the Hood:
postLabelsinunderTheHoodReportto surface high-level reason categories (e.g.Media Visual Attribute,Text Language Flag,External Link) and affected media indices without revealing proprietary classifier weights or confidence scores.Decouple Post-Level Violations from Binary Account-Wide Drops:
oon_nsfw_author_drops()for automatically aggregated labels, shift towards graded candidate discounting inhome-mixer/scorers/.grox,media-model-proxy,clip) with high confidence, it should not be unconditionally dropped invisibility-filteringsimply because of an aggregated historical author label.Transparent Recovery Criteria:
Adityakk9031 commentedon Sep 29, 2026
I've submitted a pull request addressing this issue and RFC: #220