Problem Statement
An assessment run writes a chain of JSON files to S3: collector output, triage signals, per-engine analyses, assignments, reality-check consolidations, schema designs, router decisions, load tests, and synthesis risks. How they connect to each other is not stored anywhere. It only exists implicitly across the files.
So to answer a question like "which queries read the orders table?", "if I move this destination, what else changes?", or "what decisions were made and why?", you open several files and cross-reference them by hand. There is no single place to ask.
Proposed Solution
Add a graph layer that reads the artifacts an assessment already produces and links them, then lets you query those links with Cypher over REST.
- Embedded graph database (LadybugDB), one per assessment, stored at
{base}/{db}/{job_id}/graph/context.lbug.
- 10 node types: Query, SourceTable, Destination, Engine, CoDependencyGroup, AntiPattern, Decision, LoadTestRun, Risk, Signal.
- 14 edge types covering reads, migrations, hosting, group membership, signals, observed anti-patterns, decision inputs, load-test links, and risk impact.
- One reader per phase (nine total) that turns that phase's artifact into nodes and edges, plus a
rebuild_graph step that runs them in order and skips artifacts that aren't there.
- An LRU cache (size 5) that keeps recently queried assessments in memory.
- The graph builds on the first query if it doesn't exist yet.
- Two REST endpoints:
POST /api/v1/assessments/{job_id}/graph/query runs a Cypher query.
POST /api/v1/assessments/{job_id}/graph/rebuild rebuilds from artifacts.
Alternatives Considered
- Working out the relationships in the API on each request. This re-reads and re-joins every artifact for every question and leaves nothing reusable behind.
- A relational/SQL view. The questions are mostly multi-hop walks (which query leads to which destination, how far a reroute cascaded), and those read more cleanly as graph traversals than as joins.
Problem Statement
An assessment run writes a chain of JSON files to S3: collector output, triage signals, per-engine analyses, assignments, reality-check consolidations, schema designs, router decisions, load tests, and synthesis risks. How they connect to each other is not stored anywhere. It only exists implicitly across the files.
So to answer a question like "which queries read the orders table?", "if I move this destination, what else changes?", or "what decisions were made and why?", you open several files and cross-reference them by hand. There is no single place to ask.
Proposed Solution
Add a graph layer that reads the artifacts an assessment already produces and links them, then lets you query those links with Cypher over REST.
{base}/{db}/{job_id}/graph/context.lbug.rebuild_graphstep that runs them in order and skips artifacts that aren't there.POST /api/v1/assessments/{job_id}/graph/queryruns a Cypher query.POST /api/v1/assessments/{job_id}/graph/rebuildrebuilds from artifacts.Alternatives Considered