RAGF: Using Neo4j as the Semantic Brain of an AI Governance Framework — Real Benchmark Inside

Projects & Collaboration
1

RAGF: Using Neo4j as the Semantic Brain of an AI Governance Framework — Real Benchmark Inside

The Problem

Large Language Models generate plausible actions. In regulated environments — banking, aviation, healthcare — plausible is not sufficient. Actions must be legally authorized and traceable to specific regulatory requirements.

Consider this scenario:
Operator intent "Reduce operating costs for Flight IB3202"
LLM proposal "Reroute via shorter path, extend crew duty time" — violates FAA 14 CFR §91.1057
RAGF verdict `DENY

Better prompts don't solve this. You need a deterministic interception layer.

What is RAGF?

The Reflexio Agentic Governance Framework is an open-source deterministic interceptor that sits between the LLM reasoning engine and regulated system execution.

Its core principle: certify the governance harness, not the probabilistic model.

The Validation Gate operates in three steps:

  1. Normalize the LLM's proposed action into a formal verb

  2. Query the Semantic Authority Layer (Neo4j) to validate authorization

  3. Return a deterministic verdict: ALLOW or DENY — with full audit trail

The paper has been submitted to AIES 2026 (currently under review).

Why Neo4j?

Regulatory knowledge is naturally a graph. Verbs belong to domains, domains are governed by regulations, regulations have jurisdictional scope, agents have maturity levels that gate authorization.

Approach Limitation
Relational DB Fixed JOINs work at small scale. Variable-depth regulatory traversal leads to unpredictable query plans as jurisdictions grow
Vector DB Similarity search returns probabilistic results. Governance requires exact, deterministic predicate matching
Document/KV Cannot represent the relationship graph without denormalization that breaks constraint integrity
Property Graph (Neo4j) Native traversal, Cypher pattern matching, ACID. A new jurisdiction = one relationship

The PSD2 Ontology Schema

All nodes use the BM_ prefix (Business Model) — the namespace for RAGF's core ontology layer:

CREATE (d:BM_Domain {name: 'fintech', version: '1.0', jurisdiction: 'EU'})
CREATE (r:BM_Regulation {code: 'PSD2-ART97', title: 'Strong Customer Authentication', authority: 'EBA'})
CREATE (v:BM_Verb {name: 'initiate_payment', min_amm_level: 2})
CREATE (c:BM_Constraint {predicate: 'amount_eur <= 15000', unit: 'EUR'})
CREATE (v)-[:BM_BELONGS_TO]->(d)
CREATE (v)-[:BM_MUST_SATISFY]->(r)
CREATE (v)-[:BM_REQUIRES_CONSTRAINT]->(c)

Five node types: :BM_Verb, :BM_Domain, :BM_Regulation, :BM_Agent, :BM_Constraint Four relationship types: BM_BELONGS_TO, BM_MUST_SATISFY, BM_REQUIRES_CONSTRAINT, BM_EXECUTED_BY

The Validation Query

MATCH (v:BM_Verb {name: $verb_name})
WHERE v.min_amm_level <= $agent_amm_level
OPTIONAL MATCH (v)-[:BM_MUST_SATISFY]->(r:BM_Regulation)
OPTIONAL MATCH (v)-[:BM_REQUIRES_CONSTRAINT]->(c:BM_Constraint)
WITH v, collect(r) AS regulations, collect(c) AS constraints
RETURN
  v.name AS verb,
  [r IN regulations | r.code] AS regulation_codes,
  [c IN constraints | c.predicate] AS constraint_predicates,
  -- coverage = matched_constraints / expected_constraints for this verb
  toFloat(size(constraints)) / toFloat(v.expected_constraint_count) AS coverage_score

Coverage score < 1.0 → human escalation (HITL). Coverage = 0.0 → hallucinated verb → automatic DENY.

Benchmark: Neo4j vs PostgreSQL

We implemented equivalent schemas in both databases and ran 1,000 iterations per query pattern. PostgreSQL had full indexes and prepared statements — its best conditions.

Baseline results (17-verb PSD2 ontology):

Query Description Neo4j p50 Neo4j p95 PG p50 PG p95 Ratio
Q1 Existence check (1 reg) 1.063ms 1.412ms 0.301ms 0.351ms PG 3.5x faster
Q2 Payment init (1 reg + 2c) 1.208ms 1.793ms 0.341ms 0.911ms PG 3.5x faster
Q3 Fraud override (3 regs + 2c) 2.113ms 4.750ms 0.367ms 0.572ms PG 5.8x faster
Q4 Insufficient AMM → DENY 1.475ms 3.995ms 0.303ms 0.447ms PG 4.9x faster
Q5 Hallucinated verb → DENY 1.382ms 4.243ms 0.313ms 0.417ms PG 4.4x faster

Honest interpretation: PostgreSQL wins on raw latency at this scale. Both databases meet the sub-30ms RAGF gate requirement comfortably.

The architectural case for Neo4j is not speed — it is schema flexibility (a new jurisdiction is one relationship, not a migration) and native path traceability for audit trails. At scale with variable regulatory depth, graph traversal cost grows proportionally to the subgraph reached — not the total graph size.

Scale test (500 verbs, 200 regulations, seed=42): both databases maintained stable sub-5ms p50 latency.

Full benchmark code and raw JSON results: github.com/cronocom/rafg/tree/main/benchmark

Open Domains — Community Contributions Welcome

RAGF ships with starter ontologies for PSD2 fintech and aviation (FAA 14 CFR). These domains are open for contribution:

Domain Target Regulations Status
Energy / Grid IEC 61850, IEC 61508 SIL-3 Open
Healthcare / EHR HIPAA, HL7 FHIR, IEC 62304 Starter available
Autonomous Vehicles ISO 26262 ASIL-D, UN ECE R155 Open
Insurance Solvency II, EIOPA Guidelines Open
Public Sector / Gov AI EU AI Act Art.13, NIST AI RMF Open

How to contribute: fork the repo, add your domain ontology under gateway/ontologies/<domain>/, include at least 10 verbs with formal regulation links and a hallucination test (non-existent verb → DENY).

Discussions and ontology working group: https://github.com/cronocom/rafg/discussions/1

5-Minute Quickstart

git clone https://github.com/cronocom/rafg
cd rafg
docker-compose up -d neo4j timescaledb postgres
python scripts/seed_ontology.sh
python examples/fintech_demo.py

# Expected output:
# Action: initiate_payment | EUR 5,000 | Agent AMM: 2
# Verdict: ALLOW | Regs: [PSD2-ART97] | Latency: 8.3ms
# Action: override_fraud_flag | Agent AMM: 2
# Verdict: DENY  | AMM Level 5 required | Latency: 6.1ms

Repo: github.com/cronocom/rafg | License: Apache 2.0

Happy to discuss the ontology design, benchmark methodology, or the regulatory encoding challenges. If you work in a regulated sector and want to collaborate on a domain ontology, open an issue or join the discussion.

2

This is a thoughtful and well-detailed contribution. Thanks for sharing the benchmark transparency as well.

For others reviewing this: what regulatory domains would you most want to see modeled in a graph-based governance layer?

3

Thanks Ari, glad the benchmark transparency was useful. That was a deliberate choice.

Right now RAGF has working deployments and tested ontologies in three domains: aviation (FAA 14 CFR), healthcare (medication validation, IEC 62304), and fintech (PSD2/AML). Those are the verticals with real validation scenarios, failure injection data, and production metrics in the paper.

Aviation and healthcare were the first deployments, where the regulatory structure maps naturally to the ontology model and the safety certification requirements align well with RAGF's fail-closed design. Fintech came after, driven by PSD2 compliance as an immediate pain point. That work is available as an appendix to the paper.

Energy is a logical next step given IEC 61850's graph-friendly structure, but it's not there yet.

If anyone here works in one of these sectors and wants to collaborate on extending the ontology coverage, open an issue on the repo. Happy to pair on the schema design.