| name | traceability |
| description | Maintain requirement-level traceability from source need through decisions, product behavior, acceptance evidence, implementation references, and change history so scope and validation remain auditable. |
Requirement Traceability
Use when individual requirements need durable links to their origin, downstream artifacts, and proof of satisfaction.
Procedure
- Identify the authoritative source and assign a stable reference to each material requirement.
- Record rationale, owner, status, dependencies, and any parent or derived requirement relationships.
- Link each requirement to product or design decisions that define its intended behavior.
- Link implementation or configuration artifacts only at the level useful for impact analysis and evidence; avoid brittle references to incidental internals.
- Link validation evidence such as test cases, review findings, demonstrations, or acceptance records that prove the requirement rather than merely mention it.
- Record supersession, scope change, deferral, or removal with the decision that authorized it.
- Review orphaned requirements and artifacts and repair or explicitly explain missing links.
- Use stable repository, task, document, or system identifiers so traceability survives Fleet-routed work and context changes.
Decision rules
- A link is navigation, not proof of satisfaction.
- Traceability should survive implementation refactoring where the product requirement did not change.
- Keep source requirement, derived requirement, and implementation decision distinguishable.
- Do not maintain links that create more drift than decision value.
Quality gate
Traceability is healthy when every material requirement has source, status, owner, downstream decision, and acceptance evidence; changes expose affected artifacts; superseded items retain history; and another specialist can follow the chain without reconstructing it from conversation logs.
