a chat with Gemini to explore this leading-edge AI-related concept.
State of the Art in Neurosymbolic Land - by Kurt Cagle
takeaways from GraphCon 2026 in Seattle, highlighting a quiet industry consensus: the tech stack is shifting toward neurosymbolic AI—fusing neural networks with deterministic knowledge graphs to solve the LLM grounding problem.
Key Points
The Grounding-Layer Consensus: Industry architectures now treat deterministic graphs as a mandatory foundation under LLMs rather than an open debate, moving neurosymbolics from research into real-world investment.
Markdown as the "New HTML": Documents encapsulating YAML metadata, code, and narrative prose are becoming the primary structure for information spaces, serving as human-readable context and direct entry points for LLMs.
Semantics & RDF vs. LPG: Graph architectures are converging toward W3C standards (ontologies, taxonomies, reification, and graph containment), pressing schema-less property graphs to adopt formal semantics.
MCP as the Control Plane: The Model Context Protocol (MCP) is emerging as the control plane for agentic graph architectures, operating across a protocol communication layer and a underlying graph manipulation layer (e.g., SPARQL, SHACL validation).
Convergence on Holons: Multiple organizations are independently adopting "holons"—encapsulated knowledge graphs pairing a core knowledge graph with an evolving event graph.
Reification & Hypergraphs: Assertions about assertions (reification) make hypergraphs
tractable and bridge human narrative language with structured machine reasoning.Companion Piece:
Fluents, Projections, and Observables
GraphCon — GraphGeeks
The "RDF-versus-LPG war" refers to a long-standing debate and rivalry in the graph database community over two fundamentally different data architectures used to build knowledge graphs and graph databases:
1. RDF (Resource Description Framework)
The Concept: Standardized by the W3C (Web Consortium). Information is stored as "triples" in a Subject
$\rightarrow$ Predicate $\rightarrow$ Object format (e.g., Alice -> knows -> Bob).Core Focus: Semantic reasoning, strict data models (ontologies/taxonomies), data interoperability, and global standardization using URIs/IRIs.
Database Type: Often referred to as Triple Stores (e.g., GraphDB, Stardog).
Strengths: Ideal for enterprise integration, global semantic standards, inference/reasoning, and unifying disparate data sources.
Weaknesses: Historically verbose, complex to set up, and struggles to attach metadata directly to relationships without creating complex workarounds (reification).
2. LPG (Labeled Property Graph)
The Concept: Data is modeled intuitively as nodes and directed relationships.
Crucially, both nodes and relationships can directly hold key-value properties/metadata (e.g., Alice -> [KNOWS {since: 2020}] -> Bob).Core Focus: Performance, simplicity, developer usability, and fast graph traversals.
Database Type: Graph databases like Neo4j, Memgraph, or TigerGraph.
Strengths: Highly performant for real-time operational analytics, intuitive for software developers, and flexible schema-less design.
Weaknesses: Lacks built-in W3C semantic standards, universal identifiers, or native inferencing logic, making data sharing and cross-system standardization harder.
Key Points of Conflict in the "War"
Purity & Semantics vs. Performance & Usability: RDF advocates argued LPGs were "dumb" data structures lacking formal meaning or data integrity rules. LPG advocates argued RDF was overly academic, slow, unnecessarily complex, and impractical for real-world software engineering.
Metadata Modeling: In LPG, adding properties to an edge is trivial (e.g., timestamp on a transaction).
In pure RDF, doing the same required cumbersome patterns or extra nodes.
Context in the Article
In the article, Kurt Cagle notes that this "war" is fading because the industry is reaching a middle ground:
LPG vendors (like Neo4j) are adding formal semantic structures, ontologies, and reification capabilities to support complex AI and LLM reasoning.
Modern standards like RDF* (RDF-Star) allow RDF to support properties on relationships natively, bridging the gap between the two worlds.
This highlighted excerpt argues that Markdown files are replacing HTML as the universal standard for organizing information in the age of AI.
To understand why, here is a breakdown of what Kurt Cagle means by this shift:
1. The Analogy: HTML vs. Markdown
In the Web Era (HTML): Websites were built using HTML to render text, link pages, and embed visual media for human eyes reading via web browsers.
In the AI Era (Markdown): Systems are built using Markdown to structure information for both human eyes and AI Large Language Models (LLMs).
2. Anatomy of the "New Document"
The author describes a unified document format that serves multiple roles at once:
YAML Header (Metadata): Sits at the very top of the file to store structured machine data (e.g., author, timestamps, tags, schema types).
Code Blocks: Contains live, executable programming scripts or data formats (
Python,JSON,Turtle).Narrative Prose: Human-readable explanations written around the code blocks.
3. Why This Matters for LLMs
Dual Purpose: The narrative text isn't just user documentation—it acts as explicit "prompt context" that helps an LLM understand what the code next to it actually means and how to execute or interpret it.
Efficiency: Unlike HTML, which is bloated with styling tags and JavaScript that waste an LLM's memory context window, Markdown is lightweight, token-efficient, and easy for AI to parse.
4. Graphs of Documents
Instead of isolated files or web pages connected via hyperlinks, these self-contained Markdown files are treated as nodes within interconnected networks ("graphs of documents"), creating a structured knowledge web designed specifically for AI navigation and reasoning.
Here is a practical, file-based example demonstrating how a neurosymbolic system handles a concrete task: verifying an employee expense report.
Scenario: Expense Report Validation
An employee submits a Markdown expense document. A neural model (LLM) extracts and interprets the contents, while a deterministic symbolic engine (Knowledge Graph & Rules) validates the claims against hard business rules.
Step 1: The Input File (expense_claim_104.md)
This is the document created or submitted into the system. It combines structured YAML metadata, executable JSON payload, and natural language explanations.
---
document_type: ExpenseClaim
claim_id: CLAIM-2026-0811
employee_id: EMP-4021
submission_date: 2026-08-01
status: Pending
---
# Business Trip Expense Claim
I am submitting my expenses for the GraphCon 2026 conference in Seattle.
```json
{
"vendor": "Hotel Max Seattle",
"category": "Lodging",
"amount": 450.00,
"currency": "USD",
"expense_date": "2026-07-29",
"receipt_attached": true
} Step 2: Context & Justification
Due to high conference demand, standard rooms were booked out, so I had to stay at Hotel Max. I also took a client out for dinner to discuss graph database integrations.
---
### Step 2: Neural Processing (LLM / RAG Phase)
The LLM parses the unstructured text and extracts structured assertions (triples) while standardizing entity names.
**Internal LLM Output (`extracted_claims.json`):**
```json
{
"subject": "EMP-4021",
"claims": [
{
"type": "LodgingExpense",
"vendor": "Hotel Max Seattle",
"amount": 450.00,
"date": "2026-07-29",
"event": "GraphCon 2026"
}
]
}
Step 3: Symbolic Knowledge Graph (company_policy.ttl)
The company’s policies and employee records live in a deterministic RDF Knowledge Graph (written in Turtle syntax) with strict constraints.
@prefix ex: <http://example.org/corp#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
# Employee Knowledge Base
ex:EMP-4021 a ex:Employee ;
ex:name "Alice Smith" ;
ex:department ex:Engineering ;
ex:maxDailyLodgingLimit "300.00"^^xsd:decimal .
# Policy Constraint Rule (SHACL / Logic Rule)
ex:LodgingLimitPolicy
a ex:PolicyRule ;
ex:appliesTo ex:LodgingExpense ;
ex:maxAllowedLimit ex:maxDailyLodgingLimit ;
ex:requiresReceipt true .
Step 4: Deterministic Logic Execution (SPARQL Query)
Instead of letting the LLM "guess" if $450 is allowed, a deterministic query runs against the knowledge graph comparing the LLM's extracted parameters against policy facts.
PREFIX ex: <http://example.org/corp#>
SELECT ?employee ?claimedAmount ?allowedLimit ?isViolation
WHERE {
BIND(ex:EMP-4021 AS ?employee)
BIND(450.00 AS ?claimedAmount)
?employee ex:maxDailyLodgingLimit ?allowedLimit .
# Deterministic comparison
BIND(?claimedAmount > ?allowedLimit AS ?isViolation)
}
Step 5: Final Neurosymbolic Output (validation_result.json)
The symbolic engine evaluates the query with 100% mathematical certainty and flags the policy violation.
{
"claim_id": "CLAIM-2026-0811",
"validation_status": "FLAGGED_FOR_REVIEW",
"neural_summary": "Employee claimed $450.00 for Hotel Max Seattle for GraphCon 2026.",
"symbolic_checks": [
{
"rule": "MaxDailyLodgingLimit",
"allowed_value": 300.00,
"claimed_value": 450.00,
"passed": false,
"reason": "Claim amount exceeds employee department cap by $150.00."
},
{
"rule": "ReceiptRequired",
"passed": true
}
]
}
Why this architecture wins:
Flexibility (Neural): The LLM easily reads messy human writing, varying document styles, and code snippets inside the Markdown file.
Precision (Symbolic): The Knowledge Graph applies fixed mathematical limits and business logic, preventing the LLM from mistakenly approving an over-budget expense.
You’re spot on about base SPARQL 1.1 Query—it is primarily a declarative query language designed to retrieve or update data pattern-by-pattern, much like standard SQL. On its own, raw SPARQL isn't built to orchestrate complex multi-step workflows or manage asynchronous business logic.
However, in modern enterprise knowledge graph stacks and neurosymbolic architectures, "symbolic logic" relies on extensions and complementary standards built directly on top of SPARQL to handle validation, business rules, and dynamic workflows:
1. SHACL (Shapes Constraint Language) for Hard Rules
While SPARQL asks "what data matches this pattern?", SHACL (a W3C standard) enforces "does this data satisfy business logic constraints?".
With SHACL, you define rules directly against your graph model. For example, a SHACL constraint can specify that:
An expense claim over $300 MUST have a receipt attached.
An employee CANNOT approve their own submission.
Under the hood, SHACL engines often translate these rules into optimized SPARQL queries to evaluate validity automatically and return structured violation reports.
2. SPARQL Inferencing & RDFS/OWL Rules
Standard SPARQL can execute CONSTRUCT queries, which infer and insert new assertions into the graph dynamically based on logical rules:
# "Rule: If a manager approves a claim over $500, flag for Director Audit"
CONSTRUCT {
?claim ex:requiresApprovalFrom ?director .
}
WHERE {
?claim ex:amount ?amount ;
ex:department ?dept .
?dept ex:hasDirector ?director .
FILTER(?amount > 500)
}
This allows the graph to "reason" and generate new facts automatically without hardcoding procedural if/else logic in application code.
3. How Real Workflows Are Handled: Orchestration
In a production system, SPARQL is not acting alone. The rule enforcement is layered using tools like:
Control Planes / Agentic Handshakes (e.g.,
Model Context Protocol BPMN / State Machines: Orchestration engines (like Camunda or Temporal) drive the procedural steps (Step 1: Parse Doc $\rightarrow$ Step 2: Query SPARQL $\rightarrow$ Step 3: Trigger Slack Alert), using SPARQL queries as deterministic evaluation checkpoints at each state transition.
Summary
SPARQL alone: A declarative data retrieval tool.
SPARQL + SHACL + Ontologies: A robust, deterministic rule and reasoning engine.
SPARQL + Orchestration Layers (MCP/Workflow Engines): A complete neurosymbolic business workflow.
You have hit on the exact reason why semantic web technologies like SPARQL and raw SHACL have historically struggled with mass developer adoption.
To most standard software developers, standard graph syntax can feel like an alien declarative DSL (Domain-Specific Language).
Because of this, modern production architectures rarely ask mainstream developers to write raw SPARQL or SHACL. Instead, they use three mainstream, code-friendly approaches to express rules and workflows:
1. Code-First Policy Engines (e.g., Open Policy Agent & Rego)
Instead of semantic graph queries, many teams use declarative formats like Rego (used by Open Policy Agent) or YAML-based business rules.
These allow developers to define logic in standard JSON/YAML structures without touching RDF graph syntax:
# policy.yaml (YAML-based Business Rule)
rule: LodgingExpenseCap
description: "Flag hotel expenses exceeding allowance"
when:
category: "Lodging"
amount: "> 300.00"
then:
action: "TRIGGER_APPROVAL_WORKFLOW"
severity: "WARNING"
Under the hood, a lightweight bridge converts these standard YAML policies into deterministic validation checks.
2. Standard Code / Pydantic Models (Python & TypeScript)
In developer-centric stacks, "symbolic logic" is often expressed directly in standard Object-Oriented or Functional code.
For example, using Python's Pydantic or type-system validators, rules look like regular code that any developer can read instantly:
from pydantic import BaseModel, Field, field_validator
class ExpenseClaim(BaseModel):
vendor: str
amount: float
category: str
has_receipt: bool
# Deterministic symbolic rule embedded directly in Python
@field_validator('amount')
def check_lodging_limit(cls, v, info):
category = info.data.get('category')
if category == "Lodging" and v > 300.00:
raise ValueError("Lodging expense exceeds maximum policy limit of $300.")
return v
Here, the "symbolic engine" isn't a complex graph database—it's simply deterministic, type-checked Python runtime constraints integrated directly with the LLM output.
3. Procedural Code Orchestration (Temporal / AWS Step Functions)
When it comes to multi-step workflows (e.g., Extract $\rightarrow$ Validate $\rightarrow$ Notify $\rightarrow$ Retry), developers use workflow engines expressed entirely in standard code or JSON/YAML graphs:
Temporal.io / Prefect (Code-as-Workflow): You write state machines using native Python/TypeScript
async/awaitloops, try-catch blocks, and standard conditional logic.YAML Workflow Specs (e.g., Serverless Workflow / AWS Step Functions):
# workflow.yml
start: ValidateClaim
states:
ValidateClaim:
type: Task
action: RunPydanticValidation
next: CheckStatus
CheckStatus:
type: Switch
conditions:
- if: "$.isValid == false"
next: RouteToHumanReview
- if: "$.isValid == true"
next: ProcessPayment
Why Knowledge Graphs still sit at the core
If YAML and Python code are so much easier, why do architects keep talking about SPARQL/SHACL?
Python/YAML Code is great for local rules inside a single microservice.
Knowledge Graphs (SPARQL/SHACL) are used at the global enterprise layer because they can automatically join millions of heterogeneous data points across disparate company silos (e.g., HR databases, ERPs, Jira, Slack) using unified global standards.
The Modern Compromise:
In modern neurosymbolic architectures, developers write Python/YAML/TypeScript on the surface. Translation layers (or LLMs themselves) convert those readable YAML/code structures into SPARQL/SHACL queries behind the scenes, giving developers a familiar DX (Developer Experience) while preserving global graph logic.
From Logic to Learning: The Future of AI Lies in Neuro-Symbolic Agents | AWS Builder Center
Neuro-symbolic AI is an approach that integrates the structured, compositional reasoning of symbolic systems (such as logic, rules, and knowledge graphs) with the pattern recognition and generalization strengths of neural networks. It aims to achieve more robust, interpretable, and flexible intelligence by enabling systems to both learn from unstructured data and reason over structured knowledge—bridging perception and cognition within unified architectures.
HTML to Markdown for LLMs: Why Clean Web Content Matters | OpenGraph.io Blog
Write LLM-friendly docs in March 2026 | Fern
| Format | Token use | Best for |
|---|---|---|
| Standard HTML | ~16,000 tokens per page | Human-only browsing with visual presentation needs |
| Markdown via content negotiation | ~1,600 tokens (90%+ reduction) | Serving both humans and AI agents from one source |
No comments:
Post a Comment