Filling in a spreadsheet you are not allowed to redesign

Nine rows marked “skipped” that nobody skipped

Symptom

On the first real workbook, a third of the first sheet came back skipped, including every basic company detail: organisation name, postal address, telephone, email, the name of the signing representative. The company profile holding all of those values was populated and correctly wired. Nobody had clicked skip all.

Diagnosis

Those rows had never reached the answering step at all. The reader had classified them as section banners, meaning decoration, and rows classified as decoration are excluded from answering entirely, which the interface then surfaces as skipped.

The reason was the classifier’s very first gate: does this row have other cells filled in? If so, it is a real question. That gate is sound on the path it was written for, where the file being read is a completed questionnaire. On an unfilled returnable template every answer cell is blank by definition, so the gate can never fire, and short noun-phrase labels then fall through the remaining tests (under the length limit, under the word limit, no question mark, no requirement verb) and land in a weak structural test where a merged cell or a dense identifier column tips them to banner.

Worse, one signal was actively voting against them. The sheet’s merged value cell was being read as evidence for banner, because the merge-detection code kept each merge’s width and discarded its starting column. So a merge to the right of the question, which is what an answer cell looks like, was indistinguishable from a merge across the question itself, which is what a section header looks like.

And the safety net didn’t fire: a circuit breaker disables junk detection on a sheet when too many rows are flagged, but this was a third of them, under the threshold.

Decision

Add signals, never replace the gate. That gate is live negative evidence on the shared questionnaire path, where it is right; the new signals are additive escape hatches that run after it. Three of them, and I checked which rows each one actually rescued before writing any:

a dropdown rule covering this row’s cell to the right of the question; a merge starting right of the question column, which needed the merge code to retain the starting column it was already computing and throwing away; and a vocabulary test for fill-in field labels.

The vocabulary test is the ugliest of the three and it stays, because the table of which signal rescues which row is unambiguous. The structural signals rescue the dropdown rows and the merged rows, and leave every unmerged free-text row still skipped: the address, the phone number, the representative. Those were the rows that started the investigation.

The test asserts the fix and asserts the circuit breaker did not fire, because a green test that passed via the safety net proves nothing about the signals.

The general shape: a heuristic that reads surrounding content is only as good as its assumption about what surrounds it. This one had been written against filled-in files and was correct there. Nothing was wrong with it except the input it now got, which is why it passed review, and why the bug appeared only on real customer templates.

A signal that discriminated perfectly, then discriminated nothing

Symptom

On the next workbook, the opposite failure. Four rows that were section headers, bare parent numbers with no requirement text under them, were each answered at two to five thousand characters, and the export wrote compliance ratings into the sheet’s section headers. Not one row on that sheet was classified as a non-question.

Diagnosis

The dropdown signal from exhibit 1 was rescuing them. On a form, a dropdown beside a row is strong evidence that the row is a field to fill in. On a compliance matrix, the author paints the same dropdown down the entire column, so every row satisfied the signal, including the headers, and each one was rescued as a “field row” before the classifier ever consulted the fact that the row was a parent identifier with children beneath it.

A signal present on every row of a sheet carries no information about any row of that sheet. It had been genuinely discriminating on the file it was built for and was pure noise on this one.

I did not diagnose that from reading the code. There was an existing harness that runs the reader over a directory of real workbooks and prints per-sheet counts; I extended it to print each row’s evidence flags and classification reason, so the mechanism came off the actual file rather than out of my own reasoning about it.

Decision

Three changes, each scoped to what it actually knew.

Precedence. A parent identifier with children beneath it outranks the field-row escape, because it is derived from the sheet’s own numbering and a form field never has children. But it is placed below the length and requirement-verb gates, so a numbered parent that carries a real requirement sentence stays answerable.

Coverage. Compute per-column dropdown coverage once per sheet and stop a column that covers nearly all question rows from counting as per-row evidence. With a floor of ten question rows, because on a short vertical form an author painting a dropdown down a five-row answer column would trip any percentage threshold, and short vertical forms are exactly the rescue in exhibit 1 that this must not break.

A direct reading beats an inference. A row whose question text is identical to its own row identifier has no requirement in it to answer, whatever the structural evidence says, so it is classified before any of the structural work, where no rescue can reach it, and it is exempt from the circuit breaker. The breaker exists to catch a structural inference misfiring across a sheet; on an identifier-heavy sheet, counting these would trip it and un-junk everything, which is the exact failure being fixed.

I also wrote down the fix I rejected: a general regular expression for bare identifiers. It matches published standard names and annex numbers, and a compliance matrix whose question column lists bare standards is a real shape on these files, so every row of such a sheet would be discarded, with the breaker exempt and therefore unable to rescue them. The narrow equals-its-own-identifier test survived; the general pattern did not.

A refusal that a later line of code relabelled as an answer

Symptom

Found by comparing a full machine-answered submission against the same submission answered by people. Six rows had shipped a compliance rating with an entirely empty justification column, and every one of them was labelled in the interface as a clean, sourced answer. Nothing flagged them. A bid manager reading the review queue would never have looked at them.

Diagnosis

Those rows had been refused on purpose. The answer named a supporting attachment the bid did not have, and the guard against claiming attachments correctly withheld the justification and marked the row for a human.

Then two later blocks in the same assembly function overwrote the label. One sets a source attribution whenever the row has citations; the other sets one whenever the row needs a document, unconditionally. Both ran after the guard, and both erased the review status. Attachment-claim refusals happen precisely on document-request rows, so the second block hit every affected row.

The refusal was being inferred from fields that later code was free to overwrite, and it left no trace at export time either: the guard had already dropped the refused cell, so the stored row was internally consistent and re-validating it at export raised nothing at all.

Decision

Track the refusal explicitly, as its own sticky flag, and gate both relabelling blocks on it. A source label describes where an answer came from; it is not a licence to clear a review flag, because the cell being attributed is the one that was refused. Citations and match provenance stay populated in every case, since they are what the human writing the real answer needs.

The obvious one-line version of this check is wrong, and I noted why in the code rather than in a commit message: gating on “the answer is non-empty” passes, because the validator sets the row’s answer to the primary cell’s value, which on these sheets is the compliance code. Non-empty check, check passes, row relabelled, justification still blank.

Two things I chose not to do. No backfill, since this corrects generation, so rows already stored with the wrong label stay wrong until they are regenerated. That is worth stating rather than discovering, because the validation run resets the affected sheets and will therefore look clean while real bids elsewhere are still wrong. And no decision in code about whether an unapproved row’s values should reach the customer’s file at all: the export warns and writes, since the refused value was already withheld and what remains is a validated one, while withholding it leaves a mandatory dropdown blank that some portals reject. That is a product call, so I raised it as one.

A refusal inferred from overwritable fields

guard withholds the justification, flags the row   ✓
then: citations present      → source relabelled
then: row needs a document   → source relabelled
                               (unconditionally)
stored row      clean, sourced, internally consistent
review queue    absent
export notice   none. nothing to key off at export
delivered file  a rating, and an empty comment cell

A refusal tracked as its own fact

guard withholds the justification, flags the row   ✓
refusal recorded as its own flag: sticky
both relabel blocks gated on it
citations + match provenance kept either way
stored row      pending, needs a human
review queue    present
export notice   named by row, not counted
not the gate    “answer is non-empty”. the answer
                is the rating. it passes. ← the trap

A confidence score that said “high” about one column in three

Symptom

Answers crammed into one cell on sheets that had three or four separate answer columns, with no warning anywhere. The layout resolver reported high confidence in each case.

Diagnosis

The confidence switch granted high as soon as one strong answer column was identified, however many plausible blank candidate columns it had left unclaimed. Measured against the real files, it was finding one of three columns, and three of four, and calling both high.

That number is load-bearing further down than it looks. The export trusts only a high or human-confirmed layout, and suppresses its “this layout was inferred from the sheet’s shape and never confirmed” warning when it sees one. So the single signal that would have sent somebody to the column editor was being switched off by the same over-confidence that created the need for it.

Decision

Split it into two pieces of work and do the small honest one first: degrade to medium when unclaimed blank candidate columns remain to the right of a claimed one, and return those candidates, because the strong branch was returning none, so degrading alone would have left the editor with a warning and nothing to offer. Widening detection to actually claim those columns is the larger, riskier change, and it goes after the correction path exists, not before.

The same principle drove the export’s notices, which were bare counts (“3 rows are unanswered”) with no row identity. They became lists of row labels, capped with the true total preserved and the full list logged, across four buckets including a new one for a row carrying a rating with no supporting comment. The wording is aimed at a bid manager about to submit, so it names the risk rather than the mechanism.

A separate, smaller lesson from the same export: the workbook it produced could not be opened by a common Python spreadsheet library, which some downstream tooling used. A style round-trip in the Go library was appending an empty fill element that the Python parser rejects. It looked like data being lost, and the fix was the opposite of what it looked like: zero the fill rather than preserve it, since the empty element was what preserving it produced. I confirmed that in a throwaway reproduction before touching the export, because “Excel opens it fine” had already made this invisible once.