Open-source project
semantica-agi/semantica avatar
semantica-agi/semantica

Semantica 0.7.0: a context graph layer that explains everything except the model

GitHub describes it as Graph-Native Infrastructure for Context and Accountable AI Systems. The repository metadata lists Python as its primary language. The metadata lists the MIT license. This article stays within the project description and details documented in the GitHub repository README.

13,644 stars1,561 forksPythonMIT

At a glance

What is it?
Semantica sits underneath your LLM to build context graphs, run Datalog, Rete, and SPARQL reasoning, and attach W3C PROV-O provenance to every fact. It is deliberately blind to model internals, it caps Python at 3.13, and its Knowledge Explorer refuses protected routes until you generate an API key by hand.
Who is it for?
Adopt Semantica when your audit question is what was fed into the agent, which relationships applied, and which policy fired, and when owning the storage backend matters more than convenience. Skip it if you need an account of the model's own reasoning, or if your environment is already on Python 3.14.
Can I use it commercially?
Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?
Yes. The repository received new commits within the last day.
What is it written in?
Mainly Python, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on October 4, 2026, and from our analysis. They are not legal advice.

Editorial analysis

Explainability stops at the model boundary

Semantica draws a line around model internals and refuses to cross it. Its own note says it does not expose or reconstruct what happens inside the LLM, and that the internal reasoning stays opaque the way it does for any external system. What it explains is the outside: the context fed in, the decision produced, its provenance, the relevant relationships, the applied policies, and the full execution trail. That is a narrower promise than the phrase explainable AI usually implies, and it is also the one that survives contact with an auditor. The rest of the design follows from that boundary. Graph construction, reasoning, and provenance run deterministically without an LLM, and where a model is invoked at all it is optional and vendor-neutral, with OpenAI, Anthropic, Gemini, and others reachable through semantica.llms. The consequence for a reader is precise: if your question is why the model formed that conclusion, this project will not answer it, and no amount of provenance will. If your question is which facts, relationships, and rules were in front of the model when it answered, that is exactly what the trail is built to show.

pip install semantica is the install, and 3.14 is the ceiling

The published install path is one command, taken from a public package index:

bash
pip install semantica

There is no platform specific installer and no documented step between that command and an import in the pages available here. What the command cannot decide for you is the interpreter, because the packaging metadata caps it at requires-python = ">=3.10,<3.14", and the reasoning is concrete on both ends of that range. The floor was raised because every dependency floor already needs 3.10 or newer, with pyarrow>=24, requests>=2.33, and click>=8.2 named in the comment, and a lower floor only made the universal lock file fail to resolve. The ceiling is a missing binary wheel: gensim, pulled in by the graph-embeddings and split-topic extras that ship in all, has no cp314 build, so those extras and the Docker build need a C compiler on 3.14. That failure has already bitten twice, since an automated dependency bump to python:3.14-slim in one pull request compiled gensim from source inside a slim image that has no gcc, and a second bump repeated it. The consequence is that 3.14 is a dead end today, and the cap is coupled across three files on purpose: pyproject.toml, the install matrix, and the image.

The Explorer returns 503 until you set SEMANTICA_API_KEY

The Knowledge Explorer ships as a two-service stack in docker-compose.yml. The explorer service builds from the repository Dockerfile, publishes port 8000, and waits only for the graph service to report started, not to be ready, so a cold database can still produce a failed first request. The graph service is falkordb/falkordb:latest on port 6379 with a named volume falkordb_data mounted at /data. The explorer reads its backend from FALKORDB_HOST and FALKORDB_PORT, defaults ALLOWED_ORIGINS to http://localhost:8000 and http://127.0.0.1:8000, and carries one gate that the compose file spells out in a comment: the Explorer refuses all protected routes and returns 503 until SEMANTICA_API_KEY is set. The key is not generated for you, so you create it yourself before the first call. A second variable, SEMANTICA_ALLOW_ANONYMOUS, defaults to false and bypasses the key entirely, and the comment marks it as trusted local-only setups. That is the sharp edge in this file: one variable turns off authentication for every protected route, so anything reachable beyond your own machine should keep it at false.

Decisions become objects you can search by precedent

The unit of the system is not the fact, it is the decision. Every decision is treated as a first-class object that is traceable, searchable by precedent, and causally linked, which is the difference between a log and something you can actually query when a reviewer asks whether a case has come up before. Provenance rides on the facts rather than beside them: W3C PROV-O on every fact, exportable to JSON, CSV, or RDF. Those three formats are the whole export list, so a team whose downstream tooling expects something else is doing its own conversion. The README also carries a worked recipe for an audit trail on a regulated decision, which tells you the intended entry point for that story. Conflict handling is explicit too, aimed at the case where two sources disagree: conflicting facts get flagged and duplicates get merged instead of silently overwritten, so a knowledge engineer inherits a visible dispute rather than a quietly flattened one. The cost of that choice is visible too, since unresolved conflicts stay in the graph as something your queries and reasoning paths have to deal with, not a problem that disappeared during ingestion.

Ontologies are enforced with SHACL, generated as OWL, published as SKOS

Meaning is handled with W3C standards rather than with prompt text, and the project names the three it uses: OWL for ontologies, SHACL for constraints, and SKOS for controlled vocabularies. Governance features are grouped under SHACL constraints, conflict detection, compliance rules, OWL generation, and SKOS vocabularies, all reachable through a visual editor. That combination is the part aimed at teams already living in the lakehouse, where the goal is turning tables that sit in Databricks, Snowflake, or SAP into a governed, lineage-tracked knowledge graph without exporting the data to a third-party SaaS. What the available pages do not give you is the operating detail that adoption usually stalls on. There is no statement here about how existing vocabularies are migrated in, how a broken constraint blocks a write, or how the visual editor is authenticated relative to the Explorer's API key. Treat those as open questions to answer from docs.getsemantica.ai before committing a schema to it, because a constraint set that turns out to need different rollout semantics is expensive to change after ingestion.

Reasoning runs on Rete, Datalog, and SPARQL with no model in the loop

The reasoning layer is deterministic and named in four parts: forward chaining, a Rete network, Datalog, and SPARQL, each with a fully explainable path. Because these engines do their own work, graph construction, reasoning, and provenance are described as requiring no LLM at all, and that is what makes the explainability claim in this project different from the usual one. The README's own framing for why this exists is that most AI agents run on embeddings rather than meaning, returning similarity scores with no structure, no relationships, and no way to explain why a result came back. Here a query returns a path you can read. Two limits are worth naming plainly. The comparison in the README is rhetorical rather than measured, since it contrasts an approach with a category rather than reporting numbers against named alternatives. And the page index includes a Performance section that the available text does not quantify, so no throughput or latency figure should be assumed for your own graph size. Ask for measurements on your data before you commit a latency-sensitive service to it.

Two version numbers in one repository, and an npm manifest marked private

The repository ships a Python distribution and a Node manifest side by side, and they do not agree. pyproject.toml declares version = "0.7.0" for the package named semantica, while package.json in the same root declares version "0.1.0" with private set to true. That manifest is not a published JavaScript library: its keywords include pi-package and mcp, and it points a pi skills field at plugins/skills, so it registers agent and MCP skills rather than shipping an installable npm product. The Python build is also pinned tightly, with setuptools==84.0.0 and wheel==0.48.0 as build requirements, and the lock file is uv.lock, which is consistent with the comment about the universal lock failing to resolve at a lower Python floor. For a reader, the consequence is about where you look for the truth about a version: the Python metadata and the release tags are authoritative, the npm version field is not a second release channel, and the skills bundle is what the manifest is for.

A Production/Stable classifier on a 0.7.0 package

The metadata sends mixed signals about maturity, and you should read both halves. The classifiers include Development Status :: 5 - Production/Stable, alongside Intended Audience entries for Developers, Science/Research, and Information Technology, and Operating System :: OS Independent. Meanwhile the version is 0.7.0, the most recent tags are v0.7.0 on 2026-09-22, v0.6.8 on 2026-09-05, and v0.6.7 on 2026-08-28, and the last push to main is dated 2026-09-29, so the project is being worked on. The release cadence is roughly weekly across the v0.6.x line. Around the code, the repository is unusually well equipped for regulated buyers: ARCHITECTURE.md, CHANGELOG.md, RELEASE_NOTES.md, SECURITY.md, SUPPORT.md, CONTRIBUTORS.md, a CITATION.cff, a cookbook directory, an examples directory with Arrow, Parquet, and capability-gap scripts, a checkov configuration, an osv-scanner configuration, a pre-commit configuration, and an install matrix workflow. The tension to keep in view is that a 0.x version carrying a stable classifier invites procurement to read a promise the version number contradicts, so pin an exact version and read RELEASE_NOTES.md at that version.

Editorial conclusion

Adopt Semantica when your audit question is what was fed into the agent, which relationships applied, and which policy fired, and when owning the storage backend matters more than convenience. Skip it if you need an account of the model's own reasoning, or if your environment is already on Python 3.14. Before deploying the Explorer anywhere but a laptop, set SEMANTICA_API_KEY with openssl rand -hex 32 and leave SEMANTICA_ALLOW_ANONYMOUS at its default of false, and read RELEASE_NOTES.md, since the README promises features the truncated pages do not yet detail.

Frequently asked questions

What is semantics in simple terms?

In this project's framing, semantics is the layer underneath an LLM where relationships and definitions live, rather than similarity scores. Semantica describes itself as the semantic and context layer beneath your LLM, vector store, and agent framework, turning fragmented data into a queryable Context Graph and knowledge graph.

Is "Semantica" a real word?

The project pages do not define the word, they only use it. What the repository establishes is a Python package named semantica, MIT licensed, installed with pip install semantica, with its README served in twelve languages through readme-i18n.

semantica vs palantir

No comparison is published. The README positions the project as an alternative to expensive enterprise platforms for regulated teams that cannot ship a black box or send their data to someone else's SaaS, and it names Databricks, Snowflake, and SAP as the warehouse side rather than any competitor.

semantica vs graphify

Graphify is not mentioned anywhere in the available pages. What Semantica states about itself is polyglot graph storage with RDF and LPG support, W3C standards, and zero vendor lock-in, and its own stack ships FalkorDB behind the Knowledge Explorer.

semantica vs sintaxis

There is no syntax comparison in the README. The closest thing to a claim about structure is its reasoning layer, described as forward chaining, a Rete network, Datalog, and SPARQL with a fully explainable path, all running deterministically without an LLM.

Official sources

  1. Official documentation
  2. Official README
  3. Project repository
  4. Release notes
Add this badge to your README

If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/semantica-agi-semantica.svg)](https://hysenlabs.com/projects/semantica-agi-semantica)