Versioned deterministic mapping with schema and tests.
An open technical invitation to the OpenQASM community
Help us make the IvritCode → OpenQASM bridge useful.
Quantum Etz Chaim is an independent experimental architecture that turns Hebrew-letter programs into deterministic execution traces, emits an OpenQASM 3 projection, binds the result into a replayable Run Passport, and can manifest machine state on a physical QEC-1 panel. We are asking OpenQASM engineers and users to inspect the bridge, challenge the mapping, validate it against real toolchains, and help us expand it responsibly.
QEC is asking for OpenQASM review. Inspect the deterministic IvritCode → OpenQASM bridge, test it against real tools, and help us improve it.
22IVRITCODE INSTRUCTIONS
3.0CURRENT EMITTED QASM HEADER
3.1CURRENT OPENQASM SPEC CHECKED 2026-09-16
56QEC-1 STATE INDICATORS
Independent project. Quantum Etz Chaim is not affiliated with, endorsed by, or part of the OpenQASM or Qiskit projects. The current QEC projection is intentionally described as emit-only while independent compatibility evidence is expanded.
אור and שלום pass pinned parser/import/statevector checks; no certification or hardware claim is implied.
Emitted source, trace, hashes, panel frames, and provenance travel together.
Parser validation, semantic critique, backend tests, and profile evolution.
Why this boundary
We do not want a private quantum interchange format.
OpenQASM is built to serve as an intermediate representation between higher-level tooling and quantum execution systems. That makes it the right place for QEC to expose its circuit-level projection and invite outside scrutiny rather than hide behind a proprietary output format.
A legible handoff
IvritCode remains the symbolic source language. OpenQASM becomes the explicit quantum-toolchain handoff. QEC can evolve without asking outside tools to learn QEC’s internal symbolic runtime.
Open the OpenQASM specification ↗A boundary experts can attack
The current 22-letter mapping is deterministic. That does not make it optimal. Publishing the profile lets compiler and quantum-language experts identify bad assumptions, weak semantics, or avoidable incompatibilities.
Claims can become testable
“It emits OpenQASM” is a small claim. Parser acceptance, simulator execution, and backend testing are stronger claims. QEC is designed to record those steps separately rather than blur them together.
The complete bridge
Source, projection, evidence, machine.
The OpenQASM output is one part of a larger reproducibility chain. The same run can carry a deterministic symbolic trace, its OpenQASM projection, transport frames for the physical panel, acknowledgements, and provenance in one versioned passport.
IvritCode
Hebrew-letter source with final-form and combining-mark normalization.
QEC runtime
Deterministic symbolic execution with trace, state, Gates, and provenance.
Projection
Versioned 22-instruction mapping emits ordinary OpenQASM 3 source.
Validation
Canonical אור and שלום now pass external parser, Qiskit import, statevector, and independent Rust front-end checks.
Run Passport
Source, hashes, emitted QASM, trace, machine frames, and evidence stay bound.
QEC-1P
A separate classical hardware witness manifests deterministic machine state.
The physical machine remains central.
QEC-1 is not presented as quantum processing hardware. It is the tangible end of the QEC state pipeline: 24 keys, 56 addressable indicators, low-voltage control, and a visible manifestation of deterministic execution. The OpenQASM bridge is how QEC reaches outward into quantum software ecosystems.
The claim stays narrow.
Today: deterministic emission plus corpus-scoped external parser and statevector evidence. Next: broader corpus, OpenQASM 3.1 review, and backend-facing experiments with exact versions and results.
Live projection / profile 0.1
Put Hebrew source on one side. Inspect OpenQASM on the other.
This browser demo uses the repository’s real compiler function, not a hand-written example. The default target allocates three qubits. The current profile emits an `OPENQASM 3.0;` declaration while the broader OpenQASM project currently identifies 3.1 as its current public specification. That version question is part of the review we are asking for.
IvritCode source
Try a program.
Use Hebrew letters only. Niqqud and cantillation are stripped; final forms are normalized. Try אור or שלום.
PROFILE READY / ivritcode-openqasm-0.1Gate evidence milestone
231 Gates. Evidence before execution.
QEC separately tracks symbolic directional Gate rules. Every direction remains fail-closed until replayable evidence supplies the program, deterministic seed, exact Gate index, and observed machine topology needed to approve it. Symbolism alone never activates a Gate.
This is not the same layer as the 22-letter OpenQASM mapping. It is shown here because the same design principle governs both: stronger claims require stronger, replayable evidence.
231Canonical Gates
462Directional possibilities
22Evidence-backed directions
440Reserved directions
8Evidence programs
אור · שלום · בראשית · אמת · אחד · חיים · דעת · מלכות
Where we need help
We want criticism that changes the implementation.
We are not asking the OpenQASM community to accept QEC’s assumptions. We are asking people who know the language, parsers, compiler IRs, simulators, and backend interfaces to tell us where the bridge is wrong, shallow, obsolete, or useful.
Break the emitted source.
The first canonical parser milestone now passes. Expand the corpus, reproduce our pinned results, and bring us exact diagnostics or failure cases from additional independently maintained tools.
Tell us how to version the target.
Should profile 0.1 remain a frozen 3.0 contract, migrate to 3.1, or coexist with a new versioned profile? We want the answer driven by compatibility and semantics, not by changing a header because a newer number exists.
Challenge all 22 mappings.
Deterministic is not synonymous with well-designed. Review gate choice, arity, parameter values, operand rotation, measurement behavior, and whether the profile teaches the wrong abstraction about quantum programs.
Build a compatibility matrix.
Help us test multiple independently maintained tools and separate “parses,” “simulates,” and “runs on a hardware-facing stack” into distinct, versioned claims.
Expand beyond a flat gate stream.
Guide the next profile toward OpenQASM-native control flow, parameterization, subroutines, timing, richer measurement behavior, and calibration-aware boundaries where those features actually add technical value.
Improve the Run Passport.
Review whether binding the emitted OpenQASM and validation artifacts to the same execution passport is useful. Tell us what metadata a real reproducibility record should contain and what should remain outside it.
Inspect, do not trust
The contracts and evidence are public.
The fastest way to understand QEC is to inspect the actual contracts, tests, and physical build path. The site is the invitation; the repository is the argument.
Translation contract
ivritcode-openqasm-v0.1.json is the
machine-readable 22-letter projection profile.
Versioned validation
The profile and Run Passport have JSON Schemas so structural claims can fail closed.
Inspect the schema →The actual compiler
The live demo imports the same TypeScript implementation tested by the repository.
Read src/openqasm.ts ↗Deterministic behavior
Normalization, mapping, output shape, and Run Passport binding are covered by automated tests.
Read the tests ↗External evidence
Exact validator versions, QASM hashes, parser results, and statevector evidence are captured for the canonical corpus.
Read validation evidence →Physical manifestation
QEC-1P is the separate classical bench-validation path for panel state, transport, and acknowledgements.
Open the bench proof →