Tuning Credibility Signals

This guide shows you how to put Credibility Signals to work: which fields to read, where to set your first thresholds, how to evaluate the signals against your own traffic, and how to combine them into acceptance rules that match your product's risk tolerance.

The signals at a glance

Credibility signal fields appear in responses from all Wikimedia Enterprise APIs: On-demand, Snapshot, and Realtime. They fall into three groups:

• Community flags the projects set themselves: visibility, protection, maintenance_tags, watchers_count.
• Machine-learning scores computed per revision: version.scores (RevertRisk, ReferenceRisk, ReferenceNeed).
• Context fields describing the change and who made it: version.editor, version.size, version.number_of_characters, version.is_minor_edit, and related fields.

If you want the concept behind these fields - why they exist and what safety and significance mean - start with the Credibility Signals overview. For where these fields sit inside the payload, see the data model; for the definition of any single one, the article model in the API reference.

Visibility and protection: the first line of defense

Your first line of defense is the visibility signal, which helps filter out dangerous content, including published Personally Identifiable Information (PII). What content is deemed dangerous is defined by each Wikimedia project individually, so the rules that govern changes in visibility differ per project.

The visibility object reports whether the article's content (text), editor name, or comment is visible (true) or hidden (false). In this example, the editor name and edit comment have been hidden: the name might have included a slur, and the comment might have contained personal information such as a home address. If one or more booleans in the visibility object are false, treat the edit as unsafe.

{
  "text": true,
  "editor": false,
  "comment": false
}

The protection object reveals how easy it is to change an article. Different parts of an article can be restricted in different ways; types of restriction cover creating, editing, moving, or uploading media. Admins, patrollers, and users with extended rights protect articles in response to repeated vandalism, to let disputes settle, or for other reasons.

The most frequent pattern is an article locked down to autoconfirmed users, which removes the ability for temporary or anonymous accounts to edit the page. The expiry field defines when the protection lapses.

[
  {
    "type": "edit",
    "level": "autoconfirmed",
    "expiry": "infinity"
  },
  {
    "type": "move",
    "level": "autoconfirmed",
    "expiry": "infinity"
  }
]

Read a protection entry as three parts: type is the action being restricted, level is the editor status needed to perform it, and expiry is when the restriction lapses.

Levels are set per project, so do not hardcode a list. Each Wikimedia project defines its own restriction types and levels, and they change. Ask the project itself through the MediaWiki siteinfo endpoint rather than assuming English Wikipedia's set applies everywhere - this call returns the live types and levels for English Wikipedia, and the Restrictions section of API:Siteinfo documents the response.

expiry is not always a timestamp. A protection with no end date carries one of four sentinel strings instead: infinite, indefinite, infinity, or never. Parse for those before you try to read the value as a date, or an indefinitely protected article will throw in your date parser.

Version scores: the second line of defense

The version.scores object holds three machine-learning signals: the probability that an edit will be reverted (RevertRisk), the probability of a reference being removed from the article (ReferenceRisk), and the probability that an edit needs more citations to credible sources (ReferenceNeed).

The models themselves are not ours. They are served by LiftWing, the Wikimedia Foundation's machine-learning inference platform, which is the same infrastructure the projects' own moderation tooling draws on. Wikimedia Enterprise scores each revision as it passes through the pipeline and attaches the result to the payload, so you get the number without calling LiftWing yourself.

In this example, RevertRisk predicts the edit will be reverted: the prediction boolean is true and the probability is 0.959, over 95%. A high score does not mean the edit will certainly be reverted; it computes the probability of a revert happening.

{
  "revertrisk": {
    "prediction": true,
    "probability": {
      "true": 0.959002615965355,
      "false": 0.040997384034645014
    }
  },
  "referencerisk": {
    "reference_risk_score": 0
  },
  "referenceneed": {
    "reference_need_score": 0.2621951219512195
  }
}

Each model reads differently, and two of the three do not cover every project:

Every part of the object is optional, and a zero probability is omitted from the encoded JSON rather than sent as 0. Treat an absent score as "no signal" and branch on it explicitly, rather than letting a missing key default to zero and read as "safe".

Editor context and change shape

The version.editor object shows who made the edit: did it come from a temporary account, a bot, a user with extended rights, an admin, or a seasoned patroller? Account age (date_started) and edit_count give you a quick read on experience.

Combine editor context with the shape of the change: a diff of the version's character count (is the article now much longer or shorter?) and whether the revision moved the article's version.maintenance_tags counts, such as citation_needed_count (signaling a change in verifiability). Together they tell you whether a revision is a significant change worth processing or a minor touch-up you can skip.

{
  "identifier": 4904587,
  "name": "~2026-59431-3",
  "groups": ["*", "user", "temp"],
  "date_started": "2026-05-02T18:41:16Z",
  "edit_count": 12,
  "is_bot": false,
  "is_admin": false,
  "is_patroller": false,
  "has_advanced_rights": false
}

Reading name and is_anonymous after temporary accounts

The editor object above belongs to a temporary account, and that is now the common case. Since December 2025 every Wikimedia project except Russian Wikipedia has replaced unregistered editing with temporary accounts: an editor who does not log in is issued a named account for the session instead of being recorded by IP address. The Data Primer covers what that changed on the projects; two consequences land in the payload.

• name has three possible shapes. A registered username, an IP address on the projects that still allow anonymous editing, or a temporary-account name. Temporary names follow a fixed pattern: a tilde, the year of creation, a hyphen, then an auto-generated serial broken into hyphenated groups of five digits, as in ~2026-59431-3. Match that pattern rather than testing for an IP to detect a session-only editor. The field is also optional in its own right, since a username can be suppressed after the fact if it was itself vandalism.
• is_anonymous no longer means "unregistered". On a project with temporary accounts enabled it is always false, and false is omitted from the encoded response, so the field is simply absent. Reading its absence as "this was a registered editor" is wrong on nearly every project. Use the name pattern, or the temp entry in groups, to identify a session-only editor.
• date_started carries a sentinel for true anonymous editors. The zero value 0001-01-01T00:00:00Z means there is no account start date to report. Temporary accounts carry a real timestamp, so account age remains usable for them.

Recommended starting thresholds

• A safe RevertRisk score to start with is 0.7, skipping revisions that score above it. This is a strong starting point across languages.
• Expect this threshold to favor safety over completeness: it may produce false negatives (worthwhile revisions you skip). Collect the revisions you skip so you can measure that trade-off rather than guess at it.
• Loosen or tighten per project and per language once you have evaluation data; protection and visibility rules differ between Wikimedia projects, so one global threshold rarely stays optimal.

Evaluating signals against your own traffic

Before you commit to thresholds, test them against a representative sample:

1. For your test set, take edits representative of a full day of activity with 95% confidence and a 5% margin of error. Repeat for each language you care about.
2. Run those edits through your existing moderation or ingestion system and through a signals-based flow side by side.
3. Compare the vandalism catch rate and the time it takes for an edit to be resolved in each system.
4. Review the revisions your thresholds skipped. If they contain content you wanted, adjust the mix of signals rather than only moving the score cutoff.

Field reference

Signals are available across the Wikimedia Enterprise APIs: Realtime, Snapshot, batch, and On-demand endpoints all return the same structures. The tables note which fields exist in the public Wikimedia APIs and which are parsed or added by Wikimedia Enterprise.

Article-level signals

Version-level signals

Editor-level signals

Combining signals

Single thresholds are a starting point; robust pipelines combine fields. Example rules:

• Accept a revision if revertrisk is borderline but version.editor.is_admin is true.
• Accept a revision if revertrisk is borderline but watchers_count is high - committed editors will quickly fix bad edits.
• Reject or flag a revision if revertrisk is acceptable but it carries more maintenance_tags (citation needed) than the previous version.
• Reject or flag a revision if revertrisk is acceptable but the character change exceeds 5% of the page's total length.

The right mix depends on what your product optimizes for. The Credibility Signals overview walks through the common usage patterns; for per-field definitions, use the article model in the API reference.

Where the signals live

• On-demand API guide: request single articles and inspect their signals.
• Snapshot API guide: bulk project files, each article carrying signal fields.
• Realtime API guide: stream revisions with signals attached as they happen.
• Fields, Filters, and Limit: trim responses down to just the signal fields you need.

See also

• Understanding Credibility Signals in Wikimedia Enterprise API →
• More Data with every Article Revision and Probability of Revert →
• Parsing Wikipedia References with Quality Scoring Models →
• Discover the latest updates through the Changelog →

Questions about your acceptance rules? Get in touch and we'll help you design the mix.