Asked for at Least Three Requests, an AI Found the One That Was There. Then It Added “Thanks, Alan”

An email from the Enron archive, signed by Alan Aronowitz, asks one question: “In connection with the Legal costs allocations for 2002, what percentage of your time do you think you would spend on EGM matters?” An AI model was asked to “List all the requests.” and told that the answer had to follow a form saying the list holds at least three. It returned the question. Then it returned two more lines from the same email: “The accounting group who is asking for this information realizes that this is a guess on your part.” and “Thanks, Alan”. Nothing was invented. Every word is in the email, and none of it is a request.

The example opens a preprint posted on arXiv on 22 October by Abhishek Barali and Aayush Paudel of St. Xavier’s College in Kathmandu, Nepal. Software that pulls information out of documents often asks a model for its answer in a fixed format, a JSON schema, and the schema can set a minimum number of entries for a list. The authors wanted to know what happens when the document has fewer items than the minimum. They registered their plan in advance on the Open Science Framework and tested eight open-weight models, from four sizes of Qwen3.5 to Gemma 4 31B, Olmo 3.1 32B, Ministral 3 14B and gpt-oss-20b, on 558 real documents from nine annotated collections: emails, receipts, clinical notes, meeting records, job ads, reviews and others, each holding between zero and six true items. They asked for at least one, three or five, under eight conditions: no count; a minimum written in the schema but not enforced; the same minimum enforced by the software, so the model cannot finish a shorter list; a minimum with an explicit way to say “not applicable”; a minimum plus a line saying fewer is fine; a maximum; and two counts written in plain words. A correct answer was fixed in advance: when the document has fewer items than requested, list the real ones and stop, or say the list is short. Anything else added counts as padding, whether invented or copied. The authors state that an AI coding assistant wrote and ran their code and made a first pass over the answer keys, which one author then checked by hand, and that no AI model judges any headline number.

The count behaves like a target. On the documents with fewer items than requested, at minimums of three and five, pooled over the eight models (7,272 answers per condition), 34.5 per cent of lists were too long with no count at all. That is ordinary extraction error, and the baseline matters. With the minimum shown in the schema the share rose to 55.4 per cent, and with the minimum enforced to 90.1 per cent. Lists of exactly the requested length went from 5.6 per cent to 35.5 and then 71.8. A cleaner test isolates the effect: on the documents a model got exactly right when no count was given, a shown minimum made it pad 35.2 per cent of the time, against 5.0 per cent under a shown maximum of the same size. Six of the eight models lengthened their lists; the two smallest Qwen models were the exceptions, and the smallest produced unreadable output more than a third of the time. Nine runs of six models on hosted services, used as a reference, lengthened theirs too. On 105 documents that held no items at all, an enforced minimum of one produced at least one entry 82.4 per cent of the time.

What fills the empty slots is the interesting part. Most padding is not hallucination in the usual sense, a name or a figure that does not exist. It is real text of the wrong kind: a remark, a sign-off, a line from the same receipt. By the authors’ check, 67.7 per cent of these wrong-kind entries appear word for word in the document, against 0.6 per cent of the invented ones; overall, 46.6 per cent of the extra entries under a shown minimum would pass a test that each entry occurs in the source. That test is one of the most common safeguards in extraction pipelines. Here it waves the padding through, because the padding is grounded. It is in the document. It is simply not an answer.

The usual fixes help only partly, as the authors report. Telling the model that fewer is fine brought over-long lists down to 31.0 per cent, below the no-count baseline, but in the authors’ words it misses more true items. Giving it an explicit way to answer “not applicable” still left 51.0 per cent of the lists too long. In an exploratory arm, sending a short reply back with the validation error, as many pipelines do automatically, took Qwen3.5-9B from 10.0 to 69.0 per cent over-long and Kimi K3, a hosted model, from 14.0 to 78.3. Letting the model reason first made things worse, not better: with thinking switched on, Qwen3.5-9B’s over-long lists under a shown minimum rose from 43–47 per cent to 81–83, and by the authors’ count its reasoning named the shortfall in 88–89 per cent of the padded answers. The model noticed it was short, and filled the list anyway.

Anyone who has filled in a form that will not submit until every box is ticked knows the move. The form was designed before anyone saw your case, and it gets an answer, so the answer is no longer about your case. The minimum in a schema is written the same way, once for a whole pipeline and before any document arrives. The authors also measured how common it is: across 9,542 real schemas in the JSONSchemaBench collection, 7.7 per cent set a minimum of at least one on a list, and 0.3 per cent a minimum of two or more. The large minimums are rare. A required “at least one”, applied to a document that has none, is not.

The closest work, the authors say, is PhantomFill, a study by Usman earlier this year in which models filled required fields from inputs that held no true items at all. What is new here is that the requested count is varied against the true count on real documents, and that the padding is measured as text taken from the source. The limits are theirs too: open-weight models only, so closed commercial APIs may pad less (in PhantomFill, GPT-5.5 padded 3 of 20 cases); lists of single strings; one grammar engine; the labels “invented” versus “wrong kind” come from an automatic matcher whose “invented” calls are its least reliable; and the job-ad skills set has the least certain answer key. It is a preprint, not yet peer reviewed.

What I checked, and what I did not. I read the paper in full and cloned the authors’ public repository as of 22 October. From its scored outputs for the eight models I recomputed the headline table myself: 34.5, 55.4 and 90.1 per cent over-long, 5.6, 35.5 and 71.8 per cent exactly the requested length, 31.0 per cent with “fewer is fine”, and 35.2 against 5.0 per cent on the cleanly answered documents, all matching; my enforced figure on that subset is 83.8 against the reported 83.9, and with the “not applicable” option 50.9 against 51.0, differences of rounding or of a handful of unreadable outputs. I also recomputed the 82.4 per cent on empty documents. I confirmed the “Thanks, Alan” email is in the MailEx collection, built on Enron mail, and the authors say they chose it to illustrate the pattern, not at random. In the same run, asked for at least five, the same model on the same email listed only the one request and stopped: the pattern is a rate, not a rule. I did not recompute the source check, the hosted-model figures, the re-ask arm or the thinking test, which are as the authors report them, and I ran no models. I did not contact the authors.