From a Raw File to Structured Content
When a document is uploaded, it first lands in a private, access-controlled storage location that belongs to your tenant and no one else. Nothing is processed in place on your machine and nothing is left in a shared space; the file is moved into a permanent, namespaced location that only your tenant's processing can reach. From there the real work begins, which is turning a raw file into content the platform can reason over.
A PDF, a Word file, or a scanned page is not text in any usable sense until it has been parsed. The platform sends the document to a parsing stage that extracts the page text, produces a clean structured rendering of the content, and inventories any images embedded in the pages. Tables get special handling, because a table rendered as raw grid characters retrieves badly against a natural-language question, so tabular content is converted into readable prose that preserves the meaning of the rows and columns. This parsing step is where a document stops being a picture of information and becomes information.
The images in a document get their own screening, because most of them are not worth keeping. A vision check looks at every embedded image and decides whether it is a technical diagram, chart, or schematic that carries real content, or a logo, header, or piece of decoration that carries none. The decorative images are discarded so they never pollute later search results, and the technical ones are kept and carried forward. We do this so that a later question about a wiring detail returns the wiring detail, not a company logo that happened to share the page.
Classifying by What the Document is, Not What Someone Typed
Once the content is clean, the platform classifies the document by type, and it does this from the content itself rather than from whatever label a person selected at upload. This choice is deliberate, because people mislabel files constantly under deadline, a change order gets uploaded as a submittal, a geotech report gets dropped in as a generic drawing, and if the system trusted those labels it would inherit every one of those mistakes. By classifying from the actual content, the platform routes each document to the right place based on what it truly contains.
The classifier also reports how confident it is. When the document is a clear case, it is accepted automatically; when it is ambiguous, it is flagged for a human to confirm rather than being silently forced into a category that might be wrong. This matters because a misfiled document is worse than a missing one, since it produces confident answers from the wrong source. Surfacing the uncertain cases, instead of hiding them, is part of what makes the downstream answers trustworthy.
A Stable Identity, So a Revision Replaces Cleanly
Every document is bound to a stable identity when it enters the system, and every piece of it inherits a deterministic identity derived from that anchor. This sounds like plumbing, and it is the single most important thing standing between you and a corrupted knowledge base. Bid documents get revised constantly, and a platform that treated each re-upload as a brand-new file would slowly fill with duplicate and conflicting versions, so that a question about a spec might return the answer from Revision A and the answer from Revision B with no way to tell which governs.
Because identity is stable and deterministic, re-processing the same document produces the same internal identities every time, and replacing a document is a clean operation rather than an accumulation. When a revised version comes in, the platform removes the prior version's derived data across every store it touches before the new version takes its place, and it does this as an all-or-nothing operation, so a half-replaced document cannot exist. We build it this way so that you can upload Revision B of a subcontract and trust that the old answers are gone, not lingering in a corner of the index waiting to contradict the new ones.
Built to Fail Loudly, Not Silently
Through all of these steps, the platform reports status openly and refuses to paper over problems. A document moves through visible states as it is parsed, classified, split into retrievable pieces, and stored, and if something goes wrong at any stage, the failure is recorded with the stage and the reason rather than being swallowed. Required configuration that is missing causes a loud stop, not a quiet default, because a system that guesses when it is misconfigured is a system that ingests bad data without telling anyone. This preference for failing loudly is a trust decision as much as an engineering one. A visible failure you can act on is far cheaper than a silent success that was actually wrong.
What This Does Not Do
Faithful ingestion cannot rescue a document that was unreadable to begin with. A badly scanned page, a photograph of a page taken at an angle, or a corrupt export will still produce degraded content, and while the platform will flag its low confidence rather than pretend otherwise, it cannot invent detail that the source never legibly contained. The system tells you when it is unsure, which is the honest behavior, and a human still has to decide whether a marginal scan needs to be re-captured. Ingestion makes a good document usable and a bad document visible; it does not turn a bad document into a good one.
The hardest document in any bid package to read this way is the one that carries most of its meaning in pictures rather than words, which is the engineering drawing. A drawing defeats ordinary text extraction almost completely, and getting it right takes a different approach entirely. That is the subject of the next article.
Follow us on Axion for weekly technical insight.