What happens when an LLM can use both enterprise facts and enterprise knowledge?
By this point, Metrolane has two important foundations.
Structured enterprise knowledge:
and document knowledge:
EKA — the Enterprise Knowledge Assistant — is one solution built on top of those foundations.
EKA is not Metrolane itself
Metrolane is the enterprise environment.
EKA is a consumer of that environment.
+
consumed by
produces
Two kinds of context
A useful enterprise question may need structured facts.
It may also need document knowledge.
EKA can eventually bring those together.
Warranty claim + policy
- claim status = REJECTED
- claim reason = bracket bent after a kerb strike
- policy reference = WP-EXT-36
- decision = REJECTED
The document estate includes the retrieval-ready policy.
Candidate teaching question:
Why was warranty claim WCL-2026-000002 rejected, and what policy applies to it?
RAG in enterprise terms
A simple RAG diagram often looks like:
question → retrieve chunks → LLM
For enterprise use, the real shape is richer.
reader identity / access context
LLM reasoning
sources / provenance
The retrieval layer should not ignore enterprise access or context simply because a text chunk has high semantic similarity.
Semantic Search vs EKA
The first is a retrieval experience.
The second is an LLM-driven solution.
Current architecture boundary
The current Metrolane estate already has reusable structured-read and document-retrieval foundations.
The final EKA design still needs to freeze details such as:
The Guide should not invent those details before the EKA architecture is finalized.
Access must survive the AI layer
If a normal Enterprise Reader cannot retrieve an HR document, EKA must not use that same document simply because the LLM would find it useful.
Access-aware grounding
Under different reader contexts, the visible retrieval universe changes.
This does not yet demonstrate a final EKA answer UI. It demonstrates the grounding boundary EKA must respect.
Structured + unstructured grounding
Structured + unstructured grounding
The eventual EKA architecture should be able to distinguish:
- facts asserted in canonical data
- facts asserted in source data
- retrieved document passages
- scenario/read-model context
- provenance
The LLM should reason over those inputs without silently collapsing their authority.
For example:
The final answer experience should make those distinctions understandable.
Chapter takeaway
- EKA is one LLM-driven solution built over Metrolane.
- It can combine structured enterprise context with governed document retrieval.
- Semantic Search retrieves.
- EKA reasons over enterprise and retrieval context.
- Access and provenance must survive the LLM layer.