{"slug": "show-hn-omneum-local-text-blind-context-control-plane-for-ai-agents", "title": "Show HN: Omneum – Local, text-blind context control plane for AI agents", "summary": "Omneum, an open-source context control plane for AI agents, was released as a pip-installable package that selects retrieved passages by claim coverage rather than retrieval order, backed by SQLite or PostgreSQL. In the project's five-chunk demo with four distinct claims and an 80-unit context budget, Omneum retained 2 chunks covering 4/4 claims using 51/80 units, versus raw RAG retaining 3 chunks covering 2/4 claims at 75/80 units — 32% less context capacity. The tool computes source reliability and claim support over a provenance-aware bipartite graph and evaluates structured observations without reading source text or invoking an LLM judge.", "body_md": "Provenance-aware context control plane for AI agents.\n\nOmneum is an open-source context control plane for AI agents, built to optimize the evidence entering an LLM's context window.\n\nAgents accumulate context from retrieval, tools, memory, and previous sessions, but longer context windows don't guarantee better reasoning. Context rot can slowly degrade downstream answer accuracy even when the relevant information has already been retrieved.\n\n- \n**Provenance-aware graph inference:** Iteratively computes source reliability and claim support across a bipartite graph, accounting for shared evidence origins and dependencies between sources.\n- \n**Context reconstruction:** Selects original retrieved passages based on question relevance and incremental claim coverage within a token budget.\n- \n**Text-blind evaluation:** Evaluates structured observations without reading source text strings or invoking an LLM judge.\n- \n**Local by default:** Persists your agents' observations across sessions in a[Context Graph](https://github.com/cole-h06/omneum/blob/main/docs/context-graph.md) , backed by SQLite or PostgreSQL.\n\nInstall Omneum:\n\n```\npip install omneum\n```\n\nRun the context reconstruction demo:\n\n```\ngit clone https://github.com/cole-h06/omneum.git\ncd omneum\npython -m examples.context_quality_demo.before_after\n```\n\n**Five retrieved chunks, four distinct claims, 80-unit context budget.**\n\nCompare retrieval-order packing with Omneum's claim-coverage selection under the same context budget.\n\n| Metric | Raw RAG | Omneum | \n|---|---|---|\n| Chunks retained | 3 | 2 | \n| Claim coverage | 2/4 | 4/4 | \n| Budget used | 75/80 | 51/80 | \n\nPacking chunks in retrieval order consumes 75 units while covering only two claims. Omneum retains two original chunks covering all four, using **32% less context capacity**.\n\nThe demo measures its budget with the SDK's word/punctuation counter.\n\nOmneum uses a graph-based mathematical analysis, calculated from `Observation` objects, to estimate the structural reliability of sources and the support for claims found in retrieved context.\n\nImportantly, this analysis does not naively assume every source has derived its information independently. The same information often propagates across multiple sources. Without dependency tracking, five observations from different sources can be difficult to distinguish from five reports derived from the same upstream source.\n\nFor example, consider:\n\n```\nSource A:    Acme's 2025 annual report\nClaim:       Acme reported $4.2 billion in revenue for 2025.\n\nSource B:    Financial article reporting the same claim\nClaim:       Acme reported $4.2 billion in revenue for 2025.\nUpstream:    Acme's 2025 annual report\n```\n\nHow much support should that claim receive? That depends partly on the reliability of the sources reporting it. But how do we determine the reliability of the sources? By looking at the claims they support.\n\nThis definition seems circular, and it is. Nonetheless, it provides a well-defined notion of reliability that helps distinguish strongly supported context from weakly supported context.\n\nOf course claim-level scores are only useful for context selection if they can be mapped back to chunks. To bridge this gap, Omneum stores a claim-to-chunk mapping: each chunk retains its original text and `chunk_id`, while its associated `claim_ids` reference the claims evaluated in the graph. A chunk can contain multiple claims, and the same claim can appear across multiple chunks. This allows the algorithm to associate claim support with the actual passages competing for space in the context window.\n\nBut selecting context is not simply a matter of ranking chunks by their individual scores. Omneum derives chunk utility from the claims associated with each passage, then ranks chunks to fill the model's window under a limited token budget. When a nonempty `question` is supplied, finalized claim contributions are weighted by deterministic, local lexical relevance over the original passage text. Repeated evidence from the same inferred source cluster earns only an improvement over its best selected relevance. Without a question, Omneum keeps its question-blind claim-coverage selection. Selected passages are reconstructed from their original text.\n\nThe selected passages are then reconstructed from their original text into the context passed to the LLM. The analysis itself never needs to read that text because it operates exclusively on structured relationships between sources and claims.\n\nOmneum runs between retrieval and generation. The Python SDK accepts retrieved chunks and relevance scores from the calling retrieval pipeline, or computes relevance locally using BM25 or MiniLM when explicitly enabled.\n\n```\nRetrieval / tools\n        │\n        ▼\n┌───────────────────────────────────────────┐\n│ ContextMapper / Observation input         │\n│                                           │\n│ Source, claim and provenance mapping      │\n│ Structured Observation construction       │\n└─────────────────────┬─────────────────────┘\n                      │ Structured observations\n                      ▼\n┌───────────────────────────────────────────┐\n│ Python SDK · prepare_context()            │\n│                                           │\n│ Retrieved chunks and relevance scores     │\n│ Query conditioning / candidate discovery  │\n│ Original text retained locally            │\n└─────────────────────┬─────────────────────┘\n                      │ Structured observations\n                      ▼\n┌───────────────────────────────────────────┐\n│ Omneum evaluator                          │\n│                                           │\n│ Provenance-aware graph inference          │\n│ Dependency-adjusted claim support         │\n│ No original source text required          │\n└─────────────────────┬─────────────────────┘\n                      │ Graph evaluation\n                      ▼\n┌───────────────────────────────────────────┐\n│ Python SDK                                │\n│                                           │\n│ Claim-to-chunk score mapping              │\n│ Question-weighted claim support           │\n│ Marginal claim coverage                   │\n│ Token-budget enforcement                  │\n│ Original text reconstruction              │\n└─────────────────────┬─────────────────────┘\n                      │ Reconstructed context\n                      ▼\n                  Agent / LLM\n```\n\n`client.prepare_context()` uses Omneum's provenance-aware graph inference to evaluate source reliability and claim support, accounting for dependencies between sources. The SDK uses those results to rank and select retrieved passages within the token budget, then reconstructs their original text for the model.\n\nThe prepared context is returned in `result[\"context\"]`, with selected passages in `result[\"chunks\"]` and evaluation scores in `result[\"evaluation\"]`.\n\n**Note:** Omneum supports Python 3.11–3.14 on macOS and Ubuntu. The Python SDK is the currently supported client library.\n\n**Supported Platforms:**\n\n| Platform | Supported | \n|---|---|\n| macOS (Apple Silicon / arm64) | ✅ | \n| macOS (Intel / x86_64) | ✅ | \n| Linux (Ubuntu 22.04+ / x86_64) | ✅ | \n\nRun the installer to configure the local evaluator:\n\n```\nomneum install\n```\n\nRun `omneum install` from your normal login account. Don't run the command with `sudo`.\n\nThe installer runs unprivileged while it downloads and verifies the evaluator release. The daemon version is pinned to the installed Python package version. For example, Omneum `1.0.3` only accepts daemon assets from `v1.0.3`; it doesn't resolve `latest` or fall back to another release.\n\nThe archive is verified against the release `SHA256SUMS` before installation. A missing checksum, mismatched digest, unexpected archive entry, link, or path traversal stops the install before anything from the archive runs.\n\nAdministrator access is requested only when installing machine-level service files. On Ubuntu, this includes the managed runtime under:\n\n```\n/opt/omneum\n```\n\nand public client configuration at:\n\n```\n/etc/omneum/config.toml\n```\n\nThe evaluator runs under a dedicated service identity, isolating its VOPRF private key from the login account and MCP server process. macOS uses `launchd`; Ubuntu uses systemd.\n\n`omneum-server` exposes Omneum's MCP tools over stdio and communicates with the locally installed evaluator service. The installer finishes by sending a VOPRF request through that path and verifying the response against the configured public key. A running service alone does not count as a successful installation.\n\nSee [`docs/guides/installation.md`](https://github.com/cole-h06/omneum/blob/main/docs/guides/installation.md) for service accounts, sockets, installed paths, custom endpoints, and failure handling.\n\nAdd Omneum to your MCP configuration:\n\n```\n{\n  \"mcpServers\": {\n    \"omneum\": {\n      \"command\": \"omneum-server\"\n    }\n  }\n}\n```\n\nRestart the MCP client. It launches `omneum-server` over stdio and exposes Omneum's tools to your agent.\n\nIf the executable isn't found, locate it with `command -v omneum-server` and use the returned absolute path as `command`.\n\nAsk your agent to call Omneum's `ping` tool. A successful connection returns:\n\n```\n{\n  \"status\": \"ok\"\n}\n```\n\nOmneum evaluates structured observations, selects retrieved chunks under a token budget, and reconstructs the selected text for the downstream LLM. The evaluator computes dependency-adjusted claim support, while the Python SDK handles chunk selection and reconstruction.\n\nIn this example, the FAQ derives its audit retention claim from the security policy. The upstream dependency is recorded through `upstream_sources`.\n\n``` python\nfrom datetime import datetime, timezone\n\nfrom omneum import ContextMapper, Source\nfrom omneum.information import SourceReference\nfrom omneum.context_selection import claim_id\n\nnow = datetime.now(timezone.utc)\npolicy_url = \"https://example.com/security-policy\"\n\nrecords = [\n    {\n        \"id\": \"obs-policy\",\n        \"url\": policy_url,\n        \"attribute\": \"audit_retention_days\",\n        \"value\": 90,\n        \"upstream\": [],\n        \"text\": \"Audit logs are retained for 90 days.\",\n    },\n    {\n        \"id\": \"obs-faq\",\n        \"url\": \"https://example.com/faq\",\n        \"attribute\": \"audit_retention_days\",\n        \"value\": 90,\n        \"upstream\": [\n            SourceReference(kind=\"web_document\", identifier=policy_url)\n        ],\n        \"text\": \"Audit logs are retained for 90 days.\",\n    },\n    {\n        \"id\": \"obs-incident\",\n        \"url\": \"https://example.com/incident-report\",\n        \"attribute\": \"incident_notification_hours\",\n        \"value\": 24,\n        \"upstream\": [],\n        \"text\": \"Security incidents are reported within 24 hours.\",\n    },\n]\n\nmapper = ContextMapper(\n    source=lambda r: Source(kind=\"web_document\", identifier=r[\"url\"]),\n    entity_namespace=lambda r: \"security\",\n    entity=lambda r: \"acme\",\n    attribute=\"attribute\",\n    value=\"value\",\n    observation_id=\"id\",\n    observed_at=lambda r: now,\n    upstream_sources=\"upstream\",\n)\n\nobservations = [mapper.map(record) for record in records]\n\nchunks = [\n    {\n        \"chunk_id\": record[\"id\"],\n        \"claim_ids\": [claim_id(observation.claim)],\n        \"raw_text\": record[\"text\"],\n    }\n    for record, observation in zip(records, observations)\n]\n```\n\n`ContextMapper` maps the records into assertion observations. The original text stays in the chunk mapping, accessible through the associated claim IDs. Only the structured observations are sent to the MCP evaluator.\n\nPass the mapped observations and chunks to `prepare_context()`. The dependency estimator is configured to use upstream lineage.\n\n``` python\nimport asyncio\n\nfrom omneum import DependencyEstimatorConfig, OmneumClientConfig, open_stdio_client\nfrom omneum.mcp import StdioServerParameters\n\nestimator = DependencyEstimatorConfig(\n    upstream_weight=1.0,\n    citation_weight=0.0,\n    assertion_lineage_weight=0.0,\n    ownership_weight=0.0,\n    temporal_weight=0.0,\n    graph_weight=0.0,\n    temporal_window_seconds=7200.0,\n)\n\nasync def main():\n    config = OmneumClientConfig.from_local_deployment()\n    server = StdioServerParameters(command=\"omneum-server\")\n\n    async with open_stdio_client(config, server) as client:\n        result = await client.prepare_context(\n            observations,\n            chunks,\n            estimator=estimator,\n            token_budget=100,\n        )\n\n    print(result[\"context\"])\n    print(result[\"selection\"][\"claim_coverage\"])\n\nif __name__ == \"__main__\":\n    asyncio.run(main())\n```\n\nSave as `prepare_context.py` and run:\n\n```\npython prepare_context.py\n```\n\nThe returned JSON contains the reconstructed context at `result[\"context\"]`. Graph scores are available in `result[\"evaluation\"]`, so your agent can inspect the result before invoking the model.\n\nSee [`examples/context_quality_demo/`](https://github.com/cole-h06/omneum/tree/main/examples/context_quality_demo) for a comparison with retrieval-order packing.\n\nAn agent orchestrator can use Omneum's claim support scores to control execution after retrieval. In LangGraph, a conditional edge can send the workflow back to a retrieval node when the evidence falls below a configured threshold.\n\n``` python\ndef route_context(result):\n    evaluation = result[\"evaluation\"]\n\n    if (\n        not evaluation[\"converged\"]\n        or evaluation[\"max_claim_support\"] is None\n        or evaluation[\"max_claim_support\"] < 0.30\n    ):\n        return \"retrieve\"\n\n    return \"generate\"\n```\n\nThe `retrieve` branch can run another search before the agent attempts generation. Once the routing condition passes, the model receives `result[\"context\"]`.\n\nThe threshold is an example. A workflow that needs support for particular claims can inspect their individual scores in `evaluation[\"claim_support\"]`.\n\nUse the [Python SDK](https://github.com/cole-h06/omneum/blob/main/docs/sdk.md) and [ContextMapper](https://github.com/cole-h06/omneum/blob/main/docs/context-mapper.md) to add Omneum to your agent.\n\nFramework examples:\n\nFor a complete framework-independent workflow, see the\n[enterprise policy example](https://github.com/cole-h06/omneum/tree/main/examples/enterprise/).\n\nOmneum runs locally by default. Network contribution is opt-in and allows participating deployments to contribute observations to the shared Omneum Context Graph without uploading raw context.\n\nContributions use privacy-preserving linkage through an RFC 9497 VOPRF. The shared graph can accumulate source and claim relationships across deployments while keeping the underlying text local.\n\nNetwork contribution is disabled by default and is not required for local evaluation. Hosted Network enrollment is currently limited to approved beta participants.\n\nSee [Enable Network contribution (MCP)](https://github.com/cole-h06/omneum/blob/main/docs/guides/configuration.md#mcp-configuration) for setup instructions or [How Network contribution works](https://github.com/cole-h06/omneum/blob/main/docs/context-graph.md#omneum-network) for the protocol details.\n\nOmneum evaluates retrieved context through a source–claim graph. Claims identify factual assertions within the retrieved passages, while observations preserve where those assertions originated. The graph's evaluation scores inform which original chunks are selected for the LLM's context window.\n\nObservations record information encountered during retrieval. The first supported type, an assertion observation, connects a claim to its source and preserves the provenance available at the time it was encountered.\n\n```\nObservation(\n    observation_id=\"obs-1\",\n    source=source,\n    claim=claim,\n    observed_at=datetime.now(timezone.utc),\n)\n```\n\nAn assertion can appear across multiple retrieved passages without being treated as independent evidence each time. Observations preserve these source relationships for graph inference. Conflicting assertions also remain distinct, retaining the evidence originally reported by each source.\n\nSources identify where retrieved evidence originated. Each source has a `kind` and canonical `identifier`, allowing Omneum to recognize the same source across observations.\n\n```\nSource(\n    kind=\"web_document\",\n    identifier=\"https://example.com/acme-filing\",\n)\n```\n\nSource identity matters when multiple passages reference the same fact. Omneum uses these relationships during dependency estimation so repeated evidence does not receive the same weight as independent support.\n\nClaims represent factual assertions identified within retrieved context. Omneum maps claims across source passages to evaluate their support and determine which chunks contribute useful evidence to the model's context.\n\nEach claim is represented by an `entity_namespace`, `entity`, `attribute`, and `value`.\n\n```\nClaim(\n    entity_namespace=\"company\",\n    entity=\"acme\",\n    attribute=\"fy2025_gross_revenue\",\n    value=4_200_000_000,\n)\n```\n\nMultiple passages can reference the same claim. Their source relationships are accounted for during graph inference, allowing context selection to prioritize additional claim coverage within the token budget.\n\nRetrieved passages may repeat assertions from the same underlying source. Omneum estimates source dependence using available provenance signals, including upstream references and assertion lineage.\n\nThese dependencies affect how much support each source contributes to a claim. A passage repeating an earlier report can still be selected when it adds useful context, but the repeated assertion does not receive the weight of independent evidence.\n\n`ContextMapper` maps structured retrieval records into Omneum's observation model. Claim fields and source metadata are extracted from the records supplied by the integrating pipeline.\n\nThe SDK maintains a claim-to-chunk mapping. Each chunk retains its `chunk_id` and `raw_text`, while `claim_ids` reference the claims represented in that passage.\n\nThis mapping allows graph inference to operate on structured observations while keeping the original text available for context reconstruction.\n\nAfter graph inference, Omneum uses claim support to select retrieved chunks within a context budget.\n\nSelection accounts for claim coverage across the candidate passages. A chunk's utility depends on the additional evidence it contributes to the selected context, including claims already covered by other chunks.\n\n`prepare_context()` reconstructs the selected passages from their original text. The returned `context` string is ready to be included in the next LLM request.\n\nThe selection budget applies to the retrieved evidence. The consuming agent remains responsible for accounting for the rest of the model's input.\n\n`prepare_context()` returns a dictionary containing reconstructed context, selected chunks, graph evaluation results, and selection metadata.\n\n```\nresult = await client.prepare_context(\n    observations,\n    chunks,\n    estimator=estimator,\n    token_budget=2048,\n)\n\ncontext = result[\"context\"]\nclaim_scores = result[\"evaluation\"][\"claim_support\"]\nselected_chunks = result[\"chunks\"]\n```\n\nThe `evaluation` object exposes source reliability and claim support scores from graph inference. The `selection` object records token-budget usage, while `packed_chunk_ids` identifies the chunks included in the reconstructed context.\n\nAn agent orchestrator can inspect the evaluation before invoking the LLM. Conditional routing can trigger another retrieval pass when the available evidence does not meet the workflow's requirements.\n\n[Python SDK and response schema →](https://github.com/cole-h06/omneum/blob/main/docs/sdk.md)\n\nThe [Cross-Domain Context Curation Benchmark](https://github.com/cole-h06/omneum/blob/main/benchmarks/leaderboard.md) evaluates 13 context-selection configurations on **24 synthetic cases across six agentic domains**, using six Qwen-token budgets from 64 to 256. Each configuration receives the same candidate passages within a case. Results are macro-averaged across cases and budgets.\n\nOmneum improved selection precision across all four evaluated integrations—BM25, MiniLM embeddings, BGE Reranker v2-m3, and Cohere Rerank v4.0 Pro, while reducing the number of tokens used.\n\n| Configuration | Precision ↑ | Recall ↑ | Evidence ↑ | Claims ↑ | Origins ↑ | Qwen Tokens ↓ | \n|---|---|---|---|---|---|---|\n| Original-Order RAG | 43.33% | 42.75% | 43.08% | 58.51% | 60.32% | 136.87 | \n| BM25 | 59.15% | 55.76% | 55.79% | 66.15% | 71.05% | 136.18 | \n| **BM25 + Omneum** | **63.12%** | 46.86% | 46.90% | 66.22% | 69.16% | **111.60** | \n| MiniLM Embeddings | 63.80% | 59.13% | 58.86% | 68.47% | 70.94% | 136.31 | \n| **MiniLM + Omneum** | **66.83%** | 49.08% | 50.14% | 69.74% | 68.50% | **111.08** | \n| BGE Reranker v2-m3 | 63.29% | 59.19% | 58.84% | 68.75% | 71.42% | 136.47 | \n| **BGE + Omneum** | **71.74%** | 54.76% | 55.26% | **75.36%** | **75.21%** | **116.74** | \n| Cohere Rerank v4.0 Pro | 71.11% | 64.43% | 64.39% | 72.29% | 75.20% | 136.72 | \n| **Cohere + Omneum** | **74.88%** | 54.91% | 56.20% | 72.99% | 72.86% | **112.68** | \n| Omneum Standalone | 61.55% | 52.65% | 53.42% | **75.85%** | **75.52%** | 129.27 | \n\nAcross the four integrations, Omneum increased aggregate selection precision by **3.02–8.44 percentage points** and reduced mean reconstructed-context token usage by **14.46–18.51%**.\n\nBGE + Omneum delivered the largest precision gain, improving from **63.29% to 71.74%**, alongside an increase in claim coverage from **68.75% to 75.36%**. Its precision improvement was **+8.44 percentage points** (95% paired bootstrap CI: **+2.19 to +15.37 pp**), based on 50,000 whole-case resamples.\n\nCohere + Omneum achieved the highest precision among the evaluated Omneum integrations at **74.88%**, using **17.58% fewer context tokens** than standalone Cohere.\n\nThe integrations prioritize a smaller set of supporting passages, increasing precision at the expense of aggregate recall and evidence retention. The [full leaderboard](https://github.com/cole-h06/omneum/blob/main/benchmarks/leaderboard.md) includes the paired comparisons and confidence intervals.\n\nThe benchmark also evaluates Claude Sonnet 5.5, GPT-6 Astra, and Gemini 3.8 Flash as passage-ranking judges. Each judge ranks the fixed candidate pool before token-budgeted packing. Omneum performs selection locally through `prepare_context()` without an additional frontier-model judge call.\n\n| Configuration | Precision ↑ | Recall ↑ | Evidence ↑ | Claims ↑ | Origins ↑ | Qwen Tokens ↓ | \n|---|---|---|---|---|---|---|\n| Claude Sonnet 5.5 | **85.69%** | **75.85%** | **76.49%** | 81.05% | 82.89% | 136.41 | \n| GPT-6 Astra | 85.14% | 75.33% | 76.18% | **81.48%** | **83.50%** | 136.49 | \n| Gemini 3.8 Flash | 83.81% | 74.81% | 75.33% | 80.12% | 81.27% | 136.52 | \n| Omneum Standalone | 61.55% | 52.65% | 53.42% | 75.85% | 75.52% | 129.27 | \n| BGE + Omneum | 71.74% | 54.76% | 55.26% | 75.36% | 75.21% | 116.74 | \n| Cohere + Omneum | 74.88% | 54.91% | 56.20% | 72.99% | 72.86% | **112.68** | \n\nFrontier judges achieved higher aggregate selection quality. Claude Sonnet 5.5 led selection precision at **85.69%**, while GPT-6 Astra achieved the highest claim coverage (** 81.48%**) and root-origin coverage (** 83.50%**).\n\nOmneum's integrations operate without frontier judge inference, with smaller reconstructed contexts in the recorded comparisons.\n\nOmneum's median local selection latency ranged from **194.86 ms to 207.79 ms** across standalone and hybrid configurations.\n\n| Configuration | Local Selection p50 ↓ | Local Selection p95 ↓ | \n|---|---|---|\n| Omneum Standalone | **194.86 ms** | 451.87 ms | \n| BM25 + Omneum | 207.79 ms | 461.25 ms | \n| MiniLM + Omneum | 203.84 ms | 465.36 ms | \n| BGE + Omneum | 200.63 ms | **430.51 ms** | \n| Cohere + Omneum | 206.89 ms | 480.37 ms | \n\nTiming begins with relevance scores and structured observations already available. External ranking inference and observation preparation are excluded.\n\nThe recorded frontier-judge response medians were **1.844 s** for Claude Sonnet 5.5, **2.034 s** for GPT-6 Astra, and **2.033 s** for Gemini 3.8 Flash. Provider response time and Omneum's local selection time have different measurement boundaries.\n\n| Frontier Judge | Estimated Ranking Inference Cost | \n|---|---|\n| Claude Sonnet 5.5 | $0.113996 | \n| GPT-6 Astra | $0.281080 | \n| Gemini 3.8 Flash | $0.025231 | \n| **Total** | **$0.420307** | \n\nThese are aggregate estimates from the saved frontier-ranking calls, using recorded token counts and pricing assumptions. They exclude Cohere API charges and local computation. No downstream answer generation was executed in this benchmark.\n\n**Detailed evaluations:** [Methodology](https://github.com/cole-h06/omneum/blob/main/benchmarks/README.md) · [Full Leaderboard](https://github.com/cole-h06/omneum/blob/main/benchmarks/leaderboard.md) · [Coding Agents](https://github.com/cole-h06/omneum/blob/main/benchmarks/coding.md) · [Enterprise RAG](https://github.com/cole-h06/omneum/blob/main/benchmarks/enterprise-rag.md) · [Research & Analysis](https://github.com/cole-h06/omneum/blob/main/benchmarks/research.md) · [Multi-Agent Systems](https://github.com/cole-h06/omneum/blob/main/benchmarks/multi-agent.md) · [Data Analytics](https://github.com/cole-h06/omneum/blob/main/benchmarks/analytics.md) · [Support & Operations](https://github.com/cole-h06/omneum/blob/main/benchmarks/support.md)\n\nOmneum uses SQLite as its default local storage backend. PostgreSQL is supported for deployments that use an external database.\n\n| Component | Implementation | \n|---|---|\n| **MCP server** | Local `omneum-server` process | \n| **Evaluator** | Managed local daemon | \n| **Local database** | SQLite | \n| **Graph model** | Relational source, claim, observation, and dependency tables | \n| **External database** | PostgreSQL | \n| **Graph extension** | Apache AGE | \n| **Service manager** | `launchd` on macOS; systemd on Ubuntu | \n| **Cryptography** | RFC 9497 VOPRF, Ristretto255-SHA512 | \n\nLocal installations create `omneum.db` automatically:\n\n```\nmacOS\n~/Library/Application Support/Omneum/omneum.db\n\nLinux\n~/.local/share/omneum/omneum.db\n```\n\nFor a new default graph with unsafe data-directory ancestors, Omneum uses\n`~/.omneum/data/omneum.db`. Existing graphs and explicit paths are never\nsilently relocated; shared directory permissions are preserved.\n\nPostgreSQL can be configured for deployments that use an external database. Apache AGE provides the graph projection for PostgreSQL deployments.\n\nSee [`docs/storage.md`](https://github.com/cole-h06/omneum/blob/main/docs/storage.md) for the storage schema and deployment options.\n\nThe Python SDK retains original text chunks locally for context selection and reconstruction. The evaluator processes structured observations and provenance metadata without accessing source text. The MCP server, evaluator daemon, and SQLite database run locally.\n\n| Component | Boundary | \n|---|---|\n| **Context** | Original chunks remain available to the SDK for selection and reconstruction | \n| **Context graph** | Stored in local `omneum.db` | \n| **VOPRF private key** | Held by the evaluator daemon | \n| **MCP process** | Cannot read the evaluator's private key | \n| **Source payloads** | Not required in the graph | \n| **Omneum Network** | Optional contribution through the ingestion API | \n\nOmneum persists the local context graph across MCP sessions.\n\nLocal persistence and Omneum Network contribution are configured independently.\n\n| Option | Behavior | \n|---|---|\n| **Local persistence** | Writes observations to `omneum.db` | \n| **Network contribution** | Sends pseudonymous observations to the Omneum Network through the ingestion API | \n\nSee [Omneum Network](https://github.com/cole-h06/omneum/blob/main/docs/context-graph.md#omneum-network) for Network contribution and [Local Persistence](https://github.com/cole-h06/omneum/blob/main/docs/context-graph.md#local-persistence) for Context Graph storage.\n\nContributions are welcome. See [CONTRIBUTING.md](https://github.com/cole-h06/omneum/blob/main/CONTRIBUTING.md).\n\nIf you find a security issue, please follow the private reporting process in [SECURITY.md](https://github.com/cole-h06/omneum/blob/main/SECURITY.md) instead of opening a public issue.\n\nOmneum is open source under the [MIT License](https://github.com/cole-h06/omneum/blob/main/LICENSE).", "url": "https://wpnews.pro/news/show-hn-omneum-local-text-blind-context-control-plane-for-ai-agents", "canonical_source": "https://github.com/cole-h06/omneum", "published_at": "2026-10-30 15:03:29+00:00", "updated_at": "2026-10-30 15:17:00.902323+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "large-language-models", "ai-research", "developer-tools"], "entities": ["Omneum", "SQLite", "PostgreSQL", "GitHub"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/show-hn-omneum-local-text-blind-context-control-plane-for-ai-agents", "markdown": "https://wpnews.pro/news/show-hn-omneum-local-text-blind-context-control-plane-for-ai-agents.md", "text": "https://wpnews.pro/news/show-hn-omneum-local-text-blind-context-control-plane-for-ai-agents.txt", "jsonld": "https://wpnews.pro/news/show-hn-omneum-local-text-blind-context-control-plane-for-ai-agents.jsonld"}}