The clause that was never in the specification
Splitting a wrapped specification clause on newlines invented a hold point that did not exist. A register that gains a requirement nobody imposed is worse than one that misses it.
Specification intelligence reads a supplied specification and classifies each clause: is this a hold point, a test, a submittal, or an ordinary obligation? Order matters. A clause saying both "inspected" and "shall not be covered" is a hold point, and reading it as a test loses the fact that work stops.
The imperative counts as mandatory, because NBS-style specifications write obligations as instructions — treating Submit the mix design as advisory would let most of a specification through as optional.
The defect was upstream of all that judgement, in deciding where one clause ends and the next begins. Splitting on newlines is the obvious approach and it is wrong: specifications are wrapped text, so a single clause that happened to run over a line became two clauses. The second half, read alone, classified as a hold point.
The register therefore contained a hold point that was never in the specification. That is the worse failure of the two available. A register that misses a requirement is incomplete, and somebody notices when the work arrives. A register that gains one is authoritative and wrong: it stops work that was never required to stop, and the argument about it happens on site.
The classification is deterministic on purpose. The same text gives the same answer twice, and anybody can see why a clause was read the way it was — which is the only property that makes it arguable rather than merely automated.
The part that earns its place is the join. specificationCoverage matches verification clauses against the acceptance criteria in the inspection and test plan, and reports what has no inspection stage against it. That gap is invisible from both sides: the quality manager reads the ITP, the engineer reads the specification, and it exists only between the two.