2026-09-30

Other changes reviewed today:

• In the weight mirror of X's home-mixer (the service that assembles the For You feed), the click weight went down and the post-click dwell weight was turned on.
• VF, X's impression verdict service, added Tweetypie, the tweet storage and lookup service, to the targets it compares its own verdicts against in staging.
• An anonymous e-commerce search team released PEAR, an automated research framework that splits verification into four layers, and it was added to the radar.

1The overturn-hold server was released as a read-only lookup service — X

• The server is a read-only lookup service built with axum and PostgreSQL verified.

  • The service name is abuse-ledger-service, and the Cargo name is xai-abuse-ledger-service.

  • It consists of 11 files (api.rs, boot.rs, codes.rs, config.rs, lib.rs, main.rs, metrics.rs, pg.rs, repo.rs, sql.rs, tls.rs) with 2,282 lines in total.

  • The only lookup path in the server API is the /v1/holds/lookup endpoint that the client in the 2026-09-26 commit called.

  • The path, header names, and limits are fixed as constants.

    "pub const LOOKUP_PATH: &str = "/v1/holds/lookup"; pub const DEADLINE_HEADER: &str = "x-request-deadline-ms"; pub const MAX_USER_IDS: usize = 100; pub const MAX_LABELS: usize = 32;" — abuse-ledger-service/src/api.rs, 2026-09-29

  • The request schema is {user_ids: Vec<i64>, labels: Vec<String>}, and the response is {holds: Vec<Hold>, db_ms: u64}.

  • One call can look up at most 100 user_ids and at most 32 labels.

  • The caller specifies the remaining budget with the x-request-deadline-ms header.

  • If this value is smaller than the statement timeout, the server uses it as the actual DB budget; if it is larger, the server uses the statement timeout plus QUERY_DEADLINE_SLACK = 100ms (api::budget).

• The server runs only three SQL statements verified — abuse-ledger-service/src/sql.rs.

  • The table schema being queried is ledger.enforcement_holds.

  • The lookup SQL is below.

    "SELECT user_id, hold_id, head, expires_at, case_group_id, reason, action_kind, label FROM ledger.enforcement_holds WHERE user_id = ANY($1::bigint[]) AND cleared_at IS NULL AND expires_at > now() AND (action_kind = 'suspend' OR (action_kind = 'label' AND label = ANY($2::text[])))" — abuse-ledger-service/src/sql.rs, 2026-09-29

  • This SQL returns only rows that satisfy all three of the following conditions.

    • The hold is still live (cleared_at IS NULL).
    • It has not expired (expires_at > now()).
    • Either action_kind='suspend', or action_kind='label' AND label ∈ the requested label set.

  • Only two values (suspend, label) are defined for action_kind.

  • cleared_at is a tombstone filled in when a human reviewer withdraws a hold.

  • At startup there is a CONTRACT_SQL that uses SELECT ... LIMIT 0 to check that the column projection matches the schema.

  • The health check is only SELECT 1 (PING_SQL).

  • The tests in sql.rs assert that none of the three SQL strings contains INSERT/UPDATE/DELETE/ALTER/DROP/CREATE. In principle, the server cannot write.

• The PostgreSQL client uses deadpool-postgres and TLS uses rustls verified — abuse-ledger-service/src/pg.rs.

  • The constants are POOL_WAIT_TIMEOUT = 1s, POOL_CREATE_TIMEOUT = 1.5s, POOL_RECYCLE_TIMEOUT = 500ms, and QUERY_DEADLINE_SLACK = 100ms.
  • PgError has 7 variants: BadDsn / Connect{Refused|Auth|Tls|Timeout|Other} / Saturated / Transport / Query{sqlstate, message} / Decode / Timeout.
  • Only SQLSTATE 57014 (query_canceled) is classified as ErrorCode::StatementTimeout. 28P01/28000 (auth) is classified separately as ErrorCode::AuthFailed.
  • At boot, boot::contract_check_until_ok starts AtomicBool<ready> at false and keeps /readyz at a non-200 status until the schema check succeeds.

• The actual shape of the hold record the server returns (Hold) was released verified — abuse-ledger-service/src/repo.rs.

  "pub struct Hold { pub user_id: i64, pub hold_id: i64, pub action_kind: String, pub label: Option<String>, pub head: Option<String>, pub expires_at: DateTime<Utc>, pub case_group_id: Option<i32>, pub reason: String, }" — abuse-ledger-service/src/repo.rs, 2026-09-29

  • head is a field that already appeared as the client-side diagnostic key (overturn_hold_head) in the 2026-09-26 commit, and it is now confirmed as Option<String> in the server schema.
  • Its content is still not public. It appears to be roughly the identifier of the review tool that issued the hold inferred.
  • case_group_id: Option<i32> is a group key that ties an appeal case to multiple holds.
  • reason: String is a reason string left by the human reviewer. We confirmed that the field exists, but its content format is not public.

• The TLS module is a separate 348-line file verified — abuse-ledger-service/src/tls.rs.

  • This is the code that uses rustls for the PostgreSQL connection. It parses sslmode=require|verify-ca|verify-full from the DSN and reads the CA/CRT/KEY paths from separate environment variables.
  • That is, the ledger store is accessed over mTLS, and this service sits in the role of a read-only proxy for that store.

visibility-filtering (VF) is the service that decides, for each post, "may this be shown to this viewer." VF has long had a "reference comparison" mechanism (Gen4+7, 2026-08-24), and this time a second comparison target was added on top of it. The only existing target was the Scala VF service. The newly added reference/tweetypie.rs (714 lines, introduced) calls Scala Tweetypie directly. Tweetypie is X's tweet body storage and lookup service, and its responses already contain a tweet-level visibility decision. This decision is diffed against the verdict of the Rust VF itself.

• The value that selects the reference comparison target grew from the single Scala VF service to two, adding Tweetypie verified — visibility-filtering/reference/mod.rs.

  • The value expanded from vf_service to the two values vf_service | tweetypie.

    "pub enum Reference { None, VfService, Tweetypie, } ... (_, Some("prod")) => Err(format!( "{ENV_REFERENCE} selects {reference:?} but {ENV_APP_ENV}=prod; reference comparisons are staging-only" ))," — visibility-filtering/reference/mod.rs, 2026-09-29

  • The Rust VF ↔ Scala VF comparison, which had been switched on with the dual_call_harness environment variable since the 2026-08-24 commit (Gen4+7), was moved to the VF_REFERENCE environment variable in this overhaul.

  • The new variable takes one of three values (none / vf_service / tweetypie).

  • If the old ENV_DUAL_CALL_HARNESS_ENABLED flag remains, startup fails with an error telling the operator to use the new name (migration).

  • With any value, startup is refused under APP_ENV=prod.

• The Tweetypie path calls one column of Strato (the X-internal system that code goes through to read or store data) verified — visibility-filtering/reference/tweetypie.rs.

  • The column is tweetypie/getTweetFields.Tweet.
  • The call carries GetTweetFieldsOptions { visibility_policy: VISIBILITY_POLICY_USER_VISIBLE, ... } to this column. Tweetypie then returns the response with the VF decision (Action::Allow | Drop(reason)) already attached.
  • The constants are as follows.
    • TWEETYPIE_MAX_BATCH_SIZE = 250: batches up to 250 tweets at a time
    • MAX_IN_FLIGHT = 32: fan-out cap enforced with a semaphore
    • TWEETYPIE_TIMEOUT = 1500ms
    • SAFETY_LEVEL = SafetyLevel::TimelineHomeHydration: the verdict level requested from Tweetypie
    • RECORD_CAP_PER_MINUTE = 20: cap on sample logs, 20 per minute
    • WEB_CLIENT_APPLICATION_ID = 3_033_300: the client app ID carried in the request
  • There are 7 result classes: Allow / BareDrop / Drop / Suppressed / NotFound / Failed / Missing.
  • There are 7 failure reasons: NoValue / StratoError / RateLimited / DecodeError / RpcError / OverCapacity / TweetypieFailed.
  • The result class and the failure reason are each aggregated as vf_tweetypie_reference_compare metric labels.

• Which rules to turn on for each client is now fixed in a data table verified — visibility-filtering/params/client_switches.rs.

  • The new file is VF params/client_switches.rs (+225 lines, introduced), and it enumerates 6 switches.

    "enum ClientSwitch { AgeVerification(VerifyBlurSupport), ModernBlur, StaleTweetLimits, GoreBlurIgnoresSettings, FosnrRules, FosnrFallbackDrops, }" — visibility-filtering/params/client_switches.rs, 2026-09-29

  • Each switch maps to a string key of xai_feature_switches::FeatureSwitches.

  • Each of the 4 states of VerifyBlurSupport (Unsupported | IosNeedsUpdate | AndroidNeedsUpdate | Supported) uses a different age_verification_*_tombstone_rule_enabled key.

  • Three switches are on by default via default_on (AgeVerification(Unsupported), StaleTweetLimits, FosnrRules).

  • When a request arrives, a RecipientBuilder is constructed from the TwitterContextViewer (client_application_id, user_agent, country_code) and the viewer_id to do the matching.

Following the long-standing convention of the x-algorithm repository, the home-mixer parameter file is a cron mirror that periodically copies over the production feature-switch defaults. This time the header comment of params/param.rs, // mirrored from config feature-switch defaults; last sync 2026-09-28T16:00:35Z, was updated, and three weights moved together.

• The click weight went down, and the post-click dwell weight that had been off was turned on verified — home-mixer/params/param.rs.

  • In the production cron mirror, ClickWeight changed from 0.4 to 0.3 and ContClickDwellTimeWeight from 0.0 to 0.4 at the same time.

  • last sync in the header comment of the file was updated from 2026-09-25T16:24:28Z to 2026-09-28T16:00:35Z, and the three values moved together.

    "-param!(ClickWeight, f64, "rust_home_mixer_click_weight", 0.4); +param!(ClickWeight, f64, "rust_home_mixer_click_weight", 0.3); ...

    • "rust_home_mixer_cont_click_dwell_time_weight",
    • 0.0

    • "rust_home_mixer_cont_click_dwell_time_weight",
    • 0.4

    ...

    • "rust_home_mixer_not_interested_weight",
    • -43.2

    • "rust_home_mixer_not_interested_weight",
    • -47.52"

    — home-mixer/params/param.rs production cron mirror, 2026-09-29

  • The weight of the click itself dropped by 1/4 (0.4 → 0.3).

  • The continue-click-dwell weight (sessions where the user actually stayed long after the click), which had been off at 0, was turned on at 0.4.

  • The Not Interested weight was strengthened from −43.2 to −47.52 (exactly 1.1×).

  • After the binary continuous loss type was applied to production as a click-dwell BCE in Gen4+22 (2026-09-16), one trained head appears to have shown an effect offline, and that head appears to have been put into the actual serving weighted sum inferred.

• VF's retweet source merging logic was split into a separate module verified — visibility-filtering/retweet.rs.
  • The new module visibility-filtering/retweet.rs is 318 lines, and evaluate_tweets.rs shrank by +101/−102.
  • The merge of the two source verdicts, in-batch vs fetched, which was introduced inline in Gen4+28 (2026-09-24), was split out this time into the evaluate_merging_sources function.
  • The structure is the same. If the original is already among the request candidates, it is judged as in-batch; if not, it is fetched through separate hydration, judged as fetched, and then merged.
  • Instead, the evaluate_tweets_retweet_sources { outcome=in_batch | fetched } metric moved to retweet.rs. This metric first appeared in evaluate_tweets.rs in the 2026-09-24 commit (Gen4+28). It shows how often a separate fetch is needed to judge the original of a retweet.
• A 705-line age verification golden corpus and a 130-line legacy interstitial were added verified — visibility-filtering/rules/golden_corpus/age_verification.rs and legacy_interstitial.rs.
  • This follows the 15-file split of the golden corpus that began in Gen4+29 (2026-09-25).
  • age_verification.rs fixes, as a role×tweet matrix, the verdicts that the AgeVerification(*) switches of card C produce in each client state (Unsupported / iOS update needed / Android update needed / Supported).
  • The roles are web_in_fr, web_in_us, sensitive_opt_in_web_in_fr, and so on, and the candidates are nsfw_admin_flag_media, limited, blurred, and so on.
  • local_regulations.rs and takedown.rs were also split out as new files in the same commit.
• A new toggle lets retrieval in Phoenix (the ranking and retrieval model of X For You) drop already-seen posts from the candidates verified — home-mixer/params/param.rs.
  • The new parameter is PhoenixRetrievalExcludeSeenPosts, and its default is false.
  • Because the default is false, it is not yet an active policy.
• One parameter used for the impression boost was removed from the home-mixer parameter file verified — home-mixer/params/param.rs.
  • The removed parameter is UseEngagementCounterViewCountForImpressionBoost.
  • Either the view count source for the impression boost moved from the engagement counter to another source, or the boost itself was discarded.
• The author_policy_zeroed field was removed entirely from the home-mixer signals verified — home-mixer/models/candidate.rs, scorers/value_model.rs, scorers/vm_ranker.rs, scorers/vm_ranker_request.rs.
  • This boolean disappeared both from the request shape of VMRanker (the separate ranking service attached after home-mixer that handles diversity reordering) and from the candidate dict.
  • This release does not state directly what this signal suppressed, but from its name and where it was used (a boolean carried on the candidate at scoring time), it was a marker for candidates whose score had been pressed to 0 by author policy inferred.
  • In Gen4, policy-driven candidate suppression is now decided directly in the VF verdict.
• The Phoenix serving response now also carries two kinds of view-through values verified — phoenix/crates/serving/xai-recsys-proto/src/purchase_value.rs.
  • The PUBLISHED array in Phoenix purchase_value.rs grew from 4 to 6 entries (= ALL).
  • In the previous commit (Gen4+30), it was fixed as PUBLISHED = [PURCHASE_CT, PURCHASE_VT, CONTENT_VIEW_CT, ADD_TO_CART_CT]. This time it changed to PUBLISHED = ALL, so CONTENT_VIEW_VT and ADD_TO_CART_VT (the two view-through kinds) are also carried in the serving response.
  • The assert on the encoded size cap of the proto PurchaseValueBaseline was also updated from ≤64 bytes to = 73 bytes.

1. The trust layers of the automated suspension policy are now physically separated into two services.
   • The abuse-enforcement service decides whether to actually dispatch an action. abuse-ledger-service only looks up the decisions of human reviewers (overturns); the write path is undisclosed.
   • The two services use separate DBs. The former uses its own store, and the latter uses ledger.enforcement_holds.
   • The latter communicates only through three SQL statements (PROBE_SQL, CONTRACT_SQL, PING_SQL), and an assert fixes that none of the three contains a write verb.
   • In other words, it is now possible to audit from outside the code that the dispatch path did not bypass the human verdict. The dispatch system does not hold write permission on the ledger DB.
2. The reference comparison target of VF has moved beyond the self-reference, Scala VF, to Tweetypie, the original store of tweets.
   • Rust VF and Scala VF are reimplementations of the same policy set in two languages, so their diff leans toward implementation drift rather than policy differences.
   • Tweetypie holds the tweet's own visibility decision, which it already attaches at the storage layer, so diffing against it catches drift between the "storage-axis decision" and the "serving-axis decision."
   • Pinning to a specific Safety Level with SafetyLevel::TimelineHomeHydration and refusing to start in prod show that this harness is a correctness verification tool, not a safety net.
3. Ranking has started to trust "clicks" less.
   • click_weight 0.4 → 0.3 and cont_click_dwell_time_weight 0.0 → 0.4 changed together in the same cron sync.
   • The order appears to be that the click-dwell head, which entered the training loss in Gen4+22 (2026-09-16), passed the training curve and the holdout and was then promoted to a coefficient of the serving weighted sum.
   • The two heads have different probability scales, so their exact totals cannot be compared. Even so, the direction in which "stayed after clicking" fits the production objective better than "clicked" is now explicitly fixed.
   • Not Interested going from −43.2 to −47.52 (exactly ×1.1) also strengthens the user's explicit negative signal.

2PEAR, which automates industrial search experiments with four-layer verification, was released — arXiv

• The verifier ladder has four layers, and a candidate must pass from low-cost metrics up to high-confidence metrics in order before moving to the next stage verified.
  • The order is Offline Replay → Shadow-Traffic Evaluation → Rapid Online Evaluation → Decision-Grade Online Evaluation.
  • Whether a candidate passes is decided in a confidence-gated way.

• In two online A/B experiments, Main Order/DAU rose by +2.7336% and +3.2957%, respectively verified.

  "In a real-world industrial search system, strategies optimized with PEAR significantly increased Main Order/DAU by 2.7336% and 3.2957% relative to their respective baselines in two A/B experiments." — PEAR abstract, 2026-09-28

  • Giving four decimal places and the metric "Main Order/DAU" (orders / DAU) are the standard KPI notation for e-commerce surfaces.
  • The company name is not given. The affiliation matches the "Global E-Commerce" team branding of the Alibaba International Digital Commerce (AliExpress/Lazada) line, so it is likely Alibaba inferred. However, the domain is not rendered in the v1 HTML, so this cannot be confirmed.

Radar

• PEAR (arXiv 2609.35031) is a progressive autoresearch framework for industrial search systems from an anonymous e-commerce team. The affiliation is likely the Alibaba line inferred. It uses a four-layer verifier ladder and hypothesis-guided per-task state, and reported Main Order/DAU +2.7336% and +3.2957% in two A/B tests. The metrics are verified, and the affiliation is inferred. Added to new this month in radar.md.

What to check next