Oridex makes that archive answerable inside your own infrastructure: every answer carries the document, version, clause and page it came from, no document leaves your infrastructure, and the first workflow is in production in four weeks.
The policy was underwritten in 2014. The wording sits in a scanned PDF. Two endorsements have amended it since, filed separately under a different reference. She needs the clause, the version in force on the date of loss, and some confidence that the colleague at the next desk would answer the same way.
She will get there. What she cannot produce is a record of how, and that gap is yours, not hers. It is the same gap that stretches every audit response. It lets two officers give two answers to one question, and stops the pilot at security review. One slow morning is a training issue. Ten thousand of them is an architecture decision, and it sits with you.
Not the model. Not the interface. The ten or twenty years of accumulated documents that every answer has to come from.
Large insurers can hold archives measured in tens or hundreds of terabytes. No context window holds it, and nobody is going to re-key it.
Scans, photographed forms, faxes, PDFs of PDFs, Word and Excel. The documents outlive every system that stored them.
Wording withdrawn for new business still governs the book written under it. There is no correct answer to a coverage question, only the answer for this policyholder, on this date.
Decisions are defensible in substance but not traceable in record. Reviews can cost days, and the reasoning is rebuilt from memory.
It stops in the same four places, and none of them are about the quality of the model.
Uploading claim files to a third-party cloud is not a question compliance answers with yes.
An assistant that reads what you paste cannot read what you hold.
Access to policyholder records needs to be attributable to the user and the action taken. If the retrieval layer cannot produce that record, the control breaks before the answer reaches the screen.
An answer with no source cannot be verified, so nobody downstream can act on it. The pilot demos well, then stops.
Every answer is generated only from documents you registered, and shows the document, version, clause and page it came from. The system shortens the search; your officer still makes the decision, and when the file is reviewed later, the reasoning is in the record instead of in someone’s memory.
Deployed on-premise or in your own cloud region, including fully offline, with the language models running inside your infrastructure. Documents are processed where they already sit. We build and own the platform, which is why running the whole of it inside your perimeter is a deployment option rather than a special project.
One workflow, one document set, one outcome you can measure, agreed in writing before the build. Not a proof of concept that ends as a slide.
Two products, and the honest answer is that one usually has to come before the other. Worth settling before anyone builds anything.
You need Oridex. A large archive, mostly scanned, many formats, accumulated over years across systems that no longer talk. The work is turning it into something that can be queried at all.
This is usually where the archive problem starts.You need Oriene AI. A defined, reasonably clean body of material, a precedent bank, a know-how library, a set of standard forms, and fee earners who need cited answers from it. When the material is already in good shape, Oriene runs on its own.
Smaller footprint, faster to stand up, and a sensible way to prove the approach on one practice group.Oridex prepares the archive for Oriene. When the archive is messy, Oridex gets the documents into a state Oriene can answer from; Oriene is the layer your lawyers actually use. Both can sit within the same deployment and access-control model.
Start with whichever half is blocking you. The other attaches later without rebuilding.The claims officer’s 2014 policy, and what comes back once the archive has been ingested. Nothing is re-keyed, and the scan never leaves your infrastructure.
The shape is simple. These are the parts that decide whether it survives contact with a real firm archive.
A typed policy schedule, a photographed claim form and a thirty-page loss adjuster report do not yield to the same extraction. Document types are routed to the approach that handles them, and that routing is configured per archive, not assumed.
For non-English archives we deploy recognition models for that language in place of general-purpose models tuned for English. We deployed this on the archive described below; it is not a locale setting.
Document read and write actions are recorded against a named user and retained to your policy. Retrieval respects the access rules mapped from your identity system, and the scope of that mapping is agreed per deployment.
Illustrative examples using sample data.
Your security team will ask what a record contains before anything else.
An insurance group in East Asia, holding more than ten years of policy, claims and legal records, several hundred terabytes, largely scanned, in a single non-English language, across PDF, scans and images, Word and Excel: product terms, claims procedures, internal rules, legal documents, and contracts negotiated individually with each policyholder.
They had already ruled out public cloud assistants, files could not leave, the volume did not fit, access could not be traced to a named employee, and without citations no answer could be relied on.
The group had no prior experience governing generative AI, and came to us asking for a chatbot. We advised against building one first. On that archive it would have failed the same way the public assistants had, so we built the document foundation underneath it instead.
Built to run fully offline inside the group’s own data centre, models, embeddings, database and processing, with no internet dependency
Recognition models for the archive’s own language deployed in place of general-purpose models tuned for English
Knowledge graph connecting product terms, claims procedures, internal rules, legal documents and individually negotiated contracts
Automatic document versioning and per-user access logging, built against the group’s obligations on personal data, information security, financial-advice standards, and human accountability for every answer
Two assistants specified on the same foundation: one for internal knowledge retrieval by staff, one for policyholder-facing Q&A, both designed to connect to the group’s CRM and HR systems
The output of that foundation is not a chatbot, it is a cleaned, AI-ready document base that other systems in the group can be built on. The two assistants were its first consumers, not the point of it.
DEHA Global built and handed over the platform and both assistant components against an agreed three-phase, six-month plan: a limited evaluation set with staff training first, then the internal assistant, then the policyholder-facing one. The customer is now rolling phases two and three out to its teams.
We do not publish performance figures for this deployment because we do not yet hold measured ones. The client and the delivery partner remain anonymous by agreement, the same discretion your own deployment would get. If you want a reference conversation, ask us and we will ask them.
Architecture, deployment, access controls, data handling, integrations and model options, the detail a third-party risk team asks for before anyone talks about price. It arrives in your inbox, not your calendar.
One email with the PDF. One follow-up. No newsletter.
Deployment options: on-premise, private cloud and fully offline, and what changes between them
The audit-log schema, retention, tamper-evidence and key custody
Data handling: sub-processors and DEHA Global access during delivery
Integration and model options: integration surface, AI-provider coverage and self-hosted models
Delivery model: scoping, support and the four-week implementation structure
You are not choosing between us and nothing. Three other options are on your table, and each is the right answer for someone. Here is where each one wins, and where we do not.
Some readers of this page are not insurers, they are integrators whose insurance clients have started asking for document AI, and who would rather deliver a platform than build one.
You remain the prime contractor and the face of the engagement; we supply the platform and the engineering behind it. This is how the deployment described above reached its end customer, through a partner, not directly. Delivery scope and commercial terms are agreed before the engagement starts.
Because Oridex is our own platform, not a resold API, its extraction, data model and deployment approach can be adapted to the client’s environment.
Including running entirely inside their environment where the client’s security review requires it.
Integration is where your margin lives, and we are not looking to take it. A delivery centre of around 200 engineers, appraised at CMMI Level 3 and certified to ISO/IEC 27001:2022, can support delivery within your engagement. You choose which parts to hand over.
We will tell you which of these two you are buying in the first conversation, not the third.
One process, one document set, one measure of success, agreed in writing before the build. A mutual NDA is in place before any document is shared.
Your sources connected, indexed and permission-mapped. An evaluation set built from real questions your team actually asks, so success is measured against your work rather than a benchmark.
Live for one team, in the agreed deployment environment, monitored, with a retraining cadence and a support response commitment from day one.
More document sets, more teams, more assistants, on the same foundation, without a second platform decision.
Four weeks is four weeks of someone’s time, and some of it is yours.
One business owner who can sign off the measure of success
A few days of an application owner to get one document set out of the system holding it; for older systems this is often the longest dependency
A read-only copy of that set, and your access-control list in whatever state it is actually in
An early decision on whether a privacy impact assessment runs in parallel or in front, on its own, it can outlast the build
Yes. Models, embeddings, database and processing can all run inside your own data centre with no external dependency. The deployment described above was built to run this way. If you connect an external model provider instead, that is a configuration choice you make, and the boundary of what it receives is agreed during design.
No, that is the point of the platform. Scans and images are ingested as-is, with OCR and layout analysis, and different document types are routed to the extraction approach that best suits them.
You check it. Every answer shows the document, version, clause and page it came from, and it is generated only from the documents you registered. The system shortens the search; your officer still makes the decision. We do not publish an accuracy percentage because a number without a stated measurement method is not worth anything to your risk function.
Documents are versioned automatically as they change, and the knowledge graph links a policy to the endorsements and product terms that govern it. That is what makes date-of-loss questions answerable rather than approximate.
No. Your documents are used only within your own deployment, never to train models shared with other clients.
Your team, or ours, on your infrastructure, the deployment model is your choice and it can change later. Support carries a response commitment from day one.
There is no list price, because the archive determines the work. We scope against your sources, your channels and your deployment model, and quote against that.
The technical overview answers most of what a security review asks, and it arrives without a conversation attached. When you want the conversation, it is with Brian Dang, CEO of DEHA Global, and the engineer who would run the deployment, bring one workflow and the questions your teams actually ask.
Delivering this to your own insurance clients? Say so when you write, partner terms are a separate conversation, held directly with Brian rather than through a sales process.
