Traceability · methodology to implementation

What exists, section by section

How much of the published methodology is actually built — implemented, partial, absent, or specification-only — measured against the published document on every build.

79Sections
56/67ImplementedOf the sections that describe a component. Specification-only sections are excluded from the denominator rather than counted as wins.
the source documentChecked againstThe heading structure is re-extracted from the published methodology on every build, so a new version cannot ship without the matrix being brought with it.

A reader can read the methodology, and can read that an implementation exists. The question between the two is how much of it is actually built — and the honest answer includes the parts that are not.

A figure reporting full coverage would be worthless. GII-US is pre-pilot: several parts of the methodology describe work that cannot be done before real data or real reviewers exist, and a few describe constraints on the work rather than work itself. Counting those separately, rather than quietly omitting them, is what keeps the denominator honest.

Coverage

Every published subsection by status

Specification-only sections describe how the work is done rather than a component to build. They are counted, not hidden — that is what keeps the denominator honest.

  • Implemented5671%
  • Specification only1215%
  • Partial810%
  • Not implemented34%

79 sections in total

Four statuses, and the last distinction matters. Implemented means code exists and something verifies it. Partial means some of the section is built and the note says what is not. Not implemented means nothing is built and the note says what it would take. Specification only means there is nothing to build — the section constrains how the rest of the work is done. Recording that last group rather than quietly omitting it is what stops the coverage figure from being flattered by sections that were never going to have code.

The section map is not published #

The counts above are the claim: this much of the methodology is built, this much is partial, this much is not built at all, and this much was never going to have code. What is not published is the row-by-row map — which numbered section corresponds to which rule, which file implements it, and which test verifies it.

That map is the most efficient description of the methodology that exists. It enumerates every rule in the published order and states, for each, whether it is real. Handing it over would make the coverage figure marginally more auditable and the index substantially more reproducible, and that is not a trade this project makes. The matrix is generated and checked on every build against the published document, and is available to operators through gii traceability and gii traceability --gaps.

How this stays true #

A traceability matrix decays faster than the code it describes, and it decays silently — nothing about a stale matrix looks wrong. So the heading structure is re-extracted from the published .docx on every run, not from a list someone typed once. A section added, renamed, or renumbered in a new methodology version fails the check until this matrix is brought with it. Every claimed path must exist. A row that is not implemented must explain itself, and a row claiming nothing is built may not also cite code.

Run it with npm run check:traceability, or read the data at /api/v1/traceability and gii traceability --gaps.