Traceability: from a feature to the thing that implements it

The question nobody can answer from the plan

Every project has a list of features, and every project has a design. They are almost never the same document. The features live in a spec, a backlog, or a slide someone made for a stakeholder; the design lives in a folder structure, a diagram, or a canvas. Both are true and neither can see the other.

So the question that decides whether the plan is finished — which parts of this application actually deliver this feature? — has no home. It gets answered from memory in a meeting, and memory is optimistic. The feature everyone assumed was obviously covered turns out to be covered by nothing, and it turns out that way in the third week of building.

Traceability is one tab in the Nodlume workspace whose whole job is to make that question answerable by looking rather than by remembering.

Two axes you already wrote

The matrix has features down the side and implementation across the top, and neither axis is something you fill in for the matrix's sake.

The rows are the features from Domain → Features — the same list you wrote when describing what the application is for, carrying the same Planned / In progress / Ready status. The columns are your live boards: the pages and components from Structure, the entities from Data, and the endpoints from Backend, each shown with its kind under its title.

Entities and endpoints sit on that axis for the same reason routes do. A feature is at least as likely to be implemented by a table or a POST /invites as by a page, and an axis that only offered you pages would quietly teach you that features are things pages do.

Because both axes are read from the live design, the grid changes when the design does. Add a route and a column appears. Rename a feature and its row is still the row it was — links are held against the feature's identity, not its text, so renaming "Trip sharing" to "Share a trip" keeps every tick you made.

Everything saves with the project, and in a shared project it syncs live, so a tick made by whoever is reviewing shows up for whoever is designing.

Ticking is the work

There is no Generate button on this tab. That is deliberate, and it is the one place in the product where the absence is the feature.

A tick is a claim — this endpoint is part of how we deliver that requirement — and it is a claim only a person holding the intent can make. A generated matrix would be a plausible guess at which boxes ought to be checked, printed into a document whose entire value is that its checks were checked by someone. Coverage that produces itself measures nothing.

The ticking is cheap in exchange. Row search and a status filter narrow the features, a column search matches nodes by title or kind, and the headers stay stuck to the edges while you scroll both ways, so a wide board still reads across.

The most useful five minutes is usually: filter rows to Ready, then read each one across. A feature somebody has already called done, with no cell ticked in its row, is either mislabelled or built out of nothing. Both are worth knowing before the demo.

Read it in both directions

A matrix has two kinds of emptiness and they mean opposite things.

An empty row is a feature with nowhere to be implemented. Sometimes that is a real gap — nobody designed the surface it needs. Sometimes it means the feature is vague enough that no surface obviously claims it, which is a finding about the sentence, not about the design.

An empty column is a surface no stated requirement asked for. Occasionally that is honest scaffolding. Often it is the page that got drawn because applications have one, and it will cost the same to build as the ones somebody wanted.

Neither is automatically a defect, which is exactly why the tool does not flag them as errors. It shows you the shape and lets you decide which blanks are decisions.

Deleting a node removes its claims with it — the report only ever names surfaces that exist, so a matrix cannot go on crediting a feature to a route you deleted last week.

What the report says

The links leave the workspace in the generated project report, under Traceability matrix, and the section opens with the sentence that gets read aloud:

7 of 11 features are linked to implementing nodes.

Then a row per feature: its name, its status, and what implements it — each node by title and kind — or a plain — not linked where nothing does. Not linked is printed rather than omitted, because a report that lists only the covered features is a report that gets less accurate as the project gets worse.

If no features have been written down at all, the section says so instead of rendering an empty table. There is nothing to trace, and a blank grid would imply the tracing was done and came back empty.

Traceability and coverage are different questions

The section immediately after it is Test coverage, and the distinction between them is worth being pedantic about.

Traceability asks does this feature have somewhere to live? Coverage asks does anyone claim to know when it works? A feature can pass the first and fail the second, and those are two different conversations with two different people.

Coverage builds on the links you made here. A feature counts as covered when a Test suite node tests something the feature is traced to, or when acceptance criteria are written beside one of those surfaces — both count, because a route with four written criteria is not untested merely because nobody drew a suite node at it. That gets its own counted line:

5 of 11 features are covered by a test suite or written criteria.

And criteria are criteria. Nothing in Nodlume runs, and the report never says a thing passed — only what has been claimed must be true. A report that inferred results from a plan would be the most dangerous document the tool could produce.

Sending it to somebody

The report exports as Markdown or as a standalone HTML document that prints to PDF, and a share link can render it instead of the canvas — so a client, a compliance reviewer, or the person who has to sign off can read what implements what without an account and without being taught a canvas.

That is usually the moment the matrix earns itself. "What does this app do, and what proves each part of it exists" stops being a meeting and becomes a link.

Where to start

Open a project that already has a few features and a first pass at Structure. Go to Traceability, filter the rows to Ready, and tick honestly for those first — including leaving blank the ones you cannot defend. Then flip the filter to Planned and look for the features whose whole row you cannot fill: those are the ones to design next, and the matrix just prioritised them for you.

The Traceability tab reference covers the panel itself, and Domain covers the feature list the rows come from. For the criteria the coverage line counts, planning tests before the code exists is the companion to this one.