OpenITS
Docs Schema registry AsyncAPI
Search the docs /
GitHub
Docs/Conformance
06 · Documentation4 min read

Conformance

Conformance is a contract clause, not a marketing claim. A claim names a profile so everyone knows exactly what was verified, against a public artifact, not a private negotiation.

Profiles

A conformance claim is always scoped to a named profile, so “conformant” means something precise:

  • core: the mandatory Tier 1 model for a service.
  • core-plus-augments: core plus specific declared augments.
  • core-plus-deviations: core with jurisdiction-specific constraint refinements.
  • complete: the full published surface for a service.

Because the target is a public artifact at a pinned revision, there is no per-vendor negotiation of what conformance means.

The conformance kit

The conformance kit checks that an implementation carries the model faithfully: that its data validates against the YANG (including safety must expressions), that events use the correct ce-type, and that subjects follow the canonical pattern. It produces a dated conformance report that names the profile and the exact model revision tested.

RFP language

The point of all this is to make conformance procurable. Reusable RFP language turns the standard into a requirement an operator can hold a vendor to:

The Vendor’s product SHALL conform to OpenITS core for the {service} service at revision {YYYY-MM-DD} or later, and SHALL provide a conformance report produced by the OpenITS conformance kit, dated within 90 days of contract execution.

Source: content/docs/conformance.md Edit this page on GitHub ↗
← Previous
Extension model
Next →
Getting started