Understanding Your Summary
What the numbers in your summary email actually mean. Not a walkthrough. A reference: jump to whichever section matches what you're looking at.
The summary we send by email is intentionally short. Full detail lives in the report files (see Data Prep Output), this page explains what each summary number is telling you, and why it's worth understanding rather than just glancing past.
A number becomes meaningful once you know what process produced it. That's the theme running through every section below, so don't expect a table of "normal" and "concerning" ranges here, the detailed workflow pages linked throughout are the right place for that. This page is about how to interpret a number, not what number you should hope to see.
Run-Level Quality Info
Before any of the processing steps below even begin, there's a first quality gate: the run itself. Depending on the platform, we share either the sequencer's own run metrics (MiSeq) or the sequencing facility's CCS and Lima reports (PacBio), and both are worth reading before anything else, since they tell you whether a problem originates at sequencing or sample prep, rather than somewhere in our downstream processing.
What You See Here Is Already a Curated Extract
Most sequencing providers generate long, detailed reports full of plots and figures, well beyond what's shown below. Much of that can be genuinely useful, but working through every figure takes real time, and most of it isn't necessary unless something has actually gone wrong. What follows is what we consider the most important subset, extracted from the fuller report, particularly when nothing problematic has been flagged. If you want the complete provider report yourself, ask, we're happy to share it, but for a routine run, the numbers below are usually enough to tell you whether everything went as expected.
These Are One Real Run's Numbers, Not Targets
Everything below uses actual values from one specific run, purely to show how to read a report like this and what to cross-check against what. Your own numbers will differ, and differing is normal. Don't come away thinking your PhiX gap should match this one, or that your ZMW pass-filter and HiFi rates should sit this close together, the specific figures here aren't the lesson. The reasoning is: which numbers in the report relate to each other, and what a mismatch between them would suggest about your specific run.
MiSeq Run Info
Occupied: 88.65 % (goal 85-95 %)
Reads Total: 39.5 M (should be around 40 M)
Reads PF: 31.96 M (goal > 25 M)
PhiX conc: 17.0 % (loaded 10 %)
%>=Q30: Total 94.9 %
Reads demultiplexed: 77.1 %
Most of these are straightforward: Occupied is flow cell loading density (too low wastes capacity, too high risks overclustering and lower quality); Reads PF is Illumina's own pass-filter quality gate, applied at the instrument level before any of our own QC even starts; %>=Q30 is overall base-calling quality. The goal ranges shown alongside them come from the instrument software itself.
PhiX concentration is worth a closer look, as an example of a cross-check, not for the specific numbers. The value reported is observed, not loaded. In this particular run, observed (17.0%) came out higher than loaded (10%), and a gap in that direction generally means the actual sample library was less concentrated, or clustered less efficiently on the flow cell, than expected relative to PhiX, so PhiX ends up overrepresented in the final read mix. Whether your gap is large, small, or in the other direction depends entirely on your own run, this example just shows that the comparison itself is worth making. See the AVITI section of the Overview Workflows page for why PhiX is added to low-diversity libraries like amplicons in the first place.
Demultiplexed rate is worth connecting back to that PhiX number, not read alone. PhiX reads don't carry your sample's index, so they land in Undetermined by design, not a sample file. Some of your undetermined fraction should be explained by PhiX alone, roughly on the same order as the PhiX concentration itself. If your undetermined fraction comes out substantially larger than your PhiX concentration would account for, that's a real signal of index problems beyond PhiX, worth investigating directly rather than assuming it's all PhiX. The specific percentages in this example aren't a target to match, the check is whether your own two numbers are in the same ballpark as each other.
PacBio CCS and Lima Reports
## CCS Report
ZMWs input : 15,854,131
ZMWs pass filters : 7,695,294 (48.5%)
ZMWs fail filters : 8,158,837 (51.5%)
HiFi Reads : 7,614,836 (48.0%)
>=Q30 Reads : 6,252,903 (82.1%)
## HiFi Lima Report
ZMWs input (A) : 7,614,836
ZMWs above all thresholds (B) : 7,607,463 (99.9%)
ZMWs below any threshold (C) : 7,373 ( 0.1%)
"ZMWs pass filters" and "HiFi Reads" are two different gates, not the same number reported twice. Passing the basic ZMW filter (enough passes, minimum read length) doesn't automatically mean a ZMW produces a HiFi-quality consensus, that also requires the consensus itself to clear an accuracy threshold, and a ZMW can clear the first gate without clearing the second. In this particular run, HiFi Reads (48.0%) sits just slightly below ZMWs pass filters (48.5%). Whether that gap is small or large in your own run is what matters, not whether it matches this example: a small gap is unremarkable, a noticeably larger one suggests a meaningful share of your reads are marginal on accuracy even after passing the basic filter, worth investigating rather than assuming it's routine.
The Lima report is PacBio's equivalent of a demultiplexing rate. ZMWs "above all thresholds" successfully had their barcode identified with confidence; those "below any threshold" didn't. A high rate is a healthy signal, analogous to a high demultiplexed rate on Illumina, and a notably lower one, whatever "lower" means relative to your own typical runs, would be worth the same kind of investigation as an unusually low Illumina demultiplexed rate.
What to check: read the run-level report before anything else, not after something downstream looks wrong. A discrepancy here, a PhiX gap, an undetermined rate PhiX alone doesn't explain, a wider-than-usual gap between ZMW pass-filter and HiFi rates, points you toward sequencing or library prep as the source, rather than sending you looking for a bioinformatics explanation for a problem that started before processing ever began.
Data Loss Before Clustering
The steps listed before clustering (A-D), and how many there are, aren't fixed. They depend on your data. Quality control (minimum quality score, low-complexity filtering) and primer trimming are essentially universal. Others are specific to how your data was generated, read merging, for instance, only applies to paired-end data that needs to be stitched together in the first place. See the Steps, at a Glance diagram on the PE workflow page for the general shape, and Data Prep Long-Reads for how the steps differ there. A single combined "total loss" number, on its own, doesn't tell you much, since it's the sum of different steps doing different jobs, on data that may not have gone through the same steps as someone else's project.
Every filtering or selection step can lose some data. Sometimes a little, sometimes a lot, and how much is not, by itself, the thing to judge. What matters is whether the loss has a clear explanation, and whether "fixing" it would actually mean anything.
Interpreting the Loss
Almost any loss can technically be reduced by loosening a parameter. That's exactly what makes this tricky: the question isn't whether you can push a number down, it's whether doing so recovers real data or manufactures fake data that happens to pass the filter. Take read merging: our own GDA course materials walk through exactly this. A first merging pass with default parameters succeeds on only half of the reads. The obvious next move is to loosen the minimum overlap length and allowed mismatch rate until more reads merge. That does raise the number. It can also merge read pairs that never genuinely overlapped in the first place, forcing a "merge" onto data that shouldn't have been merged at all, producing sequences that look complete but don't represent a real, quality-checked overlap. The merge rate improves; the data doesn't.
The real question for any loss, then, is: does fixing it mean recovering real data, or manufacturing acceptable-looking data? A size range set too narrow, or a quality threshold that doesn't fit this dataset's real profile, are usually the first kind, adjusting them recovers genuine reads that a miscalibrated parameter was wrongly excluding. Reads that are genuinely poor quality, or an amplicon too long relative to the read length to merge at all, are the second kind if you push a parameter hard enough to "fix" them, since nothing about the underlying molecule changed, only how permissive the filter became.
Don't Optimise the Loss Percentage
It's tempting, when a loss percentage looks high, to just loosen the relevant threshold until the number looks better. Don't, for the same reason the merge example above illustrates.
Fix the Parameter to Preserve Quality, Not to Reduce the Number
The goal of adjusting a parameter is to correctly separate real signal from noise, not to minimise what gets reported. Loosening a quality, size, or overlap filter to keep more reads doesn't fix a real problem. It just lets more noise, or outright meaningless data, through alongside whatever genuine reads you recover. The report looking healthier afterward doesn't mean the underlying data got any better. Every adjustment should be justified by a clearer understanding of what the data actually looks like, never by the number it produces.
What to check: compare each step's loss against what's typical for that specific step, not the combined total. See the Typical Retention, by Step table on the PE workflow page for concrete benchmarks and what to watch for at each one. A step that falls well outside its usual range is the actual signal to investigate. Once you're looking at that specific step, the question is always the same: is this loss explained by the data itself, or by a parameter that doesn't fit it yet?
Total Amplicons vs. Unique Amplicons
At the end of Step D, you have merged, primer-trimmed, cleaned sequences. This is your total amplicon count. Before clustering can begin, these get dereplicated: identical sequences are collapsed into one representative, with a count of how many reads shared that exact sequence. What's left is the unique amplicon count. The size of the drop from total to unique tells you something real, but this number alone can't tell you which of several possible explanations you're looking at.
A large drop (many total amplicons, relatively few unique ones) is expected in amplicon sequencing, and not inherently concerning:
- Amplicon sequencing deliberately reads the same short target region across huge numbers of template molecules, so seeing the same exact sequence over and over is normal (see the FastQC duplication note for the same point in a different context).
- It reflects more than depth alone, it can also mean a genuinely low-diversity sample, or amplification bias concentrating reads on fewer templates than were actually present. It's a healthy pattern to see, not automatically proof of anything beyond "your depth comfortably covers what's here."
A small drop (total and unique counts sitting close together) is worth a second look, for any of several reasons:
- Genuinely high community diversity: many distinct organisms, each contributing relatively few reads, so few exact duplicates form. Real biology, and a legitimate reason for a small drop.
- Read quality (estimated error rate): dereplication only collapses exact matches, so a single base error turns one read into its own "unique" sequence, distinct from its true parent. A noisier run produces more of these artificial unique sequences, and therefore a smaller apparent drop, for reasons that have nothing to do with diversity.
- Amplicon length: for a given per-base error rate, a longer read has more positions where an error can occur, so the chance of at least one error rises with length. A small drop is less automatically a sign of real diversity on a long amplicon (full-length 16S) than on a short one (a V4 fragment). See Cluster vs. Species for the same effect discussed one step later in the pipeline.
- Library preparation method (orientation): a PCR-free ligation prep, unlike the standard two-step PCR, doesn't guarantee all reads come out in the same orientation (see the Illumina section for the difference). Two reads representing the same amplicon but sequenced from opposite strands aren't identical strings, so dereplication won't collapse them, splitting one true sequence into two "unique" ones. This is exactly why PacBio data needs an explicit orientation step (see PacBio Sequence Orientation); ligation-prepped Illumina data has the identical problem.
Denoising downstream (UNOISE) sorts the diversity and error-driven explanations apart, correcting error-derived near-duplicates back into their true parent sequence. It doesn't fix an orientation problem, that needs to be caught and corrected as its own step regardless of how the rest of processing goes.
What to check: the total-to-unique ratio, before any correction has happened, gives an early signal of how much work denoising has ahead of it. Compare it across samples of comparable amplicon length, marker, and prep method within the same project, so a length- or orientation-driven difference doesn't get mistaken for a diversity difference. A sample whose ratio looks very different from otherwise-comparable ones is worth a closer look before you assume it's just unusually diverse.
The Number of OTUs or zOTUs
A raw OTU or zOTU count doesn't mean much on its own, these aren't species counts to begin with (see Cluster vs. Species for why). A few broad, genuinely useful patterns exist, but each comes with real exceptions worth knowing, since treating any of them as a strict rule will mislead you exactly when it matters.
zOTU vs. OTU
zOTU count is usually higher than OTU count, but not always. Denoising preserves fine-scale, single-nucleotide resolution that 97% OTU clustering collapses away, so you'd normally expect more distinct zOTUs than OTUs from the same data. This can flip, though, when a sample carries many rare zOTUs and a higher-than-default abundance threshold gets applied. A stricter threshold disproportionately removes rare sequences, and there are usually far more rare zOTUs than rare OTUs to begin with, precisely because zOTU-level resolution is what created those fine distinctions in the first place. Push the threshold up enough, and the zOTU count can drop below the OTU count.
What to check: if you see zOTU count below OTU count, check what abundance threshold was actually used before assuming something went wrong.
Reading the Full Cascade: zOTU → c99 → c98 → c97
We routinely cluster zOTUs further at 99%, 98%, and 97% identity, and the resulting cascade of numbers tells you more than any single count on its own. Here's a real example:
Number of OTUs : 836
Number of ZOTUs : 1946
Number of ZOTUs_c99: 1120
Number of ZOTUs_c98: 866
Number of ZOTUs_c97: 738
Two things worth noticing. First, the final number, zOTU_c97 (738), lands close to the OTU count (836), consistent with the general pattern that OTU counts and zOTUs additionally clustered at 97-98% tend to converge, they're measuring similar things from two different starting points. Second, and more interesting, is where the biggest drop happens in the cascade. Here it's between zOTU (1946) and zOTU_c99 (1120), a drop of over 800, more than the c99-to-c97 drop combined.
That tells you that a lot of the apparently distinct zOTUs sit within 1% of each other, an extremely tight radius. It's tempting to jump straight from there to a specific cause, but the clustering pattern alone can't fully distinguish between them. See Cluster vs. Species for the Coenye and Vandamme (2003) survey finding that intragenomic divergence between an organism's own rRNA operon copies typically falls in the 98.74%-100% similarity range, almost entirely within the c99 radius. That makes the c99 step interesting as a diagnostic: a large reduction there tells you many sequences differ by less than 1%, a range where both sequencing artefacts and intragenomic variation can occur, but genuinely distinct biological variants can occasionally sit within that same radius too, depending on the marker and the organisms involved. A drop that happens later instead, between c98 and c97, points toward coarser, more clearly distinct variation, more consistent with real, closely related but separate organisms.
What to check: don't just look at the final zOTU_c97 number, walk the whole cascade and notice where the largest single drop happens. An early drop (zOTU to c99) tells you the variation involved is fine-scale and sub-1%; a later one (c98 to c97) tells you it's coarser. Neither location proves a specific cause on its own, but knowing which one you're looking at narrows the plausible explanations and tells you what else is worth checking.
Richness Depends Strongly on the Marker and Sample
Typical richness varies enormously by marker and target group, and while a rough pattern like 16S bacteria > ITS fungi > COI insects shows up often enough to be a useful starting expectation, treating it as a rule will mislead you. It roughly tracks real differences in typical community complexity: bacterial communities are usually far richer per sample than fungal communities, which are usually richer than macroinvertebrate communities, in a typical environmental sample. But ecosystem type, sample type, extraction efficiency, and primer coverage all shape the actual number, and a soil sample and a single-host gut sample can differ enormously even using the same marker.
What to check: don't treat an inverted ordering as an error on its own. Specific study systems can invert it without anything being wrong; it's a prompt to think about your sample type, not a red flag by itself.
Pooling Inflates the Count
Pooling heterogeneous samples inflates the total count, for a reason that has nothing to do with resolution or thresholds. Combine samples from very different places or habitats with little overlapping diversity, and the pooled OTU/zOTU count comes out close to the sum of each location's own diversity, not a shared, overlapping figure, since non-overlapping diversity adds rather than cancels.
What to check: see Project Scope for the processing-side reasons to think carefully about what you combine into one batch; this is the diversity-counting side of that same issue.
The 20,000 Flag
20,000 is not a biological cutoff. It's simply a workflow-specific "look again" threshold based on our own experience running this particular pipeline, not something derived from the literature or applicable to other pipelines. In our experience, counts above roughly 20,000 are unusual enough to be worth a closer look before reporting them at face value.
What to check: common explanations at this scale include pooling many heterogeneous samples, an unusually permissive filtering or abundance threshold, or a reference or clustering issue, rather than genuinely that much biological diversity in one dataset. Treat a large number as a prompt to check your processing choices, not as an impressive result on its own.
Mapping Rate
Once (z)OTU cluster representative sequences are established, every original amplicon, not just the unique ones used to build the clusters, gets mapped back against them (see the Mapping Algorithms note on the PE workflow page) to build the actual count table you work with. The mapping rate is what fraction of your total amplicons successfully found a cluster to map to.
In a healthy dataset, this should be very high, comfortably above 95%. Unlike the OTU/zOTU count itself, which needs real context to interpret, a mapping rate well below that is a fairly unambiguous signal: a meaningful chunk of your amplicons have no corresponding cluster at all. A low mapping rate means those reads survived preprocessing but ultimately had nothing valid to map to once clustering was done. Two things can cause that:
- The abundance threshold. Low-abundance unique sequences that fall below the minimum abundance cutoff don't become a valid (z)OTU, and, particularly for zOTUs, aren't always close enough to an existing cluster to be folded into one either. Any amplicon that was one of those excluded sequences has nothing left to map back to.
- Chimera removal. A unique sequence flagged and removed as chimeric during clustering is, by the same logic, no longer a valid mapping target, so its reads won't map either.
Both produce the same downstream symptom, a lower mapping rate, so a low rate on its own doesn't tell you which one is responsible.
What to check: if your mapping rate looks noticeably lower than the rest of your project, or below what you'd expect from similar past work, check the abundance threshold used and the chimera count for your project side by side. It's one of the more reliable, low-ambiguity warning signs in the whole summary, worth investigating directly rather than treating as ordinary noise.
The Shape of the Abundance Distribution
A handful of (z)OTUs typically account for most of your reads, and a long tail of rare ones accounts for the rest, each detected in only a few reads or a few samples. This pattern is close to universal in amplicon data, and it isn't a flaw in your specific dataset, it's how real communities, and how PCR and sequencing themselves, tend to behave. See the OTU/Count Table page's note on why OTU/zOTU numbering itself reflects this directly: lower numbers are the abundant few, higher numbers are the long tail.
Knowing the shape is there matters beyond curiosity, because it directly affects how some downstream approaches behave.
Rarefaction. Subsampling every sample down to a common depth (see Count "Normalisation" Approaches on the OTU/Count Table page) affects the long tail far more than the abundant few. A dominant (z)OTU with thousands of reads will still show up reliably at a much lower rarefied depth. A rare one represented by only a handful of reads at full depth has a real chance of being missed entirely once you subsample, purely by chance, not because it wasn't really there. Richness in particular, since it counts everything including the tail, is especially sensitive to the rarefaction depth you choose, for exactly this reason.
Presence/absence comparisons. Methods like Jaccard-based beta diversity weight every (z)OTU equally, abundant or rare, unlike abundance-weighted metrics where the rare tail barely registers. That's exactly the group most vulnerable to the sampling-chance problem above: whether a rare (z)OTU gets detected at all in a given sample can be more a function of sequencing depth than of genuine ecological presence or absence. A presence/absence comparison run without accounting for this can end up driven largely by detection noise in the tail, rather than a real difference between your samples.
What to check: before relying on rarefaction or presence/absence methods, look at how heavy your long tail actually is, how many (z)OTUs are represented by only one or a few reads, or detected in only one or two samples. A heavier tail means more caution is warranted with both approaches; a shorter one means less. This is also a good reason to revisit the re-clustering diagnostic (zOTU vs. zOTU_c99) discussed above: a heavy tail and a large re-clustering drop often go together, and for related reasons.
ITSx Results (ITS Data Only)
For ITS amplicon projects, Step G runs ITSx on the final (z)OTU representative sequences. ITSx searches a sequence against taxon-specific HMM profiles built from 20 eukaryotic groups, looking for the conserved regions (SSU/18S, 5.8S, LSU/28S) that flank an ITS1/ITS2 region. A sequence is reported as detected when ITSx finds a compatible set of HMM matches supporting an ITS region, and the group-specific profile(s) that produced those matches provide the basis for the "preliminary origin" label reported alongside it.
The underlying architecture ITSx searches for, SSU-ITS1-5.8S-ITS2-LSU, is conserved across plants, animals, algae, amoebae, and other eukaryotes, which is why universal ITS primers amplify more than just fungal material (see Primer Design for the coamplification consequences this has in practice). A sequence reported as "detected as ITS" means it's structurally consistent with somebody's nuclear ITS region, a compatible match to one or more of ITSx's profiles. ITSx detection is evidence of ITS-like structure, not proof of biological origin. HMM matching has real limits in both directions: false positives happen, and legitimate but highly divergent ITS sequences can be missed if their flanking region doesn't match any profile closely enough.
ITSx is not a taxonomic classifier, and this matters even for sequences it detects and assigns a preliminary group to. Establishing that a sequence looks structurally like ITS, and roughly which group's profile it matched, is a different filtering decision from actually classifying it taxonomically, that's still SINTAX's job against a real reference database (see Step F). Classifying against a reference like UNITE (Step F) and running ITSx (Step G) are two separate decisions, in that order: classification is what actually determines whether it's reasonable to call a sequence fungal; ITSx, run afterward, is an additional structural check on top of that, not a replacement for it.
Here's a real example, run on the same project's OTU and zOTU sets:
ITSx Summary Report for OTU
Number of sequences in input file: 8562
Sequences detected as ITS by ITSx: 8531 (99.6%)
ITS sequences by preliminary origin:
Amoebozoa: 51 (0.6%)
Fungi: 7905 (92.3%)
Green algae: 11 (0.1%)
Metazoa: 33 (0.4%)
Red algae: 1 (0.0%)
Tracheophyta: 530 (6.2%)
ITSx Summary Report for ZOTU
Number of sequences in input file: 14502
Sequences detected as ITS by ITSx: 4501 (31.0%)
ITS sequences by preliminary origin:
Amoebozoa: 50 ( 1.1%)
Fungi: 4209 (93.5%)
Green algae: 10 ( 0.2%)
Metazoa: 12 ( 0.3%)
Red algae: 2 ( 0.0%)
Tracheophyta: 217 ( 4.8%)
Read it top to bottom, one report at a time.
OTU report. The first number, 8531 out of 8562 (99.6%), says most clusters are likely ITS-related. Within that 8531, each sequence gets its own individual best-fit category: ITSx reports whichever profile scored highest for that specific sequence, without showing what the next-best alternative might have been. 7905 sequences (92.3%) had Fungi as their individual best hit, a good result for a fungal ITS study, and a nice confirmation, though not proof, since we don't see how close the runner-up profile was for any given sequence. The same applies to every other row in the table: the 530 sequences under Tracheophyta each had Tracheophyta as their own best hit, not a weaker version of the Fungi result, a different population of sequences with their own individual winning match. Percentages here are of the 8531 detected sequences, not the full 8562, "Fungi: 92.3%" means 92.3% of what was confirmed as ITS, not 92.3% of everything.
One of the smaller categories is worth a second look: 530 sequences (6.2%) had Tracheophyta (vascular plants) as their individual best hit, consistent with plant nuclear ITS. These sequences already have a SINTAX-based taxonomic call from Step F, so this is a structural corroboration of that call, worth cross-checking against the SINTAX annotation for the same sequences, and a plausible signature of the plant coamplification issue discussed on Primer Design, exactly why that page recommends testing for it and considering PNA blockers in plant-associated samples.
zOTU report. The first number tells a very different story: only 4501 out of 14502 (31.0%) detected, far lower than the OTU rate for nominally the same underlying data. The most likely explanation is off-target amplification: primers binding a locus with no real ITS architecture at all, which ITSx correctly reports as a clean negative. This is our leading hypothesis, not something these two numbers confirm outright, and the abundance thresholds used for OTU versus zOTU calling are also worth checking as a contributing factor.
One real driver behind the gap itself: OTU clustering at 97% collapses many related sequence variants into one representative, so a single OTU can represent a whole cloud of zOTUs underneath it, some genuinely valid variants, some not. Clustering can hide heterogeneity that only becomes visible once you look at the zOTU level.
One more thing worth checking before treating a detection rate like 31.0% as concerning on its own: it's a count of clusters, not a measure of how much of your actual data those clusters represent. If most of the zOTUs that failed detection are rare, low-abundance ones, each contributing only a handful of reads, a large fraction of failed clusters can still leave the great majority of your total reads untouched. This is the same distinction already discussed on The Shape of the Abundance Distribution above: a long tail of rare clusters can dominate a count-based statistic while barely registering in the abundance-weighted picture. The reverse matters too, if some of the ITSx-negative zOTUs turn out to be genuinely abundant, that's a more serious signal than the cluster count alone suggests. Worth checking directly: sum the read counts behind the ITSx-negative zOTUs and compare that total to the sample's overall read count, not just the cluster count, since a cluster-level failure rate and a read-level impact can tell very different stories.
What to check: for ITS data specifically, the ITSx detection rate is worth reading alongside the zOTU-to-c99-c98-c97 cascade discussed above, both are ways of asking how much of your apparent zOTU diversity has detectable ITS structure versus remains questionable, from two independent angles. A low ITSx detection rate on zOTUs, especially alongside a large early drop in the re-clustering cascade, is a reasonable prompt to investigate the zOTU abundance distribution, inspect the ITSx-negative sequences directly, and consider whether the raw zOTU count is an appropriate measure of biological diversity for this project, rather than trusting it at face value. And regardless of the detection rate, remember what ITSx is actually telling you: that a sequence is structurally consistent with ITS and roughly which broad group's profile it matched, not a confirmed, species-level identification.
More Sections Coming
This page will grow to cover more subjects as we write that section up.