> ## Documentation Index > Fetch the complete documentation index at: https://docs.usenexio.com/llms.txt > Use this file to discover all available pages before exploring further. # Indexing and extraction > Follow a document from your library to a cited, served record, understand what a connection's indexing profile decides, and know how the platform keeps invented numbers out. Indexing and extraction turn the files in a connected document library into typed records you can query. Each file is replicated, classified, read, and extracted into structured facts. Every numeric or coded fact carries the passage it was read from, quoted verbatim, and the page number when the source has page structure; when the fact was read from the document's text the platform checks that passage against that text. Anything that fails a trust check is flagged for [review](/connections/review). Indexing runs on document library connections (binding shape `materialize`). Nexio operates it for you. See [Connections and data](/connections/overview) for who does what. ## How it works 1. **Replicate.** The platform lists the library under the crawl roots, skips excluded paths, and copies each file into the platform object store. Copies are keyed by their content hash, so a file whose bytes did not change is not stored again. 2. **Classify.** The connection's [indexing profile](#indexing-profiles) maps each file to a document class from its folder path and file name. 3. **Read the text.** The file's text is read and stored. A PDF with too little text in its text layer is sent to the model as the document itself instead. 4. **Extract.** The extraction pass the profile routes the class to reads the stored text and returns typed facts. Each numeric or coded fact carries its verbatim passage, and a page number when the source has page structure. 5. **Check the passage.** For a fact read from stored text, the platform confirms that its quoted passage appears in that text, ignoring spacing and symbol differences. A passage that is not found triggers one re-extraction; if it is still not found, the fact is flagged for review. 6. **Second reading on high-stakes fields.** For a class whose route names a verifier model, a second, different model reads the same text for the pass's high-stakes fields. A disagreement raises a review flag. It never corrects a value automatically. 7. **Locate the passage.** Where it can, the platform finds the passage's rectangle on the page from the document's own word geometry. A model never supplies coordinates. 8. **Project to served records.** Facts are projected into [served records](/connections/served-data) with any reviewer corrections applied on top. 9. **Flag.** Anything that fails a check becomes a review item with a plain question and the actions allowed for it. See [Review](/connections/review). ## Indexing profiles An indexing profile is the configuration that decides, for one connection, how each document is classified and which extraction pass reads it. It holds: | Part | What it decides | | ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Classification rules | Folder path tokens and file name tokens, each mapped to a document class. A folder rule can be marked as a fallback, used only when no file name rule names a more specific class. | | One route per document class | The extraction pass that reads the class, the model that runs the pass, and optionally a verifier model for the second reading. The verifier must be a different model from the extractor. | What a profile can and cannot change: * **Stored per connection.** A profile is stored as an immutable, numbered version bound to one connection, and one version is active at a time. Saving a new version deactivates the previous one. The connection's Structure page in the portal shows the active profile, or the built-in one, and the stored version history. * **A built-in profile.** A connection with no stored profile uses the built-in profile. Nexio ships one built-in profile. * **Classes and passes are fixed in code.** The set of document classes a profile can route, the set of extraction passes it can select, and the record families each pass serves are fixed in the platform. A profile must route every class, may select only a known pass, and may name only models in Nexio's model registry. A profile selects among these; it does not supply prompts, code, new classes, new passes or new record families. Adding any of them is a Nexio release. * **Operated by Nexio.** Nexio stores and changes profiles. There is no public API or portal control for editing one. ## Kinds of extraction pass Every pass is one of three kinds: | Kind | What it does | | ------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Typed pass | Reads one document class and returns typed facts with their quoted passages, which are projected into that pass's record families. | | Identification pass (`dark_document`) | Reads a document whose class has no typed pass of its own. A model identifies the document. One it identifies as a typed class with confidence of at least 0.8 is sent to that class's pass, unless an earlier version of the same file already serves records; anything else is recorded and flagged for review. | | Metadata only (`metadata_only`) | Keeps a low-value file on record. No model call. The file appears in the document listing only. | ## When a document changes or disappears * **A changed file** is re-read and re-extracted. The new extraction supersedes the old one. Served records are effective-dated: the prior version is closed with an end date and the new version opens. Nothing is deleted. * **A removed file** is de-indexed: the file is marked removed at source and the current served records traced to it are closed, so reads stop serving them. Some record families are not closed by that step; which ones is fixed in code for each document profile. The closed records and the last extraction are kept as history. Records from other documents stay current. See [Served data](/connections/served-data#why-a-field-is-null) for `provenance.source_removed_at`. * **A mass disappearance** does not de-index your served data. A pass that would de-index more than 5 documents and more than 20 percent of the known documents is parked for an operator. The same limit holds for new and changed documents. See [Sync health](/connections/sync-health). ## How long until a change shows up The platform checks every active document library connection every hour, queues new and changed files for extraction, and de-indexes removed ones. Served-data reads are cached for up to 30 seconds. A change in your library is served after the next hourly check finds it and the document is re-extracted. [Sync health](/connections/sync-health) defines the freshness target and what the portal shows when it is missed. ## What you can check yourself `GET /api/v1/catalog/funnel` returns the live count at each stage, from source documents to served rows, with the definition behind each count and the reasons documents were excluded. How flagged facts are verified and what each action changes. Read the served records and their citations.