[jacoblambert]

Summary

Specifies the t4sanity rules for T4Dataset 1.0 datasets, before implementing them: new page docs/schema/v1/requirement.md (added to the Schema 1.0 docs), like the schema spec in #294.

Docs only; no code change. 0.x datasets keep exactly the same rules and report.

How the rules were derived

Every 0.x rule was reviewed against the 1.0 format:

• Shared (30 rules): same meaning for 1.0, so same ID and the same wording as the 0.x page: the directory checks, REC001–004, REC006, REC007, most record references, the next / prev checks, REF201 and TIV001.
• 0.x only (30 rules): the format rules of the 0.x table classes (FMT001–019), status.json, calibrated_sensor, lidarseg, .info files and the 0.x traffic-light table. The page lists each with why and the 1.0 rule that replaces it.
• New for 1.0 (69 rules), numbered after the last 0.x ID of each group:
  • STR010–015: manifest.json (supported version, listed files present, hashes, unlisted files, required tables, identity vs directory names).
  • FMT020–040: manifest.json and one per 1.0 table, as in 0.x.
  • REC008–027: what spans several records: unique sensor / instance indices, counts (nbr_samples, nbr_annotations), is_thing ↔ instance, label provenance, key frames, frames per channel file, timestamps (order and unit), capabilities vs content, 0.x placeholders, routes, quaternions.
  • REF015–025, REF107–108, REF204–207, REF302–306: references of the new and changed tables, mutual next / prev, channel files matching their sensor row, and links to the lanelet2 map and inside LiDAR files (source_index, point labels).

Conventions on the page:

• t4sanity runs only the rules of the dataset's version.
• An ID keeps its meaning; changed meaning gets a new ID.
• Rules within one record are enforced when building the record and reported by FMT.
• A 1.0 rule is skipped (not failed) when what it reads could not be loaded.

To decide in review

1. REC018 key frames: the spec says sample_data.sample_token is null for non-key frames, but the 0.x converter sets it for non-key frames too, and 2D labels on those frames reach their sample through it. Strict (ERROR, migration clears it) or relaxed?
2. REC001 one scene per dataset: kept for 1.0. Still true?
3. REC023 / REC024 capabilities: declared but missing is ERROR, present but not declared is WARNING. prediction and planning are not checked; traffic_light accepts states or lamp instances.
4. STR012 hashes: reads every file, including videos and rosbags (GBs). ERROR but meant to be excluded for quick checks; or WARNING / opt-in?
5. REC025 placeholders: every dataset migrated without metadata backfill warns until it is backfilled. Intended as the signal.
6. REC013 first / last annotation: also checks they are the first / last in time. Some 0.x datasets leave them empty while labels exist, so migration has to recompute them (the rule is fixable).
7. FMT per table (21 IDs, so a table can be excluded alone, as in 0.x) or one rule for all tables.

Next

Implementation in stacked PRs after this one: version selection and STR / FMT, then REC, then REF.

[ktro2828]

LGTM