Taking a research PoC into the product — knowledge graph analysis in a multi-tenant product

Problem

The research team’s PoC ran on a dedicated server against a single dataset. In the product, many customers share the same servers, and the UI structure, data model, permissions, and release process are already defined. Working in a PoC is not the same as working inside the product without hurting other users. Closing that gap was my job.

Where the line was

• Research team: knowledge graph extraction from technical documents, the analysis methods (community detection, structural hole analysis, dimensionality reduction, density maps), and the PoC UI
• Me: porting it into the product and making it usable in production — UI and APIs, back-end models and migrations, model connectivity and permission wiring for the AI chat, isolating failures in staging and adding stopgaps, and scoping the root fix

Design decisions

• My first implementation targeted a different UI line from the one customers actually used. Once review surfaced it, I rebuilt the feature and from then on confirmed the target’s assumptions before starting
• Access is allow-listed per workspace and distinguishes unauthenticated from unauthorized requests. Cache keys include the workspace so data never mixes across customers
• Overlaying several companies’ graphs makes memory grow roughly with the square of the node count. An out-of-memory failure that never appeared in the research environment appeared in the product’s staging environment. Adding memory was not enough, so I added the fail-fast cap and serialization as stopgaps
• The stopgap prevents collateral damage; it does not make the computation lighter. I made the queueing trade-off explicit to stakeholders and filed the root fix — moving heavy computation to a separate process or the back end — as its own issue with assumptions and effort
• The AI chat avoids letting the LLM write free-form queries and is limited to allow-listed tool calls. It has no path that modifies data, and even the tools that change view settings go through server-side input validation

Approach

• The analysis methods (community detection, structural hole analysis, dimensionality reduction, density maps) and the PoC UI were the research team's work. My part was fitting them into the product's UI structure, data model, permissions, and operations
• Rebuilt the feature for the UI line customers actually used after review surfaced the mismatch, and carried it through workspace-level access control, per-user data upload, and back-end models and migrations that use a knowledge database as the input
• On the screen that overlays several companies' graphs, memory grew roughly with the square of the node count and the process crashed. Added a node-count cap that fails fast before heavy computation, serialized heavy work, and yielded the event loop so other users were not dragged down
• Kept the distinction that the stopgap prevented collateral damage but did not make the computation lighter. Split the root fix — moving heavy computation to a separate process or the back end — into its own issue with scope and assumptions, and explained the data-volume limits to the business side in concrete numbers
• For the AI chat over the graph, the LLM never writes queries; it can only call fixed tools. Read tools work on an in-memory copy of the graph sent to the screen, write tools only change view settings and pass server-side schema validation, and tool calls, time, and tokens are capped