Reading the label: IS, TS, TR — and the road to publication

Lesson 2 of 5 in The AI Standards Landscape and Core Terminology (ISO/IEC 22989).

Pick up any two documents from SC 42 and they may carry completely different weight. ISO/IEC 42001 is an International Standard you can be certified against. ISO/IEC TR 24028 is a Technical Report you cannot be certified against, audited against, or non-conformed against — it contains not a single requirement. Confusing the two is one of the most common rookie errors in this field, so learn to read the label first.

The distinction that does the work is normative versus informative. Normative content states requirements — things you must do for a claim of conformity. Informative content explains, illustrates, and guides, but binds no one. A document type tells you the ceiling of what it may contain:

ISO/IEC deliverable types — what the prefix on the cover tells you
TypeHow you spot itConsensus levelRequirements allowed?AI examples

International Standard (IS)

No prefix — just the number (e.g. ISO/IEC 42001)

Full consensus: national-body ballot at DIS and FDIS stages

Yes — normative "shall" statements; certifiable if it is a requirements standard

ISO/IEC 42001 (AIMS), 22989 (terminology), 25059 (quality model)

Technical Specification (TS)

Prefix TS

Committee consensus — published when the subject is still maturing or full consensus is not yet reachable

Yes — may contain requirements, but it is provisional; expected to be revisited (and possibly promoted to IS)

ISO/IEC TS 4213 (ML classification performance assessment)

Technical Report (TR)

Prefix TR

Committee approval — informational output

No. Entirely informative: surveys, overviews, collected data. Zero "shall" statements

TR 24028 (trustworthiness overview), TR 24027 (bias), TR 24368 (ethical and societal concerns)

Publicly Available Specification (PAS)

Prefix PAS

Lowest — fast-track publication, often from an external consortium

May state requirements, but carries the least authority; a market-speed stopgap

Rare in the SC 42 catalogue so far

How a standard gets born. Every International Standard walks the same staged pipeline, usually taking three to five years. Knowing the stages lets you decode status codes like "prEN 18286 in public enquiry" or "42006 at FDIS" — sentences that tell insiders exactly how far a document is from mattering.

The ISO/IEC standards development pipeline

  1. NP — New work item proposal

    A national body or committee proposes new work. Ballot: do enough members want this, and will enough experts show up to write it?

  2. WD — Working draft

    The working group’s experts iterate internally. Multiple WDs are common; the text is volatile.

  3. CD — Committee draft

    The whole subcommittee (e.g. SC 42) comments and ballots. Big structural fights happen here.

  4. DIS — Draft International Standard

    Full national-body ballot plus public comment — the "enquiry" stage. In the European system this is where prEN documents go to public enquiry.

  5. DIS ballot passes?

    Two-thirds of participating members in favour, not more than one quarter of total votes negative.

  6. FDIS — Final draft

    Yes/no ballot on the final text. Editorial fixes only; skipped entirely when the DIS vote is clean.

  7. Published IS

    The standard gets its year suffix — 42001:2023 — and enters the catalogue.

  8. Systematic review (every 5 years)

    Confirm, revise, or withdraw. This is why editions matter: 27001:2013 vs 27001:2022 are different documents.

The verbs are the law of the land. Inside any ISO document, four modal verbs are terms of art, defined centrally in the ISO/IEC Directives:

  • shall — a requirement. Fail it and you are nonconforming.
  • should — a recommendation. You may deviate, but a good auditor will ask why.
  • may — permission. The standard explicitly allows it.
  • can — possibility or capability. A statement of fact, not of obligation.

This is not style pedantry. When you build a compliance matrix from ISO/IEC 42001, you extract the shall statements — nothing else creates a certifiable obligation. And when ISO/IEC 23894 (a guidance standard) says organisations should do something, that wording is precisely why 23894 supports but can never replace the certifiable requirements of 42001.

Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.