2026-09-26

Other changes reviewed today:

• In the same X commit, VF began looking up the viewer's country directly from About This Account data.
• The same commit split the rule golden tests into 15 files by policy category and added a catalog that groups country codes into 9 regions.
• OneTrans-V2 merged three recommendation cascade stages into one Transformer and reported GMV +9.74% and 3.2× throughput in a production A/B test.

1VF rewrote its verdict data lookups around a data table and a scheduler — X

• The structure introduced in the 2026-09-23 commit (Gen4+27) and kept through Gen4+28 ran in this order:
  • A rule/predicate declares the set of hydrators it needs with const fn hydrators().
  • RuleEngine::hydrators_for(safety_level) inspects the active rule set.
  • The result is unioned into a Hydrators bitset.
  • Each hydrator variant runs through its own function/file.
• conversation_control_hydrator.rs (310 lines), introduced in the same 2026-09-23 commit, was the peak of this approach.
• This commit deleted the hydrator function files (conversation_control_hydrator.rs, exclusive_content_hydrator.rs, socialgraph_hydrator.rs) entirely. hydration/mod.rs was also cut by 787 lines, leaving only 169.
• Three files took their place: plan.rs (471 lines, new), execute.rs (1,280 lines, new), and sources.rs (445 lines, new).

• The number of hydrator kinds grew from 7 to 17 variants verified — visibility-filtering/hydration/mod.rs:44-62.

  • The enum listing the kinds is Hydrator, and 10 entries that were not in yesterday's list were wired in this time.

  • The code block below is the variant list.

    pub enum Hydrator {
        PureCore, Tweet, ConversationControl,          // TES family
        TweetSafetyLabels,                              // safety_label
        ViewerProfile,                                  // gizmoduck viewer
        AuthorSafety, AuthorLabels,                     // gizmoduck author (SAFETY / LABELS fields split)
        Follows, Blocks, Mutes, MuteRetweets,          // socialgraph forward edges
        BlockedByAuthor, BlockedByReplyRoot,           // socialgraph reverse
        SuperFollowsExclusive,                          // exclusive_content
        RootFollowsViewer, SuperFollowsRoot,           // conversation_control
        ViewerCountry,                                  // about_this_account (new client)
    }
    

• Each variant is registered as a row in one table rather than having its own function verified — plan.rs:32-45.

  • The row format of the table is NodeSpec { source, part, key, label }.

• One table row (NodeSpec) represents one hydrator as data on 4 axes verified — plan.rs:82-192.

  • Source is which backend is called.
  • Part is what is fetched within the backend. Columns, field sets, and edge queries count as this.
  • KeyOrigin is where the input key comes from. Examples are the request tweet id, the viewer id, and the author id filled in by PureCore (tweet core metadata).
  • label is a client·method string pair for metrics.
  • For example, Hydrator::AuthorSafety is NodeSpec { source: GizmoduckAuthor, part: Fields([SAFETY]), key: PureCoreAuthor, label: ("gizmoduck", "get_users") }.

• Among the requested hydrators, those with the same backend and input dependency are planned to be bundled into one RPC verified — plan.rs:274-305.
  • HydrationPlan makes the plan. HydrationPlan::new(level, hydrators) groups the requested hydrators into (source, input) pairs.
  • The same source with a different dependency becomes a different group. A hydrator that needs pure_core and one whose input is already in the request are such a case.
• For example, an author's SAFETY field and LABELS field fetched from gizmoduck (X's user information service) are looked up together in a single call verified — plan.rs:316-353.
  • Hydrator::AuthorSafety (SAFETY field) and Hydrator::AuthorLabels (LABELS field) both require the PureCoreAuthor input from the GizmoduckAuthor source, so they become one group.
  • Group::fields() builds the union of the two field sets and handles them with a single gizmoduck.get_users(fields=[SAFETY|LABELS]) call.
  • Follows·Blocks·Mutes·MuteRetweets also share the Flock source, the PureCoreAuthor input, and the forward direction, so they are bundled into a single socialgraph/batch_check_relationships call.

• The lookup plan is set for each SafetyLevel (a per-surface policy bundle), and a golden test pins that plan as a string verified — plan.rs:422-460.

  • RuleEngine::plan(level) locks the plan it builds for each SafetyLevel into a 5-safety-level golden string.
  • The number of calls per SafetyLevel is fixed as follows:
    • filter_all: 1 call
    • timeline_home: 7 calls
    • timeline_home_recommendations: 7 calls
    • timeline_home_hydration: 10 calls
    • immersive_expanded_recommendations: 7 calls
  • The string records, for each plan, which client·method runs against which input as which hydrator node. It even includes whether a call is skipped when logged out because it needs a viewer.

  "filter_all: 1 calls\n tes/get_tweet_core_datas after: - nodes: pure_core\n timeline_home_hydration: 10 calls\n tes/get_tweet_core_datas after: - nodes: pure_core\n tes/get_tweets_for_visibility after: - nodes: tweet\n conversation_control/get_conversation_controls after: - nodes: conversation_control\n safety_labels/get after: - nodes: tweet_safety_labels\n gizmoduck/get_viewer_data after: - nodes: viewer_profile fields: ACCOUNT|EXTENDED_PROFILE|SAFETY (skipped logged out)\n gizmoduck/get_users after: pure_core nodes: author_safety fields: SAFETY|LABELS\n blocked_by/batch_check_blocked_by after: pure_core nodes: blocked_by_author,blocked_by_reply_root blocks-rev[author,reply_root] (skipped logged out)\n exclusive_content/batch_check_super_follows after: tweet nodes: super_follows_exclusive super_follows-fwd[exclusive_author] (skipped logged out)\n conversation_control/batch_check_followed_by+batch_check_super_follows after: conversation_control nodes: root_follows_viewer,super_follows_root follows-rev[root:Community|MyNetwork] super_follows-fwd[root:Subscribers] (skipped logged out)\n conversation_control/tfe_top_country after: conversation_control nodes: viewer_country (skipped logged out)" — visibility-filtering/hydration/plan.rs:422-451

  • That is, the service itself sees the timeline_home_hydration lookups as a 4-stage graph.
    1. Five lookups start immediately with only the request tweet id and viewer id. tes/get_tweet_core_datas, tes/get_tweets_for_visibility, conversation_control, safety_labels, and gizmoduck/get_viewer_data count as these.
    2. gizmoduck/get_users (author_safety and labels) and blocked_by depend on the author id filled in by pure_core.
    3. exclusive_content depends on the result of the tweet node (tes/get_tweets_for_visibility).
    4. The conversation_control sub-lookups (followed_by and super_follows) and tfe_top_country depend on the conversation_control result. Conversation control is X's conversation setting that decides who can reply.

• The execution stage schedules the dependency graph between groups with FuturesUnordered (a Rust data structure that runs several async tasks together and returns results in completion order) verified — execute.rs:80-100.
  • The scheduler is in execute.rs and repeats the following sequence:
    • First, it initializes the ready queue with the groups where input.is_none() (groups with no external dependency).
    • It spawns the RPC of each ready group and puts it into the running FuturesUnordered.
    • When any one finishes, it stores that result in the Store.
    • With waiting_on(group), it moves the subgroups that were waiting on this group back to ready.

• A new client looks up the user's weighted top country and supplies it to the country hydrator verified — visibility-filtering/clients/about_this_account_client.rs:1-42.
  • The new client is about_this_account_client.rs (166 lines).
  • It reads the Strato (X's internal system that code goes through to read or store data) column about_this_account/tfe_top_country.User, and the hydrator that receives the result is ViewerCountry.
  • This client's result is used in the country filter of the conversation_control allowed-list verdict.
  • "About This Account" itself is a transparency UI at the bottom of the account profile in the X app, showing the account creation date, top country, and name change history. VF now consumes that data source directly.

• VF's rules layer was also reorganized verified.
  • visibility-filtering/rules/tweet_rules.rs is −575 lines, author_rules.rs is −160 lines, registry.rs is +226/−58, and rule_spec.rs is +141/−161.
  • The two-way Verdict tree (Withheld/Shown) structure introduced in the 2026-09-22 commit (Gen4+26) is kept, and the direction of moving the rule catalog itself into data continues. The detail needs more tracking.
• A single 1,493-line file of golden rule cases was split into 15 files by policy category verified — visibility-filtering/rules/golden_corpus/.
  • The original file is rules/golden_corpus.rs.
  • The new files and line counts are as follows:
    • age_gating.rs 267 lines · author_state.rs 119 lines · baseline.rs 56 lines · builders.rs 63 lines · conversation_control.rs 257 lines
    • exclusive_content.rs 61 lines · interstitial.rs 334 lines · mod.rs 173 lines · oon_media.rs 218 lines · oon_tweet_label.rs 133 lines
    • oon_user_label.rs 234 lines · relationship.rs 122 lines · takedown.rs 224 lines · tweet_label.rs 195 lines · tweet_state.rs 90 lines
• A catalog that groups country codes into regions was newly added verified — visibility-filtering/models/region.rs:1-97.
  • The new file is models/region.rs (97 lines), and it maps ISO country codes to 9 regions (AFR·AUS·CAS·EAS·EUR·NAM·SAM·SAS·SEA).
  • For example, AFR covers 57 countries including AO·BF·BI·BJ·BW·CD, EUR covers 51 countries including AD·AL·AT, and SEA covers 11 countries: BN·ID·KH·LA·MM·MY·PH·SG·TH·TL·VN.
  • If the NSFW gating list of 16 countries in Gen4+12 (2026-09-01) was country-level, rules can now also be expressed at the region level.
• A new 34-line field was added to the proto of Phoenix (X's Grok-based Transformer ranker) verified.
  • The same 34 lines were added to both phoenix/crates/serving/xai-recsys-proto/proto/recsys.proto and phoenix/python/common/xai-proto/proto/recsys.proto, and lib.rs gained +58 lines.
  • This batch does not track which field was added. When a consumer appears in a follow-up commit, we will fold it into the canon.
  • Phoenix transformer.py is +42/−5, and recsys_model.py is +5/−1.
• The key-frame pipeline of grox (a Grok-based nearline classifier) was reworked verified.
  • The new files frame_sampler.py (124 lines) and embedding_ranked_key_frames.py (193 lines) were added.
  • key_frames.py was reorganized at −53/+14, media_loader.py is +62/−34, and convo.py is +112/−61.
  • The 32×32 grayscale scene-cut·shot midframe pipeline that was open through the 2026-09-24 commit (Gen4+28) appears to be expanding into embedding-based ranking, but we did not track the detail.
• A filter in home-mixer (the service that assembles the For You feed) that hardcodes a list of Brazil 2026 election-related accounts received a small update verified.
  • The file is home-mixer/filters/brazil_2026_election_filter.rs (+22/−2), and the filter was introduced in the 2026-08-14 commit.
  • A code comment states Electoral Resolution No. 23.610 Art. 28 §1º-A of the Brazilian Superior Electoral Court (TSE) as the regulatory basis.
  • The following exception is kept.
• About 600 lines of new observability UI code were added verified.
  • It is located in under-the-hood/jetfuel/, and 8 files were added: routes/index.tsx, report.tsx, download.tsx, and _lib/{load,mock,report,ui}.
  • The frontend code of the account-level label transparency tool (mentioned as a pilot in Gen4) appears to have been opened.
  • It is not directly tied to ranking or retrieval mechanisms, so we do not fold it into the canon.

The practical meaning of this rewrite is threefold:

• First, the hydration interface moved from functions to data.
  • The previous structure had each rule declare a hydrators() list, but execution itself was still a function layer (a .rs file per hydrator variant).
  • Today execution became data too. With just one NodeSpec table, the scheduler automatically plans RPC groups for whatever combination of hydrators is requested.
  • Adding a rule no longer requires writing a new hydrator function; adding one line to the table is enough.
• Second, RPC group merging was automated.
  • Until yesterday, gizmoduck's SAFETY lookup and LABELS lookup went through different hydrator functions. Today Group::fields() automatically merges the field sets of hydrators with the same source and the same input and bundles them into one RPC.
  • This is not a micro-optimization. In X's structure, where the hydration budget concentrates on fan-out services such as gizmoduck and socialgraph, it directly affects P99.
• Third, connecting the ViewerCountry hydrator brought the conversation-control country allowed-list formally into the hydration budget.
  • Previously, country information arrived in the request context, but now hydration fills it by querying the about_this_account/tfe_top_country.User Strato column directly.
  • This means the backend of the About This Account transparency UI is now attached to the VF verdict path. The regulatory-response axis (e.g., per-country content restrictions) has formally entered the hydration layer.

Splitting golden_corpus into 15 files reads as preparation for two things. One is to divide corpus ownership by policy category, and the other is to let the verdict matrix of each category be locked independently in the two-way Verdict tree opened in the 2026-09-22 commit (Gen4+26).

2OneTrans-V2 merged three recommendation cascade stages into one Transformer — radar

1. It expanded the MoE backbone.
2. It merged per-objective retrieval channels into one generative process with DCGR (Decision-Conditioned Generative Retrieval).
3. It amortized lifelong user sequence encoding per impression with SNT (Sequence-Native Training).

• All three cascade stages were unified into a single Transformer verified — abstract.
  • The user behavior sequence is encoded only once as shared context, while stage-specific candidate features and computation are kept.
  • Joint training lets the three stages reinforce each other, and in-model knowledge distillation flows from fine-rank to pre-rank.
• The backbone was expanded to sparse MoE, and scaling was stabilized with μP-style parameterization verified.
  • This is the standard recipe of increasing capacity while holding the activated compute fixed.
  • However, this is the first statement in an industrial stack that explicitly adopts μP (parameterization that lets hyperparameters carry over unchanged when model width changes) style hyperparameter transfer.
• DCGR (Decision-Conditioned Generative Retrieval) first predicts the type of the upcoming interaction and generates items conditioned on that prediction verified.
  • What it predicts first is the decision prefix, a short token describing the type of the upcoming interaction.
  • Instead of keeping several separate per-objective retrieval channels, it unifies them into one generative process, and the business objective steers it through the decision prefix.
• SNT (Sequence-Native Training) organizes training around the user's lifelong behavior sequence, amortizing sequence encoding per impression verified.
  • Instead of recomputing the user representation for every request, it reuses it along the session and impression axes.

• In the production A/B test, GMV was up +9.74%, and under the same hardware budget throughput was 3.2× that of the previous cascade verified.

  "Deployed across all three stages of a large-scale industrial recommendation system, OneTrans-V2 improves gross merchandise value (GMV) by 9.74% and, with a co-designed serving stack, delivers 3.2× the throughput of the cascade it replaces under the same hardware budget." — arXiv 2609.28589 abstract

• The earlier two each took a different angle:
  • UNIQUE (Baidu, RecSys 2026) took the angle of combining generative retrieval and target-aware ranking into an early-fusion single architecture.
  • UniRec (Kuaishou) took the angle of aligning fusion agents for the two stages, pre-rank and rank, through joint learning.
• Moreover, the A/B figures, GMV +9.74% and throughput 3.2×, are much larger than in the other two.
  • UniRec reported app usage duration +0.616%, and UNIQUE did not publish A/B figures in its abstract.
• There is no HTML version and Semantic Scholar returns no affiliation, so we defer judgment in this batch.
• E-commerce platforms that use the GMV metric (Taobao·JD·Meituan·Pinduoduo·Shopee, etc.) are the most likely candidates inferred.
• If an affiliation is confirmed in a later v2 or a conference acceptance notice, we will revisit the canon update.

The remaining arXiv sources were dropped from the watch list. Of the 30 items in this arXiv triage, the other 29 did not pass, for the following reasons:

• AgentX (2609.30001, Meituan): a model research framework, that is, a source about a research agent architecture, not a new angle on ranking or retrieval mechanisms themselves.
  • The abstract claims "560 of 636 completed model-changing experiments recorded AUC above their business baselines" and production A/B results of "10-15% acquisition efficiency, 15-20% target-segment advertising spend, 0.3-0.8% watch time".
  • Meituan is not a service this repository tracks as canon.
  • It is closer to "how the teams that build real services do research" than to "what real services do," which is what this repository asks, so it belongs to a different thread.
• X-Rec(2609.29180): an academic GR (generative retrieval) source that learns the recommendation distribution in a continuous item embedding space with flow matching. It was dropped because the abstract has no production deployment claim.
• From Interests to Semantic IDs(2609.29983) and Learning Better Reasoning for GR with SIDs(2609.29973): two papers from the same group of authors (Mengdan Zhu·Yufan Zhao et al.). They are academic methods that improve reasoning-trace training for GR based on SIDs (semantic IDs, which represent items as hierarchical codes) and have no production A/B test.
• ScalarLens(2609.29182): a numerical embedding method using the Criteo dataset. It has only academic benchmarks.
• Fair Feed Ranking for Participatory Budgeting(2609.29819): deals with the order in which proposals are shown on the Consul Democracy platform (a participatory budgeting tool). It is outside this repository's watch scope.
• Cross-Country Code-Mixing for GR(2609.28972): an academic method on cross-country e-commerce GR.
• SEEK(2609.29803): an industrial search evaluation framework. It is a search evaluation tool, not a ranking mechanism itself.
• Decoupled Learning and Selection in Slate Rec(2609.29453): academic theory on slate (a bundle of items shown together on one screen) recommendation with a DP guarantee.
• The other 20 items fall outside this repository's domain (feed, ranking, retrieval), covering RAG, LLM eval, document search, QA, video search benchmarks, quantum GitHub, and knowledge graphs.

Industry blogs are not scanned today (Saturday)

Under the batch rules, industry blogs are scanned only on Mondays. The latest posts on the Meta and Netflix blogs are unchanged from what was checked yesterday.

• The latest post on engineering.fb.com is 2026-09-23 Private Processing to Meta AI Glasses. It is a security-topic post and was skipped.
• The latest post on netflixtechblog.com is 2026-09-18 Class Path. It is a JVM infrastructure post and was skipped.

What to check next