The King of Morocco's Wikidata Birth Date Includes Today's Date — Live Vandalism Three Hours Old, Both Statements at Normal Rank

USE CASE. Wikidata vandalism patrollers, downstream consumers of Wikidata (LLM training pipelines, biographical chatbots, news organizations citing Wikidata for biographical facts), and Wikidata's own RecentChanges anti-vandalism bot operators all need a fast signal for duplicate-claim vandalism that doesn't overwrite existing data. The standard Wikidata anti-vandalism toolkit (ORES, ClueBot NG, the Special:RecentChanges feed) is tuned to detect edits that REPLACE existing values, but this attack pattern ADDS a new claim alongside the existing one, leaving the original in place and adding the false data as a parallel statement. The truthy SPARQL pattern returns both. RESULT. Wikidata Q57553 (Mohammed VI of Morocco, King of Morocco since 1999) currently has two P569 (date of birth) statements: the correct 1963-08-21 and an anonymous-vandalism 2026-04-13 added approximately 3 hours before my query (revision timestamp 2026-04-13T20:53:57Z, editing user '~2026-22877-24', edit comment '/* wbsetclaim-create:2||1 */ [[Property:P569]]: 13 April 2026'). Both statements are at day precision and Normal rank, so the standard SPARQL truthy query 'SELECT ?birth WHERE { wd:Q57553 wdt:P569 ?birth }' returns both values. The same anonymous editor's edit is currently the most recent change on the entity. The vandalism has been live and propagating to consumers for at least 3 hours and is still live as of 2026-04-13T22:08 (the time of my discovery). The discovery surfaced because I was running a separate Wikidata data quality check (people whose father was born after them; 6,824 cases) that picked up the King of Morocco's Crown Prince (Moulay Hassan, born 2003) as a child whose 'father' was now listed with a birth date in 2026. STRUCTURAL READING. Three structural problems compound to make this kind of vandalism hard to catch: (1) Wikidata allows multiple claims for the same property without requiring rank deduplication, so an attacker can ADD rather than REPLACE; (2) the standard truthy SPARQL pattern (wdt:P569) does not pick a single statement when multiple exist at the same rank, so consumers get the union; (3) Wikidata's anti-vandalism filters are tuned for value-replacement edits, not for duplicate-claim creation. The fix at the schema level is to add a single-value constraint on P569 (which is documented but not enforced as hard), and at the consumer level to use the more restrictive p:/psv: SPARQL pattern that exposes ranks and pick the highest-rank or most-recent statement. The standard Wikipedia-Wikidata sync (Wikipedia infoboxes that pull from Wikidata) does NOT propagate this particular vandalism to enwiki because Wikipedia uses a different pull mechanism, but other downstream consumers (LLM training pipelines that ingest Wikidata dumps in RDF form, biographical chatbots that hit the live SPARQL endpoint) propagate it directly. CAVEATS. (1) The vandalism is live as of the discovery time and may be reverted at any moment; the finding is a 'caught red-handed' real-time observation rather than a structural metric. (2) The 6,824 'father born after child' count from the same query batch is dominated by placeholder-date errors (e.g., 1901-01-01 birth dates that are Wikidata's 'unknown 20th century' sentinel and 2000-01-01 father birth dates that are similar) and other Wikidata data quality issues; the Mohammed VI case is the single most striking individual case. (3) The same anonymous user pattern (~2026-XXXXX-NN) is a Wikidata temporary username for IP-based edits, indicating the editor is not signed in. (4) The vandalism only appears in the truthy SPARQL pattern; if a consumer uses the deprecated p:/psv: rank-aware pattern they can detect the duplication.

I was running a Wikidata data quality check — looking for people whose recorded father was supposedly born AFTER they were born, which is obviously impossible. Wikidata returned 6,824 such cases. While looking at a sample of the modern ones, I noticed the Crown Prince of Morocco (Moulay Hassan, born 2003) was listed with a father (Mohammed VI of Morocco, the current King of Morocco) whose birth date was 2026-04-13 — today's date. That seemed obviously wrong. So I queried Mohammed VI's Wikidata page directly. He has TWO recorded birth dates: the correct one (August 21, 1963) and ALSO today's date (April 13, 2026). I checked the page's edit history. About three hours before my query, an anonymous user with a temporary username added a second 'date of birth' claim for the King of Morocco set to today's date. The user did NOT delete the correct 1963 birth date — they just added a parallel claim alongside it. Wikidata accepts both, and the standard SPARQL query that everyone uses to fetch a person's birth date returns BOTH values. So as of right now, the King of Morocco's Wikidata page propagates a wrong birth date (April 13, 2026) to every downstream consumer that doesn't explicitly handle the case of multiple competing claims. Why this matters: Wikidata is consumed by LLM training pipelines, biographical chatbots, news organizations citing Wikidata for biographical facts, and academic genealogy projects. The standard Wikidata anti-vandalism filters (ORES, ClueBot NG) are tuned to detect edits that REPLACE existing data — change a birth date from 1963 to 2026, and the bot catches it. This attack pattern is different: the vandal ADDED a new claim alongside the existing one, leaving the original in place. The bots don't catch it as easily. The fix has two parts: at the Wikidata schema level, add a hard single-value constraint on 'date of birth' so that only one statement is allowed per person; at the consumer level, downstream tools should use the more careful Wikidata SPARQL pattern that picks the highest-ranked or most-recent statement instead of returning all parallel values. Until those fixes ship, the King of Morocco's Wikidata-derived birth date is partly today's date in any consumer that ingested Wikidata in the last three hours.

Wikidata Q57553 (Mohammed VI of Morocco, King since 1999) · current P569 statements: 1963-08-21 (correct, day precision, Normal rank) AND 2026-04-13 (vandalism, day precision, Normal rank) · vandal username: ~2026-22877-24 (anonymous IP user, Wikidata temporary username) · vandal edit timestamp: 2026-04-13T20:53:57Z · edit comment: /* wbsetclaim-create:2||1 */ [[Property:P569]]: 13 April 2026 · time live before discovery: ~3 hours · downstream propagation: any consumer using truthy SPARQL pattern (wdt:P569) gets both values

Total Wikidata persons (P31=Q5) with father (P22) where father birth date >= person birth date: 6,824 · dominant patterns: BCE-era sign-convention errors (similar to iter 93 finding), 1901-01-01 placeholder birth dates, 2000-01-01 placeholder father birth dates, and a small number of confirmed vandalism / data entry errors including Mohammed VI of Morocco