Intelligence systems built on a knowledge graph alone struggle with two things: stable identifiers across time and time-aware deltas. Graphs are excellent at shape — what connects to what, which clusters formed, where the bridges and gaps live. They are weaker at "which of these scores moved more than ten points this week, sorted." That question wants rows. A relational layer alongside the graph isn't a downgrade or an admission; it's the right tool for a specific class of question that a graph wasn't built to answer.
The shape that holds up: graph holds the discourse, the rubric concept space, the entity relationships, the structural reads. Relational holds the time-sliced observations — scores per brand per week, evidence pinned to claims with identifiers that survive a graph regeneration, audit logs of when which rubric weight changed and what cascaded. The two systems share keys, not data. A score row references a graph node by stable ID. A rubric weight change in the relational store triggers a cascade that the graph layer reads from. Neither tries to be the other.
What this changes for operators: the question "show me brands whose awareness moved more than ten points this week and whose discourse network shifted from small-world to hub-removed" stops being two separate analyses stitched together by hand. It's one query against two coordinated stores.
What's still open: keeping the two layers in sync without either becoming the bottleneck is the load-bearing engineering problem. The honest answer is that the relational layer trails the graph by minutes-to-hours and the system has to declare that lag explicitly rather than pretend to real-time consistency.