Data first: the tool is the easy part
A model reads what it is handed, so the answer quality of every project, agent and GPT you build is decided before you open the chat window. If the right file was never filed, nothing you type will bring it back.

Retrieval only sees what it retrieves
A project does not give the model your files. It gives the model the passages from your files that best matched your question, copied into the request beside your prompt. Projects explains the mechanics, your documents at scale shows what happens when there are hundreds of them, and retrieval takes the machinery apart.
The consequence is blunt. A passage that is not in the project is not in the answer. A passage in a scanned image with no text layer is not in the answer. A passage in the third version of a document, when you uploaded the first, is in the answer and wrong.
- 1Where the file actually isA mailbox, a desktop, a share drive, a personal folder
- The only part the model can see
- 2What got uploadedWhatever someone remembered to attach, in whatever version they had
- 3What retrieval findsThe closest passages in what was uploaded, not in what exists
- 4What the draft saysConfident sentences built on that subset
What was never filed is invisible to every tool on this page.
The reality most staffs are living with
Ask five people for the same number and you get four answers and a shrug. The data exists. It is in a mailbox, on a desktop, on a share drive under a folder named after somebody who transferred in 2023, on an old site nobody can edit, and in a personal cloud folder that leaves with its owner. Subordinate units and detachments keep their own conventions, each reasonable, none the same.
That costs three things, and the third is the expensive one:
- The wrong numberA narrative built on last quarter's figure. It survives until somebody upstream compares it with theirs.
- LateThe product is not hard. Finding its inputs is. Two days of the week go to a scavenger hunt that repeats monthly.
- Nobody can check itIf the source cannot be pointed at, the reviewer can only judge the prose. The only real check is a second scavenger hunt.
Where files belong
The rule is short enough to put on a wall.
One home per data type. Manning data has one home. Product logs have one home. Equipment records have one home. Not one per department, not one per person, one per data type. A second copy is where the next disagreement comes from.
Names that a stranger can read. Type, subject, period, version, in that order, in the file name. manning-roll-up-2026-09-v2 sorts, filters and explains itself. FINAL_manning(2)_use_this_one does none of those things.
Versioning that has a rule, not a habit. One place holds the current version. Superseded versions move to an archive folder or leave. A project that holds three versions of one instruction will cite whichever one the retrieval liked best, and it will do it confidently.
The first line does the work. Title, date, version, owner, in the first line of the document. That line is what retrieval matches on and what a reviewer reads first.
How GenAI helps get the data into the right place
The filing is the work, but it is not work you have to do by hand.
- Classify and route by contentHand it a folder of untitled documents and the filing rules. It proposes a type, a destination and a name for each one, and a person approves the batch.
- Find duplicates and superseded versionsThree documents, one question: which is current, what changed between them, and which two should be archived. It quotes the lines that differ.
- Draft the folder READMEOne page per folder saying what belongs there, what does not, how files are named, and who owns it. Nobody enjoys writing these. It writes a good first one.
Two more that pay off monthly. Propose metadata: a table of every file with a suggested owner, period, product line and review date, which a human corrects once and then reuses. A weekly data readiness report: what arrived, what is missing, what is older than its review date, one page per department, sent to the department head and to whoever assembles the requirement.
Can the tool reach your files?
Sometimes, and it depends on your organization more than on the tool. The shape of it:
A connector reaches only what an administrator has switched on. Most work plans of ChatGPT, Gemini and Claude can connect to a drive, a mailbox or a document library, but on a work account an administrator decides which connectors exist and what they may read. Ask before you design anything around one.
A connector reads what it is allowed to see, not what is right. It will happily find the third version of a document and the stale copy in somebody's personal folder. Filing still decides the answer.
A script can do what a connector cannot. A short script with its own permission can read a library, pick the current files and send only those to the model. What is an API covers the calling side. The reading side usually needs your IT office to register the script and grant it the narrowest permission that works, which is a ticket, and often two.
Working together, as things stand
Sharing differs by tool and by plan, and it changes often. Some tools share a single chat by link, some share a whole project with named colleagues on a team plan, and some do not share projects at all (ChatGPT projects, Claude projects). Check your own plan before you count on it.
So the pattern that works everywhere has three parts, and none of them depend on a sharing feature:
- Shared files in one library home
- Shared instructions as four lines of text
- One named owner per project
Anyone can rebuild the project in five minutes from the files and the instruction text.
Working together covers the handover in practice. Where sharing is limited, a shop that already files this way can rebuild a project on any tool in minutes.
Vendor facts checked ; re-verify before relying on them.