Why record a service and folder name instead of a filesystem path?

Because a path differs between Windows and Mac and between two people on the same platform, since it usually contains a user name. It also breaks on a reinstall or a new laptop. A service name and a folder name stay true across all of those and can be acted on over the phone.

Is it acceptable to write "unknown" in a file location record?

Yes. `unknown` and `scattered` are legitimate answers for any kind of file. Write what is true rather than a guess made to fill the field. An honest unknown points at work that needs doing. A confident wrong entry gets believed and never questioned again.

Why does an integration report a file as missing when it exists?

Most often because the connection is bound to a different account than the one holding the file, so every "not found" means "not visible from here". Before writing through any integration that targets a specific account, read back which account it is bound to, because a write to the wrong one returns success.

Are external drives covered by normal backup software?

Not by default. Time based backup software excludes external drives unless someone changes the setting. In one case the only copy of a deleted tree of 50,803 files sat on a single external drive with no second copy. If a drive is your archive, confirm what is watching it.

How do you stop a file location record from going stale?

You do not stop it, you catch it. A weekly fifteen minute pass spot checks a few lines, updates the last checked date, and picks up new kinds of files that appeared since. One file read weekly beats a thousand scattered references that break silently and are never read at all.

Library

Where do your business files really live?

Brett K Moore4 August 20268 min readChoosing guide

Written for agents, brokers, lenders, contractors, home services.

The short answer

Most agents, lenders and contractors cannot say where a given kind of file lives, because nobody ever wrote it down. Every new file goes wherever the person was standing.

The fix is one file. It records where each kind of thing lives, by service name and folder name, and it never records a filesystem path.

A path differs between Windows and Mac, and between two people on the same platform. A service name and a folder name do not.

The record holds no copies and syncs nothing. It tells you where to look and where a new file of that kind should go.

It goes stale and nothing pretends otherwise. A weekly pass is what catches a renamed folder or a swapped drive. One file read weekly beats a thousand scattered references that break silently.

Ask an agent where the signed disclosures from a closing three years ago are and the answer comes back fast, because those live in the transaction system and always have. Ask the same agent where the listing photos for that property are and it takes longer. Ask about the headshot on the flyer, the version of the contract that got redlined by email, or the walkthrough video shot on a phone, and the answer becomes a sentence with the word "somewhere" in it.

This is not disorganization in the usual sense. Every one of those files got saved deliberately, into a place that made sense at the time. The problem is that nobody wrote down which kind of thing goes where, so the rule lives in one person's head and changes depending on which device they had open.

What is a file location record?

A file location record is a single document listing every kind of file your business produces and naming, by service and folder, where that kind is kept. It holds no copies of anything and it syncs nothing. It exists so a person can find a file later and know where a new file of that kind should go.

The important word is "kind". An index of files is a full time job and it is wrong within a week. This is an index of categories: signed contracts, listing photos, headshots, walkthrough video, call recordings, bids, invoices, permits, inspection reports.

For each kind there is one line naming the service and the folder inside it. In most businesses the whole thing fits on one page and takes about forty minutes to write the first time.

Why service and folder names, and never a path

This is the decision the whole thing rests on. A filesystem path is the string your computer shows in a title bar or a properties window. It is precise about a machine rather than about a business. The same cloud folder has a different path on Windows than on Mac, and a different path for you than for your transaction coordinator on the same platform, because the path contains a user name. It changes on a reinstall or a new laptop.

Service and folder names survive all of that. "Listing photos live in the cloud drive under a folder named Listings, one subfolder per address" is true on any machine, readable by a new assistant on day one, still true after a laptop swap, and usable by somebody over the phone.

What an audit turns up

An audit on 2026-08-12 of one working machine found four separate cloud drive accounts signed in at the same time. One of the four appeared in no record anywhere. Nobody had written it down, and it was doing something.

Only one of the four was locally cached, meaning only one had its contents present on the disk rather than living behind a network call. Reads against the other three failed. They failed on a 175 byte file as readily as on a 6 megabyte one, which rules out size and bandwidth and points at access.

That is a normal finding rather than an unusual one. Four accounts arrive on a machine over time in the ordinary course of business. One personal, one from a brokerage or franchise, one shared by a title company for a single transaction and never removed, one created during a software trial. Nobody decided to run four. They accumulated.

The failure that looks exactly like success

Why does a tool say a file is not found when the file exists?

Usually because the connection is bound to a different account than the one holding the file. Every "not found" result then means "not visible to a tool pointed at somebody else's account", and nothing in the message says so.

We hit this directly. A connector was bound to the wrong account and every result it returned read as an absence. Nothing had gone missing. The tool was looking where the files had never been.

The rule that came out of it: before writing through any integration that targets a specific account, read back which account it is bound to. A write to the wrong account looks exactly like success. You get a confirmation, an identifier, a green check. The file is real, it exists, and it is in somebody else's drive.

This matters more for writes than reads. A read against the wrong account wastes ten minutes. A write puts a signed disclosure or a borrower document somewhere you did not intend and cannot see.

The related trap: knowing where a file lives is not the same as being able to open it. Some services have no programmatic route at all, so no assistant, script or integration can reach them regardless of what your record says. A plain external drive on a desk usually has none. A record naming a location tells humans where to look and promises nothing about software.

The backup finding, which is the one that should worry you

In the same period we found that the only copy of a deleted tree of 50,803 files sat on a single external drive, with no second copy anywhere.

The reason that is common rather than careless: time based backup software excludes external drives by default. People buy an external drive precisely because it is the backup, move the archive onto it, and reasonably assume the backup system now covers it. The drive holding your safety copy is the one thing your safety system is not watching.

In this trade that means listing photo archives, walkthrough video, drone footage, job site photo sets and old transaction folders. Large files, moved off the laptop because they filled it, now in one place with one copy. If the drive fails, nine years of work fails with it.

The location record does not fix that. It makes the condition visible, because once each kind of file has a named home, a home with one copy stands out on the page.

Writing the record: what goes in each line

01The kind of file, named the way your business names it. "Signed disclosures", "listing photos", "change orders", "borrower income docs", "permit sets". Use your own words rather than a filing taxonomy.
02The service. The transaction system, the cloud drive, the email account, the photo library, the external drive, the phone. Name it the way somebody would say it out loud.
03The folder inside that service, by name. If there is a per-property or per-job convention, describe the convention in one sentence.
04Whether there is a second copy. One word. This is the line that surfaces the external drive problem.
05Who else can reach it. The coordinator, the assistant, nobody. This tells you whether a file is a business asset or a personal one.
06The date somebody last opened the service and confirmed it. Not the date the line was written.

Six short fields, one line per kind of file. A solo agent finishes in half an hour. A contractor with crews and a bookkeeper takes an afternoon, because the answer to field five is more interesting.

A worked example

PAD is People, Assets, Deals: three folders of text files on your own computer plus one operating file telling an AI assistant how to work inside them. The location record is a single file under Assets, and these rules govern everything around it.

Small, high value files sit beside the record they belong to. A signed disclosure, a one page contract, a scanned form. These are the files whose pointer rots when they live elsewhere, so they live in the folder of the person or deal they concern.
Large media stays in whatever system already holds it, and the record names that system. Listing photo sets, walkthrough video, call recordings. Nothing is copied or mirrored.
No folder tree ever mirrors another one. A second tree shaped like the first recreates the exact question this was meant to end, which is which half holds this.
The location record answers "where does this kind of thing go". By service and folder. Read weekly.

One honest cost, because people find it out at the worst moment. Text in a system like this is usually versioned, so a mangled or deleted text file comes back. A photograph or a PDF sitting beside its record is on disk and typically outside version control. Delete one by accident and the recovery route is your own laptop backup. Say that out loud to whoever else touches the files.

The record goes stale, and the weekly pass is the answer

A folder gets renamed. An app gets switched. A drive gets swapped. Somebody leaves and their account gets closed with a shared folder inside it. Nothing in the record knows about any of that until something checks. We do not claim otherwise, and we would be suspicious of anyone who did.

What makes it workable is a weekly pass: somebody opens the record, checks a handful of lines against reality, and updates the dates. Fifteen minutes. It never catches everything, and it catches the changes that happened this month.

The argument for one file, plainly: one file that gets read weekly beats a thousand scattered references that break silently and are never read at all. A broken link inside an old email is invisible forever. A wrong line in a document somebody opens every Monday gets fixed in week two.

The four boxes

The four box sort applied to a file location record. What is there and should be, what is missing and should be there, what is there and should go, and what is missing for good reason.

There, and should be

One document naming, by service and folder, where each kind of file is kept, with a last checked date.

Service and folder names survive platform changes, staff changes and machine changes. That is the entire reason for the format.
`unknown` and `scattered` stay valid answers permanently. They describe real conditions and they point at the work.
A last checked date on each line separates this from a document that quietly stopped being true in March.

Missing, and should be there

A weekly pass, a second copy for anything living on one drive, and an account check before any integration writes.

The weekly pass is fifteen minutes and it is the only thing standing between this record and every other document nobody opens.
Anything whose only copy is an external drive needs a second home, because time based backup software excludes external drives by default.
Before writing through a connector, read back which account it is bound to. A write to the wrong account returns success.

There, and should not be

Filesystem paths, duplicated folder trees, and cloud accounts nobody can account for.

A path in a shared document is wrong for at least one person reading it and usually more.
A second folder tree shaped like the first is the two-folder design this approach exists to avoid, rebuilt one level down and carrying the same drift.
An audit on 2026-08-12 found four cloud drive accounts on one machine and one appeared in no record anywhere. An account nobody can explain is a place files go to be lost.

Missing, and correctly missing

The record holds no filesystem paths and no copies of anything it names. Both absences are deliberate.

No paths, because a path is a fact about one machine and this record has to be true for everyone reading it. The cost: no software can follow a line straight to a file. A human opens the service and looks.
No copies, because a copy is a second version that goes stale without announcing it, and two answers to one question is what this exercise exists to end. The cost: the record can be accurate while the file behind it is unreachable or deleted.
Both costs are accepted on purpose. A record pointing at copies would need syncing, and a syncing record is a system to maintain rather than a page to read.

How often should the file location record be checked?

Weekly, in a fifteen minute pass that spot checks a few lines and updates their dates. Anything less frequent and the record drifts far enough that people stop trusting it, and a record nobody trusts is worse than none because it still gets quoted.

The weekly pass has a second job beyond correcting lines. It is when new kinds of files get noticed. A business that starts shooting drone video in April has a new category by May, and it will live wherever the first one landed unless something asks.

If the pass keeps finding nothing, lengthen it to monthly and say so in the record. If it keeps finding wrong lines, something upstream is moving faster than the record, which is worth understanding on its own.

What this does not do

Our summary: one page, service and folder names, honest unknowns, a date on every line, fifteen minutes a week. The value shows up the first time somebody who is not you needs a file on a Friday afternoon and finds it without calling anyone.

Common questions

What is a file location record?: A single document listing each kind of file a business produces and naming, by service and folder, where that kind is kept. It is an index of categories rather than of files. It holds no copies and syncs nothing, and its job is to tell a person where to look and where a new file of that kind should go.
Why record a service and folder name instead of a filesystem path?: Because a path differs between Windows and Mac and between two people on the same platform, since it usually contains a user name. It also breaks on a reinstall or a new laptop. A service name and a folder name stay true across all of those and can be acted on over the phone.
Is it acceptable to write "unknown" in a file location record?: Yes. `unknown` and `scattered` are legitimate answers for any kind of file. Write what is true rather than a guess made to fill the field. An honest unknown points at work that needs doing. A confident wrong entry gets believed and never questioned again.
Why does an integration report a file as missing when it exists?: Most often because the connection is bound to a different account than the one holding the file, so every "not found" means "not visible from here". Before writing through any integration that targets a specific account, read back which account it is bound to, because a write to the wrong one returns success.
Are external drives covered by normal backup software?: Not by default. Time based backup software excludes external drives unless someone changes the setting. In one case the only copy of a deleted tree of 50,803 files sat on a single external drive with no second copy. If a drive is your archive, confirm what is watching it.
How do you stop a file location record from going stale?: You do not stop it, you catch it. A weekly fifteen minute pass spot checks a few lines, updates the last checked date, and picks up new kinds of files that appeared since. One file read weekly beats a thousand scattered references that break silently and are never read at all.

Worth passing along

This serves the broker or team leader and the contractor running crews, because both have other people creating files under their name and both carry the consequence when one cannot be produced. The broker version is a transaction file somebody needs during a compliance review. The contractor version is a change order the homeowner disputes. Same page, same fifteen minutes, two very different bad Fridays avoided.

Written by Brett K Moore. We build the PAD System, a records structure for people, assets and deals that lives as plain text files on your own computer. Read what it is.

Reach us directly

Follow us