Architecture
The complete technical model.
Five diagrams, in order: what the ten modules are, how the system is actually wired, what request flow is genuinely real today, how memory works now versus where it's headed, and exactly where deterministic code stops and a model — or a person — takes over.
Diagram 01
QA Lifecycle Capability Map
Ten modules as a sequence. Colors are pulled directly from the real module-status data — not hand-painted — so this diagram can't quietly drift out of sync with what the code actually does.
Hover or focus a module to see its real status.
Diagram 02
System Architecture
apps/web through services/api through the shared packages through the modules, down to the knowledge-graph backend — which is where real interface discipline shows up: one interface, three swappable implementations, zero call-site changes to move between them.
apps/web
Next.js 14 + Tailwind — the Command Center UI
services/api
FastAPI — six real, DI'd, honestly-erroring routes
packages
shared libraries
modules/01–09
the reasoning pipeline, exactly as it exists in the repo today
services/connectors
Module 10 — Integration & Extensibility Layer, not yet wired to any route
KGClientInterface
one interface, three swappable implementations
Diagram 03
Real Vertical-Slice Sequence
The actual working flow, step by step — hover or tap any step for the real endpoint behind it. Proves “no hardcoded output” as an architectural property, not a claim.
POST /requirements/{id}/assess
Module 1 scores risk with a real LLM call — informed by up to 3 similar past requirements pulled via TF-IDF retrieval, when any clear the 0.2 similarity threshold.
Diagram 04
Knowledge / Memory Layer — Today vs. Vision
Where the current retrieval approach's ceiling actually is, stated plainly next to where it's headed.
Today
- TF-IDF cosine similarity over stored requirement text — stdlib Python, no embedding model, no external dependency.
- Top-3 matches per tenant, at or above a 0.2 similarity threshold — tuned to favor precision over recall.
- Injects each match's real stored risk level and real human review decision as few-shot context.
- Scoped to Module 1's risk-assessment prompt only — test generation doesn't use retrieval yet.
- Process-memory by default; survives a restart when KG_SQLITE_PATH is set.
Vision
- Embeddings-based semantic similarity, not just token overlap — catches paraphrases that share no vocabulary.
- A real knowledge graph: requirements, defects, incidents, and code changes linked as first-class relationships, not inferred from property names.
- Org-specific weighting — a team's own severity conventions and known-risky areas shape retrieval, not just similarity score.
- Retrieval extended to test generation and, eventually, defect triage — not just risk assessment.
Diagram 05
Reasoning Boundary
The single most-asked question this site needs to pre-empt: where does AI end and judgment begin? This is the direct answer, lane by lane, across the lifecycle — including where the (not-yet-built) execution and release stages will sit once they're real.
Requirement intake
Retrieval lookup (TF-IDF)
Risk scoring
Test generation
KG persist / read-back
Review — approve / reject
Execution triagevision
Release readinessvision
Release sign-offvision
Deterministic logic
Plain code. Same input, same output, every time.
LLM reasoning
A real model call. Probabilistic — read as a draft, not a fact.
Human sign-off
Nothing ships past this lane without a person deciding.
Want the module-by-module proof behind these diagrams?
See what's actually implemented →