Technical Capabilities · Knowledge Architecture

Understanding the company, not searching its documents.

Knowledge Architecture answers the question that separates a useful system from a search box: how does the system understand this company, rather than merely retrieve text that mentions it?

Role in the system

Retrieval finds passages. An ontology knows what they are.

A company’s important facts are relationships, not documents. A customer belongs to an account, which has an owner, a contract, a payment history and a service record, each held in a different system and each true only for a period of time. Searching for a name returns mentions of it. Answering an owner’s question requires knowing what the name refers to and what it is connected to.

This category builds that structure: a company-specific model of the entities and relationships that matter, the retrieval machinery to find evidence about them, and the rules that decide which source is authoritative when two of them disagree.

What this category addresses

From a pile of records to an answerable question.

How the capabilities relate

The ontology and relationship mapping define the shape. Structured and unstructured knowledge describe what fills it. Semantic, lexical and hybrid retrieval are three ways of finding evidence inside it — kept as separate pages because they fail differently and are chosen deliberately. Context construction assembles the result. Historical and temporal state answers questions about the past correctly rather than describing the present and calling it history. Source authority and knowledge provenance decide, and then show, why one answer won.

Capture of chronology and lineage happens earlier, in Data. This category is where they are reasoned with.

Capabilities
The other categories