Most AI agents act without a trail. They store embeddings, not meaning. Semantica — MIT-licensed, ~4,500 GitHub stars — is a bet that this becomes a compliance problem before it becomes a product problem, and that the fix is a graph, not a bigger context window.
The tagline is "The Open Source Palantir for AI Agents," which is doing marketing work. The genuinely interesting claim is quieter and sits in the architecture: graph construction, reasoning, and provenance are fully deterministic — no LLM required. In a field where "explainable AI" usually means asking a model to explain itself, that's a real distinction.
TL;DR
| Question | Answer |
|---|---|
| What is it? | Graph-native context + decision + provenance layer under your existing agent stack |
| License | MIT — fully self-hostable, no vendor lock-in |
| Install | pip install semantica · Python 3.8+ · v0.6.0 (July 21, 2026) |
| Needs an LLM? | No for graph, reasoning, provenance. Optional for extraction via LiteLLM |
| Repo (Aug 11) | ~4.5k stars, 499 forks, 2,235 commits, 26 contributors, 19 releases |
| Open work | 24 issues, 30 PRs — more open PRs than issues |
| Storage | Polyglot: RDF (Oxigraph, Blazegraph, Jena, RDF4J) + LPG (Neo4j, FalkorDB, AGE, Neptune) |
| Watch out | Auth advisory (GHSA-j4mq) fixed August 11 — see below before deploying |
The actual idea: decisions as graph nodes
Strip the positioning and Semantica's core is one design choice — a decision is not a log line, it's a first-class node with a lifecycle.
from semantica.context import ContextGraph
graph = ContextGraph(advanced_analytics=True)
decision_id = graph.record_decision(
category="credit_application",
scenario="Personal loan, $85k income, 31% DTI, 3yr employment",
reasoning="Income meets threshold; employment stable; no adverse credit events",
outcome="proceed_to_underwriting",
confidence=0.88,
)
Once decisions are nodes, a set of queries becomes possible that logging simply cannot answer:
| Method | What it answers |
|---|---|
trace_decision_chain() | Full causal ancestry back to root causes |
find_similar_decisions() | Semantic precedent search across all past decisions |
analyze_decision_impact() | Downstream influence map — everything this decision touched |
check_decision_rules() | Policy compliance gate against configurable rule sets |
add_causal_relationship() | Explicit CAUSED / INFLUENCED / PRECEDENT_FOR links |
The lending example in the README is well-chosen because it's the actual regulatory scenario: an application decision CAUSED an underwriting decision which INFLUENCED a rate assignment. Months later a regulator asks why applicant A-7291 got 8.9%. A vector store cannot answer that. A log file can, badly, if nobody rotated it. A causal graph answers it structurally and exports as W3C PROV-O, which is the format most compliance frameworks actually accept.
Precedent search is the underrated feature. "Have we decided something like this before, and what happened?" is a question institutions ask constantly and answer through tribal memory. Making it a query is a bigger deal than the audit-trail framing suggests.
Why deterministic matters more than the Palantir line
The comparison table in the README is aimed squarely at RAG:
| Vector DB + RAG | Semantica | |
|---|---|---|
| Recall | Embedding similarity | Graph traversal + semantic search |
| Decision history | Not stored | First-class queryable objects |
| Provenance | None | W3C PROV-O, source-linked |
| Conflicts | Silent overwrite | Detected, flagged, resolved |
| Time travel | No | Point-in-time snapshots |
| Reasoning | None | Forward chaining, Rete, Datalog, SPARQL |
The row that matters most in practice is conflict detection. Silent overwrite is how knowledge bases quietly become wrong: two sources disagree, the later write wins, nobody knows a contradiction existed. Flagging it is unglamorous and correct.
And the reasoning engines are the reason the "no LLM required" claim holds. Rete networks and Datalog are decades-old, well-understood, and — critically — reproducible. Run the same rules over the same facts, get the same answer, every time. That property is what an auditor needs and what no LLM can offer. If your explainability layer is itself a stochastic model, you have moved the problem rather than solved it.
This is a meaningfully different position from the GraphRAG wave we covered in RAG vs agentic RAG and RAG vs MCP, where the graph is mostly a retrieval improvement. Here the graph is the accountability artifact, and retrieval is a side effect.
The security advisory that landed this week
Reported plainly, because it matters more for this project than for most: on August 11, 2026, a commit landed titled "security: require API-key auth on all Explorer API routes (GHSA-j4mq)."
The implication is direct — until that fix, the Knowledge Explorer's API routes did not require authentication. The Explorer is the browser workbench exposing the live graph, decision chains, the audit log, entity resolution, and the ontology editor. That is the whole sensitive surface.
Two things are true at once, and both should be said:
The uncomfortable part. This is a project explicitly marketed to finance, healthcare, legal, government and defense, and law enforcement, with "classified information governance" named as a use case. Unauthenticated API routes on the graph workbench is exactly the class of finding that should give a security reviewer pause about the maturity of the security model — not because one bug is damning, but because the marketing runs well ahead of what a 26-contributor project has had time to harden.
The fair part. They found it, fixed it, filed an advisory, and shipped the patch across deploy/, semantica/, tests/, and both Docker Compose files in one commit. The repo also SHA-pins all GitHub Actions, has a hardened release pipeline with pin verification, runs Checkov, and hardened its Neptune cookbook security groups with VPC flow logs. That's a project taking security seriously, and it's precisely the transparency you get from MIT-licensed open source and would never get from a closed vendor.
What to do: if you run the Explorer, update now and verify it was never reachable beyond localhost. Note that GHSA-j4mq was not yet published in GitHub's public advisory database at the time of writing, so severity and affected-version ranges aren't independently confirmable yet — check the advisory directly before assessing exposure.
The general lesson, which is not specific to Semantica: "built for regulated domains" is a statement of intent, not an accreditation. Audit it like anything else you'd put in front of a regulator.
What's actually shipping
The architecture is a real pipeline rather than one library with a broad README:
Sources → Ingest → Parse → Normalize → Split → Extract → Conflict Detection → Deduplication
→ Knowledge Graph → [ Ontology · Reasoning · Provenance · Decisions ] → Enriched KG
→ Vector Store + Polyglot Graph Store (RDF & LPG) → Export / Visualize / REST · MCP · CLI
Notable pieces:
- Entity-aware chunking built for GraphRAG rather than fixed-size splitting — chunking that respects entity and relation boundaries is one of the higher-leverage, least-discussed retrieval improvements.
- Bi-temporal facts and Allen interval algebra (13 relations) with point-in-time snapshots. Replay the graph as it existed on any past date without reprocessing — the right primitive for "what did the system know when it decided?"
- Ontology Hub with SHACL validation, OWL generation, SKOS vocabularies, and a visual editor.
- Enterprise connectors for Databricks (Unity Catalog + Delta Lake, PAT/OAuth M2M) and Snowflake (key-pair and OAuth) — turning warehouse tables into graph nodes without an export hop to a third-party SaaS.
- An MCP server exposing 12 tools (
record_decision,get_causal_chain,find_precedents,run_reasoning, and more), plus agent skill bundles for Claude Code, Cursor, Codex, Windsurf, Cline, Continue, VS Code, and OpenClaw.
The MCP surface is the most immediately useful part for most readers here: it makes an agent's own decision history queryable by the agent, which is a more durable form of memory than the file-based approaches in MEMORY.md or MemPalace.
Read the benchmarks carefully — the README does
The performance table claims node search on a 118,000-node graph going from 24 ms to 0.004 ms — 6,000× faster, plus 6.98× faster semantic deduplication and 63.6% faster candidate generation.
Credit where it's due: the README itself flags the caveat. It states outright that the deduplication and candidate-generation figures are "historical measurements recorded in CHANGELOG.md rather than an automated tests/ assertion," names the hardware (AMD EPYC, 64 GB RAM), and tells you to run pytest tests/vector_store/test_performance_benchmarks.py -s against your own data.
That is more honest than most benchmark tables, and worth saying so. The 6,000× number is also almost certainly an indexing change rather than an optimization — going from a linear scan to an indexed lookup produces exactly that shape of improvement. Real, useful, and not a general speedup of anything else.
What people should ask before adopting
"Is this production-ready?" — It's at v0.6.0. Pre-1.0 with 19 releases, 2,235 commits, and active security work. Suitable for evaluation and internal builds; treat API stability as unguaranteed and pin versions.
"Why more open PRs (30) than issues (24)?" — Unusual, and the contributor list is a clue: @claude, @codex, @Copilot, and @github-code-quality[bot] all appear alongside 26 humans. This is a project absorbing a meaningful volume of agent-generated contributions. Not a criticism — but a reviewer-bandwidth question worth asking of any fast-moving dependency in a compliance path.
"Is 'Open Source Palantir' fair?" — As positioning, it's effective and it communicates the target. As a product comparison, no: Palantir sells forward-deployed engineers, integration work, and government accreditation alongside the software, and that services layer is most of what customers buy. Semantica is the substrate, not the deployment organization.
"Do I need the whole thing?" — No, and this is its best property. Every module is independently importable. Use semantica.provenance for PROV-O lineage alone, or semantica.conflicts for contradiction detection, without adopting the graph store or the Explorer.
"What about the other Semantica?" — There is a separate Hawksight-AI/semantica repo with a similar description. The one covered here is semantica-agi/semantica, published to PyPI as semantica by the team at getsemantica.ai.
Why this direction matters
The bet underneath Semantica is that the binding constraint on enterprise AI stops being capability and starts being defensibility. An underwriting agent that is 3% more accurate but cannot explain a denial is worth less than a slightly worse one that can, once a regulator is in the room. That's the same pressure showing up in EU AI Act and US policy compliance work.
Whether Semantica specifically wins is an open question — v0.6.0, 26 contributors, and an auth advisory in the same week is an early-stage profile. But "store the decision, not just the embedding" is a good idea independent of who ships it, and it's cheap to adopt incrementally.
Related on explainx.ai
- RAG vs agentic RAG — where graph retrieval fits against the alternatives
- RAG vs MCP: complete comparison — retrieval vs tool access
- What is MCP? — the protocol behind Semantica's 12-tool server
- What are agent skills? — the plugin bundles it ships for editors
- MEMORY.md and agent persistence — the file-based alternative to a graph
- MemPalace: local AI memory — another take on durable agent memory
- Interactive codebase knowledge graphs — graphs applied to code
- EU AI Act and US AI policy guide — the regulatory pressure driving this category
Official sources: semantica-agi/semantica on GitHub · semantica on PyPI · docs.getsemantica.ai
Accurate as of August 11, 2026. Repository statistics (~4.5k stars, 499 forks, 24 open issues, 30 open PRs) reflect the repo at time of writing and change continuously. GHSA-j4mq was not yet published in GitHub's public advisory database at time of writing — consult the advisory directly for severity and affected versions rather than relying on this summary. Benchmark figures are the project's own published numbers, partly from CHANGELOG history rather than automated test assertions.