Open source

Contributing

KetQat is Apache-2.0 and vendor-neutral. This page says what the project actually needs, where the code is, and what a change has to prove before it lands.

This is a young project with few users and little outside contribution so far. That is worth knowing before you invest time: your change will get attention, and it will also be carrying more weight than a change to an established codebase.

Three ways in

Add a decoder or a noise model

Contribution packs let you add a decoder, a noise model, or a benchmark suite as data rather than code. A pack is a YAML document validated against a published schema, so a contribution cannot execute anything during review — the validator refuses YAML anchors, aliases, and tags outright.

Templates and the threat model are in contrib/. Validate before opening a pull request:

node scripts/validate-contribution.mjs contrib/my-decoder.yaml

Work on the engine

The SDK holds the transpiler, the resource estimator, the ZX pipeline, the error-mitigation code, and the Stim and PyMatching integration. It is TypeScript and Python, and the two must agree: the reproducibility hash is computed in both and the byte outputs are compared in CI.

git clone https://github.com/ketqat/ketqat-sdk
cd ketqat-sdk && npm install && npm test
python3.11 -m pip install -e ./python && python3.11 -m pytest python/tests

Report something wrong

A result that looks wrong is the most useful thing you can send. If a benchmark disagrees with a published figure, or a decoder underperforms its paper, that is a bug worth a report even if you cannot say why.

Include the reproducibility hash from the run page. It identifies the exact inputs, so the run can be repeated without guessing at parameters.

Open an issue, or for anything with a security dimension follow the security policy instead of filing publicly.

What a change has to prove

A test that fails without it. Confirm your test fails before your change and passes after. A test written after the fact often passes for a reason unrelated to the bug, and this project has merged three of those — each looked like coverage and asserted nothing.

Scientific claims carry their evidence. A decoder said to reach a threshold needs the run that shows it, not a citation to the paper it came from. Numbers on this site link to the runs that produced them.

Simulation is never labelled as hardware. Nothing may produce a result recorded as coming from a QPU when it did not, and there is no automatic fallback from hardware to simulation anywhere in the codebase. If a provider is unavailable the run fails.

Unknown is not zero. A measurement that could not be taken is recorded as absent. Filling it with a plausible default puts a claim in the record that nobody made.

Where to start

Issues labelled good first issue are real gaps rather than invented work, each with the file to change and how to tell it worked. They are deliberately few: a long list of shallow tasks in a project this size wastes the time of the people most willing to help.

This website is not yet open source

The SDK is public and takes contributions today. The web application is still a private repository, so contributions to the site itself are not possible yet. That is a governance decision that has not been made, not a technical obstacle — and it does block a real category of contribution, so it is stated here rather than left to be discovered.

Citing KetQat

Use the CITATION.cff in the SDK repository. It carries no DOI yet: minting one is a human step nobody has taken, and a citation file claiming an identifier that does not resolve is worse than one that admits the gap. Cite the repository and the version until that changes.