Skip to main content
open-index init <name> scaffolds a brain directory; then you author two kinds of file — doc_types (schemas) and entities (instances).

1. Define a doc_type

A doc_type is a concept plus its schema — one YAML file in doc_types/:
doc_types/service.yaml
  • boost sets per-field search weight — a hit in a boost: 6 title outranks a boost: 1 description hit 6-to-1. Optional; defaults to 1.
  • relationships declares the edge vocabulary so correlations are discoverable (shown in the UI + navigation guide) and lightly validated (right target type). Optional — entities may still use undeclared meanings.
Create one with open-index add-doc-type service (writes a stub you edit), or ask your agent.

2. Add entities

An entity is one instance. For storage: file types, write one JSON per entity under entities/<doc_type>/:
entities/service/checkout.json
  • id must be <doc_type>:<slug>.
  • related_to is the reserved correlation field present on every entity — it defines the graph edges (target + relationship_edge_meaning). This is how you say “this ticket is about that service” without any graph database.
Then load and validate:

3. Explore

open-index ui opens a read-only explorer. The sidebar always shows every doc_type with its count and storage policy, so the structure is visible without navigating anywhere. Four tabs:
Search + browse + drill into an entity’s relationships.
Auto-anchored on the most-connected entities — click any node to expand it.
What context CLI/MCP/UI clients fetched, and how often. Zero-result searches show what to model next.
Connectors and their schedules.

Next

Populate at scale

Manual, bulk import, connectors, and agent write-back.

Tune search

Field search kinds, boosts, and semantic weighting.