A vendor invoice PDF passed human review — how can extracted text still carry a directive the reviewer never saw?

## The claim being corrected The usual answer to *how did that reach the model* is **the document was reviewed before it was indexed**. That answer is not false — a person really did open the file. It is *aimed at the wrong artefact*. The document was reviewed **as rendered**, and the extraction stage exists specifically to recover what rendering leaves out. The distance between those two behaviours is the entire surface. ## Four things called *the document* In an accounts-payable flow where a counterparty uploads an invoice and a model reads the fields an approver signs off on, at least four distinct objects get called the document: - **the bytes** somebody uploaded; - **the rendered pages** a reviewer opens in a viewer; - **the text an extractor emitted** from those bytes; - **the field summary** the approval screen shows. A control, a review or a claim always attaches to exactly one of these. Saying *the document was checked* without saying which one is the mistake, and in practice the human checked the second while the model consumed the third. ## Why the two texts differ by design Rendering is **selective**. A layout engine decides what goes on a page, at what size, in what order, inside a visible canvas. Content that is present in the file but not placed under an eye — a value stored in an interactive form field, the body of an annotation, alternative text attached to a graphic, a run positioned outside the visible area or set at a size a person skims past — simply does not appear. Extraction is **thorough**. Its job is the opposite: recover everything machine-readable so that downstream stages do not miss a value the page happened to lay out awkwardly. A good extractor deliberately reaches into containers the page does not show, because in ordinary documents those containers hold real data. Both behaviours are correct. Neither is a defect. And the author of the file gets to choose which side of the line a given span sits on. ## What the reviewer's approval actually establishes That a person looked at a rendering and found nothing objectionable in it. It establishes nothing about the extracted string, because the reviewer never saw that string. This is the same directional discipline you apply everywhere in this domain: a passing screen proves the artefact it inspected scored below a threshold, not that a different artefact is clean. ## Why this is not about obfuscation A span in a non-displayed container is not encrypted, encoded or disguised. It is plain text sitting in a place a viewer does not paint. A machine reading the bytes can see it perfectly well; that is exactly why the extractor emits it. The asymmetry being exploited is **human visibility versus machine recovery**, not secrecy. Candidates who reach for encoding tricks here have misread the mechanism. ## Where the class does and does not apply The construction depends on the reviewer's artefact and the model's input being two different texts. In a pipeline where the model is given only a rasterised page image, non-displayed containers never reach it and this whole family is inert — a different family applies there instead. Equally, if the string an approver signs is literally the extracted text, the span is on screen and the construction has no hiding place. The interesting question in any real deployment is therefore not *is there hidden text* but *which artefact did the human actually read, and which one did the model get*. ## What an interviewer is scoring Not a list of places to hide things. They want to hear you separate the artefacts, name which stage saw which one, and refuse to let *it was reviewed* stand as an unqualified claim.