# Requirements Traceability Matrix

> Trace each requirement to the tests and endpoints that verify it, run impact analysis when requirements change, and export a requirements traceability matrix for audits.

Source: https://totalshiftleft.ai/help-center/product-documentation/requirements-traceability-matrix

## 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](/features/requirements-intelligence/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](/help-center/product-documentation/importing-and-reviewing-requirements). Each approved requirement retains its **source facts** (the deterministic facts pulled from your API spec via the OpenAPI/WSDL/GraphQL adapters), so the chain from spec text to requirement is preserved.

> Supported protocols are **REST, SOAP, and GraphQL**. gRPC is not supported and does not contribute to traceability.

## 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](/help-center/product-documentation/ai-generated-tests).

## 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](/help-center/product-documentation/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.

## Related articles

- [Understanding Rule Intelligence](/help-center/product-documentation/understanding-rule-intelligence)
- [Coverage and fidelity](/help-center/product-documentation/coverage-and-fidelity)
- [Continuous learning insights](/help-center/product-documentation/continuous-learning-insights)
- [Audit Logs](/help-center/product-documentation/audit-logs)

