ARDS is governed openly. The AxiomOrdo Standards Board chairs the process. Working groups, the RFC mechanism, and a user council ensure the standard evolves with the industry it serves.
Five bodies govern ARDS. All are accountable to the standard's stated goal: machine-readable interoperability for regulatory compliance.
The ultimate governing authority for ARDS. Chaired by AxiomOrdo. Responsible for ratifying new versions of the specification, approving domain packs, accepting or rejecting RFCs, and maintaining the integrity of the standard.
Meetings: Quarterly + extraordinary sessions as required. Minutes published publicly.
Reviews RFC submissions for technical correctness, implementation feasibility, and schema design quality. Issues technical recommendations to the Standards Board. Membership is invitation-based; nominees must demonstrate ARDS implementation experience.
Meetings: Monthly. Operates on a 60-day RFC review cycle.
One working group per published domain pack (FuelEU, CBAM, PFAS, ETS). Open membership — any organisation may join. Working groups propose schema changes, maintain domain-specific guidance, and respond to domain-specific issues.
Chaired by AxiomOrdo. Meetings: Bi-monthly per domain group.
Oversees the ARDS Certification Programme. Reviews certification applications, manages the conformance test suite, issues Certification Tokens, and handles appeals and revocations.
Meetings: As required. Decisions published in the certification registry.
Representatives from ARDS implementing organisations, regulators, and compliance professionals. Provides industry perspective, votes on strategic direction, and surfaces real-world implementation friction. Seats are held by elected representatives of the certified-product community and invited regulatory observers.
Meetings: Semi-annual. Annual open call for new council members.
Join the working group for your regulatory domain. Working group membership is open and free. All you need to contribute is an ARDS implementation or a concrete use case.
| Working Group | Domain Pack | Current Focus | Status | Join |
|---|---|---|---|---|
| FuelEU WG | ARDS-FuelEU v1.0 | Fleet pooling schema, biofuel certification linkage, EMSA submission format | Active | Join → |
| CBAM WG | ARDS-CBAM v1.0 | Precursor goods schema, transitional period handling, EU Registry API alignment | Active | Join → |
| PFAS WG | ARDS-PFAS v1.1 | Substance identification schema, CAS number registry integration, exemption workflow | Forming | Join → |
| ETS WG | ARDS-ETS v1.1 | MRV alignment, registry transaction schema, surrender obligation tracking | Forming | Join → |
Changes to the ARDS specification, domain packs, or governance are proposed through a formal Request for Comment (RFC) process. Anyone can submit an RFC.
Changes to the normative ARDS specification (ARDS-SPEC-001). Schema additions, field changes, new conformance requirements.
New domain packs or changes to existing domain packs. Must include a draft schema set and a regulatory reference mapping.
Changes to governance, certification, or tooling processes. Does not affect the normative specification.
| Stage | Name | Duration | Description |
|---|---|---|---|
| 1 | Draft | — | Author prepares RFC using the standard template and submits to standards@axiomordo.com. Assigned an RFC number. |
| 2 | Community Review | 30 days | RFC is published publicly. Any party may submit written comments. Author responds to all substantive comments. |
| 3 | TAG Review | 30 days | Technical Advisory Group reviews for correctness and feasibility. Issues a technical recommendation: Accept, Accept-with-changes, or Reject. |
| 4 | Standards Board Vote | 15 days | Standards Board votes. Simple majority for minor changes; two-thirds supermajority for breaking changes. |
| 5 | Accepted / Rejected | — | Accepted RFCs are assigned to a milestone release. Rejected RFCs are published with the rationale for rejection. |
| 6 | Implemented | Per milestone | Accepted RFC is implemented in the specification and/or schemas at the assigned release milestone. |
Use this structure for all RFC submissions. Plain text or Markdown is preferred.
# RFC-[NUMBER]: [Title]
**Type:** RFC-Spec | RFC-Domain | RFC-Process
**Author(s):** Name, Organisation
**Submitted:** YYYY-MM-DD
**Status:** Draft
## Abstract
One paragraph summary of the proposed change.
## Motivation
Why is this change needed? What problem does it solve?
Reference specific use cases, implementation friction, or regulatory requirements.
## Specification
Precise description of the proposed change.
Include:
- Exact field names, types, and cardinalities
- Normative language (SHALL / SHOULD / MAY)
- JSON Schema fragments for schema changes
- Migration path for existing implementations (if breaking)
## Domain Pack Impact (RFC-Domain only)
- Regulatory reference mapping
- Draft schema families (minimum: obligation-record)
- Working group chair proposal
## Alternatives Considered
What alternatives were evaluated and why were they not chosen?
## Backwards Compatibility
Is this change backward-compatible?
If not: describe the migration path and proposed deprecation timeline.
## References
Regulatory documents, prior RFCs, or external standards referenced.AxiomOrdo is working with a founding cohort of compliance technology vendors to shape ARDS v1.1. Design partners receive early access to domain packs, discounted certification, and a named seat at the relevant working group.
The AxiomOrdo Regulatory Data Standard and all associated schemas, documentation, and tooling are published under the AxiomOrdo Open Standard Licence 1.0 (AOSL-1.0).
AOSL-1.0 grants a free, perpetual, irrevocable, worldwide licence to any party to:
The licence does not grant rights to:
Full licence text available at standards@axiomordo.com and in Annex D of the ARDS v1.0 Specification.