1,166 of 1,194 timeline events fail event_v1, the schema they are published under

[PipFoweraker]

Found by scripts/validation/check_maturity.py on its first run, 2026-08-06.

data/serveable/api/timeline_events/all_events.json holds 1,194 records. 28 validate against config/schemas/event_v1.json. 1,166 do not.

The 28 are exactly the hand-authored events. Every bulk arXiv and Distill import fails.

Why nobody noticed

Nothing validated this collection. check_invariants.py covered manifest hashes and, since #53, catalogue counts -- but never schema conformance, and timeline_events has no producer to run a --check through. The schema and the data have been diverging since 2025-12-24 with no instrument pointed at the gap.

This is the same shape as everything else this collection has produced: a thing that reports nothing is indistinguishable from a thing that is fine.

Why it matters beyond tidiness

pdoom1-website/schemas/events.schema.json is that repo's copy of the contract, and its CI validates against it. So there are two schemas, one corpus, and a 97.7% failure rate against ours. Any consumer that starts validating will reject almost the entire collection.

It also means the headline 1,194 events is, by this repo's own published contract, 28. That is filed separately as the R5 options issue.

Not proposing a fix here

Two obviously different repairs -- widen the schema to describe what the data actually is, or fix the data to match the schema -- and they imply opposite things about what that collection is for. That question is upstream of this issue and belongs with #52 (no producer) and pdoom1#1102 (what the game actually wants).

Filed so the measurement exists and is citable, not to prejudge it.

Refs #52, #53, #62, pdoom1#1102.

[PipFoweraker]

Measured, so the "fix the data or fix the schema" call can be made on evidence rather than on the headline count. Everything below came from running jsonschema 4.25.1 against config/schemas/event_v1.json on 2026-08-07; nothing in the repo was modified.

There is no long tail. There are exactly three reasons, and two of them explain everything.

COUNT  REASON
 1166  additionalProperties: 'source_id' was unexpected
 1166  minItems @ tags: array is empty, minItems is 1
   24  maxLength @ description: longer than maxLength 1000

Every failing record fails both of the first two, and no passing record has either. The 24 over-long descriptions are a strict subset. No missing-required-field failures, no wrong types, no enum violations, no id or tag pattern violations, no out-of-range numbers.

So conformance is not a corpus-quality problem. It is two decisions. Note the consequence: fixing only one of the first two moves the passing count by zero, because each of the 1,166 fails both.

What each one actually costs

1. source_id -- pure schema question, no data work. The schema declares additionalProperties: false and the records carry a field it does not know about. The data exists and is good; the schema simply forbids it. Either the field is named in the schema, or it is namespaced, or it is dropped in projection. Nothing has to be acquired.

2. tags empty -- part data work, and the split matters. 1,129 of the 1,166 are arxiv_* and carry categories / primary_category in data/raw/, so tags can be derived, with a normalisation step to satisfy ^[a-z0-9_]+$ (cs.AI -> cs_ai). The other 37 are distill_* and have no tag-like field anywhere in data/raw/. That is genuinely missing data, not a transformation away. Checked and ruled out: data/enrichment/airr_tags/machine_v1.json holds 3,135 entries and its intersection with these 1,166 source ids is zero.

3. description over 1,000 -- a producer bug, not data. All 24 end in an ellipsis and another 80 sit in the 995-1000 band. Something truncates near 1,000 and then appends ..., pushing it over. No summary or abstract exists in raw for any of the 1,166, so "use the abstract instead" is not available.

Two corrections to what this repo says about itself

The 28 passing records ARE exactly the 28 hand-authored ids in data/raw/events/*.json. Verified by set equality in both directions, both empty. The claim held.

"1,166 bulk arXiv" is imprecise, and it is in CLAUDE.md's served-collections table. The real split is 1,129 arXiv and 37 Distill. The producer docstring says "arXiv + distill" and is right; the table is the one that needs correcting. It matters here because the 37 are precisely the records with no recoverable tags.

The hole in this measurement, stated rather than buried

sources.items declares format: "uri". FormatChecker was enabled but rfc3987 is not installed in this interpreter, so the uri format check was a no-op. Therefore 28 is an upper bound on the passing count, not a confirmed floor. Installing rfc3987 and re-running is the cheap way to close that, and it should be done before any number from this comment is quoted as final.

Refs #64, #52, coordination#35 (AK8).