Overview

Rule Intelligence maintains a traceability graph that links each requirement to the tests and endpoints that verify it. This gives you end-to-end proof — from a documented requirement, through its source facts, to the tests that exercise it — which is exactly the evidence auditors and regulated teams ask for. Explore the capability at traceability matrix.

Before you begin

Traceability builds on the same workspace as the rest of Rule Intelligence (project editor → Requirements tab, or the standalone hub → select a project).
Links form as you approve requirements and generate tests — an empty project produces an empty matrix, which is normal on day one.
The RTM export currently ships as JSON. Spreadsheet/PDF formatters reuse the same data and follow once the JSON contract is finalized.

Step 1 — Approve requirements so links can form

Traceability starts from approved requirements. Import and approve them on the Requirement Documents tab — see Importing and reviewing requirements. Each approved requirement retains its source facts (the deterministic facts pulled from your API spec via the OpenAPI/WSDL/GraphQL/gRPC adapters), so the chain from spec text to requirement is preserved.

gRPC is adapter-only — it contributes extracted facts to traceability, but the platform does not run gRPC tests at execution time.

Step 2 — Generate tests to create requirement → test links

When you generate tests, the platform records traceability links connecting each requirement to the tests that verify it and, through those tests, to the endpoint they hit. This is what turns a static requirement into a verified one. See Generate endpoint test cases.

Step 3 — Review the traceability graph and coverage

The traceability graph is what you read to answer "is this requirement actually tested?" It exposes:

Requirement → test → endpoint links — which tests cover each requirement and which endpoint each test targets.
Traceability coverage — which requirements are verified by at least one test and which are unlinked (approved but not yet covered by any test).
Links per entity — the links attached to a specific requirement, test, or endpoint.

Unlinked, approved requirements are your priority gaps — cover them by generating tests, cross-checking with Coverage and fidelity.

Step 4 — Run impact analysis when something changes

When a requirement or endpoint changes, use impact analysis to see what's affected before you regenerate or re-run. Given one or more changed endpoints, it walks the graph and returns the requirements and tests downstream of them — so you know the blast radius of a change rather than re-running everything blindly.

Step 5 — Export the RTM for audits

Export a Requirements Traceability Matrix as your audit artifact. Each row carries the columns compliance reviewers expect:

Requirement identity — requirementId, publicId, title, description, category, requirementType, priority, status.
Provenance — operation/endpoint, protocol, synthesisSource, qualityScore, extractionFidelity, and reviewedAt.
Source facts — for each linked fact: its source, fact type, statement, source reference, and confidence.
Tests — for each verifying test: test id, name, test type, and status.

The export also stamps a generatedAt timestamp and totals for requirementCount, factCount, and linkCount, so the matrix is self-describing as a point-in-time record.

Notes

The matrix is a snapshot at export time — regenerate it after approving requirements or generating tests to capture the current state.
A requirement that appears with no linked tests is approved but unverified; that's a real coverage gap, not an error.
Traceability data is scoped to your workspace/tenant — you can only trace and export within projects you have access to.

Requirements Traceability Matrix