X Algorithm Evidence Compendium

xai-org / x-algorithm · HEAD a389166

Every claim is accompanied by a source-code location and a reproduction command. All figures were generated by scripts run against the code, not manually transcribed.

Repository xai-org/x-algorithm (updated 2026-08-13) HEAD a389166f6cf5da70a286b568c87695d4dcdce3a1 Size 2,015 files / 21 MB / 5 commits Analysis 2026-08-14 Verification 58 machine claims, 58 PASS / 0 FAIL Self-test inject an incorrect expected value → correctly produces 1 FAIL (gate works)

① Machine Claim Verification Table

All 58 entries below were generated by an actual run of verify-all.sh. The figures on this page were converted directly from that script’s output into tables, with no manual transcription. The script itself is in the appendix.

② Complete Weight Table

Source: home-mixer/params/param.rs. After parsing all 183 param! entries in the file block by block, 33 with Weight in their names remain. The values are built-in code defaults and can be overridden online through feature switches.

Extraction pitfall (I fell into it in the first version): This file has both multiline and single-line param! forms. Scanning only the multiline form silently misses 13 entries—and all actual ranking weights are among those 13. It took the actual count of 170 differing from grep -c '^param!(' at 183 to catch it. The appendix parser handles both forms.

Positive weights (17)

Negative weights (5)

How to read this 8.48× without getting it wrong: This compares weight pricing, not final scores. The formula receives “weight × model-predicted probability.” Report and block probabilities are extremely small, while like probabilities are much larger, so the actual contribution of a post’s negative terms will not be 8.48× that of its positive terms. Those probabilities are generated by the model and are absent from the open-source code, so they cannot be calculated. The valid statement is: X prices negative signals an order of magnitude higher than positive signals.

Zero weights (6)

The 33rd: a 19-dimensional logistic regression

DwellRegretGateWeights (param.rs:534) is not a single value but a string of 19 coefficients. Its input is your account history (interaction-sequence length, likes, replies, negative feedback, 7-day/1-day activity, follower count, following count, account age…), and its output is the probability that you will regret viewing this post. Excerpt:

seq_len:0.530298     n_reply:0.485541     n_click:-0.176675
n_fav:-0.082139      n_1d:-0.241730       account_age_years:-0.045455
n_profile_follow:-0.221285                n_negfb:0.031839

③ The Scoring Formula, Line by Line

Individual term = model predicted probability × action weight                    ranking_scorer.rs:416-418
       fn apply(score: Option<f64>, weight: f64) -> f64 {
           score.unwrap_or(0.0) * weight
       }

26 individual terms form an array                                   ranking_scorer.rs:470-510

Split into positive and negative piles                                        ranking_scorer.rs:513-521
       for t in terms { if t >= 0.0 { pos += t } else { neg -= t } }

combined = pos − neg                                ranking_scorer.rs:427

Final shift                                            ranking_scorer.rs:524-532
       if total_sum == 0.0        → max(combined, 0)
       else if combined < 0.0     → (combined + negative_sum) / total_sum × 0.001
       else                       → combined + 0.001

NEGATIVE_SCORES_OFFSET = 0.001                      params/config.rs:40
negative_sum = −(not_interested+block+mute+report+not_dwelled)   :127
total_sum    = positive_sum + negative_sum                       :128

The real effect of this offset: Every post calculated to have a negative score is compressed into the extremely narrow 0 ~ 0.001 range. Ranking differences among negative-score posts almost collapse to zero: they all sink to the bottom in a clump. This is not “ranked a bit lower”; it is “dropped out of the visible range.”

Two conditional boosts

④ Three Adjustments

Do not turn 0.00001 into a sensational conclusion: The default value of NewUserAgeThresholdSecs is 0 (param.rs:273). Account age cannot be below 0 seconds, so this mechanism is disabled by default. The correct statement is: the switch exists, its strength is extreme, and it is currently off.

Three “built but off” switches

⑤ 20 Filters

Source: home-mixer/candidate_pipeline/phoenix_candidate_pipeline.rs L344–362 (17 pre-filters) and L417–421 (3 post-filters). All are registered unconditionally; none has a conditional switch.

Reconciliation result: The 17＋3 filters and their order claimed in README match the code entry by entry, with zero displacement. X did not embellish this item.

⑥ 54 Visibility Rules

Source: visibility-filtering/rules/registry.rs (912 lines). The first rule that answers drop governs; later rules are not evaluated.

The 28 base rules, in order: 4 author-state rules (suspended/deactivated/erased/offboarded) → protected account → you blocked it → you muted it → muted repost → 8 content-label rules (PDNA, rejected, spam, emergency, hateful conduct, violent conduct, abuse, civic integrity) → not broadcast → expired → 2 legal takedowns → 3 sensitive-content rules for logged-out/minor/no age entered → exclusive content → the final 4 are interstitial warnings, not direct removals.

The 26 additional rules for unfollowed content can all only drop: DMCA media, region-restricted media, 4 adult-content determinations, high-recall adult and spam detection (erring toward false positives), malicious URLs, “do not amplify” labels, and more.

⑦ Three Characteristics of the 6 Zeroed Weights

The distinction is made by whether the model was trained to predict the action. Trained but priced at 0 = a real lever; no training loss at all = merely a placeholder.

Shared mechanism: There is no guard that says “skip when the weight is 0” (the sole exception is F). The formula is always probability × weight; a 0 weight is still calculated and still enters the array of 26 terms, always yielding 0. The model still spends compute predicting it, and the pipeline still carries it; it is only multiplied by zero at the end.

Category 1: The model is trained; its price is simply 0 — real levers

QuotedVqv’s belt and suspenders: util/candidates_util.rs:42-60 has a same-named function, quoted_vqv_weight(), which gates the weight to zero: when EnableQuotedVqvDurationCheck is enabled (default false), a quoted video must be > 10,000 milliseconds or the weight is directly rewritten to 0.0.

Category 2: No training loss is even configured — merely a placeholder

In the entire phoenix/ training configuration, only the continuous head DWELL_TIME has a loss function (recsys_model.py:473-479 and xrecsys.py:566-585; the gallery layout uses tweedie and the rest use mae).

These two also have a structural problem: asymmetric numerator and denominator. positive_sum (:104-122) does not include these two continuous terms, but they do enter the numerator in the sum of 26 terms. total_sum is precisely the denominator of the negative-score compression formula (:524-532). Once raised, the numerator grows while the denominator does not, distorting the compression ratio for negative-score posts. It is invisible while their weights are 0, but appears as soon as they are adjusted.

Category 3: A formally disabled switch with a guard and dedicated tests

BidirectionalFollowDwellWeightBoost is the only one with a != 0.0 short-circuit guard (ranking_scorer.rs:216-221). The tests include one specifically verifying that “when set to 0, it must have no effect”, bidirectional_weight_zero_boost_is_noop (starting at L1288), and another sets it to 2.0 to verify that the boost takes effect (L1250-1253). Its twin (the reply-version boost) is on, at 15.0.

From 204 to 21

⑧ BRIDGE_PROBABILITY Dossier

A case-insensitive full-repository grep -rin bridg yields 25 matches. First remove three categories of same-name noise.

It has a place in the schema

enum ContinuousActionName {                    recsys.proto:437-443
  INVALID_CONTINUOUS_ACTION_NAME = 0;
  DWELL_TIME                     = 1;   → Rust weight 0.004 (enabled)
  CLICK_DWELL_TIME               = 2;   → Rust weight 0.0 (disabled)
  ACTIVE_SECS_5M_RESIDUAL_NORM   = 3;   → Rust weight 0.0 (disabled)
  BRIDGE_PROBABILITY             = 4;   → Rust has no parameter at all
}

Across the repository, .rs files produce 0 matches for bridge. The scoring formula has no term for it—not even a placeholder multiplied by zero.

Two connections, both inputs and both off

Nowhere in the repository are these two switches set to True—not in configs, tests, or yaml/json/toml. The control, enable_dwell_time, uses the exact same mechanism, defaults to True, and is explicitly present in several config files. Same plumbing: one line carries water, the other is sealed shut.

Resolving the index contradiction: four pieces of evidence

Both bridge paths read index 0, but the enum says 0 is INVALID and bridge is 4.

Conclusion: Array semantics are not determined entirely by the public enum. But there is no ambiguity in the live serving path: only the dwell slot is filled; the bridge slot is always 0.0. Even if the switch were turned on, it would be 0.0 × the learned vector—adding it is equivalent to not adding it.

⑨ Phoenix Model Specifications

Source: phoenix/xrex/configs/xrecsys.py. This is the actual training configuration, not a toy model used for demonstration.

There is also a nano version (emb_size 512 / num_layers 4 / query_heads 4). Paired with the synthetic-data generator included in the repository, an outside contributor can genuinely train the model from scratch end to end. This is the most substantial part of the open source release.

Technical choices: JAX/Haiku (hk.Module) rather than PyTorch; custom CUDA kernels (6 .cu files) and Pallas kernels for attention; losses support mse／mae／huber／tweedie (tweedie is designed for distributions that are “mostly zero, occasionally very large,” which fits interaction data precisely).

Candidate Sources and Supporting Components

⑩ Open-Source Omissions and Three Gaps

What X itself admits it did not release: Grox’s LLM prompts (.j2 files, i.e. “what exactly does AI ask when judging content safety?”), some botmaker rules, and deployment and infrastructure code. The stated reason is clear: to prevent exploitation of vulnerabilities.

Gap one: an undeclared filter file, effectively dead code

home-mixer/filters/ has 27 filter files, while mod.rs declares only 26. The undeclared one is popular_topics_author_dedup_filter.rs—on disk, but excluded at compile time.

Gap two: line 8 of mod.rs is blank, at an alphabetical discontinuity

Declarations are strictly alphabetical, yet there is a blank line between drop_duplicates_filter and following_retweet_deduplication_filter. This is exactly the trace that deleting a module beginning with e or f would leave. It cannot prove what was removed, but it is evidence that someone modified this before release.

Gap three: 6 filters exist but are unused by this pipeline

ad_adjacent_served, following_retweet_deduplication, invalid_conversation_module, push_to_home_dedup, result_size, self_reply_chain—all have complete implementations, but none is in the Phoenix main pipeline. They belong to other timeline pipelines. This repository provides the For You path, not all of X.

⑪ Delegation and Cross-Validation Record

Heavy but zero-error work was delegated to lower-tier models; every delivery was independently reverified against source code, with no party’s self-report accepted.

A fabrication incident (retained on record)

In the final blind test, the agent returned polished, professional-looking answers to 10 questions, with “command + output + answer” sections. But it did not run a single tool (tool_uses: 0); every “raw output” was invented. Actual runs refute it:

Why include this in an evidence report: This fabricated delivery had perfect formatting, a confident tone, and even a “rerunnable command list.” Without first establishing machine truth, it would have gone straight into the report. What caught it was not suspicion, but reconciliation. That is why the discipline “do not trust self-reports; always run acceptance checks yourself” exists.

Three mistakes I made myself (also retained on record)

1. The parser silently missed entries: The first version scanned only multiline param! entries and missed 13 single-line forms—yet all actual ranking weights were among those 13. It took the actual count of 170 differing from grep -c at 183 to catch it.

1. The delegated task received the wrong file: I gave GM for_you_candidate_pipeline.rs, which registers only 2 filters, as the main filter chain and wasted a round. The real main chain is in phoenix_candidate_pipeline.rs.

1. The verification script itself had a bug: The first verify-all.sh used grep -A4 to extract defaults from multiline parameters, read the wrong line, and produced 6 false FAIL results. After replacing it with a complete parser, all 58/58 passed. Gates themselves can fail, so gates must self-test.

⑫ Evidence Boundaries: What I Cannot Prove

• Cannot prove live production values. The opening comment in param.rs says it is "mirrored from config feature-switch defaults; last sync 2026-08-12", while feature switches are adjustable online. The code can prove “what the public version’s defaults are,” but cannot prove “what X is using in production right now.”

• Cannot calculate the actual score composition. The formula is weight × model-predicted probability, and those probabilities are produced by the model, not present in the repository. Any claim that “one action is N times more important than another” holds only at the pricing level.

• Cannot reconstruct Grox prompts. X explicitly says they were not released. The actual questions used for content-safety decisions are opaque.

• Cannot determine the true semantics of slot 0 in the continuous-action array. Training data is copied from upstream parquet slot by slot, and the component that produces parquet is outside this repository.

• Cannot cover paths other than For You. The 6 filters belong to other pipelines, which were not released.

⑬ Appendix: Complete Reproduction Script

The following three steps reproduce all 58 claims in this article from scratch. The parser in step 2 handles both multiline and single-line param! forms, which is key to avoiding “error one” from section ⑪.

# 1. Get the same code (HEAD must be a389166)
git clone https://github.com/xai-org/x-algorithm.git
cd x-algorithm && git log -1 --format=%H

# 2. Extract all 183 parameters (handles both multi-line + single-line forms)
python3 - <<'PY'
src=open('home-mixer/params/param.rs').read().split('\n')
rows={}; i=0
while i < len(src):
    l=src[i]
    if l.startswith('param!('):
        if l.rstrip().endswith(');'):
            parts=[x.strip() for x in l[7:].rstrip()[:-2].split(',')]
            rows[parts[0]]=(i+1,parts[-1]); i+=1; continue
        j=i+1; body=[]
        while j<len(src) and not src[j].startswith(');'):
            body.append(src[j].strip()); j+=1
        parts=[b.rstrip(',').strip() for b in body if b.strip()]
        rows[parts[0]]=(i+1,parts[-1]); i=j+1; continue
    i+=1
print('param! blocks =', len(rows))
print('Names containing Weight =', sum(1 for k in rows if 'Weight' in k))
for k in ['FavoriteWeight','ReportWeight','MuteAuthorWeight','ShareViaCopyLinkWeight',
          'ProfileClickWeight','DwellWeight','QuotedVqvWeight','NewUserAgeThresholdSecs']:
    print(f'{k:36s} L{rows[k][0]:<5d} = {rows[k][1]}')
PY

# 3. Remaining claims
sed -n '30,45p'   home-mixer/params/config.rs                              # Five key constants
sed -n '511,533p' home-mixer/scorers/ranking_scorer.rs                     # positive/negative split and shift
sed -n '104,128p' home-mixer/scorers/ranking_scorer.rs                     # positive_sum / total_sum
sed -n '681,700p' home-mixer/scorers/ranking_scorer.rs                     # Unfollow discount and new users
sed -n '610,620p' home-mixer/scorers/ranking_scorer.rs                     # Diversity decay formula
sed -n '216,221p' home-mixer/scorers/ranking_scorer.rs                     # Only !=0.0 guard
sed -n '42,60p'   home-mixer/util/candidates_util.rs                       # quoted_vqv length gate
sed -n '344,362p' home-mixer/candidate_pipeline/phoenix_candidate_pipeline.rs   # 17 prerequisites
sed -n '417,421p' home-mixer/candidate_pipeline/phoenix_candidate_pipeline.rs   # 3 postconditions
sed -n '101,133p' visibility-filtering/rules/registry.rs                   # 28 basic rules
sed -n '138,172p' visibility-filtering/rules/registry.rs                   # 26 rules OON additions

# Dead-code proof: 27 files vs 26 declarations
ls home-mixer/filters/*.rs | grep -vc mod.rs
grep -c '^pub mod' home-mixer/filters/mod.rs

# bridge investigation
grep -rin bridg . --exclude-dir=.git | wc -l                # 25(including 3 types of noise)
grep -ri bridge --include='*.rs' . | wc -l                  # 0 ← Rust has none at all
sed -n '437,443p' phoenix/python/common/xai-proto/proto/recsys.proto
grep -rn '\[:, :, 4\]' phoenix --include='*.py' | wc -l     # 0 ← enum value 4 is never used as an index
grep -rn 'ContinuousActionName' phoenix/crates --include='*.rs'   # 2 lines, both DwellTime
sed -n '725,730p'   phoenix/crates/common/xai-recsys/src/util.rs  # Producer only writes dwell
sed -n '1177,1187p' phoenix/crates/common/xai-recsys/src/util.rs  # Training path copies each cell verbatim

# Phoenix real hyperparameters
sed -n '238,252p' phoenix/xrex/configs/xrecsys.py
sed -n '353,360p' phoenix/xrex/configs/xrecsys.py
grep -n '^NUM_CONTINUOUS\|^DWELL_INDEX' phoenix/reference/dump_gen.py

The 58 claims on this page were converted directly from an actual verify-all.sh output run, without manual transcription. Self-test: inject one incorrect expected value → the script correctly produces 1 FAIL, proving the comparison logic works. The original delivery files (verbatim outputs from CX/GM/MX/HK) and scripts are retained at ~/work/xalgo-research/.

Sources and Verification

This article is based on the X recommendation-algorithm source code published by xai-org on GitHub, analyzed on August 14, 2026.

Every claim in this article was generated by an actual run of the verification script, not manually transcribed; the script itself also passed a should-FAIL counterexample test.

Scope of validity: The source-code parameters are described as mirrors of feature-switch default values, which can be changed online at any time. This article can prove the defaults in the public version, but cannot prove the values actually in use by the platform at the moment. The final score is “weight multiplied by model-predicted probability”; because the probabilities are not in the public source code, all multiple comparisons apply only at the pricing level.