A process owner proposes telling the extraction model to ignore hidden text — what does that actually close?

## The conversation you are actually in An owner has a working process, a finding on their desk, and a cheap-looking fix: add a line to the extraction prompt telling the model to disregard hidden text. Your job is not to refuse it — it is to say precisely what it closes, what it does not, and how the claim they can make about the process changes. ## Why the instruction asks for something impossible By the time content reaches a model's context it is tokens. There is no attached flag saying *this run was painted at 11 point in the middle of page two* and *this run came from a container the viewer never opened*. Extraction flattens provenance-of-appearance unless the pipeline deliberately carries it. So an instruction to ignore hidden text asks the model to classify on a signal that is not in its input. What the model can do instead is guess from *style*: a run that reads as an imperative addressed to a system looks unlike an invoice line. That guess catches careless constructions. It is also exactly the property an author can spend effort on — a span that reads as an ordinary remark, with a plausible reason it belongs in a vendor note, sits in the same window as the instruction meant to distrust it, and the model weighs both. ## What actually changes, and what does not | The proposal changes | The proposal does not change | | --- | --- | | The model's disposition toward obviously directive runs | Which containers the extractor emits into the context | | The cost of a careless construction | Which artefact the approver reads before signing | | Nothing about the artefact gap | Whether a page-versus-extraction mismatch is ever put in one view | The first column is a *preference*, expressed in the same channel as the content it is meant to judge, and evaluated probabilistically per document. The second column is *pipeline shape* — deterministic, unchanged by any wording. ## The honest sentence for the owner *Before: a span in a non-displayed container reaches the model every time, and nobody sees it. After: it still reaches the model every time, and the model usually declines to act on the blatant ones.* That is a real improvement in expected outcomes and not a closure. The measurable claim shifts from **cannot happen** to **usually does not**, and the finding should be recorded that way rather than marked resolved. ## Where the class genuinely stops working It stops where the two texts converge: where the string an approver reads is the string the model received, or where a pipeline simply does not emit containers a page never paints. Both are facts about pipeline shape, which is why a prompt edit is the wrong lever rather than a weak one — it operates on a different variable from the one the construction depends on. Naming that distinction is most of what a senior answer is worth here; choosing and funding a change is somebody else's chair. ## The failure mode to avoid in the room Do not answer *that will not work*. It does something, and an owner who hears absolutism stops listening. Answer with the two columns: here is what your line buys, here is the variable it does not touch, and here is the sentence you can defensibly say about the process afterwards. That is the difference between being right and being useful.