No row for the headers: what a result list leaves unmeasured
Published · Updated
Three published case studies report three or four measured outcomes each. Each also describes shipped work that no row counts. That gap is where things regress without moving a figure.
A case study result list is a choice, not an inventory. Across three published Neurolinks projects, each one reports three or four measured outcomes, and each one also describes delivered work that no row counts. Hardened security headers, multi-language generative video campaigns, newsletter and social distribution: described as part of the build, absent from the scoreboard. Worth looking at deliberately, because unmeasured capability is where quiet regression lives.
What the rows actually cover
Tatano Energy reports country domains indexed separately: 4, languages served: 7, SEO articles published every day: 8, and manual intervention required: 0. Those rows track reach and cadence. Abbys Consult reports time to first byte < 200 ms, technical SEO issues at launch: 0, and client time spent on operations: 0 h, covering speed, launch hygiene and whose hours get spent. Each list answers the question its challenge sentence asked.
The personal media platform reports articles published autonomously: Daily, model fallback levels: 3, GEO audit score after overhaul: 66→90+, and weekly content operations time: ~0 h. Notice the shapes differ. A cadence, a configuration count, a before-and-after, an approximate time cost. Different shapes need different instrumentation behind them, which matters the moment you consider adding a row for something currently unmeasured.
The described work with no row
The platform description for Abbys Consult includes hardened security headers. No result row reports on them. Tatano Energy's description includes multi-language generative video campaigns alongside the commerce platform and the daily autoblog. No row counts campaigns, videos or languages of video. The personal platform's description includes newsletter and social distribution. The rows count articles published, not anything sent or posted. In all three, shipped scope exceeds measured scope.
This is not an oversight so much as a consequence. Rows tend to follow the challenge. When credibility is judged in the first five seconds of a visit, speed earns a row. When four European markets have no differentiated visibility, domains and languages earn rows. When the goal is authority without hours a week of content operations, cadence and operations time earn rows. Supporting work stays described.
What goes unnoticed
A capability with no row can degrade without moving any reported figure. Article cadence stays Daily whether or not distribution behaves, because the row counts articles. Security headers can weaken without touching time to first byte, because one is a response header set and the other is latency. The list keeps reading the same, which is exactly why it feels trustworthy and why it is incomplete.
There is a second failure mode: rows that describe a dated state rather than ongoing behaviour. Technical SEO issues at launch: 0 is a reading taken at launch. Country domains indexed separately: 4 is a count of configuration, not proof that each domain served correctly this morning. Treat launch-time and configuration figures as timestamped observations, and decide separately what re-reads them later.
Choosing which capabilities earn a row
Three questions sort the list quickly. Would a failure here move any row that already exists? If not, the capability is invisible. Does anybody look at it in the normal course of work? With manual intervention required: 0 and weekly content operations time: ~0 h, nobody is looking by design, so a row is the only available observer. Would its failure be visible to a visitor before it is visible to you?
Cost varies by row shape, which is an argument for deciding early. A threshold like < 200 ms needs repeated measurement to stay meaningful. A cadence like Daily needs a log of publications, one entry per unit of work. A before-and-after like 66→90+ only exists because the lower reading was taken before the change. Baselines are the one row you cannot add retroactively.
Takeaway
Put the capability description beside the result list and mark every described item with no corresponding row. For each mark, make one of two decisions and record it: add a row, naming what gets measured and how often, or accept that the capability is unaudited and note who would notice first if it broke. Both are defensible. Leaving the gap undecided is what turns a clean scoreboard into a blind spot.
Sources
Neurolinks case study — Four markets, one codebase — https://neurolinks.be/work/tatano-energy
Neurolinks case study — A personal brand that publishes itself — https://neurolinks.be/work/matthieu-pesesse-media
Neurolinks case study — A consulting firm, dressed for trust — https://neurolinks.be/work/abbys-consult
Working on a project where these methods apply?