2026-10-08

1The global popular posts candidate source was turned on by default — X

• The flag that turns on the popular posts source in the home-mixer (the service that serves the For You feed) mirror changed from false to true verified — home-mixer/params/param.rs:944-948.

  • The flag name is EnablePopularPostsSource.
  • The mirror sync time is 2026-10-06T16:00:58Z.
  • home-mixer/params/param.rs is a file that mirrors X's internal feature switch defaults daily. So we read a value change in this file as a signal that the production default changed.

• The source turns on under three conditions verified — home-mixer/sources/popular_posts_source.rs:27-31.

  • The request must not be one that reuses cached posts.
  • The request must not be follow-only (in_network_only).
  • The flag must be on.

• The only per-user information used is a single list of already seen posts, and posts on this list are removed verified (same file, line 50).

  • The list is named seen_ids.

• The README also lists this source for the first time as an OON source verified — README.md.

  "popular_posts_source adds a shared list of popular recent posts."

  "A shared list of popular recent posts, initially from the most-followed active accounts."

  • The qualifier "initially" reads as meaning that for now posts are drawn only from top-follower authors but the scope may be widened inferred. The basis is that the job code in the 2026-10-06 commit (Gen4+36) picks the author set from a BigQuery snapshot, so it is easy to swap.

• The way the list is built is the same as yesterday.

  • It collects original posts from the top 0.005% of authors by followers among authors active in the last 7 days verified (2026-10-06 commit Gen4+36, home-mixer/popular_posts_job.rs).
  • It extrapolates views within 24 hours to cumulative 24-hour views assuming an 8-hour half-life, and picks the top 500 verified (same file).

• The new-author boost weight in the home-mixer mirror went from 0.02 → 0.015 verified — home-mixer/params/param.rs:384-388.
  • The new-author boost (post_unexplored) is a cold start mechanism that adds to the score of in-network posts from authors with fewer than 1,000 impressions.
  • The weight name is PostUnexploredWeight.
• A parameter of the same name also exists in the mirror of VM-Ranker (a separate service to which home-mixer delegates score refinement), but there it stays at 0.02 verified — vm-ranker/params.rs:91-95.
• Since the 2026-09-24 commit (Gen4+28), home-mixer first computes a local weighted sum and refines the score through a VM-Ranker RPC, and serves the local score if the RPC fails verified (canon Gen4+28 entry).
  • So 0.015 is the value of at least the RPC failure path, and we cannot tell from this commit alone which value is final on the normal path inferred. We have not yet checked whether the two mirrors read different feature switch keys, so we leave it as an inference.

Phoenix trains search result ranking as well as For You. During training, actual impression logs alone lack "irrelevant results", so it borrows data from other users in the batch to create fake negatives. This is called in-batch negative sampling.

• In batches that have a search query, two kinds of negatives are made verified — apply_negative_sampling in phoenix/xrex/data/recsys/recsys_batch.py.
  1. A post seen by another user is paired with my query.
  2. A post I saw is paired with another user's query.
  • If the cosine similarity of the two query embeddings is 0.9 or higher, the queries are treated as similar and discarded.
  • Negatives get a "passed without reading" label (ClientTweetRecapNotDwelled).
• The problem is that post features are all copied unchanged from the original slot. The two lexical match features added in the 2026-09-18 commit (Gen4+24) are values based on the original query, and they remained as they were even in negatives paired with the new query verified (copy code, lines 1391-1425).
  • exactPhraseSeq indicates whether the query phrase appears in the post verbatim.
  • matchedWordFractionSeq is the fraction of query words that appear in the post.
• This commit fixes this with one new file verified — negative_word_match.py (51 lines).
  • The call site is recsys_batch.py:1476-1488.
  • When search_negative_clear_word_match is on, it clears the two features of the negative slot to 0 (no value). This flag is False by default.
  • If the training data has three new columns, it recomputes the values based on the newly paired query using the external library xai_search_lexical_match.
    • lexicalTextSeq: post body
    • lexicalQuerySeq: query
    • lexicalAuthorSeq: author
• Before the correction, negatives of type 2 in particular received an irrelevant label while carrying a feature saying "the phrase matches the query exactly". The model was likely trained to trust the lexical match features less than it should inferred. The basis is that the features and labels were systematically mismatched.

• A regularization option was added that adds the output magnitude of each Transformer layer to the loss, and its default is 0 verified — recsys_model.py:664, 3827-3830.
  • The option name is per_layer_l2_weight. It adds the magnitudes (mean squares) of the attention output and the FFN output.
  • It appears to be a mechanism to keep activations from growing as they pass through layers inferred.
  • There was also a refactor that merged four functions that build loss inputs into one.
• VF (visibility filtering, the safety layer that decides whether content may be shown) now treats posts that the post store could not find as failures instead of judging them verified — visibility-filtering/evaluate_tweets.rs.
  • The post store is tweetypie, and the target is posts for which this store returned "not found".

• In the PopularPostsSource row of the source table in the candidate generation section, changed the gate from "off by default" to "on by default in Gen4+37" and added the activation conditions.
• In the new-author boost table and weight table of the ranking section and in the cold start section, wrote the PostUnexploredWeight value together as home-mixer 0.015 and VM-Ranker 0.02.
• Created a ### Gen4+37 section and added the reference commit 78460ca to the sources section.
• assets/x-pipeline.svg: added "popular list on (10-07)" to the subtitle of the SimClusters box.

• Since the Gen4 release, all of X's OON candidates came from personalized inputs such as user embeddings or clusters. For the first time, a source that gives the same list to all users entered the default path verified.
  • However, this source only supplies candidates, and actual impressions are decided by Phoenix ranking inferred. The basis is that the source creates only PostCandidates without scores.
• On the same day, candidates from popular authors were increased and the new-author boost weight in the home-mixer mirror was lowered by 25% (the VM-Ranker mirror is unchanged). We cannot confirm from the code whether the two changes are one experiment inferred.
• The search negative correction does not affect training for now because its flag is off by default verified.
  • However, the fact that a defect on the training data side surfaced only 3 weeks after the lexical features were added in the 2026-09-18 commit (Gen4+24) means the search ranker may not yet have been using these features properly inferred.

What to check next

Source check notes

No new material to fold in was found from any of the three sources checked in this run.

• Meta: the latest post on engineering.fb.com is "NTS: Authenticated Time at Meta" (time synchronization infrastructure) from 2026-10-06, which is unrelated to feeds and was skipped. ai.meta.com/blog had no new posts on feeds or recommendations.
• Netflix: the latest post on netflixtechblog.com is from 2026-09-25, so there is nothing new. On research.netflix.com, /publications still returns 404, but the first page and /research-area/recommendations open. The latest publication date on the first page is 2026-02-24, and we confirmed 0 new items. From now on we check these two paths.
• arXiv cs.IR: 30 papers were parsed, and 0 passed the acceptance criteria. There were several studies on generative retrieval with Semantic IDs (token sequences that represent an item as a hierarchical code): 2610.08732, 2610.07402, 2610.06590. However, all lack platform company authors or production evidence.