Indexing and extraction

​

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 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 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.

​

Indexing profiles

• 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

​

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 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.

​

How long until a change shows up

​

What you can check yourself