A correct answer needs more than the right document

“Which customers are affected by this supplier delay?”

It sounds like a simple question. To answer it properly you need open orders, supplier relationships, product mappings, contract commitments and customer identities, all lined up. Finding a document that mentions the supplier is where the work begins, not where it ends.

Picture a manufacturer that knows one supplier by three names. Purchasing uses a local account name. Finance uses the legal entity. Operations uses a short label everyone in the warehouse recognises. A search assistant can retrieve perfectly accurate documents for all three and still never realise they’re the same company. The answer comes back well cited and materially incomplete.

What a knowledge layer actually does

A knowledge layer is the governed context that connects your records, documents, definitions and relationships, reliably enough to answer a business question. A pile of files becomes useful when you can say which entity each one concerns, which version applies and which measures depend on it.

Several jobs sit underneath that. Entity resolution works out whether records describe the same real-world thing. Shared metric definitions explain how a measure is calculated. Lineage records where information came from and how it changed. Access rules decide who may use which parts. They’re related, and none of them substitutes for the others.

External identifiers help where they exist. GLEIF describes the Legal Entity Identifier as a code linked to reference data about legal entities. You still need a policy for the records that don’t have one, for local account structures and for parents and their subsidiaries.

Let uncertainty show

A good shared layer keeps ambiguity visible instead of smoothing it away. Two similar names don’t prove a match. An amended contract shouldn’t silently overwrite the original. A supplier relationship that was true last quarter may not apply to today’s order.

For our manufacturer, the useful answer separates confirmed exposure from possible exposure still awaiting review. That lets the operations lead act on what’s solid and assign someone to the rest.

The W3C’s provenance standards offer a model for exchanging information about how data was produced. Our business reading is straightforward: the explanation behind an answer should travel with it between systems, not live only in the head of whoever built the report.

Test the whole chain, not just the reply

Write test questions with deliberate traps. Ask about a customer with a parent company and several subsidiaries. Ask for a measure whose definition changed mid-year. Ask about a contract that has been amended. Ask the same question as two users with different permissions. You’re checking whether the system keeps its footing under ordinary enterprise complexity.

Then look underneath the answer. Did it use current information? Did a similar name cause a false match? Did it include anything the user isn’t allowed to see? Did it admit what it didn’t know? Answer quality belongs to the whole process, not to the language model alone.

Build enough context for one valuable question

You don’t have to map every relationship in the company before you see value. Pick a recurring decision. Identify the sources it needs and agree the definitions with their owners. Resolve the identities that matter, keep the lineage and test the permissions. Expand once that first decision works reliably.

That’s how Akashic is built: Data Pipelines, Master Data and Data Warehouse feed a governed knowledge layer that Business Intelligence, Ask Akashic and Machine Learning all draw on. For an executive, the point is continuity. The meaning and controls you establish for one question stay in place for the next.