What EKA is
EKA stands for Enterprise Knowledge Assistant. It is a read-only conversational intelligence layer over the live Metrolane enterprise.
This is not a generic AI-assistant page. It is a guided walkthrough of the real EKA implementation.
This chapter is the same at every reader level — it records no run anatomy to reveal.
A question goes through a governed runtime, not a search box
user question ↓ EKA understands the request ↓ EKA creates a governed plan ↓ approved tools read authorized enterprise evidence ↓ EKA evaluates what the evidence establishes ↓ EKA produces a grounded answer
EKA is not the enterprise itself.
Metrolane
Enterprise data, systems, documents, relationships and history.
EKA
An LLM-driven consumer of those governed enterprise foundations.
EKA is not just chat over data
question → search → send text to model → answer
question → interpret → plan → validate → authorize → execute governed reads → normalize evidence → resolve required features → calculate deterministically where needed → synthesize → validate citations → answer
The LLM proposes. The runtime validates. Governed tools execute.
The LLM is important, but it is not given unrestricted database access.
Each reader level adds to the one before it. The reader control in the header sets how much run anatomy the worked examples show; a visitor does not need every technical detail to follow an example.
Business reader
- what EKA is
- what enterprise questions it can answer
- why it does not simply guess
- why an answer can be COMPLETE, PARTIAL or UNAVAILABLE
- how it separates facts from explanations
Product / AI reader
- LLM planning
- tool use
- structured enterprise reads
- document retrieval
- authority
- evidence
- feature resolution
- citations
- conversation state
Technical reader
- planner inputs
- validated plan
- registered tools
- subject registry
- access decisions
- evidence types
- calculation policy
- result states
- contract versions
- prompt provenance
- run metadata
Every worked example in chapters 05 to 09 follows the same order, so the same run anatomy is visible each time.
plain-language idea → real EKA question → what EKA understood → what it was allowed to read → what it actually read → what the evidence established → what remained unknown → final answer → technical anatomy
The examples are based on EKA acceptance cases that were implemented and tested against Metrolane. The conversational UI now exists, and chapters 05–08 show it replaying these same runs, in screenshots and silent recordings.
Chapter takeaway
- EKA reads the live enterprise; it does not hold it.
- A governed runtime sits between the model and the data.
- The same run anatomy is shown for every example in this guide.