Ask a room of ChromBPNet users where their worst bugs came from and a pattern emerges fast: the inputs. The framework takes three inputs for training, and each one has a specific job, a specific format expectation, and a specific way of silently ruining your run when it disagrees with the other two. This article explains each input in turn: the peak regions, the reference genome, and the accessibility signal, plus the matched negative regions the pipeline builds during preparation. Understand what each input contributes and you will understand most of what the model can and cannot learn from your data.
Input 1: Peak regions, the lessons themselves
Peaks are the accessible regions called from your ATAC-seq or DNase-seq experiment. Computationally, they are genomic intervals: the stretches where the measured signal piled up enough to be called open. For ChromBPNet they are the heart of the training data, because they define the regions the model will study. Each peak supplies a training example, a place where accessibility truly happens in your cell type, with a real signal profile to learn from.
Two consequences follow. First, peak quality is model quality. A peak set called too loosely floods training with weak or noisy regions, and the model’s loss struggles to improve because the lessons contradict each other. A peak set called sensibly from a good experiment gives the network consistent examples of what open chromatin looks like. Second, peaks are cell type specific by construction. They come from your experiment in your cells, which is why a trained model speaks for that cell type and not for the genome in general.
Input 2: The reference genome, the text being read
A sequence model needs sequence. The reference genome is the source of the actual DNA letters for every training region: the pipeline looks up each peak’s coordinates in the reference and extracts the underlying sequence, and that sequence is what the network receives as input. Without it there is nothing to learn patterns from, since the entire premise of ChromBPNet is that accessibility can be predicted from the letters themselves.
The reference genome carries one strict requirement: the build must match the coordinates of your peaks and your signal. Genomic coordinates are only meaningful relative to a specific genome build, and builds differ in exactly the kind of positions a base-resolution model cares about. Peaks called against one build, interpreted against another, land in the wrong places. The symptoms are shifted or empty signal in your training regions, and they are among the most common input problems in practice, as the troubleshooting guide describes.
Input 3: The accessibility signal, the answers being learned
If peaks say where to look and the genome says what the letters are, the signal says what actually happened. The accessibility signal comes from your experiment’s read data, the fragment or alignment files the assay produced. For each peak, the reads overlapping that region form the measured profile, the base-by-base shape of openness, and its total depth. That measured profile and total are the targets the network trains against: it learns to output, from sequence alone, the profile shape and total count that the experiment recorded.
This is why signal files must come from the same experiment and cell type as the peaks. Peaks from one cell type paired with signal from another teaches the model a chimera that matches neither, and the usual symptom surfaces later as flat, confused predictions. It is also why the signal’s provenance matters: the same reads that produced your peak calls should be the reads you train against, so the regions and their answers describe one coherent measurement.
The fourth, quiet input: matched non-peak regions
Training data also includes regions that are not peaks. During data preparation, the pipeline selects negative regions, stretches without real accessibility signal, matched to the peaks. Matched is the operative word: the negatives are chosen to resemble the peaks in the background properties that could otherwise give the game away, so the model cannot cheat by learning superficial differences between the two sets.
These non-peaks do two jobs. They show the model what the absence of accessibility looks like in sequence terms, which sharpens the contrast it learns. And they provide the raw material for the bias model: regions with no real signal are exactly where enzyme bias can be learned in isolation, because nothing biological is there to confuse it with. Good negatives are invisible when they work, and their absence shows up downstream as motifs you cannot quite trust.
How the three inputs become a training example
Put the pieces together and each training example is a small bundle:
- A genomic region, from the peak set or the matched non-peaks.
- The DNA sequence of that region, read from the reference genome.
- The measured accessibility signal over that region, from the assay’s read data, expressed as a profile and a total count.
The network sees the sequence and tries to reproduce the profile and the count. Across thousands of such bundles, the only way to succeed is to learn which sequence patterns produce accessibility in this cell type. Every input problem you will ever debug is a corruption of one line of that bundle: wrong regions, wrong sequence, or wrong answers.
A pre-flight check for your inputs
Before a training run, five minutes of checking beats a day of debugging:
- Confirm the genome build named in your peak file, your reference genome, and your signal data is the same build everywhere.
- Confirm the peaks and the signal come from the same experiment and the same cell type.
- Spot-check a few strong peaks: their measured signal should sit inside the peak intervals, not offset beside them.
- Confirm the peak set is a reasonable size for learning; a tiny or extremely noisy set predicts a loss curve that never improves.
- Keep the exact input files, or a record of them, with the trained model, so its provenance is never a guessing game.
How input choices echo through the whole project
It is worth seeing the inputs as decisions rather than files. The peak set you choose defines the model’s curriculum, and two peak sets called differently from the same experiment will produce noticeably different models. The cell type your inputs come from becomes the model’s identity, stamped on every prediction, motif, and variant score it ever produces. Even the genome build casts a long shadow: models trained today will be compared against annotations and variant catalogs for years, and all of those comparisons run on coordinates.
This is why experienced groups treat input preparation as part of the experimental record. The peak file, the reference build, and the signal provenance are written into the methods, versioned with the project, and archived with the trained model. When a collaborator asks, two years later, exactly what a model was trained on, the answer should be a file path rather than a shrug. In a framework where the inputs are the lessons, the sequence, and the answers, respecting them is most of the craft.
Conclusion
ChromBPNet inputs are a division of labor. Peaks choose the regions worth learning, the reference genome supplies the sequence those regions are made of, and the accessibility signal provides the measured profiles and counts the model must learn to predict. Matched non-peak regions complete the set, grounding the negatives and feeding the bias model. When the three main inputs agree on build, experiment, and cell type, training has a fair chance to teach the network real biology. When they disagree, no architecture can rescue the run, which is why experienced users check their inputs first and their hyperparameters second.
Read next:
