Indexes

Xenocept configures one AeorDB index group on first boot: a set of indexes over the /sessions/ tree. They power the Sessions list view’s fuzzy-search box. Outside of that group, there are no other Xenocept-managed indexes today.

The Real Index Config

The config lives at /sessions/.aeordb-config/indexes.json:

{
  "glob": "*/session.json",
  "indexes": [
    { "name": "id", "type": ["string", "trigram"] },
    { "name": "created_at", "type": "string" },
    { "name": "comment_text", "type": "trigram", "source": ["comments", "", "text"] },
    { "name": "bubble_text", "type": "trigram", "source": ["bubbles", "", "text"] },
    { "name": "text_text", "type": "trigram", "source": ["texts", "", "text"] },
    { "name": "ocr_text", "type": "trigram" },
    { "name": "alternative_description", "type": "trigram" }
  ]
}

glob: "*/session.json" tells AeorDB to apply the indexes to every session.json file under /sessions/.

Each "source": [field, "", subfield] entry is a fan-out path: one indexed entry per array element. For comment_text, that means every comment’s text is indexed individually rather than as a single concatenated blob.

Xenocept writes this config on startup and only re-writes it if the contents differ from the desired shape. AeorDB picks up changes and rebuilds the affected indexes in the background.

Notes on the Schema

• id has both "string" and "trigram" index types — supports both exact lookup and trigram fuzzy-search on the timestamp string.
• created_at is a "string" index, not a typed timestamp index. AeorDB supports range queries on string indexes lexicographically — and since created_at is ISO 8601 UTC, lexicographic order is also chronological order.
• The OCR / AI enrichment fields (ocr_text, alternative_description) are populated asynchronously by plugins after Submit (e.g., a Gemini OCR plugin via POST /api/v1/sessions/{id}/ocr-text and /enrich). If you submit a session and search immediately, those fields may not be populated yet.

Trigram Fuzzy Search

The Sessions search UI uses GET /api/v1/sessions/search?q=..., which delegates to AeorDB’s global_search across the /sessions/ tree.

AeorDB’s trigram index extracts every contiguous 3-character substring from indexed text. A query string is decomposed the same way; matches are scored by trigram overlap. Practical consequences:

• Substring matches work ("drop" matches "dropdown").
• Typo tolerance works to a degree ("dropdwn" matches "dropdown" with reduced score).
• Very short queries (1-2 characters) won’t produce trigrams and so won’t match anything via the trigram path.

For the exact AeorDB query JSON shape (operators like eq, contains, similar, fuzzy, phonetic, match, plus the and/or/not combinators), see the AeorDB querying docs. Xenocept’s HTTP surface doesn’t expose raw AeorDB queries to callers — the search endpoint takes a single q string and runs it through global_search.