Open-1B: what auditable training actually audits

Gensyn's pitch for open-1b is precise enough to be worth taking at its word: "auditable training is the best defense against the future of AI we're being warned about," and open-1b is "a milestone toward verifiable AI." The announcement's own three-rung ladder is a good place to start, because it's honest about where most releases actually sit. An open-weight model hands you a finished cake. An open-recipe model -- most of what gets called "open source" today -- hands you the cake and the recipe card, but "nothing connects the recipe to the weights": you can't tell whether the weights in front of you are really what the recipe says they are, and a backdoor can be planted with a handful of poisoned examples out of hundreds of billions with no way to catch it after the fact. An auditable model, Gensyn says, hands you the cake, the recipe, and a kitchen camera anyone can review.

I read the tech report, cloned gensyn-ai/open-transformers, and spent an afternoon actually using the audit site at open1b.gensyn.ai rather than describing it from the announcement. The camera is real, and it is a genuinely different thing from the reproducibility literature it's implicitly competing with. But "the first model you don't have to trust" is a claim about how much trust gets removed, and the honest answer is: less than the headline, in a specific and checkable way, and not yet in practice.

What actually got trained

Strip the verification story away and open-1b is a small, ordinary-looking model: a 24-layer decoder-only transformer, d_model 2048, 16 query heads sharing 4 KV heads (GQA), hybrid sliding-window attention (512 tokens, full causal every 5th layer), untied embeddings, gain-free QK-norm, z-loss at 1e-4 -- I checked that last one against the actual training config rather than trusting the paper's prose, because the base model config in the repo defaults z-loss to 1e-5 and only the 1b_repop_v2.yaml training override raises it to 1e-4 with a comment explaining why; the two files agree, so this one checks out. All of it is trained with native int8 weight-and-activation quantization from step zero (W8A8, learned step-size quantization re-pinned every optimizer step, not trained as in the original LSQ recipe -- more on why below).

Since this is an article about checking things rather than reading them, here is the thing to check. This is configs/train/1b_repop_v2.yaml in open-transformers, the config the audit site's manifest.json names as the run's ("model":"1b_repop_v2"), trimmed to the fields the rest of this piece leans on:

train:
  resume_reset_optimizer: false
  total_tokens: 400_000_000_000
  seq_len: 4096
  micro_batch_size: 4
  global_batch_tokens:
    warmup: 3_145_728   # M=192 (48*4),  accum=4
    main:   4_718_592   # M=288 (48*6),  accum=6
    late:   9_437_184   # M=576 (48*12), accum=12
  warmup_to_main_at_tokens: 4_000_000_000
  main_to_late_at_tokens: 360_000_000_000
  ckpt_every_steps: 100
  # ... spike protocol ...
  grad_clip: 1.0
  dead_tensor_assert_steps: 100
  state_hash:
    every_n_steps: 1
 
model:
  qat:
    enabled: true
    method: lsq
    weight_bits: 8
    act_bits: 8
    per_channel_w: true
    exempt_first_n_blocks: 0
    scale_refresh_every_n_steps: 1
  attn_int8_pv: true
  emb_norm: true
  qk_norm_gain: false
  z_loss:
    coeff: 1.0e-4

state_hash.every_n_steps: 1 is the line that makes everything after it possible: every optimizer step is committed, so any interval, however short, has a target. scale_refresh_every_n_steps: 1 is the LSQ deviation. qk_norm_gain: false is the fix for the entropy collapse the paper's stability section describes.

You do not have to trust that this file is the one that ran, either, which is the nicer part. Every published checkpoint carries a meta.json with a config_resolved blob -- the fully-resolved Hydra config as the loop saw it -- and I pulled the final checkpoint's copy from gs://gensyn-open-1b/ckpt/step_000080957/meta.json and diffed it against the yaml above. Every field matches, including the two that the paper's prose alone would leave ambiguous: z_loss.coeff resolves to 0.0001, and qat.scale_refresh_every_n_steps to 1.

400B tokens, four permissively licensed public sources weighted by their on-disk token share: DCLM-Baseline (300.5B, 66.7%), FineWeb-Edu (59.8B, 13.3%, filtered to an educational score of at least 3), The Stack v2 (54.2B, 12.0%, permissively licensed files under 1MB only), and Proof-Pile-2 (36.0B, 8.0%, arXiv + OpenWebMath + Algebraic Stack). Six a3-megagpu-8g nodes on GCP, 48 H100s, 27.8 days of active training inside a 29.5-day calendar span split across seven segments by engineering restarts. 80,957 optimizer steps.

Those data percentages are the kind of number an announcement usually asks you to accept, so I summed them. The corpus is public at gs://gensyn-open-1b/data/shards/, and each source ships a manifest.yaml that is simultaneously the index, the token ledger and the checksum list -- from data/shards/proof_pile_2/manifest.yaml:

name: proof_pile_2
tokenizer_hash: c04a34f4655a5e5c8debd1345675fbeefe68e4b8f0ef08bf29aaf3f6da0a2634
dtype: uint32
shards:
- prefix: proof_pile_2_00000
  num_documents: 14917
  token_count: 268474248
  bin_blake2b: b60b7d0a73eab824e6988cd63e80f89d22950c470001cb71d6c1750fde5702ac
  idx_blake2b: b02db89cd310e9b40575bb810317f14f89be2690a4978b2a2ebea7d05b2fb65f

Summing token_count across all four manifests -- 1,700 shards in total -- gives 450,475,403,217 tokens over 332,240,125 documents, and the per-source split is 300.51B / 59.77B / 54.19B / 36.01B, matching the comment block in configs/data/recipe_v1_proportional.yaml line for line. Divide each by the total and you get 0.6671 / 0.1327 / 0.1203 / 0.0799 -- exactly the four weight values hardcoded in that same file, to all four decimal places. The mixture weights really are the on-disk shares, not a target the corpus was described as hitting. All four manifests also declare the same tokenizer_hash, so nothing was tokenized twice by two different tokenizers.

One thing that sum quietly resolves: recipe_v1_proportional.yaml still carries a loud CYCLING WARNING saying the corpus is short of the run length and "~11% of every source is repeated." That warning was written against a 500B-token budget. The run that shipped is 400B, which is 88.8% of the 450.48B on disk -- under one epoch, no repetition. The warning is stale, not wrong, and the config that ships next to it is the thing that proves it.

The same trick works on the schedule, and this is where the audit artifact starts earning its keep. The run's whole hash chain is a single public file, gs://gensyn-open-1b/logs/state_hashes.jsonl, 10,569,883 bytes, one JSON object per step. I downloaded it (its md5 matches the x-goog-hash header GCS serves, and its sha256 is 53e556e8b977f4e1…) and counted: 80,958 lines -- one init record plus exactly 80,957 steps, contiguous from 0, no gaps, no repeats, and 80,958 distinct 64-hex digests with not one collision. Each record carries consumed_tokens, so the batch-size schedule can be re-derived from the log rather than read off the paper:

expand

The token deltas between consecutive log entries take exactly three values -- 3,145,728 for 1,272 steps, then 4,718,592 for 75,446 steps, then 9,437,184 for 4,239 steps. Those are the three global_batch_tokens numbers from the config, verbatim. The first transition lands at step 1,273, the first step after cumulative tokens cross 4,001,366,016, against the config's warmup_to_main_at_tokens: 4_000_000_000; the second at step 76,719, the first step after 360,000,258,048, against main_to_late_at_tokens: 360_000_000_000. And 1,272 + 75,446 + 4,239 = 80,957. The run length is not a round number somebody chose -- it is what this config's batch ramp produces against a 400B budget, and the published log follows it without a single off-schedule step.

expand

The benchmark number is the one place the announcement could have rounded generously and didn't. On the OLMo 2 evaluation suite, open-1b's base checkpoint scores 25.4 against OLMo 2 1B's 31.9 -- and Gensyn's own conclusion states the reason plainly: "we have trained with an order of magnitude fewer tokens than OLMo 2 1B's 4T-token budget, resulting in OPEN-1B trailing on downstream benchmarks." 400B tokens against 4T is exactly a 10x gap, and the paper reproduces OLMo 2 1B's own published MMLU number (26.9 MCF) exactly before making the comparison, rather than eyeballing it from the older paper's table. That's the right way to state a losing number. A 1.6B model on a tenth of the usual token budget is not a capability play, and the paper never claims it is -- which is worth saying plainly before the rest of this piece gets into the parts that are more interesting than "does it perform well."

The eval path is shipped rather than described, too, which is rarer than it should be. From open-transformers' README:

pretrain-eval-olmes \
    --config-name 1b_repop_v2 \
    --checkpoint  runs/<RUN_ID>/checkpoints/step_<N> \
    --tokenizer   data/tokenizer.json \
    --out-dir     runs/<RUN_ID>/evals/olmes

with the pins stated next to it -- "OLMES runs against a pinned ai2-olmes commit with lm-eval==0.4.3; the DCLM-CORE path wants 0.4.4." Those two versions disagreeing is exactly the kind of detail that silently moves a benchmark number by a point, and naming both is the difference between a reproducible eval and a quoted one. Note what this command does not need, though: no hash, no meta.json, no replay. The eval harness takes a checkpoint and scores it. Nothing in the evaluation path checks that the checkpoint it is scoring is the one the chain commits to -- that is a separate exercise, and it is the rest of this article.

Three rungs, and a fourth that isn't here

Gensyn's own ladder -- open-weight, open-recipe, auditable -- maps onto a slightly more precise distinction worth naming, because "auditable" is doing a lot of work and it matters exactly which of three things it means:

1. Reproducibility. Publish the data, code and checkpoints so anyone with equal compute could re-run the recipe and land near the same place. This is what "open source" already means for OLMo, Apertus, or Pythia -- and the tech report's own framing of the problem is that this tier is not enough, because floating-point addition isn't associative: two honest runs of the identical recipe on different hardware, or even the same hardware at a different parallelism, produce different bits. You cannot check a released checkpoint against a re-run, because there's nothing for it to match exactly.
2. A hash chain over the record. Publish a cryptographic digest for every step, computed at the time of training, so a tamper to the released data, code or weights after the fact is detectable -- without needing to re-derive anything, just compare hashes. This catches retroactive tampering with the record, not necessarily tampering with the run itself while it happened.
3. A succinct proof. A cryptographic argument whose checking cost is asymptotically smaller than the cost of the computation it certifies -- a SNARK, roughly, for gradient descent. This is the only one of the three where "verify" doesn't secretly mean "redo the work."

open-1b is rung two, executed unusually well, and explicitly not rung three. The tech report says so itself, naming the alternative it rejected: existing "proof-of-learning" schemes (Jia et al., 2021) accept a claimed training trajectory as valid if it lands close enough to a plausible one, and that tolerance is exactly what a published line of follow-up attacks has learned to search inside -- an adversary hunts for a trajectory that's cheaper than honest training but still lands within the acceptance radius. open-1b has no such tolerance to search. The target is, in the site's own words, "a bit-for-bit match across devices, not agreement within a tolerance." An honest replay either reproduces the exact hash or it doesn't, and there's no known way to produce a matching hash without doing the actual computation the hash commits to. That closes off proof-of-learning's specific failure mode. What it doesn't do is make checking cheap: verifying any one step still costs the real compute of that step, redone. That's the trade this design makes, and it's the right trade to have made explicit rather than hidden -- but it means "auditable" here is reproducibility with a commitment scheme bolted on, not a succinct proof, and the difference matters for exactly the question the announcement's headline invites: how much does checking cost, and who's actually done it?

The chain, link by link

Here's what that hash chain actually reaches, end to end, and where it stops -- built from the tech report, the audit harness's own docs, and the public GCS bucket listing rather than from the announcement's summary of itself.

The chain from a seed to a 400B-token base checkpoint is real and unusually well-engineered: RepOps fixes one reduction order, one FMA convention, one subnormal-flushing behavior, and a counter-based RNG across CPU, NVIDIA and Apple GPU backends, specifically so that a single consumer device can later replay, one virtual rank at a time, what 48 datacenter GPUs did together. The topologically-invariant data stream means the exact same windows get enumerated whether you trained on 48 GPUs or you're auditing on one laptop. That's the actual engineering contribution, and it's the part of "auditable training... isn't a property that can be bolted on afterward" that's true rather than just a slogan.

What the hash doesn't cover

The audit harness's own documentation is more careful than the announcement about the state hash's scope, and it's worth quoting because it's a direct, specific limit rather than a hedge:

"What a match proves. The hashed state -- weights, optimizer moments and param groups, the target step's gradients, and the running batch digest -- is bitwise the state the run committed to at that step. It says nothing about RNG, the data-stream cursor, spike state, or the descriptor keys in meta.json: none of those are in the v3 hash, and a continuation still trusts them."

Concretely: the reduction algorithm, the clip mode, and the run's other segment-scoped settings ride along in an unhashed metadata file next to the checkpoint. A continuation of the audit relay reads that file and trusts it, because the state hash has nothing to say about it. It is worth seeing what is actually in that file, because "descriptor" undersells it. This is gs://gensyn-open-1b/ckpt/step_000080957/meta.json, excerpted:

{
  "consumed_tokens": 400004481024,
  "step": 80957,
  "git_sha": "ad3276b4e5e1cd11fe29ee7880c758853cee13ce",
  "tokenizer_hash": "",
  "container_digest": "",
  "chained_hash": "b656715341005431b657042128671c23d3c2cf6c5503b91bb62134ca5c3b023d",
  "reduction_mode": "deterministic_allgather",
  "dp_world_size": 48,
  "dp_replicate": 6,
  "dp_shard": 8,
  "replicate_reduce_algo": "recursive_doubling",
  "grad_norm_algo": "deterministic_per_tensor_sos_v1",
  "clip_algo": "global",
  "seed": 42,
  "torch_version": "2.11.0a0+a6c236b9fd.nv26.03.46836102",
  "windows_emitted": 97657344
}

Four things fall out of that, and they are all checks anyone can repeat. First, the good news: windows_emitted is 97,657,344, and 400,004,481,024 tokens divided by a 4,096-token sequence is 97,657,344 exactly, so the stream accounting closes. Second, dp_world_size: 48 with dp_replicate: 6 and dp_shard: 8 is the 6-nodes-of-8 topology the report claims -- and the final checkpoint directory does hold rng.rank_0.pt through rng.rank_47.pt, 48 of them, so the shape is in the artifact, not just the prose. But the run-config group the repo actually ships, configs/run/multi_node_4xh100.yaml, declares nproc_per_node: 4, dp_shard_size: 4, dp_replicate_size: 8 -- a 32-rank world. The committed config does not describe the run; the launcher overrode it, and the only published record of what it overrode it to is this unhashed file.

Third, git_sha is ad3276b4e5e1cd11fe29ee7880c758853cee13ce -- which matches the ad3276b in the run id, and is not a commit in gensyn-ai/open-transformers. The public repository has exactly one commit, d7b7b67, "Initial commit: the OPEN-1B pretraining and audit-replay harness." So the checkpoint names the revision it was trained by, and that revision cannot be checked out. What you can check out is a squashed re-publication that is asserted to be the same code. Fourth, and most simply: tokenizer_hash and container_digest are both empty strings. The schema has slots to pin the tokenizer and the container image -- the two inputs that sit furthest upstream of anything the state hash covers -- and in the released artifact they are blank. The tokenizer is pinned, as it happens, but one layer down, in the shard manifests' tokenizer_hash field, which nothing in the checkpoint descriptor points at.

And the relay really is a relay: Gensyn published a checkpoint every 100 steps, 810 of them -- the other 99 steps inside each segment have no Gensyn-published checkpoint at all, so auditor A hands their intermediate checkpoint to auditor B, who continues from it, exactly as sequential as the original training was parallel. Two more wrinkles the site's own copy is upfront about:

• The last step of every segment is a special case. Its "result is a checkpoint Gensyn already published, and the uploaded file alone cannot prove the auditor computed it" -- there's no way to distinguish a genuine replay of the closing step from someone who just re-uploaded Gensyn's own published answer. The site marks these "recorded as corroboration," not proof.
• Loading someone else's checkpoint is not a safe operation. The repo's own usage docs put it bluntly: torch.distributed.checkpoint unpickles its metadata index with plain pickle.load before any of the audit's own code runs, so a hostile checkpoint directory can execute arbitrary code on the auditor's machine. The documented rule is "treat 'audit this checkpoint' like 'run this script'" and sandbox anything from outside your own trust boundary. The relay design's whole point is that you don't have to trust Gensyn -- and it works by asking you to trust whichever stranger handed you the last checkpoint instead.

There's also a specific, disclosed rough edge in the exact checkpoint this release ships. The audit docs flag the base run's own final checkpoint, step_000080957, by name: a since-fixed bug in the writer means its self-reported state_hash.txt "matches no log and no replay -- even when the replay is bit-perfect." The correct verification target is a different file, logs/state_hashes.jsonl, or the meta.json chained_hash field. The file a naive reader would reach for to check "did this actually train correctly" is documented, by the people who built the tool, as the wrong one to use.

That one is easy to confirm, so I did: ckpt/step_000080957/state_hash.txt is 65 bytes and reads 95367696285af628…, while line 80,958 of logs/state_hashes.jsonl and the chained_hash in the same directory's meta.json both read b656715341005431…. Two files in the same folder, disagreeing about the same step, with only the repo's documentation to tell you which one is the artifact and which one is the write-off. The chain itself is fine -- the init digest is the one place all three published sources agree, and ckpt/state_hash_init.txt, line 1 of the hash log, and the audit site's manifest.json initStateHash are all 16554a1119745f1b…, which is a genuinely reassuring thing to have checked.

Checking a step vs. training one

Before the cost, the shape. An audit here is not a metaphor for one; it is a handful of commands, and the first one is a checksum. The volunteer runbook (scripts/audit_volunteer/RUNBOOK.md) starts by pinning the tools themselves against a published manifest, before anything gets installed:

KIT=https://storage.googleapis.com/gensyn-audit-public/audit-kit/pt-f91110a0d0c8_rp-c9ca6e71e673
curl -fsSL -O "$KIT/kit.json"
python3 - "$KIT" <<'PY'
import hashlib, json, os, sys, urllib.request
 
base = sys.argv[1]
for entry in json.load(open("kit.json"))["files"]:
    # Download under a temporary name and adopt it only once the digest
    # matches. Rejected bytes must not become an installable wheel.
    part = entry["name"] + ".part"
    urllib.request.urlretrieve(f"{base}/{entry['name']}", part)
    digest = hashlib.sha256(open(part, "rb").read()).hexdigest()
    if digest != entry["sha256"]:
        os.remove(part)
        raise SystemExit(
            f"{entry['name']}: sha256 {digest} does not match the published "
            f"{entry['sha256']}"
        )
    os.replace(part, entry["name"])
    print(f"ok  {entry['name']}")
PY

That is verbatim from the runbook; the only thing I supplied is the kit id, which the audit site's manifest.json publishes as pt-f91110a0d0c8_rp-c9ca6e71e673. I ran it. All five files matched -- two pretrain wheels, two repop wheels and a trajectory.json, 15.5MB total, 1.6 seconds. No account, no gcloud, no credential, exactly as advertised. The runbook's comment about adopting the bytes only after the digest matches is a small thing that tells you the people who wrote it have thought about the failure mode where a rejected download is still sitting on disk named like a wheel.

Then the replay itself, from the README's own Verify a training step yourself section:

pretrain-audit-replay --from-init --until-step 0 \
    --config-name 1b_repop_v2 --device mps      # or cuda, or cpu
 
pretrain-audit-replay \
    --checkpoint  step_000050300 \
    --until-step  50400 \
    --gcs-root    gs://gensyn-open-1b/data/shards \
    --expect-hash <digest from the published hash log>

The first form regenerates the seeded initialization and compares it to a canonical digest; it needs no checkpoint and no data, and finishes in about 30 seconds on a laptop. The second replays a real interval and is the actual claim. docs/audit-replay-usage.md is blunt about the trap in it: "Auditing to an intermediate step needs --expect-hash. [...] Without it the audit runs but only prints the digest (no MATCH, exits 0)." An audit that forgets the flag exits successfully having verified nothing.

Here is the part I did not expect. trajectory.json -- the file inside the kit that lists what there is to verify -- is named "init-units-v1", and it contains three units, all of them "kind": "init". There is no step-interval unit in it, for open-1b or anything else; its own notes say "Step-interval units are added per run once its checkpoints and state_hash files are published," and those have been published since 11 September. So the one-command, install-two-wheels path that the README and the runbook present as the volunteer route can currently verify precisely one thing about open-1b: that step zero's random initialization reproduces. Its digest is 16554a1119745f1b…, which is the one I already matched against three other published files, so it does check out -- and it is also, by the trajectory's own description, the one unit that "never call[s] the forward/backward paths." To replay an actual training step you leave the kit path entirely and drive audit_replay.py from a source checkout with a checkpoint and an --expect-hash you assemble yourself.

The same file is candid about something I would have missed otherwise. The kit shipped for the 15 September launch re-pinned repop to a commit that, unlike the two repins before it, "does touch kernel arithmetic," and the notes say re-verifying the init units at that commit "is not itself evidence for the kernel-level BFR contract at this commit." That is the cross-hardware bit-exactness guarantee, and the kit that ships it has no published unit that exercises it. Writing that down in your own release artifact, where almost nobody will read it, is the behaviour of people doing this in good faith. It is still a gap.

The tech report is direct about the arithmetic that makes any of this hard: "since verification of the entire training run on commodity hardware is not feasible, we designed a collective verification system." I wanted a real number for "not feasible" rather than taking the sentence on faith, so I pulled the actual per-step replay times self-reported to the public ledger.

expand

Training itself, at 48 GPUs working in parallel, took a median of 28.0 seconds per step in the main phase and 47.1 in the late phase (Table 7) -- already running at only about 5% model-FLOPs utilization, 5.2-6.8x slower than an equivalent stock PyTorch bf16 baseline depending on cluster size (Table 10), because bitwise reproducibility and int8 QAT both cost real throughput before anyone audits anything. Replaying a single step alone, on one device, is a different order of magnitude again:

Those are real, self-reported submissions, not projections -- from Johnny's 25-minute H100 replay of step 0 to ben's 19-hour Apple M4 Pro replay of step 102, a roughly 47x spread across hardware alone, and roughly 2,500x away from the original 28-47 second step time at the far end of the chart. The reason isn't that the audit tool is inefficient; it's that one device is redoing, in sequence, what 48 devices did at once, on top of the same reproducibility tax the original run already paid. Even taking the single fastest H100 submission on the ledger and imagining it sustained across the entire 80,957-step run, the total lands at roughly the same order as the original run's full cluster-time -- which is the honest content of "not feasible on commodity hardware": full coverage doesn't cost less than training, it costs about the same, just relocated onto whoever volunteers to do it. Auditing one step is cheap. Auditing the run is not, and nothing about the design tries to hide that -- the whole reason it's built as a crowd relay rather than a single verifier is that nobody, including Gensyn, could do it alone.

Three days in

I queried the audit site's own API rather than reading its marketing copy. manifest.json, /v1/runs/open-1b/coverage, and /v1/ledger.jsonl are real, unauthenticated JSON endpoints, and as of 2026-09-18 -- three days after the 15 September announcement -- they say:

Those are the numbers at 10:30 UTC. At 05:15 the same morning the same endpoint said 25, so the rate at which this is actually being checked is roughly one step per five hours, against 80,931 remaining.

That provisional row is the one the announcement's framing glosses over. "Confirmed" is a real status on the site, defined precisely: a segment turns from provisional to confirmed only "when every step has an accepted match and the final hash matches the anchored checkpoint." Today, that has happened for exactly zero of the 810 segments in the run -- the 26 accepted step-replays are scattered across only 14 segments (two more have a claim but no accepted result yet), none of them complete. And "accepted" itself is a narrower claim than it sounds: the manifest describes the server-side check plainly --

"An accepted upload is checked two ways: the cross-entropy and z-loss the runner reported agree with values the cluster withheld, and its bytes match the digest the runner declared. [...] The receiving audit tool checks their file digest and reconstructs their training-state hash before replay. The server does not perform that reconstruction."

The bit-exact hash comparison -- the whole mechanism this article has been describing -- happens locally, on the volunteer's own machine, and is self-reported. What Gensyn's server actually checks today is a loss value it withheld plus a file-integrity digest: real evidence that a replay happened, not independent confirmation that the replay's hash is correct. A handful of named people -- Johnny, adam, oleg0s, ai_dgn, KarimFoda, Ivan_Bogatyy, and five others -- have done that self-reported check on 26 of 80,957 steps. Nobody, including Gensyn, has yet independently confirmed even one complete 100-step segment of this run. That is the precise, current, checkable answer to "what can an outsider actually verify today" -- not nothing, but a great deal less than "audited."

But "the server does not perform that reconstruction" is not the same as "nobody can." Each ledger row carries a committed_state_hash, and the run's full chain is that same public 10.6MB file. Those two things can be joined, and as far as I can tell nobody had, so:

curl -sO https://storage.googleapis.com/gensyn-open-1b/logs/state_hashes.jsonl
curl -s -o ledger.jsonl https://open1b.gensyn.ai/v1/ledger.jsonl
 
python3 - <<'PY'
import json
chain = {r["step"]: r["state_hash"] for r in map(json.loads, open("state_hashes.jsonl"))}
rows  = [json.loads(l) for l in open("ledger.jsonl")]
# a receipt's "step" is where the interval started; its digest is the next link
hits  = sum(chain.get(r["step"] + 1) == r["committed_state_hash"] for r in rows)
print(f"{hits} / {len(rows)} submissions land on the published chain")
PY

27 / 27 submissions land on the published chain. Every digest a volunteer has submitted appears in the run's own 80,958-link chain, exactly once, at exactly the step the submission claims. That is not the segment confirmation the design calls for -- it re-uses Gensyn's own hash log as the reference, so it cannot detect a chain that was forged wholesale -- but it does rule out the cheapest possible fraud, a volunteer who submits a plausible-looking digest for a step nobody will check, and it is a check the site itself does not run. It also took four seconds. The off-by-one in the middle is worth knowing about if you repeat this: a receipt's step field records where its interval started, while its digest belongs to the following step, which is what the artifact directory is named after (handoffs/step_000000101/ holds the receipt that says "step": 100).

The hand-off artifacts themselves are public too, at gs://gensyn-open-1b/open-1b/handoffs/, and each one's handoff.json is the closest thing this project has to a receipt: state_hash, expected_state_hash, match, the reported ce and z_loss, a bundle_digest, the device, and the exact repop build commit. Reading all 27 of them turns up the single best piece of evidence on the whole ledger, and the site does not draw attention to it. Exactly one step has been replayed twice -- once by cxfinlayson on an RTX 3090 in 0.93 hours, once by ai_dgn on an M4 Max in 5.50 hours, the second submission carrying a "corroborates" field pointing straight at the first artifact (a different use of the word than the segment-closing case above: here it means a second, independent replay of the same interval). Both report the same digest, 236b3689f4940ba0…, and that is the chain's link at the step they close. One step out of 80,957 has been independently replayed on two different vendors' silicon, and the bits agree. That is the actual claim this project exists to make, demonstrated exactly once so far -- and it is stronger evidence for bit-exact cross-hardware reproducibility than anything on the audit site's front page, buried in a JSON file the site never links.

The receipts also show the pin drifting. Nine of the 27 were produced with repop at eab4e11d2c7f, an older build than the c9ca6e71e673 today's kit installs -- and the runbook's own rule is that "a result whose repop.commit differs from the kit's repop_commit verified a different kernel build and proves nothing about the published trajectory." Read strictly, a third of the accepted ledger is evidence about a kernel build the current kit no longer ships.

To its credit, the site is not shy about what an accepted audit doesn't show, in its own words: "Audits do not establish model accuracy, truthfulness, safety, lack of bias or data-licence compliance. They check the recorded computation, not the quality or suitability of the model, data or code." That's a more careful sentence than "the first model you don't have to trust," and it's sitting right there on the page whose headline makes the bigger claim.

The half of the release the chain never reaches

The announcement bundles "open-1b base and instruction-tuned checkpoints" under one release, and the Hugging Face collection has three repos: open-1b-base, open-1b-midtrained-93B, and open-1b-sft -- a pipeline the tech report never mentions. Reading open-transformers' own docs fills in the gap: a midtraining stage anneals 93B tokens from AI2's dolma3_dolmino_mix mixture over the base checkpoint, following OLMo 2's recipe, and then SFT tunes on allenai/tulu-3-sft-olmo-2-mixture-0225 to produce the chat model most people will actually run.

Neither of those two stages is on the audit site. The midtraining docs say so directly: "swapping the data mixture at resume rebuilds the stream with new source names; state_hash/windows_emitted cross-checks against the pretrain stream no longer apply from the branch point on. The midtrain run starts its own chain" -- a new hash sequence exists somewhere in the training code, in principle. But open1b.gensyn.ai's manifest, coverage and ledger endpoints describe exactly one run: 20260722-213626-ad3276b, 80,957 steps, the base pretraining. I listed the public GCS bucket (gs://gensyn-open-1b) directly rather than take that on faith: its logs/ prefix contains exactly one file, state_hashes.jsonl, 10.6MB -- the base run's chain and nothing else. No midtrain_state_hashes.jsonl, no SFT equivalent, no segments, no ledger entries, no way for an outsider to replay-check either stage. For the model most people will actually download and talk to, getting there from the audited open-1b-base costs two more training runs that are released the way an ordinary open-recipe model is released: code and data are named, and you're back to trusting that the recipe was actually followed.

So, do you have to trust it?

Less than before, for a specific and now-checkable slice of one release. That's a real result, not a small one, and it deserves to be read as an honest first step rather than measured only against its own headline. Bit-exact, cross-hardware reproducibility of a real 400B-token training run, with a chained per-step commitment that a stranger can independently redo on a laptop and get the exact same bits -- nobody had shipped that before open-1b, and the specific failure mode it closes off, proof-of-learning's exploitable tolerance, is a real one that the paper is right to name and avoid.

But trust doesn't disappear; it relocates, and precision about where it lands is the whole point of a claim this specific. Inside the audited pretraining run, you're still trusting that open-transformers is really the code that ran -- and that one is now concrete rather than rhetorical, because the checkpoint records git_sha: ad3276b4e5e1… and the published repository is a single squashed commit that does not contain it. You're trusting that RepOps's cross-hardware equality holds on driver and library versions nobody has tested yet, which the launch kit's own trajectory.json all but says outright by shipping zero units that exercise the changed kernels. You're trusting that the run's unhashed RNG position, empty tokenizer_hash, empty container_digest and overridden topology weren't the thing that got tampered with. And -- today -- that a self-reported loss-and-digest check on GitHub-style volunteer handles is a reasonable stand-in for the independent hash recomputation the design actually calls for, because that recomputation hasn't happened for a single complete segment yet. (The one piece of that I could take off the trust list, I did: every submitted digest really is in the published chain. That check took four seconds and the site does not run it.) Outside the pretraining run, for the model people will actually run, you're trusting the recipe the ordinary way, because midtraining and SFT never entered the chain at all. And beneath all of it, same as any model trained on DCLM, FineWeb, Stack v2 or Proof-Pile-2, you're trusting that those four upstream pipelines curated their share of 450 billion tokens the way they say they did -- an audit that proves you got exactly the declared bytes says nothing about whether those bytes were the right ones to train on.

"The first model you don't have to trust" would be a better claim as "the first model where not trusting it is a specific, byte-level, actually-startable exercise, for one part of the release, that three days in almost nobody has finished." That's a less quotable sentence. It's also, on the evidence I could actually pull from the tool Gensyn shipped, the accurate one -- and a genuinely useful floor to have built, which is exactly how the announcement's own closing line frames it: "a first step and a floor." The gap between that and "you don't have to trust it" is worth keeping in view precisely because the underlying problem -- verifiable training -- is real, and worth doing carefully rather than declaring solved a few days after launch.