Lab

Manacitra: a map of your qubits

Manacitra makes a map of a quantum processor's qubit pairs: which pairs keep a small, known difference and which lose it, and it uses the map to choose pairs for a job.

This page explains Manacitra for a reader who arrives here rather than on GitHub: what it measures, what it has shown and not shown, how the results were made, how to check them, and where everything lives. It follows the repository at commit d4f9acf1d969390a4835145248f07878ccc92815, after the v0.1.2 release, and says nothing the repository does not say there; where the words matter, they are the repository’s, and each block of them links to its source. Read it plain, or switch to Technical for the method’s detail and the field each number comes from.

1. What it is

What it measures

Manacitra makes a map of a quantum processor's qubit pairs: which pairs keep a small, known difference and which lose it, and it uses the map to choose pairs for a job. The name is the Sanskrit māna (measure) and citra (picture): mānacitra, the Hindi word for a map. The name is measure-picture, map; it says nothing about minds.

It maps pairs. It does not rank machines.

In the repository’s words, from README.md at d4f9acf.

It claims: the ten findings below, each with the repository’s verdict, on its processor and date.

Finding 1: DIAGNOSTIC on both; ibm_fez, ibm_kingston; kickoff 31, 5 Oct 2026.
Finding 2: MAP PRESENT; Rigetti Cepheus-1-108Q, through Open Quantum; kickoff 34b, 5 Oct 2026.
Finding 3: THE GATE on both (not explained by the tested neighbours); ibm_fez, ibm_kingston; kickoff 32, 5 Oct 2026.
Finding 4: USEFUL on ibm_fez (G = +0.0012 in fidelity); NOT SETTLED on ibm_kingston; ibm_fez, ibm_kingston; kickoff 33, 5 Oct 2026.
Finding 5: NOISE without a planted map; DIAGNOSTIC with one; a simulation of willow_pink's published noise; kickoff 36, 5 Oct 2026.
Finding 6: PLACEMENT; ACTIVITY; Rigetti Cepheus-1-108Q, through Open Quantum; kickoff 37, 38, 6 Oct 2026; PLACEMENT is read as “the levels depend on the program”.
Finding 7: HOLDS over two days; ibm_fez, all 176 coupled pairs; kickoff 35, 5 to 7 Oct 2026.
Finding 8: PINNED; DIAGNOSTIC; payoff NOT SETTLED; Rigetti Cepheus-1-108Q, through Amazon Braket; kickoff 40, 6 Oct 2026.
Finding 9: HOLDS; the level USEFUL; the kept share NOT SETTLED; Rigetti Cepheus-1-108Q, through Amazon Braket; kickoff 41, 7 Oct 2026.
Finding 10: SPREAD, MIXED, DOES NOT; the per-program pattern HOLDS a day later; Rigetti Cepheus-1-108Q, through Amazon Braket; kickoff 42, 6 to 7 Oct 2026.

It does not claim: that any device’s design is understood (a pair’s kept share is a measurement of what it did with these circuits; it says nothing about why, or about how the processor was built); that the map transfers to other circuit families (every map comes from one circuit family, and other circuits might order the pairs differently); that a stranger can check that the published runs were sealed before they ran (they predate the release, so their sealed predictions rest on the author’s dated records, which are not part of the release); or that it ranks machines (it maps pairs).

Technical

Manacitra runs two short circuits on a set of non-overlapping qubit pairs at once (27 in the published runs); every coupler on a chip can be covered in a few rounds. The two circuits use the same three two-qubit gates and differ only in single-qubit angles, so an exact model knows the difference between their outcomes in advance: 0.037765 for the main circuit. Each pair keeps some share of that difference, its kept share k, and the shares of all the pairs form the map. Three rules, fixed before any data was taken (according to the author's dated records, which are not part of this release), then say whether the map is real (it repeats and carries over to a second circuit), whether the provider's published error rates already contain it, and whether choosing pairs by it does better on unrelated work. manacitra pick then ranks the pairs from a map, highest kept share first, or, with --by level, by the plain level, which chose better pairs on the Rigetti processor where the kept share did not. It does not check the verdict (it warns when the verdict is not DIAGNOSTIC or MAP PRESENT), and Manacitra does not run your own job: you run it on the pairs you choose.

In the repository’s words, from README.md, What it does at d4f9acf.

2. The idea in six pictures

The idea in six pictures

Six pictures from the repository’s method page, each with the caption the repository gives it. The Technical layer adds the rest of the method’s text for that picture and, in words, everything the picture shows.

1. The kept share

The two circuits encode a four-site Hamiltonian in two qubits; the offset makes the transfer from 00 to 11 exact, so the model's P(11) moves from 0.962 to 1.000. On ibm_fez on 5 October 2026, pair [106, 107] moved by 0.040, slightly more than the model's 0.038 (k = 1.06). Pair [20, 21] moved by 0.008 (k = 0.22): the same gates, the same difference in angles, and most of the difference was gone. Both pairs ran in the same job, with 32,000 shots per variant each.

Technical

What the picture shows: Two circuits on one pair of qubits, identical except for their single-qubit gates, shown as two rows of boxes joined by the same three CZ gates. Beside them, three pairs of dots on a P(11) axis: the exact model's outcomes, 0.962 without the offset and 1.000 with it, a gap of 0.038; ibm_fez pair 106-107, 0.923 and 0.963, a gap of 0.040, k = 1.06; ibm_fez pair 20-21, 0.824 and 0.833, a gap of 0.008, k = 0.22.

In the repository’s words, from docs/method.md, picture 1 at d4f9acf.

2. The map

ibm_fez's heavy-hex coupling map with 27 pairs drawn as segments shaded from light blue (kept least, k = 0.22) to dark blue (kept most, k = 1.06), each also drawn thicker the more it kept and numbered by its rank (1 = kept most), and other couplers in light grey. Beside it, a smaller copy of the same map with the same 27 pairs shaded by IBM's published error score, from light (highest error, 0.021) to dark (lowest error, 0.011). The two shadings differ pair by pair.

The left map is ibm_fez's 27 pairs from Kickoff 31 (5 October 2026, 12:37 UTC), each coloured by its kept share. Each pair is also drawn thicker the more it kept, and numbered by its rank; every pair's k, x and ranks are in a table. The small map on the right colours the same pairs by the published score x (the pair's two-qubit error plus both qubits' readout errors, as IBM reported them at submission). Dark means better on both. The two pictures order the pairs differently: across these 27 pairs, k and x correlate at r = −0.18.

Technical

What the picture shows: ibm_fez's heavy-hex coupling map with 27 pairs drawn as segments shaded from light blue (kept least, k = 0.22) to dark blue (kept most, k = 1.06), each also drawn thicker the more it kept and numbered by its rank (1 = kept most), and other couplers in light grey. Beside it, a smaller copy of the same map with the same 27 pairs shaded by IBM's published error score, from light (highest error, 0.021) to dark (lowest error, 0.011). The two shadings differ pair by pair.

In the repository’s words, from docs/method.md, picture 2 at d4f9acf.

3. The three checks

Three scatter plots of ibm_fez's 27 pairs from Kickoff 31, each answering one question of the map rule, with its correlation and threshold above it. 1, does it repeat: k from one half of the runs against k from the other half, beside a dashed line of equal values; r = 0.87, needs at least 0.5, passes. 2, does it carry over: k on circuit A against k on circuit B; r = 0.82, p below 1 in 10,000, needs at least 0.4 with p below 0.05, passes. 3, is it already in the published score: k against IBM's published error score x; r = −0.18, needs |r| below 0.5, and the A-to-B correlation with x removed is 0.82, needs at least 0.3, passes. The title gives the verdict: DIAGNOSTIC.

The verdict comes from three checks on the same map. It must repeat: each half of the runs, 16,000 shots per variant per pair, gives nearly the same k (r = 0.87). It must carry over to a second circuit with a different gap (r = 0.82). And it must not be what the published score already says: k barely follows x (r = −0.18), and the carry-over survives with x taken out (r = 0.82). All three pass on ibm_fez, so the verdict is DIAGNOSTIC; a map that fails the first is NOISE, and one that x explains is REDUNDANT.

Technical

What the picture shows: Three scatter plots of ibm_fez's 27 pairs from Kickoff 31, each answering one question of the map rule, with its correlation and threshold above it. 1, does it repeat: k from one half of the runs against k from the other half, beside a dashed line of equal values; r = 0.87, needs at least 0.5, passes. 2, does it carry over: k on circuit A against k on circuit B; r = 0.82, p below 1 in 10,000, needs at least 0.4 with p below 0.05, passes. 3, is it already in the published score: k against IBM's published error score x; r = −0.18, needs |r| below 0.5, and the A-to-B correlation with x removed is 0.82, needs at least 0.3, passes. The title gives the verdict: DIAGNOSTIC.

In the repository’s words, from docs/method.md, picture 3 at d4f9acf.

4. The pipeline

Four boxes in a row joined by arrows: Map (in: 16 short circuits on a set of non-overlapping qubit pairs at once (27 in the published runs); every coupler on a chip can be covered in a few rounds; out: k per pair), Verdict (in: k from two circuits, split halves, published x; out: NOISE, REDUNDANT, DIAGNOSTIC, MAP PRESENT or NOT SETTLED), Pick (in: the map; out: the n pairs that kept the most, ranked without checking the verdict), Run, drawn dashed (your own job, run by you on the picked pairs, not by Manacitra). A dashed note above the Map box says that, according to the author's dated records, which are not part of this release, the rules and predictions were sealed before each map job was sent.

Map, then verdict, then pick, then run. The verdict says whether the map is worth using at all: a map that does not repeat is NOISE, and a map the published figures already explain is REDUNDANT.

Technical

Manacitra computes the map and the verdict; manacitra pick ranks pairs from the map and does not check the verdict, though it warns when the verdict is not DIAGNOSTIC or MAP PRESENT; and you run your own job. manacitra pick --by level ranks by the plain level instead, which chose better pairs on the Rigetti processor where the kept share did not (findings 8 and 9). On an archived file, pick, verdict and report read the counts by the bit reading the file declares (meta.bit_reading: IBM's, Open Quantum's or Amazon Braket's), refuse a file that declares none, and give the verdict and statistics of that run's own analysis; a Braket map's published score comes from the figures file it names. In the author's own use, the rules and a set of predictions were written down and hashed before each job was sent, according to the author's dated records, which are not part of this release. From this release on, new commitments can be checked by anyone with manacitra seal and, once signing is on, a public timestamp; the runs published here predate this release and cannot be checked that way.

Which to rank by: the kept share chose better pairs on ibm_fez and was not settled on ibm_kingston; the plain level, each pair's mean P(11) on circuit A without the offset, chose better pairs on the Rigetti processor, on the same day and a day later, where the kept share did not (Kickoffs 33, 40 and 41). On every payoff run both scores were scored against the published figures: on IBM the kept share was the primary test and the level a reference line; on Rigetti the reverse; no run has yet compared the two scores against each other under a rule fixed in advance. The dead-pair filter uses the run's own levels, never a list from an earlier day: on the Rigetti processor, dead pairs came and went between consecutive days (18-19 came back; 72-73 and 76-77 went).

What the picture shows: Four boxes in a row joined by arrows: Map (in: 16 short circuits on a set of non-overlapping qubit pairs at once (27 in the published runs); every coupler on a chip can be covered in a few rounds; out: k per pair), Verdict (in: k from two circuits, split halves, published x; out: NOISE, REDUNDANT, DIAGNOSTIC, MAP PRESENT or NOT SETTLED), Pick (in: the map; out: the n pairs that kept the most, ranked without checking the verdict), Run, drawn dashed (your own job, run by you on the picked pairs, not by Manacitra). A dashed note above the Map box says that, according to the author's dated records, which are not part of this release, the rules and predictions were sealed before each map job was sent.

In the repository’s words, from docs/method.md, picture 4 at d4f9acf.

5. The payoff

On ibm_fez on 5 October 2026, the map measured at 13:17 UTC chose 8 pairs, and the published error rates chose another 8. At 15:20 UTC all 27 pairs ran eight random circuits, unrelated to the map, with nine CZ gates each. The map's 8 pairs had a mean error of 0.0022 against 0.0034 for the published pick: 35.6% less. The absolute numbers are small, because every pair's fidelity was above 0.98.

Technical

What the picture shows: A scatter of 27 ibm_fez pairs: the kept share measured about two hours earlier on the horizontal axis, and fidelity on eight random two-qubit circuits on the vertical axis. The 8 pairs with the highest kept share are filled blue; the 8 with the lowest published error are ringed in orange; some pairs carry both. Dashed lines mark each pick's mean: error 0.0022 for the map's pick and 0.0034 for the published pick. The title reads: choosing by the map, 35.6% less error than choosing by the published rates.

In the repository’s words, from docs/method.md, picture 5 at d4f9acf.

6. How to check a sealed prediction

A timeline of four steps. 1, seal and post the hash (manacitra seal): shows the file existed then, without showing what it says. 2, run the job: the file stays as it was. 3, reveal the salt (manacitra reveal): publishes the file and its salt. 4, anyone verifies (manacitra verify): a match shows the predictions came before the results.

This one is for a stranger who wants to know whether the predictions came before the results. manacitra seal commits to a file with a salted SHA-256 hash, which is posted somewhere the producer cannot edit; after the run, manacitra reveal publishes the salt, and manacitra verify lets anyone check that the file is the one committed to. Once the repository is public, a CI workflow also signs every commit record and every data file with Sigstore's keyless signing, which records who signed and when in a public log (docs/index.md).

Technical

The commit record shows that the file existed when its hash was posted; it does not show when that was. The time comes only from where the hash was posted (the record's own sealed_utc is the sealing machine's clock).

manacitra seal predictions.md      # before the run: prints the hash to post; the salt stays in .seals/
manacitra reveal predictions.md    # after the run: writes the salt into predictions.md.commit.json
manacitra verify predictions.md    # anyone, with the file and its commit record: MATCH
printf 'x' >> predictions.md && manacitra verify predictions.md   # one byte changed: NO MATCH, exit status 1

What the picture shows: A timeline of four steps. 1, seal and post the hash (manacitra seal): shows the file existed then, without showing what it says. 2, run the job: the file stays as it was. 3, reveal the salt (manacitra reveal): publishes the file and its salt. 4, anyone verifies (manacitra verify): a match shows the predictions came before the results.

In the repository’s words, from docs/method.md, picture 6 at d4f9acf.

3. Findings

What it has shown

Ten findings, from runs on 5 to 7 October 2026. Each is given in full, with its caveats, in docs/findings.md; the number links to it. What has not been shown is there too.

#	finding	where	kickoff, 2026	verdict
1	Each pair keeps its own share, and the share repeats	ibm_fez, ibm_kingston	31, 5 Oct	DIAGNOSTIC on both
2	The map exists on a second vendor's chip, within one job	Rigetti Cepheus-1-108Q, through Open Quantum	34b, 5 Oct	MAP PRESENT
3	The gap between the best and worst pairs persisted when their neighbours were idle	ibm_fez, ibm_kingston	32, 5 Oct	THE GATE on both (not explained by the tested neighbours)
4	On ibm_fez, choosing pairs by the map gave 35.6% less error on unrelated random circuits than choosing by the published error rates	ibm_fez, ibm_kingston	33, 5 Oct	USEFUL on ibm_fez (G = +0.0012 in fidelity); NOT SETTLED on ibm_kingston
5	The rule can say no	a simulation of willow_pink's published noise	36, 5 Oct	NOISE without a planted map; DIAGNOSTIC with one
6	On the Rigetti processor, a pair's level depends on the program that measures it, not on the hour	Rigetti Cepheus-1-108Q, through Open Quantum	37, 38, 6 Oct	PLACEMENT; ACTIVITY
7	On ibm_fez, a map of the whole chip held for two days	ibm_fez, all 176 coupled pairs	35, 5 to 7 Oct	HOLDS over two days
8	On the Rigetti processor, with placement pinned, the map is DIAGNOSTIC	Rigetti Cepheus-1-108Q, through Amazon Braket	40, 6 Oct	PINNED; DIAGNOSTIC; payoff NOT SETTLED
9	The pinned Rigetti map lasted a day, and the day-old level chose better pairs	Rigetti Cepheus-1-108Q, through Amazon Braket	41, 7 Oct	HOLDS; the level USEFUL; the kept share NOT SETTLED
10	On the Rigetti processor, a pair's response to a particular program repeats a day later, and a smooth shift of the offset does not describe it	Rigetti Cepheus-1-108Q, through Amazon Braket	42, 6 to 7 Oct	SPREAD, MIXED, DOES NOT; the per-program pattern HOLDS a day later

In the repository’s words, from README.md, Findings (each number links to the finding in full) at d4f9acf.

What would discredit the map: a NOISE verdict (it does not repeat), a REDUNDANT verdict (the published figures already carry it), NOT USEFUL (it picks no better pairs), or FADES (it does not last long enough to plan by).

What it has not shown

How long a map lasts beyond two days. On ibm_fez a whole-chip map held for two days (finding 7); on the Rigetti processor a pinned map held for one (finding 9). Neither has been measured over a week. Through Open Quantum, where placement is not recorded, a fixed program's levels held over about 9 hours and a day (Kickoff 37), but its pair names did not locate the physical qubits that ran (finding 6).
Why some pairs respond to particular programs on the Rigetti processor. Kickoff 42 found the response and found that it repeats; it did not identify a cause. Coherent error that depends on the single-qubit frame is the ordinary explanation and is not tested here.
Whether the kept share chooses better pairs on the Rigetti processor. Twice NOT SETTLED (findings 8 and 9). The plain level did, both times. On both IBM chips the level was scored as a chooser for reference and gained less than the kept share did; no run has yet compared the two scores against each other under a rule naming either as the primary test.

In the repository’s words, from docs/findings.md, What it has not shown at d4f9acf.

The numbers this page states

0.037765: the difference an exact model puts between the two variants of the main circuit, circuit A. an exact model, no hardware.; From src/manacitra/circuits.py, GAP["A"].
r = 0.87: the map from one half of the runs against the other half (does it repeat). ibm_fez, Kickoff 31, 5 October 2026, 12:37 UTC.; From data/ibm_fez/k31-map.json, archived/analysis/S1/r_split_A/pearson, recomputed from the archived inputs by the repository's tests (tests/expected_fields.json).
r = 0.82: circuit A's map against circuit B's (does it carry over). ibm_fez, Kickoff 31, 5 October 2026, 12:37 UTC.; From data/ibm_fez/k31-map.json, archived/analysis/S2/r_AB/pearson, recomputed from the archived inputs by the repository's tests (tests/expected_fields.json).
r = −0.18: the map against IBM's published error score (is it already there). ibm_fez, Kickoff 31, 5 October 2026, 12:37 UTC.; From data/ibm_fez/k31-map.json, archived/analysis/S3/r_Ax/pearson, recomputed from the archived inputs by the repository's tests (tests/expected_fields.json).
35.6% less error, G = +0.0012 in fidelity: choosing 8 pairs by the map against choosing by the published error rates, on unrelated random circuits. ibm_fez, Kickoff 33, 5 October 2026, 15:20 UTC.; From data/ibm_fez/k33-payoff.json, archived/analysis/gains/k_prior/G, recomputed from the archived inputs by the repository's tests (tests/expected_fields.json); the percentage is 1 − (mean error of the map's pick ÷ mean error of the published pick), from archived/analysis/W and archived/analysis/picks (k_prior, x), as tests/test_readme_numbers.py recomputes it.
two days: a map of the whole chip, all 176 coupled pairs, held from Day 1 to Day 3 (HOLDS). ibm_fez, Kickoff 35, 5 to 7 October 2026.; From data/ibm_fez/k35-persistence.json, archived/across/verdict, recomputed from the archived inputs by the repository's tests (tests/expected_fields.json).
27% less error, dominated by one pair: choosing 8 pairs by the previous day's plain level, not the kept share, against Rigetti's figures read that day (G = +0.0122). Rigetti Cepheus-1-108Q through Amazon Braket, Kickoff 41, 7 October 2026.; From data/rigetti_cepheus_1_108q/k41-payoff.json, archived/analysis/level/relative_error_reduction, recomputed from the archived inputs by the repository's tests (tests/expected_fields.json).

Technical

The findings come from runs on 5 to 7 October 2026. The counts are in data/. Every statistic listed in tests/expected_fields.json is recomputed from the archived inputs: the raw counts where the release includes them; for the Kickoff 29 settling runs and some Rigetti comparisons, the archived probability or level tables, whose counts are not in this release; and, for elapsed times, the archived timestamps, and compared at 10⁻⁶, except the seeded resampling fields: the intervals that also resample shots, at 10⁻³, and Kickoff 42's bootstrap SDs, at 10⁻⁶ under numpy 2.5 or later (each marked in tests/expected_fields.json). Fields that cannot be recomputed from this release are named, with reasons, in tests/excluded_fields.json. Both lists are checked by pytest tests/test_reproduction.py tests/test_field_inventory.py (from a clone, after pip install -e ".[dev,aer]", which gives pytest). Every measured statistic in the README and on this page is checked by a test; times, ranges and counts are taken from the data files and listed in tests/test_readme_numbers.py.

Finding 6, in full, states its verdict this way: Verdict, by a rule fixed before the run according to the author's dated records: PLACEMENT, read as "the levels depend on the program".

In the repository’s words, from docs/findings.md at d4f9acf.

4. Limits

Limits

One circuit family. Every map comes from one encoded four-site Hamiltonian, at two strengths of its diagonal coupling (circuits A and B). Other circuits might order the pairs differently.
Three processors, three days. The hardware results are from ibm_fez and ibm_kingston, and from Rigetti Cepheus-1-108Q through Open Quantum and through Amazon Braket, all on 5 to 7 October 2026.
Two routes to one processor. The Rigetti findings through Open Quantum (2, 6) and through Amazon Braket (8 to 10) are from the same processor, but only the Braket route records where each pair ran. The difference between them is a difference between the two platforms' placement records, not between the vendors' machines.
Small absolute differences. The gap is 0.038 in P(11), and the payoff is about a tenth of a percentage point of fidelity on the random workload.
No claim about any device's design. A pair's kept share is a measurement of what it did with these circuits; it says nothing about why, or about how the processor was built.

In the repository’s words, from README.md, Limits at d4f9acf.

5. How the results were made

How the results were made: kickoffs

Every result in the findings came from a kickoff: a written brief, fixed before a run (according to the author's dated records, which are not part of this release). A brief states:

the question;
the exact circuits, and how pairs are chosen;
the shot counts;
the analysis;
the verdict rule, with every threshold;
the cost or time cap;
what goes in the hand-back.

A vertical timeline of seven numbered steps, one line under each. 1, Brief: the question and every rule, fixed in writing. 2, Sealed predictions: hashed and timed before any data exist. 3, Go: the author approves each submission in chat. 4, Run: each job is sent once, never resubmitted. 5, Hand-back: code, data, a report and checksums. 6, Independent check: the results recomputed with separate code. 7, Scorecard: every prediction marked; nothing edited. A note below: a rule changes only by a dated amendment, before the data it governs are seen, and the original rule is still reported beside the new one.

The published runs predate this release, so their sealed predictions rest on the author's dated records; from the first public release on, new commitments can be checked by anyone with manacitra seal and the signing log.

In the repository’s words, from docs/kickoffs.md and the README at d4f9acf.

Technical

The practices below are as the author's dated records describe them; those records are not part of this release.

Predictions are sealed before the run. The AI that carries out the kickoff writes its own predictions and records their hash and time before any data exist. The author's predictions are kept separately, unseen by the runner. Both are marked afterwards and never edited.
Every submission needs a go. Nothing goes to hardware without the author's go for that submission, given in chat. Each job is submitted once and never resubmitted.
The hand-back is checked independently. The runner returns code, data, a report and checksums. The results are then rechecked with separate code, and a scorecard marks every prediction and records the verdict.
Changes are written down. If a rule has to change, it changes by a dated amendment, before the data it governs are seen, and the original rule is still reported beside the new one.
The rules were tested too. Kickoff 36 tested the rules themselves, on a simulated chip where the right answers were set in advance.

The kickoff texts and the sealed predictions are kept and dated, and are not part of this release.

What the picture shows: A vertical timeline of seven numbered steps, one line under each. 1, Brief: the question and every rule, fixed in writing. 2, Sealed predictions: hashed and timed before any data exist. 3, Go: the author approves each submission in chat. 4, Run: each job is sent once, never resubmitted. 5, Hand-back: code, data, a report and checksums. 6, Independent check: the results recomputed with separate code. 7, Scorecard: every prediction marked; nothing edited. A note below: a rule changes only by a dated amendment, before the data it governs are seen, and the original rule is still reported beside the new one.

In the repository’s words, from docs/kickoffs.md at d4f9acf.

6. How to check it yourself

How to check it yourself

Install. Manacitra needs Python 3.11 or later. It is not yet on PyPI. From a clone, editable, which is the route for reproducing the published numbers:

git clone https://github.com/dogma-guru/manacitra.git
cd manacitra
python -m venv .venv
source .venv/bin/activate      # on Windows: .venv\Scripts\activate
pip install -e ".[aer]"

Then, on the simulator, with no account (paste this into a Python session):

from manacitra.backends.base import MapJob
from manacitra.backends.simulator import NoiseModel, SimulatorBackend
from manacitra.layout import pick_pairs
from manacitra.verdicts import analyse_map

pairs = [(2 * i, 2 * i + 1) for i in range(27)]
noise, _ = NoiseModel.random(pairs, seed=1).planted(sigma=0.03)  # a hidden per-pair map
sim = SimulatorBackend(noise, seed=7)
counts = sim.fetch(sim.submit(MapJob(pairs)))
result = analyse_map(counts.p11(), counts.order, x=sim.target().x_of(pairs))
print(result["verdict"]["verdict"], [pairs[i] for i in pick_pairs(result["kA"], 8)])

It prints DIAGNOSTIC and the eight pairs that kept the most. Three longer examples are in examples/: the simulator end to end, the ibm_fez numbers reproduced from the archived counts, and the payoff choice.

Reproduce. The two test commands and the payoff example, from the clone:

pip install -e ".[dev,aer]"
pytest tests/test_reproduction.py tests/test_field_inventory.py   # every listed statistic, from the archived inputs
python examples/03_pick_pairs.py                                   # finding 4: both picks and the 35.6%

Every statistic listed in tests/expected_fields.json is recomputed from the archived inputs and compared at 10⁻⁶, with the exceptions named in docs/findings.md; every measured number in the README and the findings is checked by a test.

Verify a signature. Every file in data/ is signed when it lands on the default branch, and its bundle sits beside it. To verify one:

pip install sigstore
sigstore verify identity data/ibm_fez/k31-map.json \
  --cert-identity https://github.com/dogma-guru/manacitra/.github/workflows/sign.yml@refs/heads/main \
  --cert-oidc-issuer https://token.actions.githubusercontent.com

sigstore finds the bundle data/ibm_fez/k31-map.json.sigstore.json beside the file. The expected certificate identity is this repository's signing workflow on the default branch, and the issuer is GitHub Actions' OIDC issuer.

The identity is https://github.com/dogma-guru/manacitra/.github/workflows/sign.yml@refs/heads/main and the issuer https://token.actions.githubusercontent.com.

In the repository’s words, from README.md and docs/index.md, section 9 at d4f9acf.

Technical

The seal and the signature answer different questions. The seal (manacitra seal, a salted SHA-256 hash) says what was committed to without showing it, and carries no trusted clock: the time comes only from where the hash was posted. The signature (Sigstore’s keyless signing, under the signing workflow’s own identity, recorded in Sigstore’s public transparency log) says who published which bytes, and when. Together, from the first public release on, they let a stranger check that a prediction came before a result. The published runs predate the release: their sealed predictions rest on the author’s dated records, which are not part of the release.

From docs/index.md, section 9 and docs/method.md, picture 6, in this page’s words.

7. Independent review

Independent review

Two independent trials of the public repository were run by Codex, working from the repository’s public address alone, on 7 and 8 October 2026. The first marked 35 checks PASS, 14 FAIL and 4 CANNOT CHECK; the second, on v0.1.1, 41 PASS, 7 FAIL and 4 CANNOT CHECK. In both, the installs, the examples and the three independent recomputations from the raw counts passed. What each trial found wrong, and how each item was fixed, is recorded in the repository’s build report, in section 21 and section 24. Two source reviews of the repository on 8 October raised the points that Amendments A13 and A14 answer (sections 25 and 26). The trial reports themselves are not published here: the repository is the source of every file.

8. Where it lives

Where it lives

The repository
at commit d4f9acf
README.md
the short version: what it does, the findings table, the limits, install and reproduce
docs/findings.md
the ten findings in full, and what has not been shown
docs/method.md
the method in six pictures
docs/kickoffs.md
how the results were made, and every run
build-report.md
the record of how each release was built and checked
The v0.1.2 release
8 October 2026; the tag is on commit 8b5e2ff, and d4f9acf adds the version's DOI to the README
Zenodo, concept DOI 10.5281/zenodo.23228518
always the latest version; v0.1.2 is 10.5281/zenodo.23248147

To cite it, use CITATION.cff, which gives the full citation: Manacitra: a map of your qubits (version 0.1.2) [Software and data]. Zenodo. https://doi.org/10.5281/zenodo.23228518. Source: https://github.com/dogma-guru/manacitra

If it is useful to you, you can support its work on Patreon. Forks are welcome; pull requests are not accepted at this time, and questions go to Issues (CONTRIBUTING.md).

Contact: the repository’s Issues. Pull requests from outside are not accepted at this time.

In the repository’s words, from README.md, How to cite and Support at d4f9acf.

Versions

v0.1.0, 8 October 2026, the first release; v0.1.1, 8 October 2026, the documentation release; v0.1.2, 8 October 2026, corrections from the second trial and two source reviews; the page follows the repository at d4f9acf and is updated by amendment when the repository changes.

Diagrams and data: Dogma LLC, CC BY 4.0, from the Manacitra repository at d4f9acf1d969390a4835145248f07878ccc92815.