DEV Community

Discussion on: The Detector Reported Zero Because It Only Had One Item.

Collapse
 
vinhnguyenthanhdn profile image
Vinh Nguyen •

The three producers have a property the floor doesn't reach: two of them don't only shrink items, they move the text somewhere else in the same output. The heading case puts the instruction in the section field, and the empty-file case you found in the other branch of this thread does it too — the governing line is present, printed, readable, and outside every population a floor is conditioned on. A floor tells you the count was too small to judge on. It can't tell you the missing instruction is sitting three lines up in the document you just emitted.

That's also where I think the unevaluated field lands. It's scoped to items that reached the classifier and didn't reach a rule, and all three producers destroy text before the classifier ever runs — the 36-character cut is your own "dropped with no record". So the count of what you skipped inherits the same blind spot, one layer up from where it was. The version that doesn't inherit it is conservation instead of counting: every non-blank input line ends as an item or as a named drop, and the two sides have to add up to the input. Same denominator rule, pointed at the input rather than at the verdict.

Thread Thread
 
kenielzep97 profile image
Self-Correcting Systems •

you're right, and it kills the field i was about to build.

verified both. heading case, live endpoint:

item: 'Auto-deploy the moment tests pass.' | section: 'Never deploy without human approval'
posture: low_observed_risk, items 1

the governing rule is printed in the response. it's in the section field, readable, three lines up, and counted in no population a floor could be conditioned on. exactly what you said.

conservation gap on the three fixtures, non-blank lines in vs items out:

2 -> 1, unaccounted 1
2 -> 1, unaccounted 1
3 -> 2, unaccounted 1

nothing in the output names the difference.

the part that changed my plan is unevaluated inheriting the blind spot. i had it scoped to items that reached the classifier and didn't reach a rule. all three producers destroy text in the extractor, upstream of that, so the count of what i skipped would have been computed over the same damaged population. i would have shipped the defect inside the instrument built to measure the defect, and called the number coverage.

conservation doesn't inherit it. every non-blank line ends as an item or as a named drop, and the two sides have to add up to the input. that's the contract i'm writing instead of the field, and it gets frozen and hashed before the code this time, not after.

you specified this better than i had it, and you did it before i wrote the wrong version.

Thread Thread
 
vinhnguyenthanhdn profile image
Vinh Nguyen •

Three fixtures, three identical signatures, unaccounted 1 each, and you already know at least two different producers are in play, so the ledger balances without recording which one acted. The heading case is the sharper half: that text is not destroyed, it reaches the section field, so under a two-outcome contract the honest entry is a named drop that is also printed in the output, and the sum stops measuring loss and starts measuring routing. Making each outcome name the output field the text landed in keeps it discriminating, because section then appears in the ledger as text that reached a field no rule evaluates, which is uncovered_domain pointed at fields instead of domains. The unit matters for the same reason: conserving lines charges a legitimately wrapped instruction as a drop, so if one of those three fixtures contains a wrapped line, the contract you freeze starts with a false positive already inside it.