A digital life insurer sells dozens of products, each with its own policy document, each running to pages of conditions that differ from the others in small but decisive ways. That knowledge lives in two places today: the PDFs themselves, and the heads of the agents who have read enough of them to answer fast. Whichever channel a customer picks, phone, chat, the branch app, ends up rebuilding that knowledge separately, so the same question can get a different answer depending on where it was asked.
This case puts the whole product line into one knowledge graph instead, a single workspace holding every policy, and reaches it through a Consilience API. Any channel that can make an API call, a phone system, a chat widget, an internal tool, asks the same graph the same way and gets the answer back with the clause it rests on attached. One brain behind every channel, instead of one copy of the knowledge per channel.
The material: product policies across separate records
The company sells many products, and every product is a separate policy document, dozens of pages long, with its own conditions. None of that is wrong or badly organized. The problem is that it exists as separate files, and nothing today lets a phone system, a chat tool, and a human agent all draw on the same understanding of it at once.
- One policy document per product, each dozens of pages, each with its own wording
- A product line varied enough that which condition applies to which product is a real question, not a lookup
- A customer information system, where a customer's age, history and situation already live
- Several channels a customer can use to ask a question: a phone call, a chat window, a branch visit
- No single system today that all of those channels can ask, so each one ends up doing its own version of the lookup
Every channel solves the same question on its own
A phone agent gets a question, searches their memory, and opens a PDF if they are not sure. A chat tool, if the company has one, runs on a separate script that someone wrote by hand and has to remember to update. A new agent has read fewer of the policies than a veteran, so the same question gets a thinner answer depending on who is on the line.
None of these are talking to each other. If the policy changes, someone has to update the PDF, retrain the phone agents, and rewrite the chat script separately, and there is no guarantee all three happen in step. The customer experience depends on which door they walked through.
Prepare policy records for API access
The setup happens once, centrally, not per channel. Every product's policy document goes into one Consilience workspace, and the workspace is built into a knowledge graph. From there, the Consilience API is what every channel talks to, not the workspace directly.
Getting the whole product line behind one API
Load every policy document into one workspace
All of it, every product, goes into the same place. The original files are not rewritten, only read.
Build the knowledge graph
The workspace reads the policy text and works out the concepts in it, the conditions, the exclusions, the coverage limits, and how they connect to each other and to specific products.
Put the Consilience API in front of the graph
This is the piece that makes it usable by more than one channel. A phone system, a chat tool, or an internal app sends a question to the API and gets back an answer grounded in the graph, not a separate copy of the knowledge.
Point every channel at the same API
The phone system, the chat widget and the branch app all call the same endpoint. If the underlying policy changes, updating the graph once updates the answer everywhere that calls it.
Policy questions from different customer channels
On a phone call, the customer asks: "If I sign up now, am I covered in a case like this?"
→ The phone system sends the question to the Consilience API.
The API finds the relevant policy in the graph and answers,
with the clause the answer rests on attached and cited.
The agent reads the clause back to the customer, live.
The same customer, later, asks the same thing in the chat widget on the website.
→ The chat tool calls the same API, against the same graph.
The answer comes back the same way, because it is the same
graph on the other end, not a second copy of the knowledge.
"Which of our products fit a customer with this profile?"
→ The API can also take the customer's details and return a
shortlist with the coverage differences laid out, for whichever
channel asked to present to the customer.This works because the knowledge only exists once. The graph is built from the policy documents a single time, and every channel is a caller to the same API, not a separate implementation. That is also why an update to one policy does not require updating three different systems by hand.
The human agent's role does not disappear. The API answers the lookup and hands the agent the citation to read out or check, but choosing a product, closing a sale, and handling the parts of the conversation that need judgment stay with a person.
One graph, one API, and every channel that calls it says the same thing.
What changes
| Before | Now |
|---|---|
| Each channel, phone script, chat tool, agent training, holds its own copy of the policy knowledge | One knowledge graph holds it once, and every channel reaches it through the same Consilience API |
| A phone agent has to find the clause and then re-verify where it came from before quoting it | The API returns the clause together with the answer, with a citation, so nothing has to be looked up twice |
| The same question can get a different answer depending on which channel, or which agent, picked it up | The answer comes from the same graph no matter which channel called the API |
| Updating a policy means updating the PDF, the phone training and the chat script separately | Updating the graph once changes the answer everywhere the API is called |
What we have right now is a direction worth testing, not a proven result. The next step is connecting one real channel, most likely the phone system, to a live product line this way, and seeing whether the answers hold up.
Try this workflow with your documents
Learn the steps behind this workflow, then try them with your own sources.
Open the lesson ↗