Deploy, scale & operate InsightXtract

InsightXtract is a self-hosted, container-native platform. Everything — the API, the console, the agentic extraction workers, the datastore, and the vector index — ships as containers you run inside your own network. Nothing leaves your boundary unless you point it at a hosted model, and even the model is your choice.

Architecture at a glance

InsightXtract is a small number of stateless services around a metadata database, an object store, and a vector index. The services scale horizontally; state lives in managed data services you already trust.

Components

Clouds & models — bring your own

Each pluggable dependency has a native option on every major cloud. Set a few environment variables and InsightXtract uses the managed service you already run.

Models are provider-agnostic: point the API at Anthropic Claude (direct or via Bedrock/Vertex), OpenAI (direct or Azure OpenAI), or any custom/self-hosted OpenAI-compatible endpoint. The extraction agents are written against a provider interface, so switching is a config change, not a rebuild.

Configuration reference (core)

Every deployment is driven by environment variables. These are the essentials; the deployment guides list the full set.

Document understanding & models

Two layers do the reading, and both are pluggable. The document layer turns a page into text, structure and geometry — where every value sits, which label owns it, and which box is ticked. The reasoning layer decides what those values mean. Keeping them separate is why the same agent configuration runs unchanged on a different cloud, and why an air-gapped deployment is a configuration rather than a fork.

Document layer — OCR & form understanding

A submission is not prose. A quarter of a typical application is tick boxes, and the printed text of a question lists every option whether or not it is selected — so text alone cannot answer it. The document layer returns selection state, key/value pairing and bounding boxes, which is what makes a checkbox answerable and a citation clickable.

The agent asks the document layer for what it needs rather than receiving a fixed parcel: the whole page, one page again, a search across the submission, a worksheet as rows, or the form’s key/value pairs. Engines are selected per document class, so a scanned loss run and a digital exposure workbook in the same submission take different paths.

Reasoning layer — bring your own model

Model choice is a deployment decision, not a product one. The provider interface is narrow — text, vision, document, and tool-calling — so a model is swapped by configuration and the extraction agents, schemas and rules are untouched.

Models are chosen per task, not per deployment: a small fast model for the structural pass and classification, a stronger one for extraction, and an optional escalation model that is only reached when the first attempt cannot return usable output. Every call records the model, token counts and cost against the run.

Domain models — fine-tuned insurance SLMs

A generalist model has to be told what a retention is, what an ACORD 125 contains, and which of five names on a loss run is the claimant. A model fine-tuned on your own policies, forms and claim notes has absorbed it. InsightXtract serves both, and chooses between them per task rather than per deployment — because the tasks in a run are not alike.

Set per document class, so a line of business is tuned without touching a schema:

ai_configuration:
  perception_model:  insightdlm/pc-7b        # domain SLM, in-VPC, no egress
  classifier_model:  insightdlm/pc-7b        # domain SLM
  extraction_model:  bedrock/claude-sonnet   # frontier
  escalation_model:  bedrock/claude-opus     # only on failure

That is the common pattern: the high-volume, well-bounded work runs on a small domain model inside your network, and a frontier model is reached for the hard remainder. Escalation is measured, not assumed — every call records which model answered, what it cost, and whether it was a first attempt or a retry, so the split between the two is a number you can see rather than a claim.

Domain models are served over any OpenAI-compatible endpoint — vLLM, SGLang, TGI or a managed deployment — so a model trained with InsightDLM on your own corpus is reached by pointing a base URL at it. Nothing about the agents, glossaries or post-processing rules changes; the model is a setting.

Deployment topologies

Extraction configuration

The settings above stand the platform up. These decide how it reads — and they are set per document class in the console, not in code, so an underwriting team can tune a line of business without a release. Defaults below are the ones we ship; where a default looks conservative, it is because measuring the alternative changed our mind.

How a document is read

What gets verified

Both of these can only ever empty a field, so both ship off. A blank is recoverable; a confident wrong number is not.

What gets computed

Anything derivable from data already extracted should be computed, not read. Repeatedly, a field description telling a model that two figures are different did not stop it copying one into the other — counting the rows did. Fourteen rule kinds run after extraction:

Spreadsheets

Submission workbooks open with a title banner, so the header is rarely row 1, and one logical schedule is often split across regional tabs. EXCEL_CODEGEN (on by default) reasons about each sheet’s layout, writes code against what it finds, and caches that reader by sheet shape — so a workbook seen before is read by the same code every time, which is what makes two uploads of one file give one answer.

Everything is versioned

Each setting above lives in the document class or agent configuration, is versioned with it, and is visible in the run trace alongside the value it produced. A record shows not only what was extracted but which rules touched it — which is the difference between an answer and an auditable one.

Ask a folder — chat over a submission or a claim

Extraction answers the questions you knew to ask. An underwriter looking at a new submission, or an adjuster opening a first notice of loss, also has the other kind — is there a prior act exclusion in here, who signed the application and when, what did the broker actually say about the tower. Point at a folder in Drive, press Ask, and put those questions to the documents directly.

Prepared once, then cheap

Preparing a folder is deterministic reading — no model is called — so it takes seconds and its only cost is OCR, paid once and stored. The digest then sits in the cached part of the prompt, ahead of the question. That placement is the whole cost story: with the folder behind the cache point, a question is a couple of pence; in front of it, the same question re-sends the entire folder as fresh input every time and costs roughly ten times more.

It will not answer without a quote

Every factual claim comes back with the verbatim words it rests on, the file, and the page. If the documents do not state something, the answer says exactly that rather than inferring a figure or filling the gap from general knowledge of insurance. An underwriter acting on a confident, unsupported sentence is the failure the whole platform exists to avoid.

Where the folder has already been extracted, questions the audited record answers are served from that record — instantly, at no cost, and in agreement with the record by construction. Re-reading the PDF to answer them again risks producing a different number than the one already reviewed, which is worse than not answering at all.

Citations you can open

A citation an underwriter cannot check is a claim, not evidence. Click one and the document opens at the page with the quoted words boxed. The rectangle comes from the document’s own word geometry — the quote is matched back against the page, never plotted from coordinates a model invented. Scanned pages are highlighted from the OCR geometry captured at prepare time. Where the exact words cannot be located, the page still opens and the viewer says so; a highlight over the wrong paragraph is worse than no highlight.

Tables, charts, and where to go next

When a comparison is the point — losses by policy year, expenses by function, revenue against expenses across years — the answer carries a chart alongside the prose, and every number in it is cited like any other figure. Longer answers come back as a table rather than a paragraph of pipes. Each answer also offers two or three follow-ups that this folder can actually answer, grounded in what was read rather than in what a question generator imagined.

Where the documents live

Nothing has to be uploaded anywhere new. A folder is whatever your storage location already points at — the same connectors extraction runs against, so a submission mailbox, a broker’s SharePoint site, or a bucket in your own account is askable the moment it is registered.

It answers with the permissions of whoever asked

Chat is not a back door round your document security. The folder is reached through the same registered location and the same credentials the rest of the platform uses, and the question runs under the asking user’s role — admin, builder, operator, reviewer or viewer. Someone who cannot open a folder in Drive cannot ask questions of it either, and a quote can only cite a document that user is entitled to read. Every question, the documents it read, and the answer it gave are recorded against the user, so “who asked what of this claim file” is answerable after the fact.

The same chat from your own applications

Everything the console does here is a REST call, so an underwriting workstation, a claims desktop, or an internal insights tool can offer the same interactive exploration inside its own screens — including the tables and charts, which come back as data rather than as pictures, ready to render in your own component library.

Calls authenticate with a scoped API key, and usage is tracked per key, so an embedded assistant in another product is metered and governed like any other consumer of the platform.

Settings