Erbgut

Measure the rule. Keep what pays.

In one picture

Any file becomes DNA

0 1 0 0 1 0 0 0 0 1 1 0 1 0 0 1 0 0 1 0 0 0 0 1

GC

TA

AG

CT

GA

0 1 0 0 1 0 0 0 0 1 1 0 1 0 0 1 0 0 1 0 0 0 0 1

Why DNA

DNA is dense and durable

~215PB per gram

1 gram of DNA

≈

~10,000 20 TB hard drives

500+years

SSD

~5 yr

HDD

~8 yr

Tape

~20 yr

DNA

500+ yr

Where that matters

Cold archives

Scientific & genomic records

Compliance records

Disaster-resilient backups

The problem, today

One bad strand is enough

The problem

Rules chosen once, applied to every channel

The rulebook every pipeline copies

×No run of more than 3 identical letters

GCGC content between 40 and 60%

+30%Extra strands, on every channel, just in case

Nanopore

Many insertions and deletions, especially in runs of the same letter

Same rulebookrun 3, GC 40 to 60%, +30%

Illumina

Few errors, mostly single wrong letters

Same rulebookrun 3, GC 40 to 60%, +30%

Real blind spots

Nanopore is error-prone.

substitutions

deletions

insertions

Where the rules come in

The rules give a verdict. The model gives a number.

So where do the rules come in? The encoder does not write one strand per slot. It builds several candidates for the same data and keeps one. This is a real slot from the real encoder.

Six candidates. Same data, different seeds, so the letters are different every time.

The hand rules are a yes or no. Four of these are crossed out for a run of four or five identical letters, and the encoder takes the first survivor. That is the whole decision. A rule cannot tell you that one survivor is more dangerous than another, because it does not have a number.

Our model gives every candidate a number: its predicted chance of failing on this channel, learned from where the decoder actually fails. Now look at the same six. The strand the rules handed over scores 0.62, well above the average candidate at 0.51. The one we keep scores 0.52.

And the sharpest part is the one the rules threw away: 0.45, the safest strand in the slot, rejected for a run of four. The hard rule still vetoes it, and whether that veto is worth its price is exactly what the audit measures per channel rather than assumes. Our own rerun says the run rule earns its place on Nanopore, so it stays.

Provenance, if asked: the candidates come from the encoder's own seed schedule on the real test file with the run settings, and the scores are the trained Nanopore risk model's. The search that found this slot is committed as scripts/rule_vs_model_case.py, and its output is in results/rule_vs_model_case.json. Nothing on this slide is hand-written. The letters shown are bases 17 to 56 of a 110 base strand, the first 40 after the seed; each score is the model's score for the whole strand.

One diagram

What we actually built

The whole system on one screen. Five boxes, and the arrows are the part worth watching.

The storage path, left to right. The encoder is a Fountain code: for every slot it builds 8 to 32 candidate strands, puts a checksum in each, and keeps one. Simulator A plays the lab, and it is fit on real published reads: dropouts, uneven coverage, per-read quality, errors every read shares, context effects. The decoder gets the noisy clusters back. Then a failed checksum turns a wrong strand into a missing one, and the Fountain code rebuilds the file. Every number in this deck is 300 held-out trials of that path.

One learned part in the path itself. The classic step aligns the reads and votes a draft, letter by letter. On top of it sits a dilated convolutional network of about 0.8 million parameters that reads 17 vote features per position and says keep, substitute, delete or insert.

Now the arrow that makes this a loop rather than a pipeline. We freeze the decoder, simulate each strand 32 times to see where that decoder actually fails, and train a 63 thousand parameter risk model on those failures. That model goes back into the encoder and ranks the candidates before anything is written. The codec is shaped by the decoder it will be read with, and that loop runs at most three rounds.

And the dashed lane is the firewall. Simulator B is a second channel built from different mechanisms, with its context table from a different dataset. Nothing is ever tuned on it. It only ever checks a result, which is why a gain that survives it is worth quoting.

Cyan is learned, grey is classic code. Two learned models in the whole system, 0.8 million and 63 thousand parameters. If asked about the channel profile: it is a JSON file per situation, error rates, the 5-letter context table, dropout, coverage and the read budget, fit on real reads.

Head to head their model, our clusters, our protocol

Two points off the state of the art

Two points off the state of the art, at a 48th of the size: 88.4 against 90.4 at six reads, 0.8M parameters against 38.5M

This is not two papers agreeing about how to measure. We ran their released fine-tuned checkpoint on our own held-out clusters, under our protocol.

And the first thing we found invalidates the naive version of the test: four fifths of our held-out clusters, 1,585 of 2,000, are inside their own fine-tuning split. So we score only the 415 clusters outside it. Anyone benchmarking against that checkpoint has to check the overlap first.

On that fair subset they are ahead, and we say so: 90.4 against our 88.4 at six reads, two points. At two and four reads the gap is larger, six to nine points, and that is where their scale genuinely tells.

We are ahead of their pretrained model at every coverage, by three to nine points.

And what that costs them: 38.5 million parameters against our 0.8 million, 48 times, and 463 seconds against 4.6 to decode two thousand clusters on the same GPU, about a hundred times. Two points, for a model you could not run anywhere but a GPU.

The 100M model in the earlier framing is DNAformer, not TReconLM. Their checkpoint is 38.5M, measured. If asked about the cross-paper table: it gave 91.2 against 88.8, and this measurement supersedes it because it removes the protocol differences.

Our actual claim

The question nobody else answers

TReconLM, DNAformer, BBS, Trellis BMA, ITR

Given noisy reads, recover the strand

Erbgut, per channel, at a fixed recovery target

Given a channel, does this rule pay for what it costs?

Each standard rule earns its place on exactly one of our two channels

The firewall

Every number is checked on a channel we never tune on

We have no wet lab. So the thing that keeps us honest is a second simulator, and this slide is only about that.

Simulator A is the one we tune on. It is fit on real published Nanopore reads: rates, a 5 letter context table, dropout, coverage.

Simulator B is built from different mechanisms, top to bottom. Errors inside a read are bursty instead of independent, homopolymers shorten by a run level event instead of a per base multiplier, shared errors come in damaged segments, substitutions favour transitions, and the context table is fit on a different dataset, DNAformer's reads instead of Microsoft's. Nothing is ever tuned, trained or chosen against it. It only ever evaluates.

So here is the tier 2 change measured on both. Same codec, same redundancy, same decoder, same seeds, and the only thing that changes is which model ranks the candidates. On Simulator A strand failures go from 51.96 to 48.01 percent, 3.95 points. On the simulator we never touched, 50.92 to 46.76, 4.16 points. The gain is not an artefact of the channel we fit.

And run 6 repeats the whole thing with the learned decoder in place, which is the harder test, because a better decoder repairs some of what the risk model steers around. Smaller, as you would expect, 2.76 points on A and 2.85 on B, and still clearly separated from zero on both.

The limit, out loud, and it must not be softened: we have shown the risk model's ranking transfers to real reads. We have not shown that selecting candidates by it lowers failures on real DNA. That needs strands synthesized and sequenced, and we have not done that.

If asked about the simulator against reality: Simulator A is compared with real held-out reads at every read count and sits within about three points everywhere, and where it is off it is slightly harder than reality, which is the safe direction.

If asked what we retracted: "Both hand rules are harmful on Nanopore" was our own early claim, and our own rerun disproved it, the standard limit of 3 wins. "6 reads against 8" was winner's curse in an early run; we quote the one with a margin check. Both corrections are written up with the wrong version kept visible.

If asked where it runs: both models fit on the microcontroller on the table. The 0.8M polisher runs there quantized to int8, the 63k risk model in float32, and on 300 real clusters the on-device polisher gets 229 strands exactly right against 230 for the same model in float and 211 for the classic majority vote. No laptop, no network.

Results

What the audit measured

Measure the rule. Keep what pays.

Each standard rule earns its place on exactly one of our two channels. Now it is measured, not assumed.

HackMIT 2026 github.com/timarnoldev/hackmit2026

Appendix A0

The channel simulator, step by step

What happens to each strand

1

Survives at all? Dropout, higher for unbalanced GC and long storage.

2

How many reads? Negative binomial around the read budget, so some strands get very few.

3

Shared errors Drawn once per strand and position, the same for every read. More reads can't average them away.

4

Each read A read quality factor, optional malformed reads, then each base is deleted, preceded by an insertion, substituted, or copied.

About 250,000 reads per second on a laptop. The same seed always gives the same reads.

p(error at i) = base rate × run multiplier deletions grow with run length × position ramp worse toward the end × context factor 5 letters centered on i × shared factor per strand and position × read quality per read

Fit on real train reads

nanopore_budget, fit on Microsoft train reads: substitutions 1.52%, insertions 1.89%, deletions 2.20% per base, end of strand 1.2 times the start.

illumina_standard, fit on DNAformer Illumina train reads. Errors there are about 100 times rarer and show no context effect worth a table.

Simulator B builds the same channel from different mechanisms (bursty errors, damaged segments, a context table fit on DNAformer) and is never used for optimization.

Appendix A1

Exactly two learned models

Learned polisher

Question: Which letters of the baseline's draft are still wrong?
Input: The draft and its vote columns, 17 features per position
Output: Per position: keep, substitute, or delete, plus insert a letter in the gap in front

Dilated 1D CNN, 8 residual blocks, about 0.8M parameters. The classic baseline aligns the reads and votes the draft; the polisher corrects it, like a Nanopore assembly polisher. It keeps as many insertions as deletions, so the strand length always comes out right.

Reads	Baseline	Polished
4	41.0%	56.8%
6	67.0%	82.5%
16	90.0%	95.1%

Exact strands on real held-out Nanopore clusters. 4.7% of strands stay unrecoverable even with all 27 reads.

Risk model

Question: How likely is this strand to be decoded wrongly on this channel?
Input: Candidate strands
Output: One number in [0, 1] per strand: the predicted failure rate

1D CNN over the letters. Labels: each training strand is simulated 32 times at the channel's read budget and decoded by the frozen decoder chain. Label = the fraction decoded wrongly.

Specific to one channel, one read budget and one decoder. Ranking on real held-out reads:

Appendix A2

Everything heavy runs on one ASUS Ascent GX10

The machine

NVIDIA GB10, ARM64
128 GB unified memory
20 CPU cores

One script runs the loops, then the experiments and the decoder benchmark, one after the other.

The code: about 11,000 lines of Python, about 2,500 of them tests.

What it runs

Polisher training. Vote features from simulated and real train clusters, weighted toward low coverage, adapted per channel.
Risk labels. Every training strand simulated 32 times at the read budget and decoded.
Recovery trials. 300 held-out trials of the 20 KB file per final codec, spread across the 20 cores.
The loop and the evidence. Rule audit, ablation ladder, crossover matrix, firewall.

Appendix A3

Questions we expect

You have no wet lab. How do you know it's real?

We don't synthesize or sequence anything. The simulator matches real held-out reads within about 3 points at every read count. Every gain must survive Simulator B, and the risk model's ranking is checked on real reads:

Isn't this just DNA Fountain?

The encoder is DNA Fountain style on purpose. We change how it's configured: which rules, how much redundancy, which candidate to keep, per channel. We don't claim a better encoder.

What if the hand rules are already optimal?

Then the tool says so, with measurements, and that's useful. The audit is a measurement, not a bet against the rules.

Isn't the improvement just your learned decoder?

No. The default, system B, already uses the same decoder chain. B to C isolates the rule audit, C to D learned selection. A to B is the polisher, and we report that separately. Both tiers also work with plain majority vote.

Appendix A4

Questions we expect

Couldn't you buy accuracy with more redundancy?

That's what we rule out. Codecs are judged on the Pareto front of bits per base against reads per strand, at a fixed recovery target.

How is this different from DNAformer or adaptive constrained coding?

Those optimize the decoder, the constraints or the redundancy on their own. We close the loop: the decoder's failures on a channel decide what the encoder avoids, measured against a fixed target.

Why not learn the encoder end to end?

Insertions and deletions are hard to differentiate through, and storage needs every bit back. The Fountain code guarantees exact recovery; learning only picks which candidates to use.

What has the risk model actually learned?

The first version rediscovered the run-length rule, and its real-read ranking was weak. So we measured real context errors and put them into the simulator.

Appendix A5

Questions we expect

The Microsoft dataset has known issues. Does that matter?

Yes, and we handle it. Its references aren't uniformly random, so we use it for calibration and benchmarks, never to learn risky motifs. Simulator B uses a context table fit on DNAformer.

Does the polisher beat the baseline?

On real held-out clusters, exact strands go from 41.0% to 56.8% at 4 reads, 67.0% to 82.5% at 6 reads and 90.0% to 95.1% at 16 reads. The room is at low coverage, where reading is cheap. Both claim tiers compare codecs with the same decoder, so they hold either way.

What would a real user do with this?

Describe their channel as a profile, calibrate it on a sample of their own reads, and let the tool say which rules and how much redundancy to use. Cost figures use placeholder prices.

What did the GX10 do?

Decoder training, risk labels (each strand simulated 32 times and decoded), and 300 held-out recovery trials per final codec, spread across its 20 cores. See A3.

Appendix A6

What the model learned, and we did not teach it

We never taught the risk model a rule. It only ever saw which strands our decoder got wrong. Afterwards we asked it what it thinks is dangerous.

It found the homopolymer rule by itself. Risk is flat up to a run of 4, then it climbs. The standard rule in the field forbids runs longer than 3, so the model would draw the line one or two letters looser.

We tested that, and the model is wrong about where to draw it. Moving the limit from 3 to 4 drops file recovery from 81 percent to 33 percent at 12 reads. The model answers a per-strand question and the difference there really is small; a file is 1239 strands and needs all of them, so small per-strand differences compound. It is a good guide to what is dangerous and a bad guide to where the line goes, which is exactly why we measure in reads per strand instead of trusting a score.

On GC it is flat, 3.6 points across the whole range. It calls the GC rule pointless, and our rule audit reached the same verdict from a completely different measurement.

The patterns it names are all runs, as expected. The interesting part is the order: G and C runs rank above A and T runs. No hand rule makes that distinction, it just counts identical letters.

And the cross-check. Our channel table, fitted on real reads, says the worst deletion contexts are GAAAG and AAAAG. The model never saw that table and rates them 0.93 and 0.97. The worst substitution context it shrugs at, 0.44, because voting across reads repairs a substitution while a deletion shifts everything after it. It did not learn where errors happen. It learned where errors are fatal. On Illumina every pattern comes back at zero, correctly, because there the decoder does not fail on sequence grounds at all.

About 35 seconds. Source: docs/LEARNED_RULES.md, probed from the trained model of the final run.

Appendix A7

The two models

Two learned models in the whole system, and they sit at opposite ends of it.

The polisher is the decoder's second half. It never sees raw letters: it gets the classic decoder's draft and its vote columns, 17 numbers per position, votes for each letter, for a deletion, for an inserted letter and which one, coverage, the draft base, agreement and where we are in the strand, all as fractions. A dilated 1D CNN, stem of kernel 5 and eight residual blocks with dilations one, two, four, eight, twice over, 128 channels, about 0.8 million parameters and a receptive field of about 65 positions. Two heads: per position keep, substitute or delete, per gap insert or nothing. We apply the edits so deletions and insertions balance, which keeps the strand length exact. It trained in 13 minutes.

The risk model is the opposite. It sees one candidate strand as one-hot letters, nothing else, and returns one number between 0 and 1: the predicted fraction of decoding attempts that fail for that strand. The labels come from simulating each training strand 32 times and decoding it, so the target is a failure rate, not a yes or no. It plugs into the encoder as the scorer that picks among the 8 to 32 candidates for every slot.

And this is the arrow that closes the loop: the decoder's failures become the risk model's labels, so what the decoder gets wrong decides what the encoder writes next time.

About 35 seconds. Details in docs/MODELS.md.