Filenames, keywords and the search you expect
A search result is useful only when you know what it matched. For local files, start with the filename and path, then open the source when the answer depends on its contents.
Separate finding a file from answering a question
Imagine an operations manager looking for the price quoted on an air handler last spring. A filename search can find 2026-04-air-handler-quote.pdf or a matching customer folder. It cannot, by that match alone, tell the manager which price was approved, whether the quote was revised, or what the customer ultimately paid. Those facts must be checked in the document and, where relevant, against the current business record.
The same distinction matters with inventory. Finding a spreadsheet named capacitor-stock.xlsx is a good first step; treating the filename as a live stock count would be a mistake. Search narrows the set of files to inspect. Reading, comparison, and confirmation answer the business question.
How deterministic matching helps
A deterministic search has a modest but valuable contract: the same indexed names, paths, filters, and query produce the same kind of match. You can explain why a result appeared. For example, searching AHU-42 might return a service folder because the code is in its path, and a quote because the code is in its filename. That evidence is visible without asking a language model to infer what the files mean.
This does not make a search index infallible. Renamed files, unavailable drives, permissions, stale entries, and copies with similar names can all change what is visible. A missing result is a reason to widen the query or check the location, not proof that the document never existed. A matching path is a lead, not proof that the file is the right version.
Older JE Horizon architecture writing used “Q-RAG” to describe ideas for grounded local retrieval, including document content, hashes, and generated answers. That is background about an architecture, not a statement that those capabilities ship in FilePerch or OmniHorizon today. The current FilePerch page describes searching filenames and keywords, reviewing matching paths, and working through storage plans. The current OmniHorizon page describes a Windows workspace for customers, stock, quotes, and invoices.
A repeatable retrieval workflow
Use a small sequence that leaves room to verify the result. It works for contracts, quotes, project handoffs, and ordinary personal files:
- Write down what you know. Start with a customer, project code, month, document type, or distinctive word. Avoid relying on a remembered sentence that may never have appeared in the filename.
- Search one stable term. A project code such as
AHU-42is usually more discriminating than “quote.” If the first search is empty, try a customer name or a shorter part of the code. - Inspect the path. Check the drive, customer folder, year, and whether the result lives in an archive or an active working folder. Similar filenames in different paths often represent different stages of work.
- Open likely candidates. Compare document dates, revision marks, signatures, and internal details. When a decision depends on a figure, read the figure in the source.
- Record the source of the answer. Include the filename, location, and date in a note or handoff. A coworker should be able to repeat the check without guessing which file you meant.
For a high-impact decision, such as sending a price to a customer, add a second check against the current quote or invoice workflow. Even a perfectly located old file may no longer be authoritative.
Make future searches easier before files accumulate
Good retrieval starts when a file is saved. A naming pattern such as customer-project-document-YYYY-MM-DD-revision gives each part a job. Use a real date and a revision label when a document can change. Keep the pattern short enough that people will actually follow it. A folder structure should answer a few predictable questions: who is this for, which project is it, and is this active or archived?
A weekly five-minute check can prevent a year of confusing duplicates. Look for final files still named “draft,” two “final” versions in different folders, and exports whose names lost the project identifier. If a file must be copied to another drive, confirm the copied version is readable and retain the original until your normal retention or backup process says otherwise. File organization is only part of recovery; it does not replace a backup.
What to ask of an AI answer
If a tool later offers content search or AI summaries, apply a stricter test than you would to a filename result. Can it identify the source file and the exact passage supporting each claim? Does it distinguish “no match found” from “the fact is absent”? Does it expose conflicting versions instead of silently choosing one? A hash can help detect whether bytes changed, but it cannot prove that the words in a document are true or that a generated interpretation is correct.
That standard is useful even without an AI feature. Search for the file, review its path, open it, and cite the specific source for the conclusion. It is a practical way to keep a convenient result from becoming an unsupported answer.