Package conformance
The implementation can produce a valid package structure with path identity, schema, examples, and supporting documentation.
Conformance Program
A public way to prove an implementation actually supports the standard.
The conformance program turns the standard from a document set into an interoperability discipline. It gives builders a clearer target for what to implement and gives the committee a consistent way to review claims of support.
Implementation Classes
Conformance should be explicit about what is supported.
Early implementations may support different parts of the standard. The public program should distinguish package generation, validation, and governed runtime import rather than forcing a vague all-or-nothing claim.
Validation conformance
The implementation can run a validator or equivalent checks that confirm required fields, semantics, and package integrity.
Runtime import conformance
The implementation can import a conforming package into a governed environment without losing decision, governance, evidence, or outcome semantics.
Evidence
Every conformance claim should come with reviewable proof.
The committee should be able to inspect what was implemented, how it was validated, and where interpretation choices were made.
- Specification version implemented and package version tested.
- Package archive or repository reference for the submitted implementation.
- Validator output or equivalent machine-readable conformance evidence.
- Notes on runtime interpretation, unsupported fields, or declared extensions.
- A contact point for follow-up by the committee or technical working group.
Program Rules
Protect interoperability while still allowing evolution.
The standard should stay flexible enough to grow without turning every implementation into a private dialect.
Next Step
Use the starter materials, then submit what you built.
Builders should start with the public package model, validate their implementation, and share the evidence needed for technical review.