Traceability

Traceability answers a simple question: which parts of the planned application satisfy each feature? The tab is a live requirements traceability matrix built from the plan itself — features on one axis, planned surfaces on the other — so coverage is something you mark and read, not a spreadsheet you maintain beside the project.

Features from Domain → Features form the rows. Pages, components, data entities, and backend endpoints planned in Structure, Data, and Backend form the implementation axis. Mark the cells that connect a requirement to the surfaces that deliver it.

When to use it

Use Traceability after the first pass through Domain, Data, Structure, and Backend, once both axes have something on them. If no features exist yet, the tab's empty state takes you straight to the Features panel.

Two readings matter:

• Empty rows are features with no implementation plan — a stated requirement that no page, entity, or endpoint delivers. This is forward traceability: every requirement should trace to at least one surface.
• Empty columns are planned surfaces no requirement asks for — scope that crept in, or a feature list that is missing an entry. This is the backward reading: every surface should trace to a reason it exists.

Neither reading is automatically wrong. A shared layout may legitimately serve no single feature, and a freshly added feature will sit empty until its surfaces are planned. The matrix's job is to make each gap a deliberate decision instead of an accident. For why this discipline pays off beyond one project, see tracking what implements each requirement.

Working a large matrix

The matrix stays usable as the plan grows:

• Row search and status filter narrow the feature rows by name or status, so a long feature list can be audited a slice at a time.
• Column search narrows nodes by title or kind, so you can audit one slice — only endpoints, only entities — at a time.
• Sorting flips the feature order without touching the links.

Filters and sort are view state only; they never change which links are recorded.

Coverage travels with the plan

The matrix updates as the underlying workspace changes and is saved with the project. Its links flow into the project report alongside the test cases attached to each feature, so the report answers both "what implements this feature?" and "how will we know it works?" in one place. A read-only share link with ?view=report puts that same coverage in front of stakeholders who never open the editor — the matrix doubles as the review artifact a requirements management process usually has to assemble by hand.