Neuro-Symbolic AI:
A Practitioner's Taxonomy
In the last two years, we've been compared to graph databases. To vector RAG systems. To Python scripts doing NLP.
Each comparison taught us something: there's a terminology gap in this space so wide that fundamentally different architectures get lumped together. When a Neo4j instance and an ontology-driven reasoning system both get called “knowledge graphs,” buyers can't evaluate the difference. Neither can builders.
That's why we wrote this.
Not to claim our approach is the only valid one—but to share what we learned while figuring out where we actually fit. Building reliable AI systems isn't a spectrum with “more neural” on one end and “more symbolic” on the other. It's a multi-dimensional set of tradeoffs, and the right choice depends on the problem you're solving.
This article is our attempt to map that landscape. A framework to help those building agents understand the choices they've made, the tradeoffs they've accepted, and the paths still open to them.
“You can't compare architectures you can't distinguish.”
Issue DetectedThe vocabulary is broken. Not imprecise. Not evolving. Broken.
The terms we use to describe AI architectures have been stretched, co-opted, and marketed until they communicate nothing. Every vendor claims the same words. No two mean the same thing. This isn't pedantry. When the language fails, architecture decisions follow the marketing—not the problem.
Thin application layer over API calls
Dismissive slur for anything not training custom models
Formal representation of entities, relationships, and semantics
Any database with connections between things
Retrieval using graph traversal for contextual grounding
Marketing label for 'we added a graph somewhere'
Principled integration of neural pattern recognition and symbolic reasoning
"We use an LLM and also have some rules"
Autonomous multi-step reasoning and tool use
Any LLM that calls an API
ERR_FALSE_EQUIVALENCE
ERR_TECH_DEBT
The Extrapolation Problem
CogniSwitch learned this the hard way. We build ontology-driven systems. But for years, we struggled to explain what that actually meant. Then came the moment of clarity: we started getting compared to Neo4j.
Neo4j is a graph database. It's infrastructure. But because we both used the word “knowledge graph,” procurement saw equivalence. The underlying architectures were fundamentally different.
Architecture decisions made on marketing.
Teams choose “Graph RAG” because it sounds sophisticated, not because they've evaluated whether graph traversal solves their actual retrieval problem. Valid approaches die in procurement because the terminology carries baggage.
The cost isn't just failed projects. It's misallocated projects—teams building the wrong architecture for their problem because the language didn't help them see the difference.
What Clarity Requires
Escaping the terminology trap requires more than better definitions. It requires a framework that exposes the actual tradeoffs between approaches.
It is not a spectrum. Neural on one end, symbolic on the other, “hybrid” in the mushy middle—this framing implies a single axis of sophistication. Neither is true. The reality is multi-dimensional.
Six Dimensions.
Three Questions.
The question isn't where you land on a spectrum. It's which tradeoffs your problem requires.
Beyond the Spectrum
The instinct is to draw a line. Neural on one end, symbolic on the other. This framing is broken. Moving toward symbolic isn't always “better,” and balance isn't always optimal. Different architectures optimize for different things.
Answer Consistency
“The question: If I ask the same thing tomorrow, do I get the same answer?”
You can't debug what you can't reproduce. You can't test what changes between runs. In regulated environments, inconsistency isn't a UX problem—it's a compliance failure.
High consistency often means constraining the system's flexibility. The same determinism that makes outputs reproducible can make the system brittle to novel inputs.
Decision Traceability
“The question: Can you show why the system said what it said?”
When a compliance officer asks why the system recommended X, "the embedding space placed those concepts close together" is not an acceptable answer.
Full traceability requires explicit reasoning structures—which means more upfront investment and less flexibility in how the system can respond.
Knowledge Explicitness
“The question: Where does domain expertise actually reside?”
If you can't inspect what the system "knows," you can't verify it's correct. You can't update it when regulations change. You can't explain it to auditors.
Explicit knowledge requires someone to make it explicit. That's work—often significant work involving domain experts.
Handling Ambiguity
“The question: What happens when the query is messy, novel, or underspecified?”
Real users don't speak in perfect queries. Production traffic is chaotic. A system that only works with well-formed inputs will fail in deployment.
High ambiguity handling often requires the system to infer intent—which can conflict with consistency and traceability.
Setup Investment
“The question: What does it take to get this working for my domain?”
Time-to-value matters. Team capabilities matter. Not every organization has six months and a knowledge engineering team.
Low setup investment often means lower reliability guarantees. You can ship fast, but you inherit whatever inconsistencies exist in your source documents.
Change Tolerance
“The question: When domain knowledge updates, how painful is the fix?”
Regulations update. Products evolve. Policies change. A system that's painful to update becomes a system that's out of date.
High setup investment often correlates with high change cost. The same formalization that enables reliability creates maintenance overhead.
The Tradeoff Reality
Here's what the framework exposes: you don't need to max all six dimensions. You probably shouldn't try.
A marketing chatbot doesn't need the traceability of a clinical decision support system. A creative writing assistant should have high ambiguity tolerance and low consistency.
Claiming you need maximum reliability, maximum flexibility, and minimum investment is a sign you haven't defined the problem precisely enough.
> The right question isn't “which architecture scores highest?”
> It's “which dimensions does my specific problem actually require?”
Each claims some version of “neuro-symbolic.” Each means something different.
- [graph-rag]1. Graph RAG
- [rules-llm]2. Rules + LLM (Guardrails Pattern)
- [nlp-pipelines]3. NLP Pipelines + Neural (Classic Hybrid)
- [kg-llm]4. Knowledge Graphs + LLM
- [ontology-driven]5. Ontology-Driven Systems
The Middle Path
We're concerned with the architectures that attempt to combine both—the so-called neuro-symbolic approaches. Not because hybrid is inherently superior, but because this is where the most consequential confusion exists for teams building AI for regulated industries.
1. Graph RAG
What It Is
Graph RAG extends traditional retrieval-augmented generation by using graph structures to traverse relationships between documents or concepts during retrieval. Instead of just finding similar chunks via vector search, the system can follow connections—"this document references that policy, which supersedes this older version." The graph provides navigation. The LLM provides synthesis.
Where It Shines
- Multi-hop questions across document sets
"What's our refund policy for products purchased under the 2023 partnership agreement?" requires traversing from product → agreement → policy. Graph RAG can follow those links.
- Internal knowledge bases with cross-references
Engineering wikis where Architecture Doc A references Design Doc B which references API Spec C. The graph surfaces connected context that vector search would miss.
- Document versioning and supersession
Legal or compliance teams tracking which policy version is current. The graph can encode "v3 supersedes v2" and prioritize accordingly.
Where It Breaks
- Clinical decision support
A nurse asks "Should this patient receive Antibiotic X?" The graph retrieves connected nodes. But the LLM synthesizes the final recommendation. Two nurses asking about similar patients might get different answers. That's not acceptable.
- Compliance audit responses
Auditor asks "Why was this claim denied?" Graph RAG can show what documents were traversed. It cannot show the logical reasoning chain that led to denial. "The LLM connected these sources" doesn't satisfy a regulator.
- Conflict resolution in source material
Your policy documents contradict each other. The graph retrieves both. The LLM picks one. On what basis? You can't explain it, you can't reproduce it, you can't defend it.
Ask the vendor: "If the graph traversal retrieves conflicting information from two connected nodes, how does the system decide which is authoritative?"
2. Rules + LLM (Guardrails Pattern)
What It Is
The guardrails pattern adds a deterministic rules layer that validates, filters, or constrains LLM outputs. The LLM generates freely; the rules catch what shouldn't get through. Think of it as a safety net, not a steering wheel.
Where It Shines
- Customer-facing chatbot safety
Preventing the bot from discussing competitors, making unauthorized promises, or straying into topics outside its scope.
- PII and sensitive data filtering
Blocking outputs that contain social security numbers, patient identifiers, or confidential financial data.
- Format and structure enforcement
Ensuring every response includes a disclaimer, follows a required template, or stays within character limits.
Where It Breaks
- Prior authorization decisions
Rules can block obviously wrong outputs ("never authorize experimental procedures") but can't verify the reasoning is correct.
- Medical triage advice
Rules can catch "take this medication" but can't catch subtly inappropriate guidance like suggesting a wait-and-see approach for symptoms that warrant urgent care.
- Financial product suitability
Customer asks for investment advice. Rules block explicit recommendations but can't evaluate whether the LLM's framing subtly pushes toward unsuitable products.
Ask the vendor: "What percentage of incorrect outputs do your guardrails catch before they reach users?"
3. NLP Pipelines + Neural (Classic Hybrid)
What It Is
The classic hybrid approach: symbolic NLP components (parsing, named entity recognition, coreference resolution) process input into structured form, then neural components handle downstream tasks. Or the reverse—neural components extract information, symbolic rules post-process it. This predates the LLM era.
Where It Shines
- Invoice and receipt processing
Extracting vendor name, date, line items, totals from thousands of invoices daily. The format is predictable, and pipeline efficiency matters at scale.
- Contract metadata extraction
Pulling party names, effective dates, termination clauses from legal documents. NER tuned for legal language outperforms generic LLMs on structured extraction.
- Resume parsing for ATS systems
Extracting skills, experience, education into structured fields. High volume, predictable format, narrow task—pipelines excel here.
Where It Breaks
- Conversational patient intake
Patient says "My stomach's been killing me since that sketchy taco truck last Tuesday." Pipeline NER looks for symptom entities but struggles with colloquial language and implied causation.
- Unstructured customer feedback analysis
"The app is fine I guess but the whole vibe is off." Sentiment analysis says "neutral/negative" but can't surface actionable insight.
- Multi-format document ingestion
Processing clinical notes that come as structured forms, free-text narratives, and scanned PDFs. The pipeline tuned for one format fails on others.
Ask the vendor: "What happens when an input doesn't match your expected format or entity types?"
4. Knowledge Graphs + LLM
What It Is
Knowledge graphs store entities and their relationships in a structured, queryable format. The LLM queries the graph, retrieves relevant subgraphs, and synthesizes responses grounded in that structured data. This is more than Graph RAG—the graph isn't just navigation, it's the knowledge representation itself. But meaning is implicit.
Where It Shines
- Enterprise org chart and people queries
"Who in the London office reports to Sarah and has worked on Project Atlas?" The graph holds org structure, project assignments, locations. Traversal finds the answer precisely.
- Product catalog and compatibility questions
"Which accessories work with Model X and are currently in stock?" Entity relationships give structured answers.
- Research literature navigation
"Show me papers that cite Study A and were authored by researchers at Institution B." The citation graph and author affiliations are explicit.
Where It Breaks
- Drug interaction checking
Graph contains "Drug A interacts_with Drug B." But does that mean "avoid combination" or "monitor closely"? The relationship label doesn't carry the semantics.
- Loan eligibility determination
Eligibility isn't just traversal—it's conditional logic. "Eligible if income > X AND credit_score > Y." The graph stores data; it doesn't encode decision rules.
- Insurance claim adjudication
Claim entity linked to policy, patient, procedure. But adjudication requires interpreting policy language, applying exclusions, evaluating medical necessity.
Ask the vendor: "If two entities in your graph have conflicting attributes, how does the system determine which is correct?"
5. Ontology-Driven Systems
What It Is
Ontology-driven systems go beyond knowledge graphs by formalizing not just entities and relationships, but the meaning of those relationships, the constraints that govern them, and the rules for valid inference. The LLM's role shrinks. It handles natural language input/output. But it doesn't decide what's true. The ontology does.
Where It Shines
- Clinical protocol adherence checking
"Did this provider follow antibiotic stewardship guidelines?" The system evaluates against formal criteria and returns a traceable yes/no with evidence.
- Regulatory compliance validation
"Does this financial product disclosure meet SEC requirements?" Validation is deterministic; the audit trail shows exactly which requirements were met or violated.
- Prior authorization decisioning
The ontology encodes payer policies: covered indications, required prior treatments. The decision follows explicit logic, not LLM interpretation.
Where It Breaks
- Open-ended research exploration
"What are the emerging trends in sustainable packaging?" This requires synthesis across unstructured sources. Ontologies encode what's known; they don't discover what's emerging.
- Customer service with high query variability
Consumer asks "I'm kinda frustrated with the thing I bought, can you help?" The query is vague, emotional. Ontology-driven systems want precision.
- Rapidly evolving domains
Startup building AI for a market that's changing quarterly. By the time the ontology is formalized, the domain has shifted.
- Low-stakes, high-volume interactions
Internal chatbot for office FAQs. Building an ontology is massive overkill. A simple RAG setup handles this fine.
Ask the vendor: "Show me the reasoning chain for this decision—not the sources retrieved, but the logical steps from query to conclusion."
Interactive Architecture Comparison
Select architectures to compare their dimensional profiles. The radar chart visualizes tradeoffs across all six dimensions.
Select Architecture
Compare With
Comparing the Shapes
No architecture wins on all dimensions. The diagonal tradeoff is clear: reliability and explicitness come at the cost of flexibility and investment.
| Architecture | Consistency | Traceability | Explicitness | Ambiguity | Setup | Change |
|---|---|---|---|---|---|---|
| Graph RAG | Low-Mid | Mid | Low-Mid | Mid-High | Mid | Mid |
| Rules + LLM | Low-Mid | Low-Mid | Low | Mid-High | Low-Mid | Mid |
| NLP Pipelines | Mid | Mid | Mid | Low-Mid | Mid-High | Low-Mid |
| KG + LLM | Mid | Mid | Mid | Mid | Mid-High | Mid |
| Ontology-Driven | High | High | High | Low-Mid | High | High |
Frequently Asked Questions
What's the difference between Graph RAG and Knowledge Graphs + LLM?
Graph RAG uses graph structure primarily for navigation—traversing relationships to gather better context for retrieval. The nodes typically contain unstructured text (document chunks). Knowledge Graphs + LLM uses graph structure for representation—entities have types, relationships have labels, the structure itself carries meaning. The graph is the knowledge, not just the index.
If Rules + LLM gives me determinism, why would I need Ontology-Driven?
Rules + LLM gives you determinism at the filter layer. The rules are deterministic. The LLM generation that precedes them is not. Ontology-Driven systems give you determinism at the reasoning layer. The system doesn't generate an answer and then check it—it derives the answer through formal inference.
Isn't a knowledge graph just a database with relationships?
It can be. And that's the problem. When vendors say "knowledge graph," they might mean a Neo4j instance (database) or a formally modeled ontology (reasoning system). The question to ask: "What do your relationships mean? If I query 'contraindicated,' how does the system know what to do with that information?" If the answer involves formal definitions and constraints, it's more than a database.
“We'd rather you choose well than choose us.”
A Specific Choice, Not a Universal Claim
We've spent the previous sections mapping a landscape without crowning a winner. That was deliberate. No architecture is universally optimal.
But CogniSwitch exists, and we made choices. This section explains what we chose and why—not as a pitch, but as a case study in matching architecture to problem.
01. Extraction
Ontology-governed, LLM-assisted.
LLMs mine documents, but ontologies constrain them. Output is structured knowledge, not text chunks.
02. Execution
Deterministic execution.
Rules engine handles inference. Explicit, auditable, consistent. Same input, same output, every time.
03. Evolution
Dynamic knowledge management.
Living system. New knowledge ingested, old deprecated. Adapts as domains change.
Where We Land
Strong on reliability and explicitness. Weaker on flexibility. That's the tradeoff we chose.
Why Regulated Industries
Here's what makes this viable: we didn't have to build the ontologies from scratch.
The domains that need this level of rigor are the same domains that have invested in the ontological infrastructure to support it. We're leveraging what already exists.
The Honest Tradeoffs
Ontology selection is where we spend the most time.
Choosing the right ontologies, mapping them to customer-specific requirements, validating coverage—this is real work. It's not something we hide or automate away.
Not suited for domains without established ontologies.
If your industry doesn't have formal knowledge standards, building them from scratch is expensive. We're not the right fit for a domain that's still figuring out its own vocabulary.
Not suited for exploratory or creative use cases.
If you want a system that imagines, riffs, or generates novel ideas, our architecture will feel restrictive. We optimize for correctness, not creativity.
Not a weekend project.
You won't spin this up in a hackathon. The value comes from the rigor; the rigor takes time to establish.
What This Enables
Audit trails that satisfy regulators
Every decision traces to formal rules, explicit knowledge, and source documentation. When compliance asks "why did the system say this?", there's an answer.
Consistency guarantees
Same question, same answer. Not because we got lucky with prompt engineering, but because the reasoning path is deterministic.
Evolvable knowledge
New guidelines get ingested. Deprecated policies get sunset. The system evolves without rebuilding from scratch.
Portable intelligence
Built on open standards. The knowledge graph and ontologies aren't locked in our proprietary format. If you need to move, you can.
We're betting on a future where regulated industries demand more than “good enough” accuracy.
> That audit requirements will tighten, not loosen.
> That the gap between demo and production only closes with reasoning proof.
> That ontological infrastructure makes formal approaches viable.
“If your problem fits this shape, we should talk. If it doesn't, we'd rather point you to an architecture that fits than sell you something that won't.”
“Some choices feel irreversible. They're not.”
Not Everything Needs Governance
Let's be clear: if you're building a video generation platform or a creative writing assistant, compliance frameworks aren't your concern. The overhead of formal knowledge structures will slow you down without adding value.
This essay isn't for every AI application. It's for a specific category: systems making decisions that affect health, money, and regulatory standing. Systems where “the model said so” isn't an acceptable answer.
A Message to Agent Builders
You've made choices. That's fine. The neural-heavy architectures you chose got you to market and let you demonstrate value. They weren't wrong.
But now you're facing questions your architecture wasn't designed to answer. “Can you prove why the system said that?” “Where's the audit trail?”
Here's the architectural insight that matters:
Governance and compliance don't have to live inside your core application. They can stand next to it.
Your vector RAG pipeline, your LLM orchestration—these can remain. The governance layer can be an independent stack that evaluates, monitors, and documents what your system produces. You don't have to rebuild your application to add governance. You have to add governance infrastructure alongside it.
The terminology is broken. "Neuro-symbolic," "knowledge graph," "agentic"—these terms have been stretched until they communicate nothing. We tried to restore meaning by showing what different architectures actually do, not what they claim.
Six dimensions. Three questions. Not a ranking of better and worse, but a tool for matching architecture to problem. What does your specific use case require? Which tradeoffs can you accept?
Five architectures, each with strengths and limitations. No universal winner. Just shapes that fit different problems.
The Questions That Matter
If you're building AI for regulated industries, these are the questions to ask—of vendors, of your own team, of any architecture you're evaluating:
Where does meaning live?
In the model weights? In retrieved documents? In formalized ontologies?
The answer determines your traceability ceiling.
What happens when sources conflict?
Does the LLM guess? Do rules arbitrate? Is there a formal resolution mechanism?
The answer determines your consistency guarantee.
Can you show the reasoning chain?
Not just what was retrieved—but why it led to this conclusion.
The answer determines your audit readiness.
What's the cost of being wrong?
If a bad answer means a frustrated user, that's different from a compliance violation or patient harm.
The answer determines how much rigor you need.
What governance infrastructure exists independent of your core application?
If governance is embedded in your LLM pipeline, you're coupling two different problems.
If it's adjacent, you have flexibility.
“The tension between flexibility and consistency, between speed and rigor, between neural pattern-matching and symbolic reasoning—these are enduring design choices, not temporary limitations.”
For those building in regulated industries, the question isn't whether to address governance. It's when, and how.