Roadmap

Where indx is headed, from the MVP through v1.0 and beyond.

Treat the dates and phases as indicative direction, not commitments. They help you plan, but priorities shift as the project and its community grow.

As of 2026-06-06

Today is 2026-06-06. The “quarter hints” below are relative and may move. For the canonical, always-current state of any feature, check the GitHub repository and the rest of this documentation.

The three phases at a glance

Phase	Theme	Headline scope
Phase 1 — MVP	End-to-end, cloud default + local profile	The six-stage pipeline, core data model + .indx, cloud-backed model defaults, local / air-gapped profile, the CLI commands, the SDK
Phase 2 — v1.0	Breadth + rigor	Full slot matrix, advanced Relate/Enrich, indx.toml + reproducibility manifest, performance hardening, published benchmark
Phase 3 — Beyond	Living knowledge	Incremental/watch-mode re-indexing, richer relation inference, cross-space linking, community adapter ecosystem

Phase 1 — MVP (now → next quarter)

The MVP delivers the full thesis end to end: a directory becomes a portable knowledge space in one command.

The shipped defaults are cloud-backed and require OPENAI_API_KEY. The local profile and the zero-dependency core path keep it fully offline when you need that.

• End-to-end pipeline running all six stages: Walk → Parse → Chunk → Relate (basic) → Enrich (basic) → Embed+Pack. “Basic” Relate covers sibling, parent, and continues. “Basic” Enrich covers topics, tags, and summaries.
• Core data model: KnowledgeSpace, Document, Chunk, and Relation, with .indx serialization. See the data-model reference.
• The default stack and local profile. Defaults use parser=docling, llm=openai:gpt-5-mini, embedder=openai:text-embedding-3-small (dim 1536), store=qdrant, and output=.indx. The local profile uses llm=ollama:qwen2.5, embedder=bge-m3 (dim 1024), plus the same local-capable store and output path. Switching profiles changes the embedding dimension, and therefore the dim recorded in the manifest.
• The CLI commands, plus component flags and per-stage progress/summary: indx <dir> --out <dir>, indx inspect <archive.indx>, indx query <archive.indx> "<text>", and indx demo (a zero-config offline walkthrough that builds, inspects, and queries a bundled sample corpus). See the CLI reference.
• The SDK: DirectoryPipeline, first-class access to the model objects and their graph, load/save of .indx, and custom slot registration. See the SDK reference.
• A documented fully-local / air-gapped path. See the air-gapped guide.

Offline from day one (opt-in)

The shipped defaults are cloud-backed and need OPENAI_API_KEY, but offline is a first-class path. Opt into the local profile with pip install "indx[local]". Or use the zero-dependency fallbacks shipped in core (plaintext parser, hash embedder, jsonl store, none VLM, .indx + jsonl writers) for a complete run with no network egress. See Bring Your Own Stack.

Phase 2 — v1.0 (following ~2 quarters)

v1.0 broadens the swappable slots and adds the rigor that production and regulated users need.

• Full slot matrix:
  • Parser adapters: Unstructured, LlamaParse, MarkItDown.
  • Hosted LLMs (any OpenAI-compatible / hosted model via adapter).
  • VLM support for image/figure understanding.
  • Embedding adapters.
  • Stores: pgvector, chroma, lancedb.
  • Outputs: langchain, llamaindex.
• Advanced Relate: references and duplicate-of edge inference, plus type-aware Enrich that adapts behaviour to the detected document type.
• indx.toml configuration with explicit precedence (code / .use() > CLI flag > environment variable > indx.toml > built-in default) and a reproducibility manifest recorded into the knowledge space. See the configuration guide and reproducibility guide.
• Large-directory performance hardening: parallelism, batching, and observability polish for estates of 10k+ files. See the performance guide.
• A published retrieval-quality benchmark measuring the lift from structure and relations versus a flat chunk-soup baseline.

Phase 3 — Beyond v1.0

Later work makes knowledge spaces living artifacts and grows the ecosystem. Throughout, indx stays out of being a runtime or vector DB.

• Incremental / watch-mode re-indexing: delta updates without a full re-process.
• Richer relation inference, plus cross-space linking and merging.
• A community adapter ecosystem and registry.
• Optional managed/serving integrations, strictly downstream. Serving stays out of core.

Success metrics we’re steering by

The roadmap is judged against a few concrete targets.

Category	Metric	Target
Activation	Time-to-first-knowledge-space (install → first .indx)	< 60 seconds on defaults, small dir
Activation	Zero-config success rate	> 90% on common document directories
Retrieval quality	Accuracy vs. flat chunk-soup baseline	Measurable lift from structure + relations (recall@k / groundedness)
Breadth	Adapters across all six slots	Defaults at MVP; full matrix by v1.0; growing community adapters after
Reliability	Crash-free runs on large directories (10k+ files)	> 99%
Adoption	PyPI installs, GitHub stars, external contributors	Month-over-month growth; ≥10 external contributors by v1.0

Open questions

These are deliberately unresolved and may shape what ships in each phase.

ID	Question
OQ-1	.indx format: container choice, and whether embeddings ship inside the archive by default or by reference (size vs. portability).
OQ-2	How document-type detection is implemented at MVP — heuristics, LLM classification, or both — and the canonical type taxonomy.
OQ-3	Which retrieval engine backs indx query for the no-DB (jsonl) case — in-memory brute force vs. a lightweight local index.
OQ-4	How references are resolved (filename mentions, link extraction, embedding similarity) and the acceptable precision bar.
OQ-5	The scope of determinism guarantees given inherently non-deterministic LLM enrichment.
OQ-6	The default chunking strategy and whether it is parser/type-aware out of the box.

Known risks and mitigations

ID	Risk	Mitigation
R-1	Parser dependency surface. Heavyweight parsers add install weight, model downloads, and failure modes, working against the <60s / air-gapped goals.	Lean default install, optional extras per adapter, cached/offline model paths.
R-2	Local-profile performance. ollama:qwen2.5 + bge-m3 on commodity hardware may be slow on large estates.	Parallelism, batching, cloud defaults for general use, clear perf guidance.
R-3	Relationship quality. Weak references / duplicate-of inference erodes the central value prop.	Start conservative (high precision), benchmark, iterate.
R-4	Ecosystem churn. LangChain / LlamaIndex / vector-DB APIs move fast.	Thin adapter layer, version pinning, contract tests.
R-5	Positioning confusion. Users may think indx competes with parsers.	Consistent “composes, not replaces” messaging across docs and CLI.
R-6	Scope creep toward a runtime/DB. Pressure to serve retrieval or store vectors.	Hold the line: serving and storage stay downstream of core.

Composes, not replaces

indx does not build a better PDF extractor, and it is not a vector database or a hosted retrieval runtime. Even as the roadmap grows, those non-goals stay fixed. A parser is just one swappable slot inside the pipeline.

Related reading

• Bring Your Own Stack — the swappable-slot architecture the v1.0 matrix builds on.
• FAQ — common questions about scope, status, and what indx will and won’t do.