From user story to unit test. Every gap a graph query.
Requirements traceability is not a spreadsheet exercise — it is a structural property of the knowledge graph. SysEdge maps the full chain from user story to deployed symbol, and makes every missing edge visible as a query result before the code ships.
The traceability chain
One chain. Every link queryable.
SysEdge represents the full requirements-to-code path as a directed graph. Every hop is an edge type with a defined direction. A missing edge is a gap — not an assumption, not a comment in a Slack thread.
A gap anywhere in this chain is visible instantly. There is no "I thought that was tested" — the graph either has the edge or it doesn't. Running test-gaps --instance X returns every feature with missing VERIFIES edges, by tier, with a hint for the test file to create. Running coverage-review --uc UC-XXX checks the use case specification against seven AS-REQ dimensions and returns PASS, WARN, or FAIL on each one.
The chain is bidirectional: you can traverse forward (which tests cover this story?) or backward (which stories justify this endpoint?). Both directions are graph queries that take milliseconds — no grep, no manual cross-referencing.
The knowledge model
Why an ontology, not a database.
A task tracker stores rows. An ontology stores meaning. In SysEdge, a Feature is not a ticket — it is a capability a Module provides. A UseCase is not a description — it is a user-visible flow that realises a Story. A SysTest is not a file path — it is a verification artefact with a tier, a scope, and a set of VERIFIES edges pointing at the Features it exercises. The graph holds these distinctions structurally, not as conventions in a spreadsheet.
This matters for two reasons. First, a Claude Code session querying the graph gets typed, directed answers — "which features have no use case?" returns a precise set, not a fuzzy keyword search. Second, the ontology enforces consistency across twelve parallel sessions: if two sessions add features to the same module, the graph rejects duplicate nodes and merges redundant edges rather than silently creating a second copy of the same concept.
The first query surfaces architecture standards with no ADR — the exact gap that explained the Formbricks PII defect. The second surfaces features with no use case — specification omissions that become invisible bugs. Both are single CLI commands returning precise, actionable results in under a second.
coverage-review — AI-powered specification analysis
Seven dimensions. Every use case, before a session touches the code.
The coverage-review command evaluates a use case against seven AS-REQ dimensions — a structured rubric for specification quality derived from requirements engineering research. Each dimension returns PASS, WARN, or FAIL with a specific, actionable finding.
| Dimension | Name | What it checks |
|---|---|---|
| AS-REQ-001 | Actor Completeness | Can the actor complete their goal through the use case set? Are all named actors covered by at least one flow? |
| AS-REQ-002 | Auth Boundaries | Can an engineer derive the CASL permission string from the use case alone? Is the permission model explicit enough to implement without guessing? |
| AS-REQ-003 | Exception Coverage | Are all reachable failure states specified? Does the UC describe what happens when services fail, permissions are revoked, or data is invalid? |
| AS-REQ-004 | Ontology Alignment | Are entity names and relationship directions correct? Does the UC use the formal ontology vocabulary consistently? |
| AS-REQ-005 | Testability | Is each acceptance criterion substitutable directly into an expect() assertion? Are criteria precise enough to fail deterministically? |
| AS-REQ-006 | Scope Definition | Is the out-of-scope section explicit enough to prevent scope creep? Are decisions recorded — not just what is in scope, but what is explicitly out? |
| AS-REQ-007 | Bidirectional Traceability | Is there a backward link to the parent User Story? Are there forward VERIFIES edges from executed tests? Both directions must exist. |
Below is the output from running coverage-review against UC-FBK-005 (Export responses to CSV) on the Formbricks codebase. Three FAILs and four WARNs — all pointing at the same root cause as DEF-FBK-001.
These findings existed in the specification before any session wrote code. Running coverage-review at the start of a session surfaces them in under five seconds — before the first line of implementation.
Importing existing documents
Bring your existing specs into the graph.
If your project already has user stories, use cases, requirements, or architecture documents — in Markdown, plain text, or DOCX — the import skills read them and populate the graph. Every import uses a review-and-confirm step: no silent writes.
- /import-stories Reads a Markdown, TXT, or DOCX document and creates SysUserStory nodes. Each story is extracted, reviewed, and confirmed before any graph write.
- /import-use-cases Parses use case documents into structured SysUseCase nodes with actors, flows, acceptance criteria, and parent story links. Gaps in the document are flagged before import.
- /import-requirements Imports requirement statements and links them to the nearest matching features and modules in the graph. Orphaned requirements are reported separately.
- /import-architecture Reads architecture documents, creates Module and Component nodes, and links them to existing features. Architecture standards present in the document are matched against the standards library.
Every import uses a review-and-confirm step — no silent writes. The skill presents what it found, what it will create, and what it could not parse before touching the graph.
Exporting for documentation
Generate structured docs from the graph.
The graph is the source of truth — not the documentation. Export commands render slices of the graph as structured Markdown for handover, review, or audit. The output reflects the current graph state at the moment of export.
- /export --type stories Renders all user stories and their linked use cases as a structured requirements document. Includes coverage status and traceability links.
- /export --type application-arch Outputs the application architecture — modules, features, dependencies, and endpoints — as a structured Markdown overview. Suitable for architectural review.
- /export --type technical-arch Renders the technical architecture including module boundaries, inter-service calls, and data flow. Links architecture decisions (ADRs) to the standards they address.
- /export --type test-coverage Produces a coverage report by instance and tier — component, integration, use case, and end-to-end — with per-feature gap annotations.
The specification gap that caused the defect is visible before the code.
AS-REQ-003 and AS-REQ-006 caught the PII anonymisation omission in Formbricks before a single line of implementation was written. The same coverage-review command runs against your use cases in under five seconds. Specification quality is not a retrospective audit — it is a graph property checked at session start.