How to Name Files Attached to ELN Records for Easy Retrieval

A lab file naming convention is a standard pattern that encodes what a file is, which experiment it belongs to, and what version it is, so that any team member can find and interpret it without opening it. Naming conventions exist because files attached to experiment records outlive the memory of whoever created them, and a file called "gel_final_v2_fixed.jpg" is only interpretable by its author.

Attachments are where experiment records touch reality: the gel image, the instrument export, the sequence file that supports a conclusion. When their names are ad hoc, retrieval slows down and files get orphaned from the records that explain them. This guide covers the elements of a useful name, versioning, instrument exports, and how a team adopts one convention.

What Breaks When Names Are Ad Hoc

Ad hoc naming produces three connected failures. Retrieval slows down, because searching for a gel requires guessing what the author called it. Duplication appears, because the same file is saved again when the original cannot be found. Orphaning follows, because files detached from any recognizable experiment or version can no longer be trusted, which quietly erases the evidence they once were.

The cost is paid at the worst moment, during review or investigation, when a result must be traced to its source file and the name gives no route to it. The convention is therefore a retrieval and trust mechanism, not an aesthetic preference: a well-named file can be found, and a findable file can be verified.

The Core Elements of a Useful Name

A useful name carries a small set of elements that answer the questions a stranger would ask: which project or experiment, what kind of content, and which version or date. A typical pattern combines a stable experiment identifier, a short content descriptor, and a version or date, such as an experiment ID followed by a descriptor like "gel" or "seqdata" and a version number. The elements are joined by hyphens or underscores, not spaces, so the name survives paths, scripts, and sharing.

The experiment identifier does the heavy lifting, because it is the key that links the file back to the ELN record. Content descriptors should come from a short controlled vocabulary, "gel", "raw", "align", "qc", so that names are comparable across the team. Whatever else the name contains, it should never depend on the creator's personal shorthand.

Naming Patterns That Survive Handoffs

Names that survive handoffs share three properties. They use stable identifiers rather than personal ones, so "EXP-2026-0412-gel-v1" survives while "amy_gel_tuesday" does not. They avoid ambiguous qualifiers, so the version is a number or a date, never "final", because every "final" file eventually gets a "final2". They keep the same element order across files, so sorting groups related files together instead of scattering them.

The convention should also tolerate reality: files arrive from instruments with their own names, and renaming everything by hand fails as soon as the team gets busy. The convention works when it states what must be renamed, what must never be renamed, and what the ELN record carries instead, which is the next section's topic.

Instrument Exports: Rename or Keep?

Raw instrument exports deserve special treatment: their original names are often the only link to the instrument's internal run database, and renaming them can break that provenance. The practical rule is to keep the raw export under its instrument name and add context around it, in the ELN record and in the folder or in a manifest, rather than rewriting the name itself.

Derived files, the processed results a researcher creates from the raw export, should follow the team convention with the experiment identifier and descriptor. This split preserves both provenance and findability: the raw file keeps its instrument identity, and the derived files carry the names the team searches by. For teams that want instrument exports and experiment records connected, the Zettalab workspace links structured records with team file storage, keeping raw exports with the records that explain them.

Versioning in Names vs Versioning in the Record

File names can carry version numbers, but names are not an audit trail: a renamed file can silently replace its predecessor. The version number in the name is a retrieval convenience, while the record of who changed what and when lives in the ELN or the file system's history. Both belong in the workflow, and they should not be conflated.

The convention should therefore state that version numbers in names advance on content changes and that superseded versions are retained, not overwritten. Retaining old versions preserves the comparison that reviews depend on, and the ELN record links to the version that supports each conclusion. For teams that want file attachments and experiment records connected, ZettaNote within the Zettalab workspace supports attaching files to structured experiment records, and the broader platform keeps project files and documentation in one searchable context.

FAQ

Should I rename raw instrument files to match our convention?

Generally no. The raw export's original name is often the only link to the instrument's run database, and renaming it can break that provenance. Keep the raw file under its instrument name and add the context around it, in the ELN record and in the folder or manifest, instead. Derived files you create from the raw export should follow the team convention, because those are the files the team searches by.

How should I name gel images attached to experiments?

Use the experiment identifier, a short descriptor such as "gel", and a version number, following the team's standard order, for example an experiment ID plus "gel-v1". The lane labeling and interpretation belong inside the image and the ELN record, not in the filename. A name built from the stable experiment identifier is what lets the image be found from the record and verified against it.

Are spaces and special characters a problem in file names?

Yes, in practice: spaces and characters like slashes, ampersands, or non-ASCII symbols behave differently across operating systems, shared drives, and analysis scripts, and they break paths at inconvenient moments. Use hyphens or underscores between elements and keep names lowercase where possible. A convention that avoids problematic characters from the start prevents a class of failures that has nothing to do with science.

What is better in a file name, a version number or a date?

Both work, but they answer different questions: a version number shows sequence, while a date shows when, and files generated by instruments or software often already carry dates. Pick one as the standard, use it consistently in the same position, and never use words like "final" in place of a real version, because they are not orderable and always get contradicted. The version or date in the name is for retrieval; the change history belongs to the record system.

How do we get a whole team to adopt one naming convention?

Start from files the team already produces, keep the convention minimal, and make the ELN or template carry the pattern so it is applied at the moment of attachment rather than remembered. Adoption improves when the convention visibly pays off, which happens as soon as retrieval gets faster. Review attachment names during experiment review, and let the convention evolve through a short controlled change process rather than personal improvisation.

Conclusion

File naming is a small discipline with a compounding return: stable identifiers, a short controlled vocabulary, real versioning, and respect for raw instrument provenance keep attachments findable and verifiable long after their author has moved on. The convention's test is simple, whether a new team member can locate the file behind any recorded conclusion. To attach files to structured experiment records, explore Zettalab's ZettaNote ELN.