Adding Context to LambdaDB Collections

Describe what your data is for, and keep its context with the Collection.

A Collection name identifies a dataset, but it rarely explains why it exists. Someone browsing a project may still need to know what the data covers, which application uses it, or which team maintains it.

LambdaDB Collection descriptions and metadata tags give that context a place alongside the data.

Describe the purpose and add labels

A description explains in plain language what the Collection contains and what it is intended to support. Metadata tags are string key-value labels for context you want to record consistently, such as a purpose, owning team, or ingestion pipeline.

In agentic search, an agent may need to choose among several Collections before running a query. When its tools expose descriptions and metadata tags, it can use that context to understand what each dataset covers and select Collections relevant to the task. For example, it could distinguish a server code index from an SDK code index or a product knowledge base.

Both are optional. A description can contain up to 255 characters, and a Collection can have up to five metadata tags. You can supply them when creating a Collection, and they are returned when you list or describe Collections.

These labels are distinct from immutable versioning Tags, which name and pin committed data snapshots. Collection metadata tags describe the resource; they do not preserve a data version.

Here is a metadata example for a code index. This shows only the description and tags fields, not a complete create request. The index ID and hash are illustrative.

{
  "description": "LambdaDB server code index for API contract and implementation investigations. Includes source, tests, docs, and build configuration.",
  "tags": {
    "purpose": "code-search-v1",
    "repository": "github.com/lambdadb/lambdadb",
    "index-id": "example-index-id",
    "config-hash": "0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef",
    "team": "search"
  }
}

Example: organizing code search

A code-search application could use one Collection per Git repository and index configuration, storing source files and searchable chunks together. The description would explain the repository, the index's purpose, and the scope of the indexed content.

In the example above, the application could use purpose=code-search-v1 to recognize its Collections, repository to identify the source, index-id to distinguish indexes, and config-hash to record the indexing configuration. The optional team=search label adds operational context.

A CLI or agent tool could list Collections across all result pages and inspect their metadata tags client-side. After identifying relevant Collections, it could read separate application control documents to verify full repository identity and retrieve detailed settings. This flow does not require server-side filtering by metadata tags.

These tag names and discovery steps are application conventions. LambdaDB stores and returns the metadata; the application defines its meaning and how to use it.

Descriptions and a few consistent labels can make Collections easier to understand without putting every detail in their names. The same approach can record a knowledge base's purpose, an owning team, or pipeline context, while detailed application state stays in dedicated records.