Knock-in Quantification from Sanger — HDR and Prime-Edit Rate
Put the intended allele itself in the basis: measure what fraction of the pool carries your knock-in, what fraction is still wild type, and what fraction is NHEJ byproduct — from one control trace and one edited trace.
🔒 Nothing you paste is logged or stored
Predicted, not measured
- How good is it?
- Every run reports its own R²: how much of the observed window the basis actually explains, measured on YOUR traces, where a low value means the model is wrong here rather than that the edit is weak. On agreement with a reference method for real samples — amplicon sequencing or clonal genotyping — none is published for this implementation. The underlying decomposition is TIDE/TIDER's, whose authors report their own concordance, and that number does not transfer to this code so it is not quoted. This implementation's near-exact recovery of synthetic mixtures is deliberately not offered as validation: a synthetic mixture is built from the same idealised one-hot peaks the basis assumes, so recovering it tests the arithmetic and cannot test the assumption.
- Only valid for:
- A pool whose intended edit is known EXACTLY, read against a control amplicon of the same locus and chemistry, with both reads extending well past the edit. The novel inserted bases of a knock-in carry an assumed peak shape rather than a measured one (returned as constructedPositions) — the more of the window they occupy, the more of the fit is testing that assumption. NOT valid when the reported R² is low; nor for separating an intended pure DELETION from an unintended indel of the same net length ANYWHERE in the window, not only one at the same site (the tool reports which case it is in `sameShiftByproduct`: when that column is not fitted, knockinPercent is the sum of the two); nor for telling an on-target knock-in from a random integration of the same donor; nor for resolving haplotypes, since a Sanger trace of a pool has no phase information.
- Fitted on:
- Nothing fitted. There are no coefficients anywhere in this tool: the basis is the caller's own control trace, re-registered into the intended edited allele and into every unintended indel shift, and the only free parameters are the mixing proportions themselves, solved per run under non-negativity. The decomposition is the one TIDE introduced for indels (Brinkman et al., Nucleic Acids Research 2014) with the intended allele added as its own column, which is what TIDER does for a knock-in. The one thing not taken from the data is the expected peak shape of the novel inserted bases, which the control cannot supply.
An indel-spectrum readout answers "how much editing", which is not the question a knock-in experiment asks. This tool names the intended allele — the donor's insertion, the pegRNA's substitution, replacement or deletion — and builds a column for it, so the decomposition of the edited trace has three kinds of thing in it at once: the wild-type allele, the intended edited allele, and one column per unintended indel shift around the cut or nick. The mixing proportions are solved under non-negativity, which matters because an unconstrained fit will happily report that minus fourteen per cent of a pool carried the knock-in, and every run reports its own R² so you can see whether that basis explains your traces at all before you read the percentages. That is the concrete difference from the CRISPR Editing Efficiency tool: its basis is indexed by net shift alone, so an intended edit and an unintended indel of the same net length are one column there and a substitution knock-in is invisible entirely; here the intended allele's actual bases are in the basis, and where the two columns really are identical the result says so rather than guessing.
How to use the Knock-in Quantification tool
- 1Load the unedited control trace and the edited pool's trace, both .ab1 — or click Load example to see the decomposition on a synthetic mixture of wild type, a 6 bp insertion knock-in and an unintended 4 bp deletion.
- 2Pick the shape of the intended edit — substitution, insertion, deletion or replacement — and give the allele it installs: the inserted sequence, the reference and edited bases, or the deleted length.
- 3Give the edit position, 1-based in control read coordinates: the first base the edit replaces, or, for an insertion, the base the insert lands immediately before. Set the cut or nick position separately if unintended indels start somewhere other than the edit.
- 4Optionally widen the largest unintended indel fitted (1-20 bp, 10 by default) or the decomposition window (20-300 bases, 70 by default).
- 5Read the three-way split — intended edit, wild type, unintended indels — with the byproduct spectrum inside the last one.
- 6Check the gate and the warnings before believing any of it: the R², the upstream identity that says these are the same amplicon, the reference-allele check, and whether the intended-edit column was distinguishable from a byproduct column at all.
Frequently asked questions
How is this different from the CRISPR Editing Efficiency tool?
That tool's basis is indexed by net shift only: every allele that moves the downstream trace by the same number of bases is one column. So it cannot tell an intended 6 bp edit from an accidental 6 bp NHEJ indel of the same net shift, and a substitution knock-in — a point mutation, a prime edit that swaps bases one for one — shifts nothing at all and reads there as unedited with a confident fit. This tool puts the intended allele's actual BASES in the basis as their own column, which is what makes the split possible: the edited positions themselves are the signal. Use the other tool when the question is total knockout efficiency; use this one when you have a specific intended allele and want its share.
How does it separate the knock-in from NHEJ byproducts?
By fitting all three at once. The expected trace for the intended allele is built from your control read, re-registered around the edit, with the novel inserted bases supplied as idealised peaks; the byproducts are the same control read shifted by every insertion and deletion size from 1 up to the maximum you set, starting at the cut or nick; wild type is the control unshifted. The observed edited trace is decomposed onto that basis by non-negative least squares, so no allele is ever assigned a negative share, and the proportions are the answer. This is the decomposition TIDE introduced for indels (Brinkman et al., Nucleic Acids Research 2014) with the intended allele added as its own column, which is what TIDER does for a knock-in.
What does the R² mean, and why is it shown next to the percentages?
It is how much of the observed window the basis actually explains, measured on your own two traces. It is the honest confidence figure here because it is a measurement rather than a claim, and it is the one number in the result that is about the model rather than about your sample: below 0.7 the tool fails its own gate and you should read the result as "these traces do not fit this model" rather than as a weak edit. A wrong edit spec, a wrong cut position, a failed trace and a donor that integrated somewhere else all land there.
How accurate is the knock-in percentage?
There is no published agreement figure for this implementation against a reference method — amplicon sequencing or clonal genotyping — and none is quoted here. The underlying decomposition is TIDE/TIDER's, whose authors report their own concordance, and that number does not transfer to this code. What you get instead is the per-run R² above, which is a measured property of your traces rather than a borrowed statistic. This implementation does recover known synthetic mixtures almost exactly, and that is deliberately NOT offered as validation: a synthetic mixture is built out of the same idealised peaks the basis assumes, so recovering one tests the arithmetic and cannot test the assumption. Treat the number as a quantitative estimate that would have to be checked in the lab, which is why the tool is marked predictive.
When does the intended edit become impossible to distinguish?
When its column is the same vector as a byproduct column. The clearest case is a pure deletion whose cut is at the edit: an intended 6 bp deletion and an unintended 6 bp deletion produce exactly the same expected trace, so that byproduct column is dropped and the reported figure is the SUM of the two — including an unintended indel of the same net length that arose anywhere in the window, not just at the edit. The result says which case you are in rather than hiding it, and the gate fails outright when the nearest column is within 0.0005 cosine of the intended one. A related bias is milder but real: an unintended INSERTION is modelled by its shift plus a "something is here, unknown what" row, so when insertion byproducts are large the intended share reads low. Separating any of these needs amplicon sequencing.
Does a knock-in percentage tell me the cells are correctly edited?
No, and three specific things are outside what a Sanger trace of a pool can support. It cannot tell an on-target knock-in from a random integration of the same donor elsewhere in the genome, because that copy contributes nothing to this amplicon — a junction PCR or long-read check is what distinguishes them. It carries no phase information, so 50% is equally consistent with every cell heterozygous and with half the cells homozygous. And an imperfect HDR event — a donor that copied part of its payload, or brought a nearby scar in with it — is simply a different allele from the one in the basis: it lowers the R² or spills into the byproduct columns rather than being reported as what it is.
Which position do I enter, and does it match VCF or HGVS?
One rule for all four edit kinds: the 1-based control-read position of the first base the edit replaces. An insertion replaces nothing, so there it is the base the insert lands immediately BEFORE — which is deliberately one MORE than the VCF/HGVS anchor, since that notation names the base before an insertion. A spec transcribed from VCF needs +1 on an insertion. For a substitution or a replacement the reference bases you name are checked against the control read and a mismatch is rejected before anything is fitted; an insertion and a deletion name no reference bases, so there only the position can be range-checked and an edit anchored one base out will not be caught.
Does it work for prime editing, and are there size limits?
Yes — a pegRNA's intended edit is described with the same four shapes (substitution, insertion, deletion, replacement) and becomes the intended column, while the indel byproducts at the nick become the shift columns; set the nick as the cut position. The limits are: unintended indels from 1 to 20 bp (10 by default), a decomposition window of 20 to 300 bases (70 by default), an alignment offset override within ±40, and a named reference or edited allele of at most 200 bases, since a longer knock-in cannot be resolved inside one Sanger window anyway. Out-of-range values are rejected rather than quietly clamped, and the allele has to be spelled in A, C, G and T — an ambiguity code has no single expected channel, so there is no trace to build for it.