Account-level sensitive label returns three minutes after Support confirms the account and posts are clear

[taiseisouma0723-dot]

Summary

An account-level sensitive-content label has now been removed and reapplied four times. The interval between removal and reapplication has become progressively shorter, and every recurrence has required another Premium Support DM.

In an earlier recurrence, the account-level label returned approximately 12 hours after it had been removed.

In the latest recurrence, X Support explicitly confirmed that neither the account nor its posts were marked as sensitive. Approximately three minutes after that confirmation, the account-level sensitive label returned.

No new sensitive or adult content was posted during that interval. The relevant post was suitable for all ages.

This behavior is consistent with an automated reclassification process overwriting a newer Support-confirmed clear. However, the exact source of the reapplication cannot be determined without X’s internal label provenance and event logs.

This is not a request to stop labeling genuinely adult content. It is a bug report concerning non-durable appeal outcomes, delayed reclassification, and repeated account-level suppression of all-ages posts.

Observed behavior

1. Account-level and post-level sensitive labels are reviewed and cleared.
2. Support confirms that neither the account nor its posts are marked as sensitive.
3. The account-level label is later reapplied.
4. This removal-and-reapplication cycle has occurred four times.
5. The interval between removal and reapplication has become shorter:
   • approximately 12 hours after an earlier account-level clear;
   • approximately three minutes after the latest Support confirmation.
6. No new sensitive content was posted during the three-minute interval.
7. At least one affected post was text-only and contained no image or video.
8. Each recurrence generated another Premium Support contact and another internal handoff.

Expected behavior

A successful review should create a durable state change.

After Support confirms that an account and its posts are clear, the same label should not be recreated minutes later unless there is new, strong, content-specific evidence produced after the clear.

Stale, delayed, residual, or previously reviewed classification signals should not overwrite a newer Support decision.

Actual behavior

The current loop is:

review and clear → short interval → label reappears → new Support ticket

A Support-confirmed clear currently appears to have no durable effect if another classification event or account-level aggregation process runs afterward.

Relevant published code paths

The published code contains a post-to-user aggregation path that can calculate account-level labels after an applied post-label event:

• safetyLabelToUserLevelAggregationV2Forwarder.strato
• safetyLabelToUserLevelAggregationV2Processor.strato
• postToUserLabelRules.strato

The published visibility-filtering rules also show separate consequences for account-level and post-level NSFW states:

• author_rules.rs
• tweet_rules.rs

This incident does not prove which internal writer or classifier caused the reapplication. The following failure modes should nevertheless be investigated:

• a stale or delayed Applied event arriving after the Support-confirmed clear;
• an automated account-label writer overriding a newer review decision;
• previously cleared post-level labels continuing to contribute to account-level aggregation;
• a race condition between Support-side removal and automated reclassification;
• a cache or replicated account state restoring an outdated label;
• the absence of a durable appeal marker, version number, or tombstone preventing older evidence from recreating the label.

Why this is a product bug, not merely a policy disagreement

The issue is not whether genuinely adult content should be labeled.

The issue is that a completed review does not remain effective.

This causes two separate failures:

Creator-facing failure

All-ages posts may lose recommendation and discovery eligibility even after the account and posts have already been reviewed and judged clear.

Users cannot post with confidence when the account state may change again within minutes without new sensitive content.

Operational failure

Every reapplication creates:

• another complaint;
• another review request;
• another Premium Support conversation;
• another internal escalation;
• and another manual removal of the same restriction.

The system is repeatedly recreating Support work instead of resolving the underlying account state.

Requested behavior

• A Support-confirmed clear must remain effective unless new evidence is created after the clear.
• Events or classification results older than the clear must not recreate the same account label.
• Previously cleared post-level safety labels must be reconciled before account-level aggregation runs again.
• A new all-ages post must not automatically restore an account restriction solely because of residual historical state.
• Text-only posts must not receive adult-content treatment unless the text itself meets an appropriately high-precision threshold.
• Content warnings and recommendation exclusions should be evaluated separately where technically possible.
• If a label is reapplied after review, the system must record and expose the precise trigger: new media, text classification, user report, residual-count threshold, delayed event, or another source.

Suggested engineering direction

Make review outcomes versioned and durable

Store a review-clear timestamp or generation number. Any automated classification event created before that state must be rejected as stale.

Conceptually:

• support_clear && no_new_evidence → do not reapply
• event.created_at <= support_clear.created_at → ignore as stale
• new_high_confidence_evidence → allow a new reviewable label
• author_was_cleared && current_post_is_clean → preserve normal recommendation eligibility
• current_post_is_adult → retain existing adult-content restrictions

Reconcile contributing post labels

When an account-level label is cleared, identify and reconcile the post-level labels that contributed to it. Otherwise, the same residual evidence may immediately satisfy the aggregation rule again.

Preserve label provenance

Record which rule, model, post label, report, or event caused the account label to be recreated. Support cannot explain or correct the recurrence without this information.

Add a regression test

Test the following sequence:

1. An account receives an automated sensitive-content label.
2. Support reviews and clears the account and contributing posts.
3. No new sensitive content is posted.
4. A delayed or stale classification event arrives.
5. The cleared account must remain clear.

Reproduction and observed facts

• The account-level label has been removed and reapplied four times.
• Support confirmed that both the account and posts were clear.
• The account-level label returned approximately three minutes after that confirmation.
• An earlier account-level recurrence occurred approximately 12 hours after removal.
• No new sensitive content was posted during the three-minute interval.
• At least one affected post had no image or video.
• The recurrence generated another Premium Support follow-up.

Post URLs, timestamps, screenshots, and the Support conversation reference can be provided in a follow-up comment if required. Account credentials and private ticket contents are intentionally excluded from the public issue.

Scope

This issue concerns:

• durable review outcomes;
• delayed or stale reapplication;
• account-level labels suppressing clean posts;
• and repeated Support workload caused by the same restriction returning.

It does not request that X recommend unlabeled adult content to minors or to users who have opted out of sensitive media.