> Source: https://wexa.ai/docs/context/overview

# Context

A project holds four stores: the context graph for entities and how they connect, the knowledge base for prose found by meaning, the data catalog for data that lives outside Wexa, and the project ontology for what kinds of thing may exist. Each tool checks its own grant, named on its page.

Start with the store whose question matches yours.

- [context-graph](/docs/context/context-graph): Save and read entities and relationships.
- [knowledge-base](/docs/context/knowledge-base): Documents found by tag and meaning.
- [code-sync](/docs/context/code-sync): Keep a repository in the code graph.
- [ingestion](/docs/context/ingestion): Bring a connected source in.
- [save-context](/docs/context/save-context): Save nodes and relationships.
- [query-context](/docs/context/query-context): Run read-only Cypher.
- [delete-context](/docs/context/delete-context): Delete nodes and relationships.
- [graph-stats](/docs/context/graph-stats): Counts of the graph.
- [graph-subgraph](/docs/context/graph-subgraph): A bounded part of the graph.
- [create-ontology](/docs/context/create-ontology): Define node and relationship types.
- [knowledge-base-add](/docs/context/knowledge-base-add): Add a document.
- [knowledge-base-retrieve](/docs/context/knowledge-base-retrieve): Retrieve documents by tag.
- [delete-kb-document](/docs/context/delete-kb-document): Delete documents by tag.
- [search-code](/docs/context/search-code): Search ingested code.
- [fetch-code](/docs/context/fetch-code): Fetch one code span.
- [code-sync-api](/docs/context/code-sync-api): The code sync routes.
- [connector-read](/docs/context/connector-read): Read source rows live.

**Choose between the four stores**

### Where your data goes

A project holds four stores, and each has exactly one property that no other has, which is the fastest way to tell them apart and the way this page is organized.

You need no credential to read this page. Each store has its own tools, and each tool checks its own grant, listed on its reference page. Read this page before you save anything, because nothing fails when you choose the wrong store. The cost arrives later, as a question none of your stores can answer.

#### How the four stores differ

1. **Look at the shape of your question.** The four stores are not interchangeable, even though all four can loosely be called "where the information is".
2. **If the answer depends on connection**, use the [context graph](/docs/context/context-graph).
3. **If the answer is in prose you want found by meaning**, use the [knowledge base](/docs/context/knowledge-base).
4. **If you want to know whether to trust a table that lives elsewhere**, use the [data catalog](/docs/context/create-ontology).
5. **If you are describing what kinds of thing may exist**, use the [project ontology](/docs/context/create-ontology).

| Store | Question it answers | Only store that | Console |
|---|---|---|---|
| [Context graph](/docs/context/context-graph) | What is connected to what? | You query by traversing relationships | **Context Graph** |
| [Knowledge base](/docs/context/knowledge-base) | What did we write about this? | Holds unstructured prose | **Knowledge Bases** |
| [Data catalog](/docs/context/create-ontology) | Where did this table come from? | Describes data that lives outside Wexa | **Data Sources**, **Lineage** |
| [Project ontology](/docs/context/create-ontology) | What kinds of thing may exist? | Describes the shape of another store | **Ontology** |

The console names are entries in the sidebar. Knowledge Bases, Lineage and Ontology show only to roles that can curate context.

#### Decide whether a question belongs in the context graph

**What it stores.** The nodes and relationships describing your project's world: its entities and how they relate. A customer, an order, a repository, a person, and the edges between them.

**What it is good at.** Questions whose answer depends on connection. Which customer an order belongs to, which services depend on the one you are about to change, who touched a record and in what order. It is the only store that can answer a question of that shape at all.

**What it is wrong for.** Long prose that you want answered approximately. You can put a paragraph on a node, but nothing will search it by meaning, and a differently phrased question will not find it.

It is also wrong for describing a warehouse table. You would model a copy of something the data catalog already tracks properly, and the copy goes stale.

#### Decide whether a document belongs in the knowledge base

**What it stores.** Documents and passages, held for retrieval by meaning rather than by exact match.

**What it is good at.** Getting a grounded answer out of writing nobody wants to read in full, such as policies, runbooks, specifications, support transcripts and past decisions. You ask in your own words and get back the passages that are about it, whether or not they use your wording.

**What it is wrong for.** Anything where approximate is not good enough. A retrieved passage is evidence, not a lookup. The current credit limit for one customer belongs in the context graph, where there is exactly one of it.

It is also wrong for facts you will want to traverse. A passage saying two systems are connected cannot be walked from one to the other.

#### Decide whether a table belongs in the data catalog

**What it stores.** The inventory of your data assets, meaning tables, columns and dashboards, with their lineage, quality scorecards and ownership. It holds a description of data that lives *outside* Wexa, and not the data itself.

**What it is good at.** Deciding whether to trust something before you use it. Where a table came from, what fed it, who owns it and what its quality judgement says. That question arrives just before someone builds a report on a number they have never questioned.

**What it is wrong for.** The rows. Cataloguing an asset does not copy its contents into Wexa, so you will have a faithful description of data you still cannot read. It is also wrong for entities born inside Wexa that live nowhere else. Those are context.

#### Decide whether a type belongs in the project ontology

**What it stores.** Your project's vocabulary of node and relationship types, layered over the platform schema that every project shares.

**What it is good at.** Saying what *kinds* of thing may exist. It governs what can appear in the context graph, and holds no content of its own.

**What it is wrong for.** Anything with an instance. You never put a customer in the project ontology. You put the *type* `Customer` there, and the customer in the context graph. If you add a type for a single real thing, the type belongs to the vocabulary and the thing belongs in the context graph.

#### Put a procurement policy where people can ask about it

A 40-page procurement policy that people keep asking questions about belongs in **the knowledge base**. It is prose, and the questions will be phrased in a hundred ways the document never was.

In the context graph you get a long string on a node nobody can search. In the data catalog you have described a document you still cannot read.

#### Answer a question about connection

"Which customer does this order belong to, and which agent last touched it?" belongs in **the context graph**. The question is entirely about connection, and traversal is the only way to answer it.

That is two hops across two relationships. No amount of similarity search produces this answer, because the answer is not written down anywhere as a sentence.

#### Check a warehouse table before you build a report

A warehouse table your team is about to build a report on belongs in **the data catalog**. You want its lineage, its owner and its quality scorecard, the things that tell you whether the number is safe to publish.

The table stays where it is, and the catalog describes it. If you also want agents to reason about that table as an entity in your world, that relationship is context, and the two records coexist.

#### Add a kind of thing that does not exist yet

"We now track Contracts, and a Contract renews a Subscription, and neither type exists yet" belongs in **the project ontology**. You are describing what kinds of thing may exist, which none of the other three stores do.

Add the types first. The individual contracts then go into the context graph as nodes of that type.

#### Store something that belongs in two places

Some material legitimately lands in two places, which does not mean you chose wrongly. A support transcript is prose, so it belongs in the knowledge base. The customer, the product and the escalation it mentions are entities, so they belong in the context graph.

Do not copy the same thing into both and expect them to stay in step. Store each part where its questions will be asked.

#### Limits and behavior of the four stores

| Behavior | Detail |
|---|---|
| Interchangeability | None. Each store has one property no other has. |
| Wrong choice | Nothing fails at the moment you make it. The cost arrives later. |
| Catalog and rows | Cataloguing an asset does not copy its rows into Wexa. |
| Ontology and instances | The ontology holds types. Instances go in the context graph. |
| Duplicated content | Copies in two stores do not stay in step. |
| Governance | Policy decisions, approvals, audit and quota apply identically across all four. |

The stores are separate because they are governed the same way and queried differently. A query does one thing well instead of four things approximately. You get the difference where it helps, and none of it where it does not.