Open source · leggi dal codice sorgente
Il 13 agosto 2026, X ha pubblicato i pesi di ranking numerici che aveva trattenuto a gennaio. La maggior parte dei dati che circolano sull'“algoritmo di X” sono errati — di solito perché erano corretti per il modello del 2023, che non esiste più. Ogni numero su questa pagina è un link alla riga del codice sorgente da cui proviene, bloccato a un commit specifico.
182
parametri attivi
modificabili senza un deploy
23
costanti compilate
richiedono una modifica al codice
135
componenti della pipeline
fonti, filtri, scorer
12
affermazioni verificate
ciascuna rispetto alla sua riga sorgente
2798
account nominati nel codice
rimossi da Per Te a meno che tu non li segua
Incolla un link a qualsiasi post pubblico. Otterrai le regole che si applicano effettivamente ad esso — incluse le restrizioni per paese che possono nasconderlo — lette dal commit bloccato.
I pesi
X states it runs cron scripts that set the defaults in the repository's code to be the primary production values, and aims for experiments running at 10% or more of traffic to be visible in the repository. The values below are those defaults, read at the pinned commit.
Questi sono i pesi che lo scorer applica — misurati, non promessi. Prima del punteggio, `perturbed()` moltiplica 25 dei 27 pesi sottostanti per `(sigma * perturbation_sign(salt, user_id, head)).exp()` — il segno è fisso per spettatore e per head. I 2 che lascia invariati sono i pesi modificatori: BidirectionalFollowDwellWeightBoost, BidirectionalFollowReplyWeightBoost. `WeightPerturbationSigma` e `WeightPerturbationSalt` sono feature switch: X può modificarli senza rilasciare codice. Al commit fissato `WeightPerturbationSigma` è 0.0, e la condizione `sigma <= 0.0` li restituisce invariati. Leggilo alla fonte
Ogni riga contiene il codice da cui è stata letta — premiSpiegaper espandere le righe effettive di Rust, senza lasciare la pagina.
| Azione | Peso | vs un like | Fonte |
|---|---|---|---|
| binaryMultiplies the predicted probability of a discrete action. | |||
| share via copy linkShareViaCopyLinkWeight | 20 | 40× | |
| quoteQuoteWeight | 5 | 10× | |
| replyReplyWeight | 5 | 10× | |
| share via dmShareViaDmWeight | 5 | 10× | |
| follow authorFollowAuthorWeight | 4 | 8× | |
| shareShareWeight | 2 | 4× | |
| retweetRetweetWeight | 1 | 2× | |
| favoriteFavoriteWeight | 0.5 | 1× | |
| clickClickWeight | 0.3 | 0.6× | |
| open linkOpenLinkWeight | 0.2 | 0.4× | |
| video openVideoOpenWeight | 0.07 | 0.1× | |
| dwellDwellWeight | 0.05 | 0.1× | |
| photo expandPhotoExpandWeight | 0.05 | 0.1× | |
| quoted clickQuotedClickWeight | 0.05 | 0.1× | |
| post unexploredPostUnexploredWeight | 0.02 | 0× | |
| profile clickProfileClickWeight | 0 | — | |
| quoted vqvQuotedVqvWeight | 0 | — | |
| vqvVqvWeight | 0 | — | |
| not dwelledNotDwelledWeight | -0.02 | −0× | |
| block authorBlockAuthorWeight | -31.2 | −62× | |
| not interestedNotInterestedWeight | -47.52 | −95× | |
| mute authorMuteAuthorWeight | -58.8 | −118× | |
| reportReportWeight | -234 | −468× | |
| continuousApplies to a quantity (watch or dwell seconds), not a probability. | |||
| cont click dwell timeContClickDwellTimeWeight | 0.4 | — | |
| cont dwell timeContDwellTimeWeight | 0.004 | — | |
| modifierNot a head weight: adds to another weight, or gates a branch. | |||
| bidirectional follow reply weight boostBidirectionalFollowReplyWeightBoost | 15 | — | |
| bidirectional follow dwell weight boostBidirectionalFollowDwellWeightBoost | 0 | — | |
Il raggruppamento in binario, continuo e modificatore è nostro — the weights struct and each field's use in vm-ranker/scoring/value_model.rs. X non pubblica questa tassonomia; li separiamo perché solo quelli binari sono confrontabili tra loro.
Imposta una probabilità prevista per ogni azione e osserva il suo contributo al punteggio. Qui vengono offerti solo i pesi che moltiplicano una probabilità — questa è l'aritmetica che il codice esegue effettivamente.
Perché qui non esiste un “equivalente dei Mi piace”: Weights multiply a predicted probability, not an engagement count. Dividing one weight by another does not yield an exchange rate between actions.
Verifica delle affermazioni
Queste non sono invenzioni. La maggior parte erano cifre accurate per il 'heavy ranker' che Twitter ha pubblicato nel 2023, una pipeline Scala che da allora è stata sostituita. Hanno continuato a circolare dopo che la cosa che descrivevano ha cessato di esistere.
Ogni affermazione qui sotto include le ricerche che la supportano — il pattern, i file, il conteggio — così puoi eseguirle tu stesso contro il commit bloccato. Non ne vedrai mai una qui che ci contraddice: se lo facesse, questa pagina non riuscirebbe a essere costruita piuttosto che pubblicare la frase che smentisce.
Contradicted by the source
“Una ripubblicazione vale 20 volte un 'mi piace'.”
RetweetWeight è 1.0 e FavoriteWeight è 0.5, quindi una ripubblicazione ha il doppio del peso di un 'mi piace' — non venti volte.
Da dove proviene: Nessuna versione pubblicata dell'algoritmo ha mai usato 20. L''heavy ranker' del 2023 ha anche pesato il retweet a 1.0 contro il 'mi piace' a 0.5.
Was true, of an older version
“Una risposta vale 27 volte un 'mi piace' (o 13.5 volte).”
ReplyWeight è 5.0 contro FavoriteWeight 0.5, quindi dieci volte — e quaranta volte tra follower reciproci, perché BidirectionalFollowReplyWeightBoost aggiunge 15.0 al peso della risposta per i post originali tra account che si seguono a vicenda.
Da dove proviene: Entrambi i valori erano reali, per un modello che non esiste più: l''heavy ranker' del 2023 ha pubblicato 27 il 31-03-2023, poi 13.5 il 05-04-2023. Descrivono una pipeline Scala sostituita da quella attuale in Rust.
Was true, of an older version
“I clic sul tuo profilo valgono 12 volte un 'mi piace'.”
ProfileClickWeight è 0.0. Un clic sul profilo non contribuisce in alcun modo al punteggio ponderato.
Da dove proviene: 12.0 era il peso del 2023 per `good_profile_click` — un segnale diverso e composto (aprire un profilo E poi mettere 'mi piace' o rispondere). Il modello attuale ha un semplice 'profile-click head', pesato a zero.
No such parameter exists
“Un segnalibro vale 10 'mi piace' — i segnalibri sono il segnale più forte.”
Non c'è un peso per i segnalibri in param.rs, quindi i segnalibri non entrano affatto nel punteggio ponderato. Non sono, tuttavia, invisibili: bookmark_count viene 'idratato' su ogni candidato come una caratteristica del modello, e ClientTweetBookmark conta come un'interazione positiva nella cronologia dello spettatore. Letti, ma non pesati.
Da dove proviene: L'aggiornamento Scala del 2025 ha dichiarato un parametro home_mixer_model_weight_bookmark — con un valore predefinito di 0.0. Nessuna versione pubblicata lo ha mai pesato a 10.
Cosa abbiamo cercato, al commit bloccato
Non c'è un peso per i segnalibri in param.rs
bookmark · 2 file · 0 corrispondenze
bookmark_count viene idratato su ogni candidato come una caratteristica del modello
bookmark_count · 1 file · 5 corrispondenze
ClientTweetBookmark conta come un'interazione positiva nella cronologia dello spettatore
ClientTweetBookmark · 1 file · 1 corrispondenza
Right numbers, wrong reading
“Una segnalazione annulla 468 'mi piace' (−234.0 ÷ 0.5).”
L'aritmetica è corretta e la conclusione è comunque sbagliata. I pesi moltiplicano una PROBABILITÀ PREDETTA, non un conteggio di azioni. X afferma che la probabilità di base di una segnalazione è più di mille volte inferiore a quella di un 'mi piace', quindi dividere un peso per un altro non fornisce un tasso di cambio tra le azioni.
Da dove proviene: Questo non è obsoleto — è un'interpretazione errata di numeri corretti, e appare anche su pagine che pubblicano la tabella giusta. X ha aggiunto un avviso esplicito a riguardo nel suo README il 14-08-2026.
No such parameter exists
“La velocità di coinvolgimento conta 1000×, l'autorità dell'autore 50×, la recenza 22×.”
Nessun parametro denominato per velocità, autorità o recenza esiste in param.rs. L'età non è affatto un peso — è un taglio netto: AgeFilter elimina qualsiasi post più vecchio di MAX_POST_AGE, una costante compilata di 48 ore. Nulla moltiplica il punteggio di un post per la sua freschezza.
Cosa abbiamo cercato, al commit bloccato
Nessun parametro denominato per velocità, autorità o recency esiste in param.rs
velocity|authority|recency · 1 file · 0 corrispondenze
AgeFilter elimina qualsiasi post più vecchio di MAX_POST_AGE
AgeFilter::new\(.*MAX_POST_AGE · 1 file · 1 corrispondenza
Contradicted by the source
“Un gruppo coordinato può seppellire il tuo post segnalandolo in massa o bloccandolo in massa.”
X affronta questo direttamente nei commenti di param.rs, e il meccanismo che descrive è verificabile: il modello predice la TUA probabilità di un'azione, quindi le raccomandazioni sono personalizzate — le segnalazioni da una "brigata" influenzano principalmente ciò che viene raccomandato a persone simili a quella brigata. E un coinvolgimento conta solo se avviene su un post servito nella Home Timeline: navigare direttamente a un post, ad esempio da una chat di gruppo, non ha alcun impatto sul ranking.
Da dove proviene: Un'inferenza ragionevole dai pesi negativi molto grandi, che i soli pesi non supportano.
Cosa abbiamo cercato, al commit bloccato
X affronta questo direttamente nei commenti di param.rs
recommendations are personalized · 1 file · 1 corrispondenza
Was true, of an older version
“X ha pubblicato il codice ma ha trattenuto i pesi di ranking per motivi di sicurezza.”
Vero per la release di gennaio 2026, falso dal 13-08-2026. I valori numerici predefiniti sono ora in param.rs, e X afferma che gli script cron li mantengono uguali ai valori di produzione primari.
Da dove proviene: Resoconto accurato del rilascio di gennaio 2026, mai aggiornato dopo agosto.
Cosa abbiamo cercato, al commit bloccato
X afferma che gli script cron li mantengono uguali ai valori di produzione primari
cron scripts that set the defaults · 1 file · 1 corrispondenza
Contradicted by the source
“I post contenenti link esterni vengono declassati.”
Nel codice di ranking pubblicato, OpenLinkWeight è POSITIVO a 0.2 e applicato incondizionatamente — l'apertura di un link è premiata. I link sono penalizzati solo tramite etichette di sicurezza come MALICIOUS_URL e DO_NOT_AMPLIFY, che riguardano la destinazione, non il collegamento esterno.
Cosa abbiamo cercato, al commit bloccato
I link sono penalizzati solo tramite etichette di sicurezza come MALICIOUS_URL
MALICIOUS_URL · 7 file · 1 corrispondenza
… e DO_NOT_AMPLIFY
DO_NOT_AMPLIFY · 7 file · 1 corrispondenza
Contradicted by the source
“Un segno di spunta a pagamento garantisce un boost nel ranking.”
Nessun moltiplicatore premium, verificato o di abbonamento esiste in param.rs, e nessun tale "rescorer" appare negli scorer pubblicati. Il codice del 2023 ne conteneva uno — moltiplicatori di 4.0 in-network e 2.0 out-of-network per autori Blue Verified — ed è scomparso dall'albero attuale. Limite onesto: Phoenix è un modello appreso i cui pesi non sono pubblicati, quindi una correlazione appresa non può essere esclusa leggendo il codice.
Da dove proviene: La pipeline Scala del 2023 applicava effettivamente un moltiplicatore Blue Verified di 4.0 / 2.0.
Cosa abbiamo cercato, al commit bloccato
Nessun moltiplicatore premium, verificato o di abbonamento esiste in param.rs
premium|verified|subscription · 1 file · 0 corrispondenze
nessun tale ricalibratore appare negli scorer pubblicati
premium|verified|subscription · 8 file · 0 corrispondenze
Contradicted by the source
“X ora pubblica le richieste di rimozione governative nel suo repository open-source, e il Brasile è l'unico paese elencato.”
Il repository pubblica il MECCANISMO di applicazione, mai una richiesta. Le regole che rimuovono un post per gli spettatori in un paese con restrizioni — LegalTakedown e LocalLawsTakedown — leggono una ragione che contiene il codice del paese, ma tale ragione viene recuperata in fase di esecuzione da un servizio non pubblicato, e il tipo che la contiene (TakedownReason) è definito in un crate assente dal repository. X pubblica anche l'infrastruttura relativa a quel tipo, in Scala: un filtro di lettura gizmoduck che rimuove i takedown non applicati prima che una lettura venga restituita, una colonna e una trasformazione del Tweet Entity Service che recuperano le ragioni di takedown di un post, e i processi interni che trasformano tali ragioni nelle etichette mostrate a un account su se stesso. Quindi le struct Thrift che lo contengono — Takedowns { country_codes, takedown_country_reasons } — sono lette dal codice pubblicato, in 3 file: `takedowns/gizmoduck/RedactUnenforcedTakedownsFilter.scala`, `takedowns/tweet-entity-service/TakedownReasonsTransform.scala`, `under-the-hood/scalding/UthPctdAccountTakedownEventsJob.scala`. Ciò che aggiunge è più MECCANISMO, non una singola richiesta: al commit fissato, nessun codice paese è scritto accanto a una ragione di takedown al di fuori dei test fixture — gli unici codici a due lettere che il codice di takedown contiene sono `xx`, `xy`, i sentinelle globali che la fonte stessa nomina, che significano ovunque e sono l'opposto di un paese. E il metodo che chiederebbe al Tweet Entity Service quei codici sotto il proprio nome, get_takedown_country_codes, non appare affatto nel repository. Il Brasile è una cosa completamente diversa: un elenco hard-coded di 2795 account segnalati alla Corte Elettorale, provenienti dal dataset pubblico dei candidati, rimossi da 'Per Te' per ogni spettatore in tutto il mondo a meno che non seguano l'account — senza alcuna condizione di paese, il che è l'opposto di come funziona qui un takedown legale. Limite onesto: un repository senza paesi hard-coded non è una piattaforma senza takedown per paese. Le richieste esistono; vivono al di fuori del repository, aggregate, nel Centro Trasparenza e nel rapporto DSA.
Da dove proviene: Il post di X del 14 agosto ha annunciato due cose: i pesi di ranking e il filtro per le elezioni in Brasile. Musk lo ha ripubblicato il giorno successivo in 61 caratteri — “Qualsiasi censura richiesta dai governi è ora chiaramente visibile” — senza nominare né il repository, né le richieste, né i paesi; la stampa lo ha collegato a un avviso rivolto agli utenti che era stato annunciato, non implementato. Le parole “richieste” e “nell'algoritmo open-source” appaiono per la prima volta insieme su un account aggregatore.
Cosa abbiamo cercato, al commit bloccato
L'infrastruttura Scala pubblicata legge le struct di rimozione Thrift — Takedowns { country_codes, takedown_country_reasons }
\bTakedowns\b|\btakedownCountryReasons\b · 43 file · 15 corrispondenze
Contradicted by the source
“Silenziare una parola chiave nasconde ogni post che la contiene.”
Una parola chiave silenziata non è una singola regola. Il servizio di timeline pubblicato lo applica con 2 filtri che non leggono lo stesso testo: ViewerMutedKeywordFilter, registrato in phoenix_candidate_pipeline.rs, lo confronta con tweet_text; FollowingViewerMutedKeywordFilter, registrato in reverse_chron_posts_pipeline.rs, lo confronta con ancestor_texts, quoted_tweet_text e tweet_text. I campi che solo alcuni di essi leggono — ancestor_texts e quoted_tweet_text — sono scritti da conversation_gap_ancestor_hydrator.rs, quote_hydrator.rs e quoted_post_text_hydrator.rs, registrati in phoenix_candidate_pipeline.rs, phoenix_scores_pipeline.rs e reverse_chron_posts_pipeline.rs. Una pipeline che non esegue questi hydrator non li riempie mai: lì il testo di un post citato o ancestrale non è semplicemente non letto, è assente. Oltre la timeline, il motore di regole di filtraggio della visibilità — il livello che può nascondere un post ovunque appaia — include ViewerMutesAuthor (Mutes) e ViewerMutesRetweets (MuteRetweets), e nessuna regola la cui decisione legga una parola chiave. L'unico risultato di parola chiave silenziata che questo repository nomina, MatchesMutedKeyword, appare esattamente 1 volta — in graphql_results.rs — e solo a sinistra di un match arm che lo mappa a un'etichetta interstiziale. Nulla qui lo decide; ciò che lo fa non è pubblicato. Due limiti onesti. Questo repository è il servizio che costruisce una timeline: ciò che il silenziamento fa nelle notifiche o nella ricerca è deciso altrove, in codice che X non pubblica, e un'assenza qui è un'assenza dal repository, non dal prodotto. E non ti diciamo quale scheda serve ogni pipeline — quel cablaggio attraversa diversi livelli, e una mappatura che non possiamo estrarre in modo pulito è una mappatura che non pubblichiamo.
Da dove proviene: Il silenziamento è un'unica impostazione nel prodotto, quindi viene interpretato come un'unica regola che si applica ovunque. Il codice pubblicato mostra qualcosa di più ristretto: una parola chiave silenziata viene applicata mentre una timeline è assemblata, e i filtri che la applicano non leggono tutti lo stesso testo — quindi un post può contenere la parola in un punto che nessun filtro su quel percorso esamina mai.
La pipeline
Le fonti candidate producono post, gli idratatori allegano funzionalità, i filtri possono eliminare un post del tutto, gli scorer possono solo spostarlo. Ogni nodo si collega al suo file. Gli archi dichiarano come li abbiamo derivati — letti dal codice, forniti dal layout della directory o, nel loro punto più debole, abbinati per nome.
Per paese
Due elenchi di paesi decidono cosa cambia in base a dove si legge, e non significano la stessa cosa. Uno nasconde i contenuti sensibili agli spettatori che non hanno dichiarato la propria età. L'altro decide semplicemente quali paesi il modello è autorizzato a distinguere — ogni altro paese diventa “altro”, il che non è una restrizione, ma solo un punto cieco. Ogni scheda qui sotto indica da dove viene letto il proprio elenco: una costante applicata dal codice, o un fallback che un parametro di runtime può sostituire.
Clicca su un paese in rosa per leggere gli account che questo codice nomina lì, uno per uno. Nell'intero repository, esattamente un paese ha un tale elenco.
Come viene verificato: “l'intero repository” viene controllato sull'intero repository, non su una singola lingua: ogni file sotto il commit bloccato viene letto, e un elenco di account nominati viene trovato in base alla sua FORMA — un @handle scritto in una riga di commento, immediatamente seguito dall'ID numerico dell'account. Questa forma non dipende da Rust, quindi il giorno in cui lo stesso elenco viene pubblicato in un'altra lingua, la build lo segnala invece che la pagina rimanga in silenzio.
2798 account sono nominati direttamente nel codice sorgente, tramite ID numerico e handle. Tutto il resto nel percorso di applicazione agisce su un'etichetta allegata in fase di esecuzione, e tale etichettatura non è pubblicata.
Brazil2026ElectionFilterhome-mixer/filters/brazil_2026_election_filter.rs:73ID utente segnalati alla Corte Elettorale per le elezioni brasiliane del 2026.
Filtro elezioni Brasile 2026 Art. 28 § 1º-A della Risoluzione Elettorale n. 23.610: I fornitori di applicazioni che utilizzano un sistema di raccomandazione per gli utenti devono escludere dai risultati i canali e i profili segnalati alla Corte Elettorale ai sensi del § 1º di questo articolo e, salvo i casi di boosting a pagamento, i contenuti pubblicati su di essi. https://dadosabertos.tse.jus.br/dataset/candidatos-2026
⚠ Nessuna condizione di paese, mercato o locale appare nel file del filtro o intorno alla riga che lo registra. Questa è un'affermazione sul codice pubblicato — quale pipeline serve quale mercato può essere deciso in un livello che X non pubblica.
Altri 52 account sono nominati in questo file e NON sono filtrati — il codice spiega perché ciascuno è stato lasciato intatto: 44 × “@… nessun account attivo trovato.”; 8 × “Riteniamo che l'account @… segnalato dal candidato non sia l'account effettivo del candidato, quindi non lo stiamo attualmente filtrando.” Quindi 2847 account nominati sono qui contabilizzati, 2795 dei quali effettivamente filtrati.
Registrato nella pipeline a home-mixer/candidate_pipeline/phoenix_candidate_pipeline.rs:391
Gli ID numerici nel file sono offuscati — il repository lo afferma. I handle non lo sono.
ThunderServiceImplthunder/thunder_service.rs:30⚠ Nessuna condizione di paese, mercato o locale appare nel file di filtro o intorno alla riga che la registra. Questa è un'affermazione sul codice pubblicato — quale pipeline serve quale mercato può essere deciso in un livello che X non pubblica.
Tutti i 3 account, in ordine di origine
Gli ID numerici nel file sono offuscati — il repository lo afferma. I handle non lo sono.
Questo elenco è riprodotto da un repository pubblico Apache-2.0, che dichiara che gli handle sono inclusi per trasparenza. Riportiamo ciò che il codice fa. Non approviamo, verifichiamo o giudichiamo i rapporti che hanno inserito qui alcun account.
Rimozioni governative
Il repository contiene le regole che nascondono un post ai lettori in un paese che ne ha fatto richiesta. Non contiene alcuna richiesta, né alcun paese: la ragione che include il codice del paese viene recuperata in fase di esecuzione da un servizio che X non pubblica.
0
richieste di rimozione pubblicate nel repository
0
paesi associati a una
2
regole che agiscono su una ragione di rimozione
Come viene calcolato: ogni file nel repository viene scansionato in fase di compilazione — non solo quelli Rust, perché l'infrastruttura di rimozione risiede anche in Scala, e un'assenza misurata dove la cosa non è più non è un'assenza. Il codice di test viene rimosso su due scale — i file che un genitore dichiara `#[cfg(test)] mod …;` sono esclusi, e nel resto il corpo `#[cfg(test)]` viene tagliato — e ciò che viene cercato è un codice paese scritto accanto a una motivazione di rimozione. I codici a due lettere che la fonte stessa nomina a livello mondiale (`xx`, `xy`) significano ovunque piuttosto che un paese: sono messi da parte e elencati apertamente. La build fallisce se questo numero smette di essere zero — l'affermazione di cui sopra non può diventare obsoleta da sola.
reads a DMCA flag on the media
la regola delega: il campo viene letto in TweetPredicate::HasDmcaMedia · rule_spec.rs:661, has_dmca_media() · tweet.rs:34
reads allow/deny country lists carried by the media — not a takedown reason
la regola delega: il campo viene letto in media_restricted_in() · tweet.rs:68
reads the takedown reasons attached to the post at runtime — Dmca, LegalRequest, UnspecifiedReason
la regola delega: il campo viene letto in takedown_in() · tweet.rs:58
reads the takedown reasons attached to the post at runtime — BystanderReport
la regola delega: il campo viene letto in takedown_in() · tweet.rs:58
Da dove proviene il paese: il tipo che lo contiene, TakedownReason, non è definito in nessun file di questo repository — viene importato da xai_core_entities, una crate che non è pubblicata qui.
E il metodo che recupererebbe i paesi di una rimozione, get_takedown_country_codes, non appare da nessuna parte nel repository. L'interfaccia esiste sul lato di X; il codice pubblicato non la chiama mai.
Interpretate questo correttamente: un repository senza paesi hardcoded non è una piattaforma senza rimozioni per paese. Le richieste esistono — vivono al di fuori di questo repository, aggregate per paese e per semestre nel rapporto di trasparenza di X, mai avviso per avviso. Ciò che viene misurato qui è ciò che dice il codice, non ciò che fa l'azienda.
Metodo e limiti
I pesi sopra sono applicati alle probabilità prodotte da Phoenix, un trasformatore appreso i cui parametri addestrati non sono pubblicati. La lettura del codice non può escludere una correlazione che il modello ha appreso da solo.
X dichiara di trattenere i modelli di prompt Grox LLM e alcune regole di applicazione, per ridurre l'abuso. Il codice del classificatore e il motore delle regole sono pubblicati; il testo del prompt no.
X afferma che gli script cron mantengono questi valori predefiniti uguali ai valori di produzione, e che gli esperimenti superiori a circa il 10% del traffico dovrebbero essere visibili qui. Entrambe sono affermazioni su un sistema che nessuno al di fuori di X può osservare.
I nomi dei parametri e gli estratti di codice sono mantenuti in inglese: citano il codice sorgente e un identificatore tradotto smette di corrispondere alla riga che cita. I controlli delle asserzioni sono tradotti — gli identificatori al loro interno sono lasciati invariati.
Questo è il metodo che vendiamo, applicato a una fonte su cui tutti discutono: prendere qualcosa di opaco, trasformarlo in un grafo dove ogni valore porta la riga da cui proviene, e rifiutarsi di pubblicare un numero che non possiamo citare. Facciamo lo stesso per gli appalti pubblici, i finanziamenti alla ricerca e i dati aziendali.