> ## Documentation Index
> Fetch the complete documentation index at: https://cortex-e852fafe-t3code-rewrite-docs-declutter.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Glossary

> The terms HydraDB uses across the docs, and the deprecated aliases you may still see.

Use this page when a term in a guide or API response is unfamiliar.

## Scope

### Database

A separate workspace for data, typically one per customer or environment. A
query searches only the database you specify.

### Collection

A named group of content *within* a database, typically one per end-user, team, or agent. Omit
it and HydraDB uses the database's default collection, which is created on the
first write. A query that names another collection does not read the default one.

See [Multi-tenancy](/essentials/v2/multi-tenant) for how scoping affects writes
and reads.

### Multi-tenancy

Serving several customers or users while keeping their data separate. Use
databases for separate customer workspaces and collections to organize data
within them. Your application chooses which each caller may access.

### ACL and principal

An access-control list (ACL) names who may retrieve a document. Each entry is a
principal: a user, group, or domain represented by a string. Queries must send
the caller's principals to enforce document permissions. See
[Access Control](/essentials/v2/access-control).

## Content

### Knowledge

Shared context your agents work from: documents, files, and content from apps.
See [Knowledge](/essentials/v2/knowledge).

### Memory

Information to remember between conversations: a preference, past exchange, or
saved fact. Your application chooses which user collection to store it in. See [Memories](/essentials/v2/memories).

### Source

One ingested item: a file, an app record, or a memory. Each source has an `id` you
use to check status, inspect, update, or delete it.

### App source

A record your app or connector already parsed, such as a Slack message or a Jira
ticket, sent with typed fields instead of as a file. See
[App Sources](/essentials/v2/app-sources).

### Chunk

A passage of a source, sized for retrieval. Queries return ranked chunks, and you
pass them to your model.

### Infer

A memory flag. With `infer: true`, HydraDB extracts the preference or fact from raw
input such as dialogue or event logs. With `infer: false` (the default), it stores
exactly what you send.

## Processing

### Ingestion

Sending content to HydraDB, through the ingest endpoint or a connector.

### Indexing

Processing content so it can be searched. It runs in the background after
ingestion; check the source status before querying newly added content.

### Entity

A named person, organization, service, or topic found in content. Entities are
connected by relationships in the context graph.

## Retrieval

### Retrieval

Finding relevant passages and source details for a question. Your model uses
these results to write an answer.

### Semantic search and embeddings

Semantic search matches by meaning rather than exact words. An embedding is
the numerical representation of text used to compare meanings.

### BM25

The keyword-ranking method HydraDB uses to score text by its matching words.

### RAG

Retrieval-augmented generation: search for relevant content, then include it in
a model's prompt so the answer can use that content.

### Reranking

Reordering search candidates by their relevance to the question.

### Hybrid search

The default `query_by` mode: matching by meaning and BM25 keyword matching,
blended by `alpha`. `query_by: "text"` uses BM25 alone. See
[Semantic Search](/essentials/v2/semantic-search).

### Fast, thinking, and auto

Query `mode` values. `fast` is one low-latency pass. `thinking` expands the query,
reranks, and pulls in forceful relations. `auto`, the default, picks one per query.

### Context graph

A record of the entities and relationships HydraDB extracts from content, returned with
query results as `graph_context`. See [Context Graphs](/essentials/v2/context-graphs).

### Graph traversal and hops

Following relationships between entities or stored items. One hop is one
connection; multi-hop traversal follows a chain of connections.

### Triplet

One edge of the context graph: a source entity, a relation, and a target entity,
such as "billing policy, governs, failed payment handling".

### Forceful relations

Links between sources that you declare at ingest with `relations`, for when two
sources belong together but their text does not say so. Returned in
`additional_context` in thinking mode.

## Deprecated aliases

`database` and `collection` were previously called `tenant_id` and
`sub_tenant_id`. Wherever you meet an old name (a request field, a route, a
webhook payload), it is a deprecated alias, and it keeps working. A request that
sends both names with different values is rejected with `400`.

<Warning>
  One exception: in the **indexing webhook payload**, `tenant_id` and `database` do
  NOT carry the same value. `database` is the name you ingested into; `tenant_id` is
  an identifier for it. Everywhere else (request fields, routes, query
  parameters), they remain interchangeable. See
  [Webhooks](/essentials/v2/webhooks#payload).
</Warning>

| Deprecated | Canonical |
| - | - |
| `tenant_id` | `database` |
| `sub_tenant_id` | `collection` |
| `sub_tenant_ids` | `collections` |
| `/tenants/…` routes | `/databases/…` routes |

Prefer the canonical names in new integrations. See
[Multi-tenancy](/essentials/v2/multi-tenant#7-migrating-from-the-legacy-tenant-and-sub-tenant-fields)
for the full compatibility contract.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.