The truth
Not so long ago, everyone who built software agreed on one thing: simple and stupid wins. Not simple as in shallow. Simple as in a tool that does one job, does it every time, and asks nothing of the person using it. We knew this the way you know gravity.
Then AI arrived, and the truth got quietly shelved. The new capabilities tickle the part of a builder's brain that wants to do more: agents calling agents, orchestration diagrams that look like subway maps. I am not going to write about this as if I did not make the mistake. I made it more than most people I know.
What grounded me was not a methodology. It was my colleagues, asking small, sharp questions: which rule applies here, is this clause enforceable. They did not want AI. They wanted answers. So the shift happened: stop building what the technology makes possible, start shipping what covers the pain point. The complexity does not disappear in that trade. It moves behind the curtain, until the tool all but disappears.
This is the story of one system built on that rule. I am Mohammad Abdelrahman, Head of AI Engineering & Transformation at SERGAS Group, a pioneer of LPG distribution in the GCC that designs, supplies, installs, and maintains gas and fire-safety systems across the region. The system is a legal and compliance answer engine, internally called the Legal Skill: a FalkorDB knowledge graph doing the heavy lifting, delivered to employees as a Claude Skill. The graph is deep. The models are real. And the thing people touch is as simple as asking a question.
The part nobody expects: deployment was the easy bit
Here is the sentence that surprises every enterprise architect I say it to. The entire user-facing application shipped as a skill. One upload to the company's Claude team workspace and it was live for every employee; the same folder dropped into the Claude Code environments on the engineering side, where the MCP connection to the graph already existed. No dependencies. No installations. No rollout project, no training beyond "ask it a legal question."
A Claude Skill is, at heart, a markdown file of instructions (a SKILL.md that tells Claude when to reach for it and how to behave) plus the small scripts it calls on demand to deliver an output. That makes it a full application delivery channel hiding in plain sight. The transport was already there too: the MCP server fronting FalkorDB is part of the company's Claude environment, so the skill added a capability without adding a single piece of infrastructure. If Claude runs, the Legal Skill runs.
The skill stays light on purpose; everything heavy lives on the internal network, built once, serving everyone. Simplicity at the edge, complexity in the engine room, and the engine room is somebody's job, not everybody's problem.
TL;DR for the technical reader: SERGAS Group turned its legal and regulatory corpus into a governed, hybrid GraphRAG system. FalkorDB holds the knowledge graph on the internal network, an MCP retrieval service exposes it through narrow read-only tools, and a Claude Skill carries the workflow to employees with zero installation. Retrieval returns cited evidence in roughly 200 milliseconds at p95. Claude reasons over the evidence, safety findings are flagged for human review, ingestion is admin-gated, and nothing in the corpus is model-authored.
The challenge: one legal team, an inbox that never empties
SERGAS operates across four countries and 28 departments. Every engagement carries two kinds of law at once: a commercial contract that must hold up in court, and a physical scope of work that must satisfy fire codes, Civil-Defence approvals, and LPG standards, or it is simply unlawful, unsafe, or unapprovable.
On the ground it looked like this. Every customer-facing employee handles documents that may carry legal weight: a contract, a proposal, a tender. The safe move was always the same: email it to the legal team and wait. So everyone did. The legal team drowned in requests it could not triage, because filtering what needs a lawyer from what does not is itself legal work; no team size fixes that. And the quiet failure mode was worse: faced with a review that would take days, plenty of employees skipped the check altogether. The riskiest documents were often the ones nobody sent.
Underneath sat a knowledge problem. A single answer can touch hundreds of points: laws, amendments, Civil-Defence codes, LPG standards. The UAE takes safety seriously and keeps rolling out updates; knowing which update supersedes which point, across which emirate's authority, is a full-time job nobody actually held.
My colleagues did not want AI. They needed to know, in the time it takes to ask, whether a document is safe to sign, which points they could address with the client on the spot, and whether a lawyer genuinely needs to see it.
Why law is a graph problem
Legal knowledge is a network wearing the costume of a library. An answer rarely lives in one paragraph. It depends on relationships: the regulation governing a clause, the amendment that superseded an article, the procedure that operationalises a code. Miss one hop and a confident answer becomes a dangerous one. The worst failure mode in this domain is not "no answer." It is a fluent answer quoting a repealed article.
Flat document search loses exactly this structure. Vector similarity can tell you that "liability cap" resembles "limitation of liability." It cannot tell you that one article repealed another, and in law, that difference is the meaning. So the store had to be a graph, where supersession, exception, and operationalisation are first-class, traversable edges. The questions are also lexical (article numbers) and semantic (paraphrased intent), so it had to do full-text and vector search too, and serve an entire organisation interactively.
Why FalkorDB
I did not go shopping for a graph database. I found FalkorDB while testing Graphiti, the popular open-source framework for building graph-native knowledge bases for AI agents. Neo4j was the graph database I already knew, so when I saw Graphiti supporting this other engine alongside it, curiosity took over: who is this competing with Neo4j? Then the latency numbers got my attention. FalkorDB calls itself an "ultra-fast, multi-tenant graph database" purpose-built for GraphRAG and agent memory, and in testing, the ultra-low-latency claim simply held. That mattered doubly here, because the whole system lives behind a network connection: every millisecond the database does not spend is a millisecond the round trip gets back.
We also wanted every retrieval shape in one engine, not three systems stitched together. Three things won it:
Multi-hop traversal as linear algebra, at memory speed. FalkorDB is, in its own words, "the first queryable property-graph database to leverage sparse matrices to represent the adjacency matrix in graphs and linear algebra for querying." A graph hop is a matrix operation and the whole graph lives in RAM, so "which SOP operationalises the law that governs this clause, two hops away" resolves as one fast algebraic step.
Vector, full-text, and range indexes in the same engine. Semantic recall for paraphrased questions, exact recall for article numbers and named laws, and date filtering come back from a single query. No stitching, no drift.
Operationally boring, in the best way. One container, openCypher rather than a proprietary dialect, and first-class MCP integration, so the skill-to-graph bridge is a supported path rather than a workaround. For an internal deployment run by a small team, boring is a feature.
A pure vector database would have collapsed the supersession structure into similarity scores. A document store cannot answer "what superseded this article" as a query. FalkorDB was all of it at once, fast enough to feel instant on a LAN.
Three actors, one division of labour
The whole system reduces to a mental model you can hold in one hand.
The FalkorDB knowledge graph is the memory. Every law, code, and SOP, and every relationship between them, held as verbatim, versioned text on the company's internal network. It is the source of truth, and the only one.
The Legal Skill is the orchestrator. It carries the retrieval playbook to wherever the employee's Claude session runs, interprets the question, and calls the retrieval service through narrow MCP tools. It stays light because the heavy machinery stays server-side.
Claude is the analyst. It reasons over the retrieved, cited evidence and explains it. It is never the authority. It is designed and instructed to answer only from what retrieval returns, with citation requirements and a regression suite (including hallucination-resistance cases where no evidence exists) holding that line.
When an employee asks a question in plain language, the skill sends the question, its parsed constraints, and its embedding to the retrieval service on the internal network. The graph query itself returns in tens of milliseconds; the full locate-and-return completes in roughly 200 milliseconds at the 95th percentile, so retrieval is never the part anyone waits on. The corpus stays on the internal network, the supporting models for embedding and extraction run locally through Transformers.js on ONNX Runtime (CPU and WASM), and only the retrieved evidence enters the session context. Nothing new to procure, approve, host, or pay per call.
How law becomes a graph
The graph is designed around legal reasoning, not arbitrary text chunks. Nodes are the citable units of legal meaning: articles, clauses, obligations, exceptions, regulators, departments, versions. Edges carry the relationships that make an answer safe or dangerous: GOVERNS, SUPERSEDES, AMENDS, EXCEPTION_TO, OPERATIONALISED_BY. Chunking follows the law's own structure, never a token count, so a citation is never severed from the text it governs.
Trust is layered. The text of every node is verbatim official source, never model-authored. The structural backbone is hand-verified, because one wrong SUPERSEDES edge would mislead every downstream answer; finer extracted edges are model-proposed and review-gated. And the write path has one door: new laws and SOPs enter only through the administrator. Everyone can ask the law. One gatekeeper teaches it.
Two layers of law run through everything: Layer A is commercial (enforceability, liability, consumer protection), and Layer B is physical (fire and life safety, Civil-Defence approvals, LPG standards). Layer is a first-class dimension in the graph, which lets the engine weight the catastrophic axis appropriately.
The graph model, in one query
A query is worth a page of schema prose. Here is "what governs a liability cap in the UAE, what did it replace, and is the implementing procedure still current":
MATCH (c:ClauseConcept {key: 'liability-cap'})
-[:GOVERNS]->(art:Article {country: 'UAE', status: 'active'})
OPTIONAL MATCH (art)-[:SUPERSEDES]->(prior:Article)
OPTIONAL MATCH (art)-[:OPERATIONALISED_BY]->(sop:SOP)
-[:BELONGS_TO_DEPARTMENT]->(d:Department)
RETURN art.citation AS operative_law,
prior.citation AS superseded_law,
d.name AS owning_department,
sop.title AS procedure,
sop.effective_date < art.effective_date AS sop_predates_lawThat last returned column is the quiet star of the system. The graph does not just find the procedure. It notices, structurally, when the procedure predates the law it implements. No flat store can hand you that as a query result.
How retrieval answers a real question
The retrieval service exposes the graph to Claude only through narrow, read-only MCP tools (resolve_query_context, expand_graph_context, get_citation_bundle, and a handful more), each doing one thing and returning a validated structure. The model can retrieve, expand, and compare; it can never mutate the graph or run an unrestricted query.
Ranking is deterministic-first: jurisdiction match above all (a UAE requirement is not an Oman requirement), operative status over archived, exact identifiers often over semantic similarity. Two governance overlays sit on top. Safety-auto-RED forces any fire or safety finding to the top severity, because a gas company's risk axis is catastrophic, not merely financial. The currency engine knows legal time: superseded law is never returned as current unless asked, and the system warns when a procedure predates a superseding regulation.
Walk through it once, end to end. A contracts officer asks: "Can we cap our liability at the contract value for the fire-alarm maintenance agreement in Abu Dhabi?" The service parses the constraints, searches full-text and vector in parallel, and expands from the liability-cap concept to the operative civil-law article, the fire code and its Civil-Defence approval obligations, and the department's maintenance SOP. Claude receives the bundle and answers:
No, a general liability cap cannot exclude liability for safety failures. Under the operative civil law, any agreement exempting liability for a harmful act is void, so a cap that would shield the company from injury or fire-safety failure is unenforceable [citation]. A commercial cap on ordinary contractual losses is acceptable, but it must carve out death, personal injury, and safety-related liability. Note also the Civil-Defence approval and fire-code maintenance obligations that attach to this work [citations], and that the current department SOP predates the amendments and should be reviewed. This is a Layer-B safety matter and has been flagged for review.
Every claim cited to verbatim operative text. The stale SOP surfaced without being asked. And the escalation is deliberately human-shaped: the system marks the finding at top severity, states why, and puts the handoff in the hands of the person reading it. The moment a question touches life safety is exactly the moment you want a human owning the next step, not an unattended automation.
The solution in action
Day to day, the pattern is always the same and always short. A salesperson gets a tender an hour before a client call, asks the Legal Skill what liabilities the scope carries, and addresses most of the points with the client on the spot, cited. An engineer confirms which Civil-Defence obligations attach to an installation before quoting it. And when something genuinely needs a lawyer, the escalation arrives pre-qualified, with the evidence attached.
1. Contract review that cites its sources. A B2B service agreement runs through the review workflow: each clause mapped to its governing law and the company playbook position, a liability cap flagged for failing to carve out safety liability, a risk-banded summary returned with redline suggestions. Every finding cited.
2. Stale procedures surface themselves. Because law-to-SOP links are edges and versions are explicit, the system notices when a procedure predates the regulation it implements, and says so in the answer. Nobody has to remember to check. The graph remembers.
The results
The current version is live for the UAE operation as a beta, and adoption is still spreading; AI habits take longer to form than AI systems take to build, and I would rather report the honest curve than a launch-day fantasy. Even so, the numbers are promising. Escalations to the legal team have dropped by roughly half. Not because people stopped checking, but the opposite: the employees who used to skip the review entirely now run the check themselves in the moment, and what does reach the legal team is a genuinely valid concern with cited evidence attached.
The quieter numbers compound underneath. A question that used to mean hours of hunting through PDFs now returns as a cited answer in well under a minute. The marginal price of asking is zero, because embedding and extraction run on local models, which is exactly what an everyone-checks-everything culture requires. And the win colleagues mention first is not speed at all. It is consistency: the same question now gets the same cited answer for everyone.
Running it
The operational footprint matches the philosophy. FalkorDB runs as a single container on an internal server, graph and indexes in memory, persisted to disk; updating the corpus when a law is amended is an ingestion operation, not a redesign. The graph is reachable only from the company's environment on the internal network, the MCP tools are read-only, and the write path has one door, the administrator. Every answer is auditable end to end: the constraints applied, the nodes retrieved, the exact source text and version.
What we learned
Chunk by legal structure, never by tokens. A chunk is one legal unit with its citation intact. A weaker embedding is always preferable to a chunk that severs an article from its exception.
In law, the relationships are the meaning. An embedding knows a clause resembles another. Only the graph knows one repealed the other. Embeddings find; the graph reasons.
Spend the complexity where the user cannot see it. Everything heavy exists so the person in front of the system can ask a plain question and trust a cited answer. The skill that ships to them is the thinnest part of the whole architecture, and that is precisely why it works.
What's next
Stay tuned for the next version. The headline is Arabic: the biggest and most requested upgrade, and because the embedding model is already multilingual, it is ingestion work rather than a rebuild. Through the rest of the beta phase we are collecting every scrap of feedback we can get. Then we lean on FalkorDB's ultra-low latency to ship the same system, unchanged, to the group's other countries, with proactive alerts on law changes riding along. The graph grows. The skill stays simple. That is the whole point.
