Fileosophy.

(file + philosophy)
ORIGINAL / ungated gated posture · _UNCLEARED placeholder / SRC_ batch special (_starter / _archive) app-native (exempt) naming example (a file, not a folder)
Workflow
Hover a folder — or the project-root row — to add / rename / delete · drag to move · drop on the root name to move to the top level.

// Who is this for?

Everyone.

If you make files and later have to find them again, this is for you.

If you make files and later have to find them again, this is for you — a wider circle than it first sounds. Editors, designers, writers, directors, producers, solo shops, whole post houses. Anyone whose work ends up as a folder someone has to open later.

Why this exists

Staying organized isn't the hard part of a job — it's the quiet part. The tax you pay in the background: where does this go, what do I call it, which of the three export folders is the real one. Every one of those is a small decision skimmed off the top of the attention you'd rather spend actually making something. And the bill comes due twice — once now, and again in eighteen months when you need the project back and it's gone feral.

Left to itself, any project turns into a graveyard: FINAL_v2_real_FINAL, a folder called stuff, three copies of what you sent the client in three different places, an edit session named after whatever the editor had for lunch. Tuna is not a version. NEW FOLDER (3) is not a location. None of it is laziness — naming a file is a thoughtful decision, and one nobody wants to make at 2am.

So Fileosophy makes the decisions in advance. One structure, one naming grammar, and a folder tree that explains itself: every folder tells you what belongs in it, and every asset you didn't create lands somewhere that remembers where it came from and whether you're cleared to ship it.

You don't have to take the whole thing

Fileosophy is opinionated, and you're welcome to adopt it wholesale. But the opinions sit on a floor of plain best practices — how to name a file so it sorts, survives a move between machines, and reads at a glance. That floor is portable. Bring your own structure and these still make it better.

Nobody teaches this

For something this universal, almost no one is ever taught it. It should be taught in school, near touch-typing and how to write an email. It isn't. So consider this the class nobody gave you. Read one article and steal one idea, or read all of them and rethink the lot — either way you'll leave operating a little more deliberately than you came in.

Guide / 01_NAMING.FILES

Naming files the right way

The rules everyone agrees on — before anyone argues about the rest.

Every operating system lets you name a file almost anything. That freedom is the problem. A filename is the smallest unit of organization you have, and it has to work for three readers at once: scripts parse it, the filesystem sorts it, and future-you scans a folder of two hundred looking for the one that isn't broken.

A handful of rules make a name behave for all three. None are controversial — this is the floor.

1 · No spaces

Spaces break shells, URLs, and scripts. Use one separator that never fights you — _ or - — and use the same one everywhere.

2 · Skip the special characters

/ \ : * ? " < > | are reserved or meaningful to the filesystem. Stay inside letters, numbers, and your chosen separators. The period earns its place in exactly one spot: before the extension.

3 · Pick a case and keep it

The bug isn't upper versus lower — it's mixing, then moving between machines that draw the line differently. Decide once, apply it everywhere.

4 · Pad your numbers

Computers sort text, not math, so shot10 lands before shot2. Zero-pad to a width you won't outgrow — SH0002, SH0120 — and the alphabetical sort becomes the numeric one for free.

5 · Write dates that sort themselves

Lead with the biggest unit: YYYY-MM-DD. It's the one date format that sorts chronologically when sorted alphabetically. 03-08-2026 is ambiguous and files out of order.

The rule under the rules

Be consistent, be descriptive. A good name says what the thing is without your opening it — and says it the same way every time. What these don't tell you is which pieces belong in the name, in what order, and why. That's where Fileosophy starts having opinions.

Guide / Principles / 02_MEDIA.FIRST

Sort by what it is, not where it came from

Media-first — and why provenance is the second question.

When you go hunting for a music cue, one thing is certain: it's music. What you may not remember is whether you made it, licensed it, or pulled it from an archive. A tree should ask the question you can always answer first.

So Fileosophy sorts source media media-first — by type. Provenance is answered one level down, at each leaf, by a posture folder.

Four postures

  • 01_ORIGINAL — owned to this project. Ungated.
  • 02_GENERATIVE — AI output; rights uncertain. Gated.
  • 03_STOCK — licensed off the shelf, instantly. Gated.
  • 04_ARCHIVAL — a bespoke, negotiated licence. Gated.

The order is a gradient: made, made-with-a-tool, bought-easy, bought-hard.

The gate is on the "wrong" thing, on purpose

Most systems guard what you own. Fileosophy gates what's licensed, not what's owned — because those are the files that trip you up at delivery. 01_ORIGINAL isn't gated; nothing in it can fail to clear. The three licensed postures each carry an _UNCLEARED folder.

And the gate isn't a legal quarantine — it's a swap list. Pull thirty stock clips into a rough cut; you'll license the five that survive. All thirty sit in _UNCLEARED so the cut stays intact, and only the licensed few graduate up.

Why not sort by provenance?

A provenance-first tree scatters your music across four buckets and forces the hard question (whose is this?) before the easy one (what is it?). Media-first keeps everything of a kind together and files the rights obligation right beside the media it applies to. Provenance still matters — it's just the second question.

Guide / Principles / 03_THE.SUPERSET

Build the superset, then delete down

Why the structure gives you more than you need.

Most folder templates hand you a bare skeleton and trust you to add branches as the job demands them. It sounds lean. In practice it fails the same way every time: you don't add them. The folder you didn't make is the decision you didn't make — so the file ends up loose on the desktop, and the structure quietly rots.

Fileosophy ships the other way: comprehensive, on purpose. The reasoning is an asymmetry.

Deleting down is cheap; building up is not

Removing a branch you don't need is a five-second, no-stakes act. The tree is a map, and a map showing a road you didn't take costs nothing. But inventing a branch mid-job is real friction — name it, place it, match the grammar — and it lands exactly when your attention belongs on the work. Worse, everyone invents a slightly different folder, and that's where the muscle memory evaporates.

So the default is a considered superset. Not using 3D on a talking-head job? Leave the branch empty or delete it. The one thing you never do is reinvent it next time.

Comprehensive isn't infinite

This is a superset, not a dumping ground. Every folder earns its place by being something a post job plausibly needs, and each comes with its reasoning attached — so an empty folder is never a mystery. It's a suggestion with a rationale: here's where this kind of thing goes, and here's why.

Guide / Principles / 04_ORDER.BY.USE

Order by how often you reach for it

Why the folders aren't in pipeline order.

The obvious way to order pipeline-output folders is by pipeline flow — plates, then elements, then composites, then grades, in the sequence the work happens. Fileosophy doesn't. It orders them by how often you open them.

Frequency is what the number buys you

Because numbered folders hold a fixed order, the number becomes prime real estate — so you spend it on what your hand reaches for most. In 02_INTERMEDIATES, the hub you're in all day (01_EDIT.OUTPUTS) sits first, then the folders you live in, then the heavier renders below. The folder you open forty times a day is never more than a glance from the top.

A bonus that falls out for free

The lower slots line up with their source disciplines by number: 3D, splat renders, colour, sound. An output sits at the same number as the discipline that made it — a second layer of consistency nobody had to engineer.

The trade-off, stated plainly

02_COMPOSITES ends up above the very things that feed it — the renders and elements composited into it. Read as a flow, that's backwards. Fileosophy accepts that, because you navigate this tree hundreds of times a day and diagram it approximately never. Pipeline flow is how you'd draw the work; access frequency is how you do it.

Guide / 05_FAQ

Questions & answers

The things people ask before they commit to a new way of working.

Still deciding whether this is for you? Start here. If your question isn't answered, the guide articles above go deeper.

Does the site store any of my information?

No. Everything happens in your browser. When you build a structure and download it, that file is assembled right on your own machine — your folder names, your settings, your project details are never uploaded, never sent to a server, and never stored anywhere on our end. There's no account to create and nothing to sign into. Close the tab and the only trace left is the files you chose to save.

Is this free? What does it cost?

It's free. The guide and the folder-structure builder are a free tool — read everything, build a structure tuned to your job, and download it, all at no cost and with no account or sign-up. Nothing here is paywalled, and nothing gets upsold at you.

It started as the system one working post-production shop actually uses, cleaned up enough to hand to someone else. Where it goes from here may change, but the core — the guide and the builder — is free to use today. If it saves you an afternoon of folder-wrangling, that's the whole point.

If it does save you that afternoon and you feel like buying the next coffee, there's a tip jar in the footer. Completely optional, never gated behind anything — it just helps keep the tool free and getting better.

How is this different from just using a folder template?

A template hands you empty folders and wishes you luck. But the folders were never the hard part — the hard part is the hundred small "where does this go, what do I call it" decisions you make on every job. Fileosophy answers those in advance and, more importantly, tells you why. Every folder explains what belongs in it, the naming grammar is built so files sort correctly and survive a move between machines, and nothing is arbitrary. An empty folder here is never a mystery — it's a labeled place waiting for the thing that goes there.

Do I have to use the whole structure?

No, and you shouldn't force it. It's a superset on purpose — more than most jobs need. Delete the branches that don't apply; that's a five-second, no-stakes edit. The one thing you never have to do is invent a folder mid-project at 2am. Build down from complete rather than up from empty.

What if I already have a system that works?

Then keep it — and steal the parts that help. Fileosophy is opinionated, but the opinions sit on a floor of plain best practices: name files so they sort, drop the spaces and special characters, stay consistent. That floor is portable — it makes any structure better, including yours. Adopt the whole thing, take one idea, or just tighten how you name files. All three are wins.

Can I rename things or change the numbering?

Once it's downloaded, the files are yours — rename, renumber, prune, whatever fits your shop. The structure is an opinionated starting point with the reasoning attached, not a rulebook. The guide explains why each choice was made, so when you change something, you're doing it on purpose instead of by accident.

Which apps or software does it work with?

Any of them. The structure is software-agnostic — it doesn't care whether you cut in Premiere, Resolve, or Final Cut, paint in Photoshop, or light in Blender. It's about where your files live, not which tools make them. There are a few optional spots for app-specific things like presets if you want them, but nothing about the structure is tied to a particular piece of software.

Do I need to install or run anything?

No. It's a website. You build the structure you want, download it as a set of empty folders, and unzip it wherever your project lives — local drive, NAS, cloud. There's nothing to install, no command line, no dependencies. And if the tree is simple enough that you'd rather recreate it by hand, the guide shows you the whole thing, so you can.

Does it work across different computers, teams, and shared drives?

Yes on all counts. It's just folders, so it lives anywhere — a Mac, a PC, a NAS, a synced cloud drive — and moves cleanly between them. That portability is deliberate: the naming conventions (no spaces, no special characters, consistent case, numbers that sort) are chosen specifically to survive the trip between machines and operating systems. For a team, that's the whole point — everyone works from the same map, so there's no debate about where a file goes, and no three-people-invent-three-different-"exports"-folders drift.

Is this only for post-production?

That's where it's most complete today, but the ideas underneath — sort by what a thing is, make every folder explain itself, name files so they sort and survive — apply to anything that ends up as a folder someone has to open later. More workflows are on the way.

How do I get help, or share a structure I've built?

There's a community Discord — the link's in the footer. It's the best place to ask a question, float an idea, flag something broken, or show off a structure you've tuned for your own kind of work. Worth being straight with you: this is a small, mostly one-person project, so the Discord isn't a staffed support desk — it's a room of people solving the same problems, and often another creator will have your answer faster than I would. The more everyone shares what's worked for them, the sharper the whole thing gets for the next person.