How should I name and tag files so I can find old drafts and sources quickly?

A filename should answer three questions at a glance: when was this, what project is it part of, and what stage or kind of document is it? If you have to open a file to answer any of those, the name is failing at its job.

Start every filename with the date in YYYY-MM-DD format. ISO 8601 sorts correctly in any file browser, unlike formats such as 6/15/24 or 15-06-2024, which sort differently across systems and locales. Follow the date with a lowercase project slug, then a version marker, then a short type label.

Avoid spaces, slashes, colons, and question marks. These characters cause problems on some file systems and break links and scripts that reference the path. Hyphens and underscores are safe and readable.

Use zero-padded version numbers (v01, v02, not v1, v2) so version 10 doesn't sort before version 2. This is the same reason dates get padded. If you write in a tool that stores files as plain local documents, such as the markdown editor NeoGlint, the filename is often the most visible piece of metadata you have, so it pays to make it carry its weight.

Tags fail when they're open-ended. If one week you tag a file writing and the next week article and the week after draft, no filter will ever find your work reliably. The fix is dimensional tagging: a small set of tag categories where each file gets exactly one tag per category.

A workable three-dimension scheme looks like this:

• Project — the specific body of work, such as nebula-article or thesis-chapter-2.
• Status — where the file sits in the workflow: idea, outline, draft, revised, final, archived.
• Type — what kind of artifact it is: source, note, draft, reference, output.

Keep the approved list visible somewhere you'll see it. Adding a new tag should feel like a small decision, not an accident. When you're tempted to invent a tag, ask whether an existing one covers it; most of the time it does.

If your files are plain markdown, tags often live in front matter at the top of the document, and many editors and search tools can index those fields. Combine tag filters with filename searches to narrow results fast: a date range plus a status:draft filter returns exactly the old drafts you're hunting for.

Folder hierarchies feel tidy until they don't. A structure four or five levels deep means every file lives at exactly one address you must recall. Search, by contrast, doesn't care where a file is as long as its name and metadata are consistent.

A practical compromise keeps folders shallow and predictable:

1. A top-level folder per active project, plus one archive folder for finished work.
2. Inside each project, separate folders for drafts, sources, and notes.
3. Filenames carry the date and version; subfolders rarely go deeper than this.

Move finished projects to the archive folder when they're done, and apply an archived status tag. Archiving keeps active folders scannable without deleting history you may want later.

One more habit matters: back up. If you store files locally — as you would with an offline-by-design editor like NeoGlint — you are the custodian of that data. A simple rule is to keep local files under version control or a synced backup destination you control, so a disk failure doesn't erase your archive.

Fast retrieval is a product of consistency, not clever tooling. If your filenames always start with a date and your tags use a fixed vocabulary, then a search for 2024-06 nebula draft will surface every relevant file, even years later.

Build a small set of search habits:

• Prefix search — type the first few characters of a known pattern, like 2024-06, to narrow by month.
• Tag filters — in editors that index front matter, combine status:draft with project:nebula-article.
• Content search — command-line tools such as ripgrep or grep -r find phrases inside files, not just in names. This catches sources you saved but forgot to tag.

On Windows, the built-in search can be slow and inconsistent for plain text, so a dedicated tool like Everything or ripgrep is often faster. The same logic applies on Linux and macOS. The point is to have one search method you trust and use every time, rather than switching tools and hoping.

If you write in a local editor like NeoGlint, your files remain plain markdown on disk, so any external search tool can index them. No export step, no locked-in database — the files are the database. That makes long-term retrieval a matter of maintaining your naming and tagging discipline, not depending on a specific app's search feature.

Drafts often get cannibalized. A paragraph from one article becomes a section in another; an old outline becomes the seed for a new project. The risk is losing track of what came from where, or accidentally editing the original when you meant to reuse it.

The safe pattern is to treat reuse as a new file:

1. Copy the original file — do not move it.
2. Rename the copy with the new project slug and today's date.
3. Change the type tag from draft to source or reference.
4. Add a line in the new file noting the original filename.

This keeps provenance visible. If the original later needs updating, you can find it and decide whether to sync changes. It also means your archive stays intact: nothing is overwritten by accident.

For developers, this mirrors a familiar rule: don't mutate shared inputs. For writers, the equivalent is don't edit the source draft in place. Duplicate, rename, retag, then work. A local-first tool like NeoGlint makes this easy because every file is a plain document you can copy and rename outside the app — no import/export dance required.

Any naming system drifts if left alone. New projects introduce new tag temptations; old ones leave behind files with statuses that no longer apply. A light, regular review keeps the archive usable without turning maintenance into a chore.

A simple quarterly ritual:

• Sweep for orphans — search for tags not on your approved list and either delete them or promote them deliberately.
• Check filenames — scan recent files for missing dates, inconsistent separators, or non-padded versions.
• Archive finished work — move completed projects to the archive folder and apply the archived status tag.
• Back up — confirm your local files are covered by whatever backup or version control you rely on.

Fifteen minutes every three months is enough. The goal is not perfection but predictability: when you search in two years, the system should still return the right files. If you use an offline editor, you own the data, so you also own the housekeeping — and that's a small price for a searchable, permanent archive.