Listed implementation
The submission is complete enough to be referenced publicly as an early implementation of the standard.
Submit an Implementation
Give the committee something real to review.
This page defines what early implementers should prepare when they want their Operating Specification package, validator, or runtime support reviewed as part of the public standards effort.
The goal is not gatekeeping. It is to create enough structure that submissions become useful inputs for interoperability, release planning, and committee learning.
Submission Checklist
Bring the package, the proof, and the implementation notes.
Early committee review will work best when submissions arrive with a consistent minimum set of artifacts and metadata.
- Your package archive or repository link.
- The implemented specification version and package version.
- Validator results or equivalent conformance evidence.
- Runtime notes, declared extensions, and known limitations.
- Named technical contact and organization details.
Review Outcomes
What happens after a submission arrives
The committee should make review outcomes legible so submitters know whether they are listed, blocked, or routed into follow-up work.
Needs clarification
The package is promising, but the committee needs more evidence, tighter versioning, or clearer extension notes.
Working group follow-up
The implementation raises important compatibility questions that should be reviewed through the technical or governance group.
Current Intake
Open a real submission draft while the committee process is still forming.
In this first phase, submissions route through Aegora directly using a structured intake draft. That keeps the workflow honest today while still establishing the metadata the later committee process should inherit.
Prepare
Use the starter kit and conformance model before you submit.
Strong submissions start with a clean package, declared versioning, and explicit evidence of how the implementation behaves.