# RagLeap Roadmap

This page summarizes the current status of the RagLeap ecosystem across
its three layers: the commercial platform, the standalone open-source
app, and the focused pip-installable packages. All version numbers here
are live-verified against real PyPI releases and real code - not
projected or aspirational. If anything here looks out of date, check
[Home.md](Home.md) and the package's own CHANGELOG.md, which are the
real sources of truth.

## Layer 3 — pip-installable packages (current focus)

| # | Package | Purpose | Status |
|---|---|---|---|
| 1 | `ragleap-rag` | Core retrieval: ingestion, hybrid vector search, provider-agnostic generation, guardrails | Complete v0.12.3 - 245 tests, live-verified. Known honest limitation: token_count is word-count not real tokenization. (Milvus similarity_score normalization was fixed in v0.12.3 - previously inconsistent with the other 5 backends' [0,1] range; verified against Milvus's own docs before fixing.) |
| 2 | `ragleap-graph` | Neo4j knowledge-graph-augmented retrieval | Complete v0.6.7 - 89 tests (88 passed, 1 skipped without GEMINI_API_KEY). LLM entity/relation extraction, hybrid vector+graph retrieval, per-document idempotency, lineage lookup (find_lineage), per-user data isolation (user_id=), Postgres-backed audit logging (audit=), concurrent-write safety via composite_key uniqueness constraints + automatic retry-with-backoff on Neo4j transient deadlocks (closes #183). Two genuinely open limitations: no ontology cross-validation between relation types and entity types; relation extraction runs once per chunk, not cross-document. |
| 3 | `ragleap-vectorstores` | Pluggable vector backends beyond what ships in ragleap-rag core | NEXT - basic pluggability already lives inside ragleap-rag (6 backends); this package is for anything beyond that baseline. |
| 4 | `ragleap-tools` | Built-in tools: search, code exec, calculators, file ops | NEXT |
| 5 | `ragleap-integrations` | MCP-native connectors + curated native integrations, building on the existing WhatsApp/Telegram/Discord/Voice channel code in Layer 2 | NEXT |
| 6 | `ragleap-agents` | Role-based crews, tool-calling, human-in-the-loop approval gates | AFTER |
| 7 | `ragleap-flows` | Low-code orchestration + HITL checkpoints, bootstrapped from the existing n8n integration | AFTER |
| 8 | `ragleap-observability` | Tracing, hallucination detection, and a full LLM-as-judge evaluation framework (Ragas/DeepEval-caliber) | DECISION NEEDED - this is new engineering, not extraction; nothing like the eval-framework half exists internally today. |
| 9 | `ragleap-ops` | Docker/K8s templates, Helm charts, CI/CD, IaC | ONGOING - grows alongside every phase above, not a single release. |
| 10 | `ragleap-studio` | Visual low-code builder UI | LATER |
| 11 | `ragleap-memory` | Shared long-term memory layer across agents/employees | LATER - an untracked packages/ragleap-memory/ directory already exists from concurrent automation; not yet a scoped, owned package. |
| 12 | `ragleap-intelligence` | Early-stage vision, not yet scoped - see note below | VISION / EARLY DISCUSSION ONLY |

**A note on `ragleap-intelligence`:** this entry exists to hold a place
for the "AI Employee Twin" concept discussed in project chat - one
persistent AI assistant per employee, capable of autonomous action
(with optional human-in-the-loop), cross-device presence, and role
continuity across employee turnover. This is a genuinely large, mostly
unscoped vision at this stage, not a committed roadmap item with a
version target. Open questions before this becomes real scoped work:
device/data-access boundaries (office-only vs personal devices),
telephony impersonation of an employee, consent and labor-law
implications of persistent per-employee monitoring/assistance, and
local-vs-cloud model requirements for data sensitivity.

## Immediate next steps for `ragleap-graph`

In priority order:

1. **Audit logging** (Postgres-backed, database_url=, writes+reads).
2. **Ontology cross-validation** - blocked on a design decision.
3. **Eval framework** (graph-RAG vs vector-RAG) - new engineering.
4. **Cross-chunk relation extraction** - architecturally larger, lowest priority.

Plus non-code items: Gemini key rotation (still open), the Layer 2/3
voice-package relationship decision, and /simple/ endpoint data
verification. See the repo's open issues for the full tracked list.

## Contributing

RagLeap's open-source layers (the ragleap-core monorepo: the standalone
app in core/ and channels/, and the pip-installable packages in
packages/) are open to external contributors. If you'd like to help:

- Check open issues on GitHub for scoped, ready-to-pick-up work - each
  one states what's needed and why, following the same
  live-verification standard the rest of the project holds itself to.
- New packages (ragleap-tools, ragleap-vectorstores,
  ragleap-integrations, and beyond) are genuinely open for design
  proposals, not just implementation - open an issue with a proposed
  API surface before a large PR, so design discussion happens before
  code review.
- The project's non-negotiable standard: every claim in code, docs, and
  release notes is either live-verified against real infrastructure, or
  explicitly labeled unverified. PRs that claim "tested" without a
  real, reproducible test are held to the same bar as everyone else's
  work here.
- See Home.md for the full package/version table and links to each
  package's own CHANGELOG.

## Layer 1 — commercial platform

Multi-tenant SaaS, AI Employees, billing, managed hosting. Private repo
(ragleap-backend), not part of this open-source roadmap. See
docs.ragleap.com for platform documentation - that site is scoped to
Layer 1 only and has no content about the pip-installable packages
above.