Under the Hood does not carry label-source provenance into the report, contrary to README:411

[repowazdogz-droid]

README:411 lists as a benefit of Under the Hood:

one can see whether labels have been manually applied outside of automated systems

I could not find a path in the released code that carries per-event label source into the report.

Source is structured where the label is read. visibility-filtering-client/tweet_safety_label.rs:197-209 maps safety_label_source into three distinct variants: BotmakerAction (carrying rule_id), ToolAction (carrying agent_tool and actor_ldap), and GrokAnnotationAction (carrying source). xai_x_thrift is not published, so I am not claiming what each variant denotes. The point is only that a per-event source discriminator exists and is structurally distinct at this layer.

It is not carried through the Under the Hood path.

• under-the-hood/scalding/UthDailyPostsJob.scala:263 retains event.labelType.originalName. The event body is read at :266 and :269 for createdAtMsec and expiresAtMsec only.
• under-the-hood/thrift/uth_serving.thrift:53-61: UthPostLabelAggregate and UthAccountLabelAggregate hold a label name and day counts. There is no source field to populate.
• under-the-hood/strato/columns/underTheHoodReport.User.strato:194-199 and :210-215 emit label, about, effect, and counts.
• under-the-hood/strato/graphql/under_the_hood.thrift:9-13: the response is generatedAt, reportJson, reportInfo.

The static about text does not stand in for it. Those strings are per-label-type constants, and seven of them state the disjunction rather than resolving it. underTheHoodLabels.strato:12 reads "Post detected by automated systems or in response to a user report", with the same construction at :30, :40, :61, :77, :95, and :120.

Two resolutions look legitimate to me:

1. Carry a coarse category derived from the variant, for example automated, manual, or LLM, without exposing rule_id or actor_ldap.
2. Amend README:411 to describe what the report contains.

I searched the tracker for manually applied, actor_ldap, ToolAction, BotmakerAction, GrokAnnotation, label source, and source provenance, with no matches. #11 edits two of these files and its description notes it avoids inventing source metadata absent from the aggregate. If you consider that the same target, say so and I will fold this in rather than track it separately.

Audited at a389166f6cf5da70a286b568c87695d4dcdce3a1. This is a static reading of the checked-in types and job code. under-the-hood/ and visibility-filtering-client/ ship no build target, so I have not executed anything.

[kiri234-code]

I can provide a real-world example confirming the practical impact of this issue.

My July 2026 Under the Hood report for @kiriko_ap shows:

• 73 total posts
• 1 post labeled NSFW_HIGH_PRECISION
• No account-level labels

However, the affected post was manually given a one-time content warning by me, the author, before it was published. It was not an unlabeled post that I know to have been detected by an automated system or reported by another user.

Under the Hood nevertheless describes NSFW_HIGH_PRECISION as content identified “by automated systems or in response to a user report.” That description does not represent the known author-applied labeling path.

The current report therefore makes at least two materially different possibilities indistinguishable:

1. The author responsibly applied a content warning before publishing.
2. X independently detected or received reports about content that had not been appropriately labeled.

This distinction also matters for account-level aggregation. If author-labeled posts are stored under the same NSFW_HIGH_PRECISION label and the aggregation logic evaluates only the label type, appropriately self-labeled posts may appear to count toward account-level visibility restrictions in the same way as unlabeled violations.

Could the team please clarify:

• whether an author-applied content warning itself produces NSFW_HIGH_PRECISION;
• whether author-labeled posts count toward account-level NSFW aggregation;
• and whether the report can preserve a coarse source category such as AUTHOR_APPLIED, AUTOMATED, USER_REPORT, or MANUAL_REVIEW?

At minimum, the static explanation should not attribute an author-applied label exclusively to automation or user reports.