Capstone: Make a Workflow Reportable

Seven sections have been written without any of them being read against the others. The test that matters here is a question rather than a record, because questions are what a reporting specification has to survive once somebody is relying on it.

Four of them, each answerable only if a particular section was done properly. The third one is the interesting one: against a specification that treats every absence as a zero, “which segment is worst” does not merely lose precision, it inverts, and it sends somebody to fix the team with the best data capture rather than the worst.

Then eleven validation checks run by stable ID, testing the seams. Does every date have both a capture rule and a stated gap? Does the backfill have a direction that cannot destroy information? Does every metric with teeth publish its blind spot? None of these is answerable from inside the section that created the problem.

What the specification is not

It does not make reports accurate, and accuracy was never the problem. A number computed correctly from data that was never captured is perfectly accurate and completely wrong.

What it buys is the ability to tell apart two situations that every unprepared reporting system confuses: the work that did not happen, and the work that happened and was not captured. Those look identical in a number and demand opposite responses. One is a performance conversation. The other is a process defect, and having it as a performance conversation is how good people get managed out over a logging pattern nobody told them about.