---
title: "Traceability"
description: "End-to-end links between requirements, code, tests, deployments, and monitoring"
---

# Traceability

Traceability in TraceRTM is a connected graph that answers: what was built, why, how it’s validated, where it runs, and who owns it. Good traceability is live (kept current) and governed (validated, auditable).

## Overview

- **Forward**: Requirements → design → code → tests → deployments → monitoring.
- **Backward**: Incidents/defects → impacted components → upstream requirements/owners.
- **Lateral**: Dependencies and related workstreams (blocks/depends_on).

## How TraceRTM implements it

- **Artifacts** for every item type (feature, code, test, API, infra, wireframe, etc.).
- **Typed links** (implements, tests, deploys_to, monitors, depends_on, parent_of) with validation.
- **Views** to slice the same graph for each role—no duplicate records.
- **Audit and history** so changes are explainable and reversible.

## Building it in practice

- Create/import artifacts for requirements, code, tests, and deployments.
- Link code to requirements with `implements`; tests with `tests`/`verifies`; deployments and monitors with `deploys_to` and `monitors`.
- Enforce required links before moving to “Done”.
- Keep links updated during refactors; stale links erode trust.

## What “good” looks like

- Every requirement links to code and tests.
- Deployments reference the artifacts they run and the monitors that watch them.
- Relationship rules prevent dangling/invalid link types.
- Reports show coverage and change impact without manual stitching.

## Related

- [Traceability Matrix](./01a-traceability-matrix/)
- [Relationships](./04-relationships/)
- [Workflow States](./02a-workflow-states/)
