EQL Standards Submission Roadmap
EQL v0.1 is a TypeScript compiler for a cross-layer intermediate representation over heterogeneous quantum computing. This page states what is built today, which standards bodies EQL is being submitted to, on what timeline, and what we honestly expect the outcome to be.
What EQL is
EQL v0.1 is a TypeScript compiler for a cross-layer intermediate representation — the layer that makes heterogeneous quantum hardware platforms composable, auditable and portable. A single source program describes qubits, gates, timing and measurement; the compiler lowers it to OpenQASM 3.0, to vendor-native circuits, or to another intermediate representation. Ten hardware platforms are in the registry, twenty-five standard gates are in the catalogue, and sixty-plus SI unit types are carried through the front end so that a unit-incompatible value is rejected at compile time rather than at the hardware.
The same intermediate representation spans hardware description, error-correction policy, classical control, application intent, cost model and provenance — so an experiment can be described once and audited later. Every compiled artifact carries a canonical hash and an Ed25519 signature, which makes a result citable and independently verifiable. EQL is positioned as the human-readable layer above low-level representations such as QIR: the portable layer that targets multiple backends, not another vendor's private dialect.
Implementationv0.1 · TypeScript compiler (strict)
Unit types60+ SI units, dimensionally checked
Gate catalogue25 standard gates
Hardware platforms10 target platforms
Front endLexer · recursive-descent parser · 20 AST node types · 8 precedence levels
ProvenanceCanonical hash + Ed25519 signature on every artifact
LicenceApache 2.0 (implementation)
Module status: EQL is a ROADMAP module (L5). The language is under active construction. Nothing described on this page is a shipped product.
Where the compiler actually stands
The build follows a thirteen-week plan with a hard exit criterion for every week. W1-2 is complete and verified; W3-4 is next and is the piece that makes the language safe to submit to a standards body.
W1-2 · SHIPPEDLexer, parser, AST and the Vitest suite are done. Build verification: 0 TypeScript errors, clean production build, 73/73 tests passing. `eql bell-pair.eql` parses to a JSON AST.
W3-4 · NEXTDimensional type checking. Every numeric literal carries a unit, and the compiler rejects unit-incompatible arguments before they reach hardware — for example `rx(angle=2.0 Hz)`, where a dimensionless angle is required, and `delay(duration=1.0)`, where seconds are required.
W5 ONWARD25-gate catalogue with vendor-native extensions, then the 10-platform hardware registry, then OpenQASM 3.0 codegen as the reference backend, then canonical serialisation and signing.
rx(angle=2.0 Hz) q[0]; // error: argument 'angle' expects a dimensionless quantity, // got frequency [Hz] delay(duration=1.0) q[0]; // error: argument 'duration' expects a time quantity, // got dimensionless
Dimensional compatibility is enforced at compile time. A unit error never reaches a control system, never becomes a silent miscalibration, and never lands in an audit trail as a reproducibility failure.
The standards bodies in scope
Four bodies, two at HIGH priority and two at MEDIUM. Priorities reflect fit, not entitlement: nothing here is a member seat, and every submission is a contribution offered into a working group that may accept it, amend it, or decline it.
IEEE P3109HIGH priorityStandard for Quantum Computing Application Programming Interface
The working group is defining the cross-vendor application programming interface for quantum computing. EQL targets the interface layer: a human-readable program specification that compiles to QIR or to a vendor-native circuit.
Contribution submitted Q4 2027 · working group review and v1.0 release across 2028 · ratification with EQL referenced as a DSL targeted 2029.
candidate
EQL is a candidate because it already exists as a working reference implementation under Apache 2.0, with a lexer, parser, unit registry and deterministic serialisation. A working implementation plus a published spec is what a working group can actually consume — and EQL is positioned above QIR rather than competing with it, so it adds a layer the group does not have.
IEEE P3120HIGH priorityStandard for Quantum Computing Performance Benchmarking
The working group is defining how quantum performance is measured and reported, including error-correction code representation. EQL's contribution here is the representation of error-correction codes inside the same intermediate representation used for application circuits.
Contribution targeted 2028, following the P3109 submission and the EQL v1.0 release.
candidate
Benchmarking needs a way to name, hash and reproduce the exact artifact that was measured. EQL emits a canonical hash and an Ed25519 envelope for every compiled program, which makes a benchmark citation verifiable rather than asserted. The T5.4 audit engine then adjudicates the resulting claims independently.
OMG Quantum WGMEDIUM priorityQuantum Computing Standards
Object Management Group working group covering quantum computing modelling. EQL's contribution is a model interchange format: the same cross-layer intermediate representation carries hardware description, QEC policy, classical control, application intent, cost model and provenance.
Submission targeted Q1 2028.
candidate
Interchange formats are the natural home for a cross-layer IR, and EQL is vendor-neutral by construction — one source compiles to OpenQASM 3.0, Qiskit, Cirq, Q#, QPanda3 and other backends, so no vendor is forced to fork the model. The Apache 2.0 licence keeps it fork-friendly for a consortium.
ETSIMEDIUM priorityQuantum Computing Standards
European Telecommunications Standards Institute quantum computing standardisation, aimed at telecom-adjacent and European market requirements. EQL's contribution is the vendor-neutral orchestration and timing layer for distributed deployments.
Submission targeted Q2 2028.
candidate
ETSI is the European path into the same recognition EQL is seeking, and it rewards a vendor-neutral specification that a European operator or research network can adopt without changing vendors. EQL's timing-aware fields and cross-vendor provenance map onto that requirement, and the European funding and academic-bridge path is where the co-authors come from.
Submission timeline · Q4 2026 → 2029
| Quarter | Milestone |
|---|---|
| Q4 2026 | EQL v0.1 design spec complete · compiler build starts (W1-2 shipped) |
| Q1 2027 | EQL v0.1 released as a public repository · Colab quickstart, no install required |
| Q2 2027 | Validation runs on the CERN Geneva Quantum Network path and on Origin Quantum wuKong-180 |
| Q3 2027 | IEEE-style specification published (20-30 pages) with a public review period |
| Q4 2027 | EQL contribution submitted to the IEEE P3109 working group |
| 2028 | P3109 working group review · EQL v1.0 release · P3120, OMG and ETSI submissions |
| 2029 | IEEE P3109 ratification with EQL referenced as a DSL |
This is a plan, not a schedule of commitments made by third parties. Working-group calendars, membership and review outcomes are not ours to set.
50–70% probability of meaningful recognition within 24 months
That is our estimate, and it is an estimate — not a guarantee, not a forecast, and not a commitment from any standards body. Working groups accept contributions only when the members choose to, and the most likely single outcome is still that EQL stays a good tool that some people use.
| Outcome within 24 months | Estimate · moat |
|---|---|
| Accepted as an IEEE P3109 working group contribution | 50% · HIGH |
| Referenced as a recommended DSL in the P3109 annex | 30% · MEDIUM-HIGH |
| Adopted in IEEE P3120 for performance benchmarking | 40% · MEDIUM |
| De facto standard without formal adoption | 30% · MEDIUM |
| Fails to gain standards traction | 10% · LOW |
Read the number as: a better-than-even chance that EQL is taken seriously as a cross-vendor orchestration language inside two years, and a minority chance that it changes how quantum software is written. Both numbers move if the pilot partners do not materialise — which is why the next step is a working repository rather than a paper.
How the language becomes a standard
Four steps, in order. Each one is a precondition for the next, and none of them can be skipped.
1 · Reference implementationA working, Apache 2.0, zero-dependency compiler that runs in a browser tab. Standards bodies respond to code, not to design intent — the repository is the first argument.
2 · Industry pilotUniversity and industry partners compile their own circuits, publish notebooks against the same API, and file issues that harden the specification before it is submitted.
3 · Standards proposalA formal specification and a tested implementation are submitted into a working group, where the language becomes a proposal under review rather than a vendor roadmap item.
4 · De facto standardOnce the language is referenced in a standard or adopted by enough vendors, the abstraction compounds: hardware platforms are added by third parties, and the orchestration layer is owned by the ecosystem rather than by a single vendor.
The compiler is the means, not the goal. A language nobody uses is a repository, not a standard. The goal is a specification that a working group can adopt and a vendor ecosystem can implement without asking our permission — at which point the orchestration layer is settled, and the orchestration layer is the layer everything else compounds through.
Contribute to the language itself
EQL is Apache 2.0, TypeScript, zero runtime dependencies in the core library and browser-runnable. The specification is written in public, the test suite is public, and the issues are open. If you want a gate, a unit type, a platform adapter or a worked example on your own hardware, the shortest path is a pull request against the compiler.
EigenOS-Quantum/eqlThe compiler — lexer, parser, unit registry, gate catalogue, hardware registry, canonical serialisation and signing. Apache 2.0, zero runtime dependencies in the core library.
https://github.com/EigenOS-Quantum/eqlEigenOS-Quantum/eql-examplesExample circuits, tutorials and Colab notebooks that run without installation. The shortest path from curiosity to a compiled artifact.
https://github.com/EigenOS-Quantum/eql-examplesEigenOS-QuantumThe organisation. All four public repositories are Apache 2.0 and fork-friendly.
https://github.com/EigenOS-QuantumGates, units, platform adapters and examples are all mergeable without a governance discussion.
The language specification is drafted in the open and reviewed before it is ever offered to a working group.
Apache 2.0 means an independent implementation is a legitimate move, not a legal one.
Standards bodies read working code
If you maintain a quantum codebase, a hardware adapter or a benchmark suite, tell us what EQL should compile to. Partner, pilot and standards-track conversations all start from the same place: a concrete circuit and a real requirement.