[ Ingest ]
Read documents and websites
Product sheets and terms are uploaded, existing websites are crawled automatically. Everything is split into knowledge blocks along the document structure and stored in a dedicated index per tenant.
[ graphrag × insurance ]
Insurance documents become an advisory journey.
Insurance knowledge lives in documents: terms and conditions, product sheets, benefit catalogues. This platform ingests such documents and entire websites, structures the knowledge along a business ontology of the insurance trade, and automatically generates a complete advisory website from it: with cited answers in conversation and a sales cockpit for handing over to the broker. This page shows how the system is built, which decisions stand behind it, and what was learned along the way.
Take knowledge in
Documents and websites flow into a search index and a knowledge graph, cleanly separated per tenant.
Ontology, not filing
A business ontology of customer groups, product groups, and product names structures the knowledge, open to new terms.
A website from knowledge
Navigation, pages, and copy emerge automatically from the ontology, all the way to a finished advisory website.
Advice with citations
Every answer in conversation cites its source. If the knowledge falls short, the system says so honestly.
[ structure beats search ]
Search hits are not advice.
Full-text search finds passages. Advice needs more: Who is asking, a private customer or a business? Which product is this about, and how does it relate to the others? That context comes not from search but from structure: a business ontology that orders the knowledge along the logic of the insurance trade, from customer group through product group to the individual product.
The most surprising lesson of this project: the most effective ontology ended up living not in the graph database but in the prompts. A knowledge graph was built and tested, Neo4j with its own database per tenant. The biggest lever, though, was the ontology phrased as instructions for the language model: it classifies every topic cluster and builds the site's complete information architecture from it.
The result: a folder of documents becomes, without editorial effort, an advisory journey that carries visitors from first interest to a qualified inquiry.
[ from document to advice ]
From upload to the broker handover
The platform is one continuous journey: documents go in at the front, and a structured website, cited answers, and qualified inquiries come out at the back. The knowledge passes through these stations.
[ Understand ]
Recognise topics
The knowledge blocks are clustered into topics. Four parallel language-model perspectives describe each topic: a title, the customer group, the product group, and the product name.
[ Structure ]
The ontology sorts
Every topic gets its place in the hierarchy: customer group, product group, product. The taxonomy is deliberately open: if no known term fits, the system coins a realistic new one instead of filing wrongly.
[ Generate ]
The website builds itself
The ontology yields the three-level navigation, plus pages in three archetypes: landing, overview, product. Copy with local context, images with attribution. The result is a finished, deployable website.
[ Advise ]
Answers with evidence
Visitors ask their questions in conversation. Answers come strictly from the stored documents, every statement cited with its source. If the knowledge gives no answer, an honest refusal follows, with an offer to make contact.
[ Hand over ]
Inquiries into the cockpit
Contact inquiries carry their page of origin: the broker sees which product someone is interested in before the first conversation. After double-opt-in confirmation, the inquiry moves through the pipeline, from lead to close.
[ architecture ]
Three layers, from document to website
The same principle applies here: keep the layers strictly separate. The knowledge foundation ingests documents and keeps every tenant apart, the ontology layer structures the knowledge, and the delivery layer turns it into website, advice, and sales.
Knowledge foundation
Search index and knowledge graph, separated per tenant
Documents and crawled websites run through queues into processing: split along the document structure, multilingual embeddings, stored in a dedicated search index per tenant. Nothing mixes between clients.
In parallel, a knowledge-graph path was built: Neo4j Enterprise with its own database per tenant, a language model extracts entities and relationships from the texts, queried via full-text anchors and neighbourhood search, with the results of both worlds merged into one shared context.
The honest lesson: for this content, the lighter route via topic clusters and the ontology carried further in the end. The graph remains the expansion path for questions that hop across several relationships.
Business ontology
Customer groups, product groups, products, phrased openly
The starting vocabulary: two customer groups, thirty product groups, fifty-five product names from the insurance trade, from private liability to wind-farm cover. Deliberately open: realistic new terms are allowed, and in doubt the label is Undefined rather than a wrong assignment.
Four parallel language-model perspectives describe each topic cluster. The results become the three-level information architecture: a navigation with firm rules, clean addresses, and no duplicates.
The core lesson: an ontology in prompts iterates faster than any database schema. Change the vocabulary, rerun, done. The structure stays alive instead of freezing into a schema.
Delivery & sales
Generated website, cited answers, lead cockpit
Three page archetypes cover the journey: landing page, overview, product page. The copy carries local context for regional visibility, images arrive automatically with attribution, and the result ships as a fast static website.
Conversation runs under a citation rule: every answer quotes its source as a numbered document. What the documents do not support is not claimed but honestly declined, with an offer to make contact.
Inquiries land in the sales cockpit with their page of origin: first the double-opt-in confirmation, then the pipeline from lead through contact and appointment to the broker closing.
[ lessons ]
The ontology ended up living in the prompts.
The GraphRAG path was built end to end: extraction, a graph database per tenant, anchor search, fusion with the search index. It worked in the demonstrator. Optimising cost and quality then showed: for this content, the lighter route via topic clusters and a prompt ontology delivered the better ratio. So the graph became the expansion path instead of the production path. Maturity, here too, means taking the simpler road when it carries.
Two disciplines proved themselves in particular. First, the citation rule: in an insurance context, a cited answer with an honest way out is worth more than a fluent guess. Second, provenance: an inquiry that knows which product page it came from is prequalified, because the broker knows the interest before the first conversation.
The platform came together in a good seven months with a small team: eleven services in one container network, deployed automatically, with an insurance partner as the pilot.
[ numbers ]
The platform in numbers
2 · 30 · 55
terms in the ontology's starting vocabulary: customer groups, product groups, product names, open to new ones
4
parallel language-model perspectives describe each topic: title, customer group, product group, product name
per tenant
a dedicated search index and a dedicated graph database: client knowledge never mixes
100%
of the answers in conversation carry a source citation, with an honest refusal when in doubt
[ technology ]
Technology in use
Neo4j
Elasticsearch
LangChain
OpenAI
Celery
Django
Neo4j
Elasticsearch
LangChain
OpenAI
Celery
Django
PostgreSQL
Redis
Gatsby
React
Docker
PostgreSQL
Redis
Gatsby
React
Docker
Put the potential of this technology to work.
Wondering how the knowledge in your documents could become structured advice? Then let's talk: you bring the challenge, I bring the experience and the tools.