Technology
Language models for fluency. Symbolic logic for verification. Knowledge graphs for grounding. One stack, designed so every output can be traced, validated, and defended.
The premise
LLMs are powerful.
They are also wrong about things, fluently
The strength of large language models is their fluency over open-ended language. The weakness is that fluency is not a guarantee of correctness — and inside the model, there is no mechanism that distinguishes a true claim from a confidently phrased one.
For consumer applications, this is acceptable. For an enterprise that has to answer to auditors, regulators, or its own compliance team, it is not.
The standard industry response has been to wrap the LLM in retrieval (RAG), filtering (guardrails), or human review. These help, but they treat the model as a black box and patch around it. The output is still produced by an unconstrained generative process — and the constraints are advisory, not architectural.
We took a different path.
What neurosymbolic means
A neurosymbolic system combines two ways of producing answers:
Large language models — handles open-ended language, pattern recognition, and synthesis. It is what makes modern AI fluent and broadly capable.
The symbolic side
Logic, types, contracts, knowledge graphs — handles rules, constraints, and verifiable structure. It is what makes outputs inspectable and consistent.
Most current AI products are neural-only, with symbolic checks bolted on as an afterthought (filters, validators, post-hoc parsers). We build the symbolic layer into the core of the system, so it controls what the neural side is allowed to produce — not just what slips through afterwards.
The result is a stack where the language model still does what it does best, but operates inside a structure that can verify, log, and constrain its outputs by construction
Why this matters for enterprises
Three properties that fall
out of the architecture
Provenance
Because retrieval, reasoning, and validation are separate stages with their own logs, the path from query to output can be reconstructed deterministically. Every claim can be mapped to the passage that supports it. Every constraint applied is recorded.
Inspectability
Because the symbolic layer expresses rules as data — types, contracts, graph structures — the behaviour of the system can be examined and modified without retraining the underlying model. The neural component is replaceable; the rules of operation are not bound to a specific model version.
These three properties are what compliance, audit, and risk-management functions actually ask for. They are also what most enterprise AI deployments cannot produce
System architecture
Four layers, each with a defined contract
Production benchmarks against industry baselines, run on enterprise hardware.
The contract layer
The component that distinguishes this stack
The contract layer is the architectural primitive that separates this system from prompt-engineered or guardrail-wrapped LLM stacks. It is conceptually adapted from Design by Contract (DbC) and dependent type theory, applied to the LLM-call boundary.
A contract over an LLM call is a tuple of three specifications:
01.
Pre-conditions
Are predicates over the input space that must hold before the call is dispatched. In practice, this is where retrieval evidence is asserted — a contract may require that retrieved passages cover all entities mentioned in the query, or that at least one passage of a specified provenance class is present. If pre-conditions fail, the call is not made; the system either retrieves additional evidence or short-circuits to a refusal.
02.
Post-conditions
Are predicates over the output space that must hold after the call returns. These include type conditions (the output must conform to a specified schema), referential conditions (every cited claim must correspond to a retrieved passage), and semantic conditions (domain-specific predicates encoded against the output structure).
03.
Invariants
Are predicates over the relation between input and output. They express guarantees the call must preserve — for example, that no entity present in the output was absent from the retrieval evidence, or that no claim in the output contradicts a constraint expressed in the knowledge graph
Contract evaluation is performed by a symbolic engine, not by another LLM call. This is intentional: the validation cannot itself hallucinate, because it operates on structured representations rather than generating language. When validation fails, the diagnostic is structured — which condition failed, on which output element, with what evidence — and can be fed back to the reasoning layer as a re-prompt or surfaced to the calling application as a typed error.
The published specification of the contract layer is in Trustworthy Agent Design (arXiv:2508.03665, 2025).
The knowledge graph layer
Hybrid-driven reasoning over enterprise knowledge
Enterprise data is rarely well-modelled by either pure vector indexes or pure structured graphs. Vector indexes capture semantic proximity but lose entity structure. Graphs capture entity structure but require explicit construction and maintenance.
Our knowledge graph layer is built on a hybrid-driven reasoning architecture (HyDRA) that uses LLM-driven extraction under symbolic constraints to construct and maintain the graph. The construction process is itself contract-controlled: the LLM proposes entity and relation candidates, and the symbolic layer validates them against schema constraints, type specifications, and referential conditions before they are committed to the graph.
This means three things in practice:
Construction is incremental and traceable.
Every entity and every relation in the graph is annotated with the source passage, the contract that validated it, and the timestamp of construction. A user-facing query can resolve not only the answer but the full evidential chain through the graph.
Schema evolution is safe
The contract specifications for the construction process are versioned. When the schema changes, the system can identify which existing graph elements were validated against an outdated contract, and selectively re-validate them
Retrieval over the graph is constraint-aware
A query against the graph is not only a pattern match — it is a constraint satisfaction problem. The retrieval layer can express requirements such as "return only entities whose source provenance falls within the user's permitted scope" as part of the query itself, rather than filtering after the fact.
The published specification of the graph construction architecture is in
HyDRA - Knowledge Graph Construction (arXiv:2507.15917, 2025).
Deployment model
Cloud-optional, not cloud-dependent
The full stack is designed for on-premise deployment. This is not a feature flag — it is the default configuration, and the cloud-hosted alternative is the variant.
Model weights deploy on your infrastructure
The reasoning layer operates against an LLM that runs on hardware you control. We support multiple backends, including open-weight models (Llama, Mistral, Qwen families) and customer-provided models. There is no architectural dependency on a third-party model API.nts, structured databases, knowledge graphs, internal wikis — retrieved together, reasoned over jointly.
The retrieval and graph layers operate against your indexed data
Indexing is a one-time operation against your document repositories, databases, and structured sources. Indexed data does not leave your environment. Re-indexing is incremental.
Contracts are versioned configuration that lives in your environment. The provenance log is a structured store under your control, with retention and access policies you define.
No telemetry to ExtensityAI by default
The deployed stack does not phone home. Operational metrics, error reporting, and usage data are local. If you want to share metrics with us — for joint diagnostics or roadmap input — that is an explicit configuration, not a default.
Cloud deployment is supported for use cases where on-premise is not required (typically: pilots, non-sensitive knowledge bases, or hybrid setups where the sensitive components stay on-premise and the rest run cloud-side). The architecture is the same. The boundary moves.
What is open source
The neurosymbolic engine is public. Read it. Run it. Verify what we describe
The core neurosymbolic engine — the contract layer, the symbolic validation runtime, and the framework primitives that this stack is built on — is published as the open-source SymbolicAI framework, under BSD-3.
Three things this gives you:
Independent verification
The architectural claims on this page are inspectable in code. Where we describe a contract evaluation mechanism, you can read the implementation. Where we describe how validation diagnostics are generated, you can run it.
Auditability of the foundation
For organisations whose risk function requires source-code review of AI components, the foundation layer is reviewable today, without an NDA.
Continuity
Open-source release is a commitment that the foundation layer is not held hostage by our commercial roadmap. If our priorities shift, the engine remains in the public record.
The proprietary layers above the open-source foundation — the enterprise integrations, the deployment tooling, the consulting-developed contract libraries for specific domains — are part of the commercial offering. The line between what is open and what is commercial is documented and consistent.
GitHub: github.com/ExtensityAI/symbolicai
Substance
The architecture and the research
are the same artifact
The technology described on this page is grounded in published research. The relevant work:
Trustworthy Agent Design
A practical whitepaper on designing trustworthy LLM agents with contract-based controls that validate inputs, outputs, and semantic requirements before agents act.
HyDRA - Knowledge Graph Construction
A whitepaper on HyDRA, a hybrid-driven reasoning architecture that uses collaborative agents, competency questions, and verifiable contracts to automate reliable knowledge graph construction.
SymbolicAI Framework (Open Source)
A developer-focused whitepaper on SymbolicAI, the open-source neurosymbolic framework for composing LLMs with Python-native symbolic abstractions, semantic primitives, and contract validation.
Full publication list available on request.
