What is Moʻolelo
Moʻolelo is a self-hosted federated enterprise knowledge platform for organizations whose institutional knowledge spans multiple source systems — code repositories, documentation wikis, issue trackers, document libraries — and whose compliance posture rules out shipping that knowledge to a third-party cloud.
You install it once into your own infrastructure (Kubernetes today, with optional VM-resident ML workloads). It pulls from your sources, normalizes the records, builds a unified knowledge graph with cross-document reference edges, serves hybrid (lexical + semantic) retrieval over the corpus, and respects every source-system access control end-to-end.
Three surfaces, one knowledge substrate
Moʻolelo exposes the same underlying knowledge through complementary surfaces:
- Search — Apache Vespa hybrid retrieval (BM25 + dense vectors) over chunks, with per-tenant ACL filtering and supersession-aware ranking.
- Knowledge graph — NebulaGraph holds one node per entity (page, issue, PR, document) and typed edges for cross-document references. Search hits can carry a "see also" set of one-hop neighbors so the answer to "why did we change this?" surfaces the linked incident report next to the matching PR. See graph expansion.
- Supersession — The platform knows when one entity replaces another (a newer policy supersedes an older one, a PR closes an issue). Tenants choose whether superseded entries are filtered, demoted, or surfaced with a marker. See supersession.
All three surfaces share the same chunks, the same access controls, the same audit log, and the same residency boundary.
Why "federated"
Moʻolelo is built around a hard invariant: personal data of any individual physically resides only in the regional vault for that individual's residency. The global knowledge graph carries tokens, never PII. Queries federate across regions; the data itself never does. This is the difference between an enterprise knowledge platform you can deploy in a regulated multinational and one you can't. See data residency.
What Moʻolelo handles for you
- Ingestion from your sources. Backfill the existing corpus, then keep up via webhooks. Authentication uses each source's standard mechanism (Personal Access Tokens for GitHub, OAuth 2.0 for Atlassian, Microsoft Graph application permissions for SharePoint).
- Durable record storage. Every record lands in an Apache Iceberg table you can query directly with Trino, DuckDB, Spark, or any other Iceberg-aware tool. The store is the source of truth — every other index is a projection of it.
- Hybrid retrieval. Apache Vespa serves combined BM25 (lexical) and dense-vector (semantic) search using a multilingual embedding model. Per-tenant alpha tuning blends the two.
- Knowledge graph projection. Each chunk text is scanned for cross-document references (Jira keys, GitHub
owner/repo#N, Confluence inter-page links, URLs to known sources) and projected as typed edges in NebulaGraph. Stub vertices upgrade in place when the referenced entity is later ingested by its own connector. - Tenant- and source-aware access control. Authority chains track the source-system permission that granted access; the audit log records every served query and every graph expansion result.
Who it's for
Operators of regulated multinational organizations — financial services, healthcare, government, defense, regulated manufacturing — who need first-class knowledge intelligence over their institutional corpus but can't or won't push that corpus to a SaaS vendor.
Size doesn't decide it — problem shape does. The same binaries serve a five-person team running everything on a single node and a multinational running half a dozen regions over a petabyte-class corpus.
If you can deploy a Kubernetes Helm chart and you have at least one supported source system, you can run Moʻolelo.
What you'll need
- A Kubernetes cluster (1.28+) for the data plane.
- An object store — AWS S3, S3-compatible (MinIO, Ceph, Cloudflare R2), Google Cloud Storage, or Azure ADLS Gen2.
- A Postgres database for connector configuration and supersession decisions.
- Apache Pulsar 3.x and Project Nessie 0.99+ as the streaming and catalog substrates (deployable into the same cluster, or use existing ones).
- Optional: a GPU pool if you want maximum embedding throughput. CPU-only deployments work for smaller tenants.
On the roadmap
Moʻolelo is a knowledge substrate, not a finished product surface. What ships today is the ingest path, the unified graph + retrieval layer, the supersession engine, and the access-control stack. Forward investment is going into:
- Conversation ingestion — bringing chat transcripts (Slack, Teams), LLM-agent traces (Langfuse), and meeting recordings into the same residency-clean substrate so the institutional memory captures more than just written artifacts.
- Knowledge-gap intelligence — using the unified retrieval + graph + query-log signal to surface where the corpus is thin: topics queried frequently with no good answer, entities heavily referenced but never written about, areas where a key contributor's expertise lives only in conversations. The output is "write more about X here" recommendations, not synthetic content.
Neither is shipped yet. We don't document unshipped features as if they exist — when they land, they get their own pages and a connector framework entry.
Where to next