2026-09-03

Other changes reviewed today:

• In the same commit, X added the first mode in Phoenix, its ranking model, that restores semantic IDs (SID, items represented as hierarchical codes) back into dense vectors.
• The same commit also added a path that exports the trained model as a CUDA serving bundle and a checkpoint writer with encryption.
• Tencent PCG applied TGR, which combines ranking, generative retrieval, slate (a group of items shown together at once) generation, and inference tokens in one frame, to 5 surfaces.

1Impression verdict rules became data definitions; ranker got an SID restore mode — X

• The Gen4 release contained three things.
  • The 4-stage labeling path of the safety pipeline (Content Understanding → Labeling Rules → Storage → Visibility Filtering)
  • Rules spread across the three SafetyLevels of VF: 54 for TimelineHomeRecommendations, which serves recommended posts (including the 28 of TimelineHome, which serves Following), and 1 for FilterAll verified — registry.rs test. VF (visibility-filtering) is the service that decides, post by post, 'may this viewer see it?'.
  • The Phoenix ranking model training code and the production cron mirror param. A cron mirror is a file that syncs production configuration values daily.
• Gen4+11 (bc8e5f0) on 2026-08-28 expanded RuleContext to about 25 domain methods. It also added a golden corpus of 90 cases in 13 categories and tied the rule wiring code to the test assertions. Wiring a rule that is not in the tests breaks CI.
• Gen4+12 (6384ca7) in the early hours of 2026-09-01 stated the 16 NSFW-gating countries in code for the first time and built a new special video safety pipeline based on motion-reveal.

This commit (Gen4+13, same day at 20:47 UTC) came 20 hours after 6384ca7 and opens three things at once. Policy is unchanged, but several facts the canon (this repository's service and topic notes) did not know are confirmed at the code layer.

• The physical structure of VF rules changes from a struct per rule to a data-based spec. Gen4+11 fixed the representation with the golden corpus; this time the representation itself got thinner, down to data literals.
• The recon path that restores RQ-VAE-family semantic ID codes into a dense vector appears in the Phoenix ranking model code for the first time. RQ-VAE represents a vector by picking one code from the residual codebook of each level and adding them. How X uses SID internally as a learned ranker input is revealed for the first time.
• StableHLO bundle export for the handoff from JAX training to CUDA serving, and an Orbax checkpoint writer that uses envelope encryption, are standardized at the infrastructure layer.

A. Impression verdict rules became one-line data definitions instead of per-rule structs

• Nine rule files were deleted and three were created verified.

  • The new files are visibility-filtering/rules/rule_spec.rs (89 lines, new), visibility-filtering/rules/tweet_rules.rs (1,125 lines, new), and visibility-filtering/rules/author_rules.rs (354 lines, new). Together they total 1,568 lines.
  • The nine deleted files (2,670 lines in total): nsfw_age_gating.rs(639) · nsfw_interstitial.rs(242) · nullcast_rule.rs(79) · socialgraph_rules.rs(301) · tes_rules.rs(446) · tweet_flag_rules.rs(114) · tweet_label_drops.rs(327) · user_label_drops.rs(239) · user_rules.rs(283).

• The new shared abstraction lets one rule be written as a one-line literal. This abstraction is RuleSpec, and it has three variants.

  • Tweet consists of a tweet-condition predicate and a drop or interstitial action.

  • Author consists of an author-condition predicate and a drop.

  • Custom is an arbitrary function pointer. It is used when the condition is hard to express as a predicate (for example, a rule that must look at the viewer's state and relationship at the same time).

  • There are only two actions, Drop and SensitiveMediaInterstitial. The interstitial action automatically checks the viewer's sensitive-media opt-in state.

  • RuleSpec is defined as follows:

    #[derive(Clone)]
    pub(super) enum RuleSpec {
        Tweet {
            name: &'static str,
            when: fn(TweetPredicates<'_>) -> bool,
            action: RuleAction,
            exempt_author: bool,
        },
        Author {
            name: &'static str,
            when: fn(AuthorPredicates<'_>) -> bool,
            reason: FilteredReason,
            exempt_follower: bool,
        },
        Custom {
            name: &'static str,
            evaluate: fn(&RuleContext<'_>) -> VfAction,
        },
    }
    

• The common exceptions repeated in every rule moved into fields of the spec. Previously, "Allow if the author is the viewer" and "Allow if the viewer is a follower" were written separately in code for each rule. Now two fields handle this check in one place.

  • The two fields are Tweet.exempt_author and Author.exempt_follower, and the place that handles them is RuleSpec::evaluate.

• Rules were not moved over one-to-one by old file. They were regrouped by the type that triggers the policy.

  • nsfw_interstitial.rs was split into a label-triggered interstitial and an author-flag-triggered interstitial. The former is NSFW_MEDIA_INTERSTITIALS, which belongs to the home base rules, and the latter is NSFW_AUTHOR_INTERSTITIAL.
  • tes_rules.rs was split into home-common rules (stale and takedown, TES_HOME_DROPS) and recs-only rules (DMCA and geo-restricted media, RECS_MEDIA_DROPS). A recommendations-only rule axis became explicit in code for the first time.

• The NSFW gating country list is now held by the context, not by the rule verified — visibility-filtering/rules/tweet_rules.rs sensitive_viewer_no_stated_age.

  • What moved is Arc<NsfwGatingCountries>. In Gen4+12 (6384ca7, early the same day), nsfw_age_gating.rs held the country list in a struct and an Arc<NsfwGatingCountries> field.

  • Now RuleContext holds a reference and looks it up with context.nsfw_gating_country(code).

  • Rules are now stateless zero-sized data literals. Instead, the Policies struct has a field nsfw_gating_countries: Arc<NsfwGatingCountries>. At evaluate time, it passes the reference with RuleContext::new(..., &self.nsfw_gating_countries).

  • The three rule names (SensitiveViewerLoggedOutDropRule · SensitiveViewerUnderageDropRule · SensitiveViewerNoStatedAgeDropRule) are kept as they were, because audit logs, regression tests, and the transparency report (Under the Hood) refer to these names as literals.

  • The new code is as follows:

    fn sensitive_viewer_no_stated_age(context: &RuleContext<'_>) -> VfAction {
        if context.viewer().has_no_stated_age()
            && context.viewer().country()
                .is_some_and(|country| context.nsfw_gating_country(country))
            && sensitive_base_condition(context)
        {
            VfAction::Drop(FilteredReason::ContainNsfwMedia)
        } else {
            VfAction::Allow
        }
    }
    

base: !context.viewer().is_author() && tweet.has_media() && (tweet.has_safety_label(SafetyLabelType::NSFW_HIGH_PRECISION) || tweet.has_safety_label(SafetyLabelType::NSFW_HIGH_RECALL) || (tweet.is_nsfw_flagged() && !tweet.is_retweet())) ... if context.viewer().has_no_stated_age() && context.viewer().country().is_some_and(|c| self.gating_countries.contains(c)) && sensitive_base_condition(context) → Drop(FilteredReason::ContainNsfwMedia) (old code as of Gen4+12, moved into the form above in Gen4+13) — Gen4+12 visibility-filtering/rules/nsfw_age_gating.rs

• A regression test fixes that the policy did not change verified — visibility-filtering/rules/registry.rs.
  • The new test wired_rule_order_matches_pre_migration_sequence verifies rule names as literals, including their order. The targets are 28 for TimelineHome, 26 additional for TimelineHomeRecommendations, and 1 for FilterAll.
  • The code confirms that this commit is a pure refactor, not a change in policy semantics.

• The key signal of this commit is that the code asserts that policy did not change. Four days after Gen4+11 (2026-08-28) fixed rule verdicts with the 90-case golden corpus, a commit that restructures the representation itself arrived. X has settled into an order: first build regression defenses after a VF rewrite, then refactor on top of them.
• Surveying and auditing the rule list becomes much easier. Previously, checking "which NSFW/drop rules exist in this repository" meant skimming nine files. Now opening tweet_rules.rs alone shows every rule at a glance, grouped by constant. This form also suits quoting the original text in regulatory responses and in the transparency report (Under the Hood).
• A recommendations (recs)-only rule axis is now explicit in code. RECS_MEDIA_DROPS (DMCA/geo) came out as a separate constant. This means that recs-only rules added later attach only to this constant and do not mix with the home base.

B. The Phoenix ranker can restore semantic ID codes into dense vectors and add them to its input

• The new file is a decoder for ranker input, not a retrieval model verified — phoenix/xrex/models/recsys_sid.py.
  • The file is phoenix/xrex/models/recsys_sid.py (72 lines). It loads an SID artifact trained offline and contains one function that restores a dense vector from SID codes at ranking time.
• The artifact contains residual codebooks and a 2-layer MLP decoder. _load_sid_decoder(path) loads the tensors below from .safetensors.
  • stages is a stacked residual codebook of shape (num_levels, codebook_size, code_dim). In the RQ-VAE style, it picks the residual embedding of each level and sums them. The codebook size and the number of levels are set by the artifact and are not hardcoded in the code.
  • dec_w0 · dec_b0 · dec_w1 · dec_b1 are the 2-layer MLP decoder (relu → linear).
• The restore function runs in the order below.
  • codes = sids - 1 converts 1-based codes to 0-based. Rows with sids[..., 0] == 0 are marked as missing.
  • For each level, it picks stages[l, code_l, :] and adds the residual (residual sum).
  • It restores the dense vector with the 2-layer MLP and relu.
  • It applies L2 normalization (eps=1e-12).
  • It masks missing rows to 0.
  • It freezes the decoder completely with stop_gradient.
  • Only one linear project recon_dim → target_dim ({prefix}_sid_recon_proj, trainable) is left as a parameter. The result is cast to the dtype and returned to the ranker post tower.
• The recon mode is turned on with a config field, and the default is the existing approach verified.

  • Two fields were added to RecsysAggregatedModelConfig.

    sid_embedding_mode: Literal["learned", "recon"] = "learned"
    sid_decoder_path: str = ""
    

  • The default "learned" keeps using the existing learned SID embedding table.

  • Setting "recon" bypasses the learned SID table. Instead, it builds recon vectors from the SID codes of history_seq and candidate_seq and adds them to the post tower embedding.

  • To turn it on, you must use the legacy build_inputs path, must not use sid_hash_level and sid_cross_attn, and must specify sid_decoder_path.

• This commit is the first code release of the X SID line. It shows in code for the first time how the SID codes themselves are turned back into dense features. The SID-related X material released so far falls into three kinds:
  • In Gen4+3 (11a71f8) on 2026-08-18, the fields sid_known, sid_k_l1/2/3, and sid_gap_l1/2/3 were wired into VMRanker (a value model stage that reorders candidates on a separate server).
  • In Gen4+4 (aad7179) on 2026-08-19, SlateContext.sid* fields appeared in the Phoenix proto.
  • In Gen4+5 (d0cef2f) on 2026-08-20, SIDs came in the slate context of the serving response.
• The decoder is completely frozen. Because it uses stop_gradient and the artifact is built offline, only the codebook and MLP matrices need to be deployed for serving. The only part that is trained is the single recon_dim → target_dim project. Codebook tuning happens only offline, and training the ranker does not move the codebook.
• This path is not a retrieval model. Restoring vectors from the codebook and attaching them to the ranker input makes the candidate representation denser; it does not replace candidate generation itself with SID. Its lineage differs from approaches that "take SID as the autoregressive generation target", such as Kuaishou OneRec (Kuaishou's one-model generative recommendation lineage) or Tencent TGR (§2 of this daily). X still uses SID as an input signal inside the cascade.
• The code is wired but off (wired-but-off), and the default is "learned". If sid_embedding_mode="recon" appears in the production config in the next commit, that is a signal that the X SID pipeline has moved from a "learned table" to an "offline codebook + recon at serving time".

C. A path that exports the JAX-trained ranker as a StableHLO bundle for CUDA serving was introduced

• A new entry point lowers the forward pass of the ranking model and exports it as three kinds of files verified — phoenix/xrex/train/recsys_bundle_export.py.
  • The file is phoenix/xrex/train/recsys_bundle_export.py (634 lines), and the entry point build_bundle(trainer) lowers the forward pass with jax.export.
  • The export calls are jit(...).lower().as_text(dialect="stablehlo") and jax_export.export(platforms=("cuda",)).serialize().
  • The three files are StableHLO MLIR bytecode (.mlirbc), a .jax_export container, and MANIFEST.json. StableHLO is an operation graph format read by XLA-family compilers.
• Embedding lookup is outside the exported graph. The input of the forward pass is a tensor that concatenates the already looked-up embedding rows.
  • The input name is merged_embeddings.
  • MANIFEST.embedding holds {rows, rows_padded, num_shards, width, dtype, merged_slices, hash_table}, so the serving side knows how to concatenate the results of the embedding server.
  • This reveals in code that the serving architecture of the X ranker is a split structure: "the embedding server does the lookup, and the GPU server runs StableHLO".
• Multiple buckets are created per batch size. A separate program is lowered for each bucket, and at serving time the bucket that matches the request batch size is chosen.
  • The setting is export_bundle_bs_per_device, and the default is "1,2,4".
• The seqpack path supports only one attention kernel and does not support the block-sparse layout of FA4.
  • Only pallas_ranker_varlen_attn is supported. The block-sparse layout of FA4 (cutedsl_ranker_varlen_attn) explicitly raises NotImplementedError.
  • Because the GB300 config of Gen4+6 (2026-08-21, 28e414f) uses attn_impl="cutedsl_ranker_varlen_attn", exporting the GB300 training config as is requires switching the attn kernel to pallas.
  • The code shows a link where the attention implementation differs at the handoff from training to serving.
• The manifest also records the number of SID levels, so the serving side knows how many SID levels to load. This pairs with the SID restore mode in §B.
  • sid_num_levels is echoed as is in the manifest prep_spec.
• Bundle export is turned on only when attached to copy_port (hot checkpoint deployment) of the checkpoint deployment pipeline. A bundle goes out with every deployment via copy_port.

  • Four new fields were added to Trainer.

    export_stablehlo_bundle: bool = False
    export_bundle_bs_per_device: str = "1,2,4"
    export_bundle_history_seq_len: int = 0
    export_bundle_candidate_seq_len: int = 0
    

  • __post_init__ raises ValueError if export_stablehlo_bundle is on but checkpoint_config.copy_port is off.

  • The bundle goes out to {OUT_PATH}/.{prefix}/export/.

• This is the first code-level release showing that X standardized the handoff from JAX training to CUDA serving with StableHLO. Until now, the canon's understanding was "Phoenix is trained with JAX/Haiku and serving is a separate stack". This commit confirms that the serving stack receives and runs compiled StableHLO.
• The explicit separation of embedding lookup and dense forward pass is now settled as an architectural fact. This fact accurately supports the canon's understanding that X does not hold embedding tables on a single GPU but looks them up on a separate server.
  • The table scale is a vocab of 100M/100M/30M in Gen4+4 xrecsys_search, and the separate servers are the embedding server and mm_embedding_client.rs.
• Export is off by default. This commit alone cannot confirm whether production serving actually consumes StableHLO bundles. If export_stablehlo_bundle=True appears in the production config in the next commit, that is a signal that serving attached to this path.

D. An Orbax writer that saves training checkpoints with envelope encryption was introduced

• A new file wraps the handlers of Orbax (a checkpoint library for JAX) and implements envelope encryption in-tree verified — phoenix/python/training/xai-checkpointing/xai_checkpointing/orbax_encrypted.py.

  • The file is orbax_encrypted.py (288 lines), and it wraps the Orbax PyTreeCheckpointHandler.
  • Envelope encryption is a standard pattern of the AWS KMS family. A master key issued by KMS wraps a Data Encryption Key (DEK) for each directory, and the data is symmetrically encrypted with the DEK.

• Every saved file must start with a magic header, and if even one file lacks the header, the commit is refused after finalize.

  • The header is b"XAIENC01". Only _DEK and _DEK.claim (the DEK file and claim issued by KMS) are exceptions.

  • The check code is as follows:

    def assert_all_enveloped(path: pathlib.Path) -> None:
        offenders = []
        for f in sorted(path.rglob("*")):
            if not f.is_file() or f.name in ("_DEK", "_DEK.claim"):
                continue
            with f.open("rb") as fh:
                if fh.read(8) != b"XAIENC01":
                    offenders.append(f)
        if offenders:
            raise RuntimeError(
                f"encrypted save left plaintext at rest; not committing: {list(map(str, offenders))}"
            )
    

• Only array leaves are allowed in a checkpoint; string, dict, and Python scalar leaves are explicitly rejected. This restriction removes the risk of arbitrary code execution when the serving side loads this checkpoint.

  • The only allowed leaf is jax.Array, and _ArraysOnlyRegistry and _require_array_leaves enforce this.

• Metadata and the storage layer are also encrypted. The tensorstore KvStore is replaced by an encrypted wrapper, and _METADATA, _CHECKPOINT_METADATA, and the sharding metadata are all handled with encrypt_write.

• A process restored from an encrypted checkpoint cannot save in plaintext. Trying a plaintext save makes the save itself fail. This is a downgrade-prevention mechanism that blocks, at the code level, any accidental loss of encryption.

  • This is a guard newly added in checkpoint_write.py.

    if getattr(self, "_restored_encrypted", False):
        raise ValueError(
            "restored from an ENCRYPTED checkpoint but the orbax writer cannot "
            "produce encrypted saves — refusing to downgrade to plaintext saves"
        )
    

• New config fields were added that set whether to encrypt, the key, the context, and the chunk size.

  • These are the new values in CheckpointConfig.

    encrypt: bool = False
    encryption_key_id: str | None = None
    encryption_context: dict[str, str] = field(default_factory=dict)
    encryption_chunk_size_bytes: int = 8 * 1024 * 1024
    

  • encryption_context: dict[str, str] follows the AWS-KMS encryption-context pattern as is. It is a standard field that lets KMS callers bind key use to metadata.

  • The chunk size is 8 MiB by default.

• The code confirms that X encrypts training checkpoints at rest. Previously, one could only guess that this was handled at the infrastructure layer. Now envelope encryption, KMS, and magic header enforcement are in the xrex training Python code (in-tree). The source does not state a regulatory framework (SOC2, FedRAMP, GDPR, etc.) explicitly.
• The downgrade-prevention guard stands out in particular. It goes in the same direction as the VF reference_compare harness of Gen4+7, which enforced staging-only use with a panic at boot under APP_ENV=prod. It fixes policy in code as a fail-close assertion, not as a config value. This is a pattern seen across X's current cycle.

E. SID codes were added to the product info of product ads (DPA)

• A field for SID codes was added to the DPA product message in the serving proto verified — phoenix/crates/serving/xai-recsys-proto/proto/recsys.proto

  • Dynamic Product Ads (DPA) is an ad format in which the advertiser uploads a product catalog and X automatically generates ads personalized for each user.

  • The added field is repeated int32 sid_codes = 8 in DpaProductInfo.

    message DpaProductInfo {
      int64 product_key = 1;
      bool is_hero = 2;
      int64 gender_impressions = 3;
      int64 gender_clicks = 4;
      int32 gpc_l1_id = 5;
      int32 gpc_l2_id = 6;
      int32 gpc_l3_id = 7;
      repeated int32 sid_codes = 8;
    }
    

• The same commit also reserved a block of numbers in the action-name enum at once. This secures room for the ads conversion actions to expand further inferred.

  • reserved 214 to 252 (39 numbers) was reserved in the DiscreteActionName enum.

• Whether the DPA SID codebook is the same as or different from the organic post SID codebook
• Whether a server-side connection that consumes sid_codes already exists
• Whether there are A/B results

F. Other changes: the ads blender default changed and the embedding path was cleaned up

• Multimodal embedding fetch was cleaned up as a zero-copy refactor. The caller now passes the destination slice.
  • The file is phoenix/crates/serving/xai-recsys-mm-server/src/mm_embedding_client.rs (+33/−8). fetch_mm_embeddings_sync delegates to the new fetch_mm_embeddings_into(&self, post_ids, emb_dim, dest: &mut [f16]).
• Search query embeddings are now stored once instead of being copied per candidate. At serving time they are replicated only for real candidates, not for padding. Memory use and clarity improved.
  • The files are phoenix/crates/common/xai-recsys/src/util.rs (+68/−14) and phoenix/crates/serving/xai-recsys-engine/src/python.rs (+10/−2).
  • Previously, candidate_search_query_embeddings was replicated per candidate and stored as N copies in a CPU-side buffer.
  • Now, at serving time it is replicated with repeat_query_into(dest, query, n_slots) only for the real candidates, num_real_candidates(num_item_hashes, cap) of them.
• The multimodal embedding Kafka publisher in grox (the sub-repo for the Grok-based nearline classifier) moved to a multi-region producer and was restructured to be async-friendly.
  • The file is grox/flows/mm_emb/task_embedding_pub.py (+29/−26), migrated from ScramKafkaProducer to MultiRegionKafkaProducer.
• The code that injected the SCRAM password directly through an env-var was removed. It appears to have moved into the multi-region config.
  • The file is grox/core/data_loaders/kafka_loader.py (0/−16).
• The ads blender default changed to the multi-risk approach verified. It is not directly related to the VF refactor.
  • This is the only change in home-mixer's (the service that assembles the For You feed) home-mixer/params/param.rs (+2/−2). The AdsBlenderType default changed from partition_organic_low_risk to multi_risk.
  • MultiRiskAdsBlender was introduced in Gen4+9 (45b48ba, 2026-08-26). This commit appears to move the default on the production cron mirror to it.

• Added a Gen4+13 row to the one-line summary and the generation table (commit sha 7ba7768, +2,964/−2,861, 34 files).
• Created a new "Gen4+13 — visibility-filtering rules restructuring" subsection in the "Safety / visibility-filtering / labeling pipeline" section. It covers rule_spec.rs at 89 lines, tweet_rules.rs at 1125 lines, author_rules.rs at 354 lines, 9 deleted files, and the fact that the regression-prevention test checks the order of rule names as literals.
• Created three new blocks at the bottom of the "Phoenix training and index" section: "Gen4+13 SID recon mode wired into the Phoenix ranking model", "StableHLO bundle export wiring", and "envelope-encrypted Orbax checkpoint writer".
• Created a new block in the "Ads" section: "Gen4+13 DPA product SID carried in the serving wire format".
• Added 7ba7768(2026-09-01, Gen4+13) to the commit sha list in ## Sources.
• Updated the git log direct check line (2026-09-02 → 2026-09-03, 12 commits → 13 commits).
• Changed Last updated from 2026-09-02 to 2026-09-03.

• Policy semantics are unchanged, but several facts the canon did not know are now confirmed at the code layer.
  • In the X ranker, SID returns to a dense vector through an RQ-VAE-family codebook
  • The handoff from training to serving goes through a StableHLO bundle, and embedding lookup sits outside that graph
  • Checkpoints are encrypted at rest with envelope encryption (in-tree)
  • The SID of DPA ads products is carried in the serving payload
• The VF refactor is the natural next step after the golden corpus in Gen4+11 (2026-08-28). X removed a safety net, built up regression-defense assets internally instead, and settled on a sequence of thinning the representation on top of them. What was removed is the media fallback cache of Gen4+9. The assets built include the comparison harness reference_compare.rs, newly added at 812 lines in Gen4+7 (d011592). This sequence is consistent with the other commits of this cycle (dark_traffic, reference_compare, golden corpus, and this rules restructuring).
• That SID, StableHLO, and encryption landed in a single commit is more likely a pre-wiring for a specific production rollout than a coincidence inferred. All three are wired but off, so once a config gate is turned on in a later commit, we can observe which direction production moves.

↑ Contents

2TGR unifies generative ranking, retrieval, slate generation, and reasoning — Tencent

• The 13 authors are listed in a team-signature format ("TGR Team, Lei Cheng, Haonan Hu, Beibei Kong, Yudong Li, Zang Li, Yunsheng Pang, Hongyang Su, Jianchao Tu, Yunlong Wang, Bing Wen, Junzhang Zhu, Shaojie Zhu, Chengxiang Zhuo").
• The target surfaces are stated in §1 "Our setting" as "news feeds, short videos, long videos, music, and web novels". Mapped to PCG products, they are likely Tencent News, Weishi, Tencent Video, QQ Music, and the 阅文/QQ阅读 family inferred. The only basis is the kinds of surfaces; the paper body anonymizes the five surfaces as Scenarios 1–5.

This framework matters for two reasons.

• First, it is a production claim answering Kuaishou's OneRec family from the second-largest company so far. Kuaishou's OneRec-V1 → OneRec-V2 → OneRec-Think → OneReason was a single-company series, and Tencent PCG has now stated a production deployment in the same direction (one-model recommendation).
  • Paper §1 states this explicitly: "Aligned with the one-model direction of OneRec at Kuaishou".
• Second, it is the first source to name HSTU and OneRec each as a replacement target within one frame. CCFormer replaces HSTU in Scenarios 2–5, and BARGE and HiGR replace OneRec as offline baselines. It is an attempt to unify the Meta HSTU lineage (ranking) and the Kuaishou OneRec lineage (one-model) as two axes.

A. The ranking model CCFormer carries all production traffic on two surfaces

• CCFormer (TGR-GenRank) is a generative-paradigm Transformer ranker. It introduces feature-field separated cross attention, subspace token mixing, and hierarchical sequence compression. These are ranking-specific elements that inherit the HSTU lineage.
• In Scenario 1 (video recommendation) it replaces a "long-standing, iteratively optimized DLRM ranker", and in Scenarios 2–5 it replaces an "already deployed HSTU model".
• It was fully launched on two surfaces and now carries all production traffic (§3.6): "CCFormer was fully launched in Scenarios 1 and 2 and now serves the entire production traffic of both." Scenarios 3–5 are stated as being in A/B.
• The main online figures are as follows (§3.6, Table 6).
  • Scenario 1: CTR +3.57%, UCTR +1.93%, Page View +3.86%, Video View +3.47%, Watch Time +1.29%, Ad revenue +1.64%.
  • Scenario 2 (ads ranking): Ad revenue +1.71%.
• It states that it trains faster with less compute than HSTU (§3.5): "scales predictably at roughly half the GFLOPs of HSTU, trains 2.21× faster."

B. The generative retrieval BARGE was fully deployed as one retrieval channel

• BARGE (TGR-GenRec) is a retrieval that generates hierarchical semantic IDs, and it targets two structural gaps (Abstract): "two structural gaps in hierarchical semantic-ID generation — the loss of item boundaries when multi-token items are flattened and semantic drift caused by early prefix errors."
• The structure has three parts: item context-aware attention, hierarchical path reranking, and orthogonal dual-path decoding. The paper also calls the first "item-boundary-aware".
• The codebook is stated in Table 1 as "OSQ-VAE (dual)". The detailed training objective in §4.2 was not within the fetch range of this daily, so a deep dive is needed.
  • The relationship to the TIGER family (the RQ-VAE lineage that Kuaishou HD-Rec and Alibaba MetaStrategy refer to) is mentioned in the table as "TIGER lineage". However, we could not confirm the codebook initialization approach (whether RQ-KMeans is used).
• It was fully launched as one of the retrieval channels and exists alongside the other retrieval channels (Abstract): "is fully rolled out as a generative retrieval channel with parameters, beam width, and serving latency unchanged, delivering +0.60% CTR and +1.70% total reading time — gains that grew larger and more stable after full launch."
• Offline, Hit@5 was higher than OneRec: "outperforms OneRec by 10.2–16.9% in Hit@5 across two industrial scenarios." Online, CTR rose +0.60% and reading time rose 1.70%.

C. HiGR, which generates whole slates, stopped at A/B

• HiGR (TGR-GenRec) generates whole slates. It consists of a PCRQ-VAE (Prefix-Contrastive RQ-VAE) tokenizer, coarse-to-fine decoding in the Hierarchical Slate Decoder (HSD), and listwise multi-objective alignment.
• Paper Table 1 compares it with OneRec-V1/V2/Think axis by axis. The concrete implementation of "prefix-structured semantic IDs" and the stage-by-stage decoding of HSD are outside the fetch range, so a deep dive is needed. The mentions of Meituan OneSug and Xiaohongshu RankMixer were not confirmed within this paper's fetch range.
• There is no statement of a full launch; it stops at A/B. The Abstract says: "serves whole slates below 50 ms P99 latency at roughly 60% lower GPU demand than full-sequence decoding." It also says "consistently lifts engagement, traffic consumption, and commercial value across three A/B-tested scenarios".
• Offline, slate quality is higher and inference is faster than a matched-capacity OneRec: "improves offline slate quality by 15.9–21.3% over matched-capacity OneRec with a 5× inference speedup." In the three online scenarios, Average Watch Time rose +1.22%, Average Video Views rose 1.73%, CTR rose 0.68%, and ad revenue rose 0.56%.

D. TGR-Reason injects reasoning tokens made of semantic IDs, not text, into decoding

• Offline, a Think model produces reason tokens in semantic ID form, and during online decoding these are injected as a prompt to condition it (Abstract): "Offline, a LatentRec-trained Think model materializes complete semantic-ID reason tokens; Direct Reasoning Injection uses them as hierarchy-aligned prompts to condition online decoding."
• The reason tokens are thinking tokens in semantic ID form, not a text CoT. The Table 1 caption defines them as "reasoning-enriched semantic IDs generated offline by a LatentRec-trained Think model".
  • The Think model learns latent reasoning and exports the result offline as a semantic ID corpus; at serving time these SIDs are injected as a prompt to condition decoding.
  • The approach is similar to Kuaishou PushDualGen (a combination of SID and skippable copy), but here the copy is an SID rather than text.
• The deployment status is expressed only as "statistically significant gains", and it is not a full launch. The surface it applies to is anonymized as "one of our commercial content platforms".
• Offline, it states that it raised Hit@1 for cold-start new users, but it does not disclose the absolute baseline value: "raises cold-start new-user Hit@1 by +477.8%". Online, Effective Consumption Rate rose +1.75% and new-user Exposure-to-Conversion Rate rose 13.09%.

E. The offline comparison used two public datasets and a Tencent industrial dataset (§3.4)

• The public datasets are Taobao and KuaiRec (Table 2).
• The industrial dataset is one month of production logs from a Tencent recommendation system (§3.4): "industrial dataset of one month of production logs from a Tencent recommendation system: over 4 billion samples, 3 million users, and 10 million items."
• The baselines are DIN, DeepFM, SASRec, MIMN, HSTU, OneTrans, and STCA on the public benchmarks, and HSTU, OneTrans, and STCA on the industrial benchmark.
• The qualitative comparison targets in Table 1 are HSTU, OneTrans, OneRec-V1, OneRec-V2, OneRec-Think, OneReason, GPR, and PinRec. HLLM, PinnerFormer, TIGER, and LC-Rec did not appear explicitly within the fetch range.

"Within Tencent's Platform and Content Group (PCG), recommendation runs across a deliberately heterogeneous portfolio of surfaces — news feeds, short videos, long videos, music, and web novels — which together serve hundreds of millions of daily active users." — arXiv 2609.00986v1 §1

"delivers statistically significant lifts in all five A/B-tested production scenarios (+3.57% CTR in the video-recommendation scenario; +1.71% advertising revenue in the advertising-ranking scenario)" — arXiv 2609.00986v1 Abstract

• This is the first source in which HSTU and OneRec are each named as a replacement target within one frame. Until now, the canon's understanding was that the HSTU lineage is the standard for Meta ranking and the OneRec lineage is Kuaishou's one-model direction. TGR unifies these two lineages as different components: CCFormer replaces HSTU, and BARGE and HiGR replace OneRec.
• The strongest deployment claim is CCFormer, not BARGE or HiGR. CCFormer is the only one carrying the entire traffic in two scenarios ("fully launched, now serves the entire production traffic of both"), and the other scenarios are in a state where they could move toward launch. BARGE launched as one retrieval channel, and HiGR stops at A/B. Tencent expressed confidence in ranking, but not yet in retrieval and slate generation.
• The reason token is an SID. Where Kuaishou PushDualGen combined SID with skippable copy (text), TGR-Reason puts a semantic ID, not text, in the copy role. It can be reinterpreted as an SID CoT rather than a text CoT.
  • Spotify Research (2608.23154) reported in a controlled experiment that "explicit reasoning traces lower offline effectiveness in both SFT and RL", and TGR-Reason contrasts directly with this. TGR-Reason does not use text traces, so it effectively sidesteps Spotify's counterexample.
• The items to deep dive in the next cycle are the six below. All are outside the scope of this daily, so they are marked as needing a deep dive and left as follow-up work that a person starts manually.
  • The training objective and initialization of the BARGE OSQ-VAE codebook (RQ-VAE or RQ-KMeans, TIGER family or newly introduced)
  • The concrete implementation of item-boundary-aware attention (a mask or a loss term)
  • The Prefix-Contrastive objective of HiGR PCRQ-VAE and its actual difference from OneRec SID
  • The backbone of the Think model (Hunyuan? Qwen? an in-house LLM?) and the scale of the reason token corpus
  • The absolute baseline value behind cold-start Hit@1 +477.8%
  • The actual Tencent product mapping of Scenarios 1–5 (whether it can be confirmed from external announcements or blog posts)

↑ Contents

3Two of 30 new arXiv papers passed the radar criteria — arXiv

Of today's 30 new arXiv cs.IR papers (parsed successfully, lookup normal), 2 passed the acceptance criteria and the other 28 were rejected. The acceptance criteria are platform-company authors or a production deployment or A/B statement.

• Tencent PCG's TGR (arXiv 2609.00986) was read in detail in §2 above. As soon as it passed, it was folded into the canon in the SID thread and also registered separately in New this month.
• ByteDance's ReST (arXiv 2609.01240) is a rec-native Transformer ranking framework deployed on TikTok Shop Ads. It was added to radar.md New this month.
  • All 12 authors are affiliated with ByteDance.
  • The components are dual-gated attention, rotary positional/temporal embedding, stabilized residual normalization, training-only auxiliary objectives, and a heavy reusable encoder with a lightweight cross decoder (projection-free KV attention).
  • It states that it ran a one-week online A/B test: "conduct a one-week online A/B test on TikTok Shop Ads, one of the largest advertising platforms".
  • It reports the result as follows: "This latency-constrained configuration improves AUC by +1.31% and lifts Advv by a statistically significant +11.93% (p<0.01), while satisfying all other monitored production guardrails".
  • It then states the deployment: "ReST has since been fully deployed in production".
  • It kept 50 ms P99 latency, and the large size is 5.36M–5.69M parameters.
  • In the scaling law thread, this is the fourth company statement, after Meta HSTU/Wukong/LLaTTE and Alibaba TransRetrieval.
  • It claims that rec-native design scales consistently at the sequence length, depth, and width where LLM-style Transformer blocks saturate.

Most of the 28 rejected papers fall into three groups: papers without a platform production statement, such as benchmark, evaluation, and RAG methodology papers; academic experiments restricted to a domain, such as POI, medical, science, and e-commerce; and papers whose author affiliation could not be confirmed. Only two of these are kept as adjacent sources.

• CoGR (arXiv 2609.00638) "It Takes Two to Match: Co-Evolving Generative Retriever with Reinforcement Learning" has only offline benchmarks and no production deployment statement.
  • The authors are Runpeng Dai (UNC Chapel Hill) and Kaili Huang, Changsung Kang, and Ciya Liao (affiliated with Apple) observed 2026-09-03 — the affiliations were checked in the author list of the paper HTML.
  • It trains keyword generators on both the query and item sides symmetrically through GRPO-based co-evolving RL.
  • It states that on an internal dataset ("Internal APP Marketplace") and a public benchmark (WANDS), F1 was higher by +10.9% / +36.1% respectively than 10 sparse/dense/generative baselines.
  • Given the Apple affiliation of Kang and Liao and the dataset name, it is presumably the App Store, but the paper does not disclose the company name.
  • It was rejected because it did not meet the production condition of the radar acceptance criteria.
• UEWM/WMG-RL (arXiv 2609.01067) "World Model-Guided Reinforcement Learning via Counterfactual User Engagement Simulation" was rejected because it has no production statement.
  • The authors are Ang Li and 7 others.
  • It builds offline reward supervision with a user simulator (UEWM). When the policy proposes several candidates, UEWM predicts feedback for each candidate in parallel and converts it into a dense reward.
  • It claims that a 1.7B student matches or surpasses a large LLM in downstream recommendation.
  • We will review it again if the user simulator line appears as a production statement from another company.

↑ Contents

Radar

• Tencent PCG's TGR (arXiv 2609.00986) is the first case to name HSTU and OneRec each as a replacement target in one frame. It was folded into two places: radar.md New this month and the generative retrieval / semantic ID thread.
  • The 4-in-1 composition is CCFormer (ranking), BARGE (generative retrieval), HiGR (slate generation), and TGR-Reason (SID reason token injection).
  • CCFormer was fully launched in Scenarios 1 and 2 and replaces HSTU. It reported CTR +3.57%, ad revenue up 1.71%, half the GFLOPs of HSTU, and 2.21x faster training.
  • BARGE was fully rolled out as a retrieval channel, with Hit@5 +10.2–16.9% over OneRec.
  • HiGR reports slate quality +15.9–21.3% over OneRec at 5x speed.
• ByteDance's ReST (arXiv 2609.01240) was fully deployed on TikTok Shop Ads. It was folded into radar.md New this month.
  • In a one-week A/B it obtained AUC +1.31% and Advv +11.93% (p<0.01), under a 50 ms P99 condition.
  • It claims that the rec-native Transformer scales more consistently than LLM blocks in sequence, depth, and width.
  • This is the fourth company statement in the scaling law thread.

↑ Contents

What to check next

↑ Contents