Exploring Fragment Morphology: A Deep Dive into Microsoft Word's "fragmentation_3d_final_corrected.doc"

The filename fragmentation_3d_final_corrected.doc is the kind of artifact that turns up in every genetics lab: a report file passed between analysts, versioned by hand, and eventually mistrusted. But behind that unglamorous document sits a genuinely interesting analytical problem. When we size and interpret DNA fragments, the raw data is not a picture at all. It is a three-dimensional dataset, and how we flatten it into a shareable document determines whether the underlying morphology survives the round trip. This article uses that "3D" framing to explain what a fragment analysis result actually contains and how to manage the files that carry it.

Want expert help putting this into practice? FragmentMorphology can guide you through it.

The three axes hiding inside a fragment result

A capillary electrophoresis electropherogram or a gel image looks flat, but the information is inherently three-dimensional. The first axis is fragment size, expressed in base pairs and derived by mapping migration time against a co-injected size standard. The second axis is signal intensity, measured in relative fluorescence units (RFU) or band density, which reflects the quantity of DNA at each size. The third axis is dye channel or lane identity, which separates co-loaded targets labeled with different fluorophores or run in parallel wells.

Every meaningful interpretation lives at the intersection of these three axes. A short tandem repeat (STR) allele is a peak at a defined size, in a defined dye channel, above a defined intensity threshold. Collapse any axis carelessly, for example by screenshotting only the size axis into a Word document, and you strip away the context an analyst needs to defend the call.

Why the .doc export is where morphology gets lost

Related: Fragmentmorphology Best Practices for Effective Design.

Pasting an electropherogram into a document is the most common way fragment morphology degrades. Consider what happens in practice:

• Resampling distorts peak shape. A vector trace rendered to a low-resolution raster image loses the fine structure that distinguishes a true sharp peak from a broad artifact or a stutter shoulder.
• Axis labels drift. Cropping to make the figure fit a page can remove the size-standard peaks that anchor the base-pair scale, leaving reviewers unable to verify sizing.
• Channel color is flattened. Grayscale printing merges dye channels, erasing the separation between overlapping alleles from different loci.
• Metadata is severed. The instrument run parameters, injection time, and analysis method that made the trace reproducible do not travel inside a pasted picture.

The lesson is not to avoid reports, but to treat the document as a summary layer over the primary data, never a replacement for it.

Keep the primary data primary

Fragment analysis instruments write native binary files, commonly .fsa or .ab1 formats, that preserve all three axes plus the size-standard trace and run metadata. These are your source of truth. A disciplined workflow keeps them intact and read-only, then generates derived outputs from them on demand.

A practical filing convention beats a filename like "final_corrected" every time:

• Immutable raw store. Archive the native .fsa/.ab1 files under a run identifier that includes date, instrument, and plate. Never overwrite them.
• Analysis parameters as data. Record the sizing algorithm, size standard used, and peak-detection thresholds alongside the raw files so a reviewer can reproduce the exact call.
• Reports as disposable derivatives. Any .doc, .pdf, or slide is regenerable from the raw data and parameters. If it is lost, nothing of value is lost.

This is the same principle that separates a source file from a compiled binary: the human-readable report is convenient, but the machine-readable trace is authoritative. The discipline pays off most when a result is challenged months later. If a reviewer disputes an allele call or a fragment size, an analyst with the intact native file can reopen it, reapply the recorded parameters, and demonstrate exactly how the number was produced. An analyst who kept only a pasted figure in a document can demonstrate nothing, because the evidence itself was thrown away the moment the screenshot was taken. In regulated and forensic settings this distinction is not a matter of tidiness but of admissibility.

Version control belongs to runs, not filenames

See also: Fragmentmorphology Best Practices You Need to Know.

The "final_corrected" naming spiral is a symptom of tracking versions in filenames rather than in a system built for it. Every appended suffix, "v2", "revised", "USE THIS ONE", is a private note that means nothing to the next person and quietly loses the audit trail. A better model borrows from software: the primary artifact is immutable and identified by an intrinsic run identifier, while changes are recorded as new derived analyses that point back to the same source. When the reanalysis differs from the original, both survive, each traceable to the same raw trace and each stamped with the parameters that produced it. Nothing is overwritten, so nothing is lost, and "which version is correct" becomes a question the record answers rather than the analyst's memory.

Reconstructing morphology from a well-kept file

When the primary data is preserved, interpreting a fragment becomes a reproducible procedure rather than a memory exercise. A worked example: suppose an STR locus is expected in the 100 to 350 base-pair window. Load the native file, apply the internal size standard, and confirm the standard's fragments fall within tolerance of their known sizes. Only then read the sample peaks. A heterozygous genotype appears as two peaks of comparable height; a homozygote as one. Stutter peaks sit one repeat unit shorter than a true allele and at a characteristic fractional height, and dye "pull-up" appears as a small peak at the same size in an adjacent channel. None of these judgments are possible from a flattened screenshot, but all of them are routine from the intact trace.

A file-hygiene checklist for fragment data

Adopt these habits and the "final_corrected" naming spiral disappears:

• Version by run, not by filename. Let the run identifier and a database or lab information system track versions, not ad hoc suffixes.
• Store thresholds with results. A peak call is only meaningful relative to the analytical threshold that produced it; record both.
• Preserve the size standard. Every archived trace should retain its co-injected ladder so sizing can be re-verified independently.
• Export losslessly for review. When a figure must go into a document, export vector graphics or high-resolution images that retain peak shape, axis labels, and channel color.
• Separate the summary from the source. Treat prose reports as communication, and the binary trace as evidence.

Handled this way, the difference between a trustworthy result and an untrustworthy one stops depending on who last saved the document. It rests instead on an unbroken chain from instrument to interpretation, where the three axes of size, intensity, and channel remain intact at every step. At FragmentMorphology, that chain-of-custody mindset is the foundation of every reliable fragment call, because a result you cannot reconstruct is a result you cannot defend.