Query the evidence, don't trust the summary

Start here

No key, no signup, nothing to negotiate. Three steps take you from the API to a hash you recomputed — paste them and they work:

# 1. what the archive measures — it opens with its own negative
curl -s https://rosettaquantum.com/v1/state

# 2. one sealed file, with the hash it claims and its two public copies
curl -s https://rosettaquantum.com/v1/archive/PR-CLEV-001

# 3. recompute that hash yourself and compare — prints MATCH
curl -s https://rosettaquantum.com/v1/archive/PR-CLEV-001 \
| python3 -c '
import sys,json,hashlib,urllib.request
d=json.load(sys.stdin)
raw=json.load(urllib.request.urlopen(d["github_raw"]))
meta={k:v for k,v in raw["meta"].items() if k!="content_hash"}
body={k:v for k,v in raw.items() if k not in ("meta","storage")}
mine="sha256:"+hashlib.sha256(
    json.dumps({"meta":meta,**body},sort_keys=True,ensure_ascii=False).encode()).hexdigest()
print(mine); print(d["content_hash"])
print("MATCH" if mine==d["content_hash"] else "MISMATCH")'
      

Step 3 prints MATCH. If it ever prints MISMATCH, we are wrong and you can say so in public — that is the whole point:nothing here asks to be believed. The hash covers the file's content, not the file: storage is excluded because it says where a copy lives, not what it says. The four conventions are below, under How to verify anything this API tells you.

For agents

# the full contract, machine-readable
curl -s https://rosettaquantum.com/v1/openapi.json

# MCP over JSON-RPC 2.0 — no key either
curl -s -X POST https://rosettaquantum.com/mcp \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'
      

Point an MCP client at https://rosettaquantum.com/mcp — 9 read-only tools, no authentication step.

We publish our own usage

curl -s https://rosettaquantum.com/v1/usage

How often this API is actually called, in the open. If it says zero, it says zero — the same rule as the quantum-wins counter. It stores no IP, no user-agent and no identifier: only a date, a surface and the shape of the route, so nothing there can reconstruct what anyone looked up. It also states its own blind spots, because a number without its limits is a claim.

Returns the measured state of the archive. Today it opens with0 measured quantum wins — in no sealed run so far has a quantum method beaten the classical champion. That negative is the product of this archive, not a gap in it, so the API states it first.

Endpoints

No authentication. CORS open. Cached 5 minutes at the edge.

How to verify anything this API tells you

content_hash is not the sha256 of the file. It is the sha256 of a canonical payload: the document without meta.content_hash, without meta.schema and without storage, serialised in a fixed way. Hashing the file as downloaded gives a different value — forRQ-EXP-EON-K20-002 the declared hash is 4ffdfeb4… while the sha256 of the file is a6ff6a5f…. Both are correct; they are answers to different questions.

Download the bytes as they were sealed

Use GET /v1/archive/<id>/raw, or either public mirror. Do not useGET /v1/archive/<id> for verification: that endpoint re-serialises the JSON, and a float written 6.0 comes back as 6. The seal is unaffected; your ability to recompute it is not. Measured over the 72 published runs:72 of 72 verify from /raw, 17 of 72 from the re-serialised endpoint. The /raw response carries the declared hash in thex-rq-content-hash header so you can compare without parsing the body.

The four conventions, and why there are four

The archive grew in four stages, and a published hash is a public fact: older files are not re-sealed to make the set uniform. Their hashes are anchored in Bitcoin and third parties have already cited them — re-sealing would invalidate real anchors. So verifying means trying the four and reporting which one reproduced. That is history declared, not disorder.

v3 is the one that travels. Under v1 and v2 the hash depends on how Python prints numbers: it writes a float 6.0 where JavaScript, Go and Rust write 6. Parse such a file in another language, re-serialise it, and you get a different hash — silently, and looking exactly like tampering. It is not. Under v3 that limitation is gone: JCS normalises numbers, which is what it was designed for. New seals go v3 and only forward.

The tool

tools/verificar.py — one file, no dependencies, all four conventions. It reports which one reproduced each hash, or fails loudly. Verified over the full archive: 72 of 72.

# download as sealed, then verify — prints VALID and the convention used
curl -s https://rosettaquantum.com/v1/archive/EXP-0012-001/raw -o sellado.json
curl -sO https://raw.githubusercontent.com/RosettaQuantum/evidence/main/tools/verificar.py
python3 verificar.py sellado.json
      

Each sealed file is also timestamp-anchored in Bitcoin via OpenTimestamps, on a chain none of the parties to this archive controls. Full spec in thearchive protocol.

MCP server

POST https://rosettaquantum.com/mcp speaks JSON-RPC 2.0 and exposes 9 read-only tools: estado_del_archivo, buscar_evidencia, ver_archivo, listar_por_tipo, buscar_algoritmo_cuantico, uso_de_la_api, ver_estructura, ver_propagacion and listar_fuentes_cuanticas.

curl -X POST https://rosettaquantum.com/mcp -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

Licence and citation

Data is CC BY 4.0; attribution is deliberate. Cite as:Rosetta Quantum Evidence Ledger, CC BY 4.0 — https://rosettaquantum.com/ledger. The code is Apache-2.0.

What this API does not do

It is read-only. There is no write endpoint, no qlib.solve(), and no paid tier — those arrive when there is demand and measured advantage to sell, not before. If you find an error in the archive,open an issue: external correction is the QA loop this project wants.