[ 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.
[ knowledge graph × insurance ]
Insurance policies become individual advice.
Insurance is a thicket: products and providers are manifold, and what a person needs and wants to cover is individual. Fitting advice is therefore time-consuming for the broker, especially as an independent broker with a huge portfolio of insurance providers. The answer: policies and product documents are imported, a knowledge graph links life situation and product world, and prospective policyholders receive the insurance product that fits their situation. The broker closes the deal.
Take knowledge in
Scattered policies, product sheets, and websites become one structured knowledge base, cleanly separated per broker.
A graph, not a filing cabinet
The knowledge graph connects life situation and product: a homeowner needs different coverage than a young family. That turns hits into advice.
A website from knowledge
Visitors find an advisory journey that adapts to their question: instead of hunting for the product, they are shown the one that fits.
Advice with citations
Prospects build trust because every answer shows its source, and the broker takes over prepared, qualified inquiries.
[ 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 a knowledge graph: a web of terms and their relationships that gives the knowledge the logic of the insurance trade, from customer group through product group to the individual product.
That is exactly what the knowledge graph delivers: it connects life situation and product world. A homeowner needs household and life insurance; a young family brings a heightened need for security. From the entire knowledge, an advisory landing page emerges that adapts to the visitor: instead of hunting for a product, they are shown the one that fits.
The result: a folder of policies becomes, without editorial effort, an advisory journey that carries visitors from first interest to a qualified inquiry. The broker closes, with full knowledge of the needs.
[ 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 goes through these stages.
[ Understand ]
Recognize 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 knowledge graph 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 knowledge graph 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, and the entire interaction with the advisory journey is available to the broker: they know the interest and the needs before the first conversation. After double-opt-in confirmation, the inquiry moves through the pipeline, from lead to close.
[ architecture ]
From document to individualized advice
A knowledge graph structures the knowledge, and the engine room 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, a dedicated search index per tenant.
Alongside it, the knowledge graph: its own graph database per tenant, with a language model extracting entities and relationships, queried by anchor and neighborhood. Both worlds merge into one shared context, an approach known as GraphRAG.
The real value of the graph: it connects what no text places side by side. A homeowner needs household and life insurance. Semantic search only finds such connections when they are spelled out, and they never are.
Business logic
Customer groups, product groups, products, phrased openly
The starting vocabulary: two customer groups, thirty product groups, fifty-five product names, from private liability to wind-farm coverage. Deliberately open: new terms are allowed, and when in doubt the label is Undefined rather than a wrong assignment.
Four parallel language-model perspectives describe each topic cluster. That becomes the three-level information architecture: firm rules, clean addresses, no duplicates.
The core lesson: this web of terms, technically an ontology, is faster to adapt as an instruction for the language model than any database schema. The structure stays alive.
Delivery & sales
Content on demand instead of one-size-fits-all
The core is content on demand: a static website tries to satisfy everyone, stays abstract, and reaches nobody fully. Here it is the other way around: the prospect's search query is known, and a page emerges from it, cut to their situation.
A citation rule applies throughout: every answer quotes its source. What the documents do not support is not claimed but honestly declined, with an offer to make contact. That is where trust comes from.
The goal of the journey: qualify, and prepare the lead for closing. Inquiries land in the sales cockpit with their origin and the entire interaction, so the broker knows the needs before picking up the phone.
[ lessons ]
The quality of the advice came from the knowledge graph.
The most important lesson: the strength and quality of the advice only came with the knowledge graph. Semantic search finds passages that match a liability policy, but not what is connected to it: that liability and home contents coverage bundled together earn a discount at insurer A, and that the living situation needs clarifying first. Across the variety of the data, search could not deliver such connections; the web of terms and relationships could.
The price is compute: the route through the graph takes longer, because extraction and enrichment run hybrid. And what the knowledge graph returns ends up inside the language model, because the model needs all relevant connections to prepare the content of the advisory journey. Structure and language model work together; neither replaces the other.
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
3 levels
in the knowledge graph: from customer group through product group to the individual product, open to new terms
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.