A model added one character to a table cell. Schema validation could not catch it.

A model asked to transcribe a table will sometimes improve it. Not maliciously, and not often — but reliably enough that we had to build a check for it.

The case that made us build it was small. A cell in a loan document read 循环贷款, a revolving loan. The model returned 循环贷款等 — the same words with 等 appended, turning a specific instrument into "revolving loans and so on". One character. If you skim the output against the scan, you will not see it.

Why the usual checks miss it

Most table extraction is validated against a schema. Is the column present? Is the type right? Is the row count plausible? A schema answers all three and reports success, because the column is still the column and the type is still a string. The value is wrong in a way that no structural check can express.

The only check that catches it is comparison against the source. So after the model produces a cell, the verifier asks a narrower question: does this exact text appear in the text layer of the page this table came from? Not "is this a reasonable value" — that question is what produced the error.

What that looks like in the output

A cell the document confirms is delivered as a normal value. A cell the document cannot confirm is marked, and the delivery as a whole is labelled as carrying warnings rather than reported as a clean success. The manifest records the specifics:

{
  "outcome": "succeeded_with_warnings",
  "warnings": [
    "extra_fields:2",
    "unconfirmed_cells:个人关键信息"
  ],
  "source_pages": 7
}

That is a real manifest from this site, trimmed of identifiers. It says three things: the extraction is usable, two fields were produced that the schema did not ask for, and one column could not be confirmed against the source at all. A user receiving that file knows exactly which column to check by hand.

What the production record shows

Across the table deliveries recorded on this site, 13 of 14 were marked with warnings rather than clean. Four carried unconfirmed cells. It would be easy to present that as a problem; the honest reading is that the check is doing what it was built to do, and the alternative — reporting all fourteen as success — would have been a lie in at least four cases.

The lesson generalises beyond tables. Any time a model is asked to reproduce something that already exists in a document, a structural check tells you the shape is right, and says nothing about whether the content is. If the content matters, it has to be compared to the source.

What to do with this

1. Treat unconfirmed as a question, not a failure. The cell needs a human look; the other 99% of the sheet does not.
2. Do not ask for a value the document does not contain. A model asked to fill a blank will fill it.
3. Check the warning counts against the number of columns you defined. Extra fields are how a model quietly expands scope.

If you want to see the behaviour on your own document, the structure preview is free: it returns the detected tables and columns before any credits are spent on a delivery.