Every Fact Cited, Dated and Disputed: Building Nodus on FalkorDB A developer built Nodus, an organizational knowledge graph on FalkorDB that models every fact as a versioned, bi-temporal Assertion node linked to the exact character range of its source Span, so answers about ownership, dependencies and decisions cite their evidence. The system keeps an append-only assertion ledger alongside fast traversal edges, letting blast-radius queries run in under a millisecond while resolving each result back to its supporting quote, and it resolves contradictions by only letting a new claim supersede an old one when its authority is equal or higher. "Who owns ledger-service ?" sounds like a ten-second question. In most companies it takes an afternoon. The service catalog says Platform. A design doc from last spring says Payments. A Slack thread from Tuesday says "Infra owns Ledger now." The person who would know left in the reorg. Each source is a little bit right, and none of them says when it was right. The usual AI answer is to throw all of it into a vector store and let a model summarize. That gives you a fluent paragraph, but it can't tell you which source won, whether the answer was true last quarter or is true today, or what it is quietly making up. For questions about ownership, accountability and decisions, a confident wrong answer is worse than no answer. I wanted a company brain that shows its receipts. That became Nodus . Nodus is an organizational knowledge graph built entirely on FalkorDB https://www.falkordb.com/ . It pulls people, teams, systems, projects, tickets, docs, chats and architecture decisions ADRs into one bi-temporal graph. It answers "who owns this?" , "who knows about this?" and "why was this decided?" , and every answer comes with an exact quote from its source. The core idea is simple: a fact is not a chunk of text; it is a versioned claim with evidence. Every claim Nodus learns becomes an Assertion node that points at the exact character range of the Span it came from. Each assertion knows: valid from , valid to recorded at , retracted at 4 structured data or human confirmation, 2 docs, 1 chat, 0 drafts The two clocks let Nodus answer two different historical questions. "Who owned Ledger before the reorg?" asks about reality. "What did we believe about Ledger last month?" asks about the brain's own state. Most systems can't tell those apart. Nodus can, and nothing is ever deleted. FalkorDB is the only datastore. Storage, vector and full-text search, graph algorithms, temporal reasoning and permission checks all happen inside it. The rest of this post covers the four hardest design problems and how FalkorDB solved each one. The first design fought itself. If every fact is its own node, you keep perfect provenance, but a question like "what breaks if Ledger goes down?" has to walk through an assertion node at every hop. If facts are plain edges, traversal is fast, but the moment ownership changes you lose the history and the conflicting claims. I stopped choosing and kept both layers in the same graph: Source - :HAS SPAN - Span <- :EVIDENCED BY - Assertion , with assertions linked to each other by SUPERSEDES , CONTINUES , DISPUTES and CONFIRMS . This layer is append-only and holds the full story. OWNS , LEADS , DEPENDS ON , PART OF , AFFECTS , REPLACES . Each edge carries {aid, valid from, valid to, authority} , where aid points back to its assertion. Queries walk the fast edges on the right; the dashed aid link is how any answer finds its way back to the claim and quote on the left. Operational queries run on the fast layer and only touch the ledger to fetch citations. Here is the blast-radius query: MATCH p = x:Entity {id:$x} <- :DEPENDS ON 1..3 - s:Entity WHERE all e IN relationships p WHERE e.valid from <= $V AND e.valid to $V RETURN s.id, s.name, length p AS hops, e IN relationships p | e.aid AS aids ORDER BY hops That is a variable-length traversal https://docs.falkordb.com/cypher/match with a time filter on every hop, and on the demo graph it returns in under a millisecond on FalkorDB's sparse adjacency matrices https://docs.falkordb.com/design . The aids it returns resolve straight to the assertions and quoted spans behind each dependency, so the answer cites its sources at no extra cost. Real companies contradict themselves constantly, so contradiction handling had to be a first-class rule rather than an edge case. Nodus uses one rule: a new claim only replaces an old one if its authority is equal or higher. The demo shows this end to end. The catalog authority 4 says Payments owns Ledger. Someone posts "Infra owns Ledger now" in Slack authority 1 . Nodus doesn't flip ownership based on a chat message. It records a dispute, keeps answering "Payments", and flags the conflict. Once the Payments lead confirms the handover, that confirmation authority 4 supersedes the old fact and Infra becomes the owner, with the full chain of evidence intact. The same ledger powers stale-doc detection . One query finds the latest version of each wiki page that still asserts a fact superseded after the page was last edited. Outdated docs flag themselves. A rule like this is easy to get subtly wrong, so I tested it with property-based tests . They feed the same messages in random orders and check that the final state always converges to the same answer. If arrival order changed the outcome, the brain would be guessing. Some questions aren't about one node's neighbors. They're about the shape of the whole organization: which systems are most critical, who is a single point of failure, where the silos are. FalkorDB ships native GraphBLAS implementations https://docs.falkordb.com/algorithms of exactly the algorithms for these, and they are fast. The catch is that they filter by node label and relationship type , not by property predicates evaluated per hop. I couldn't pass valid from <= $V < valid to into PageRank, and running on the live graph would mix in edges from every era. So Nodus builds snapshot graphs . For a timestamp $V , it materializes a lightweight read-only graph named