Machine-Readable Evidence: Tables, PDFs, and Images

Start with a composite example: a DTC portable power brand sells into the US and Germany. Its third-party test report — twelve pages, one lab — is a scan on the download page, and the spec table is a PNG on the product page. Asked whether the unit runs a 400 W camping fridge overnight, an assistant answers that the page “does not list runtime data,” then names two brands that do. Every number it needed is printed there, in a shape the model could not lift.

Evidence counts only when a model can bind one value to one product, one field, and one test condition in one pass — and format decides whether that binding happens.

Format decides usability, not credibility

Reusing a number requires three bindings: passage to product, value to field, field to conditions. Pass all three and the number enters an answer; fail one and the model writes “not provided.”

The breaks are structural. A sentence carries its own boundary; a table cell borrows its field name from headers. Text in a PDF must be recovered by a parser, digits in an image guessed by OCR: the first two are structure, the last two reconstruction.

Format	What the model receives	Where it breaks	Use it for
HTML body copy	Sentences that survive extraction	Accordions, JavaScript rendering	Conclusions, test method
HTML table	Rows as objects, columns as fields	Header row exported as an image	Specs, comparisons, fees
CSV or feed	Whole fields, read in bulk	Internal jargon as field names	Many SKUs, markets
Text-layer PDF	Extractable text, fragile order	Two columns, repeating headers	Originals, compliance
Scanned PDF or image	OCR only, error unpredictable	Digits, units, superscripts	Record-keeping only

Tables fail on fields, not on data

A table puts a field name and its value in one block — the cheapest input for comparison. Three checks decide whether yours is usable.

Put the unit inside the cell, not a caption: “20 hours” and “20” are different claims, and only one is comparable. One object per row, one field per column, no merged cells: merge input and output, and a model will plausibly file 1,800 W under the wrong side of the device. Missing values read “not applicable” or “not tested” — a blank cell is permission to infer from the row above. Test conditions obey the same rule; see turning specs into evidence.

Two ways a PDF is unreadable

One kind has no text layer. A scan is an image, so everything rests on OCR, which confuses 0 with O, Wh with kWh, a decimal point with a speck. A report read one digit wrong is worse than none: it produces a confident, wrong answer.

The other kind has a text layer and scrambled order. Two-column layouts, headers on every page, tables split across spreads, watermarks over text: extraction returns stitched fragments — fine in a viewer, useless in a parser.

Demote the PDF to an attachment. Lead with a conclusion paragraph — who tested, against which standard, which sample, which conditions, what result and validity — then a table of the values buyers screen on, then the link, model and date in the filename.

Images have a lower ceiling. Alt answers “what is this image,” not “what values are in it.” A certificate photo gets issuer, number, covered models; a spec sticker gets one line and a pointer to the table.

Example: one report, three publications

Example — invented brand and figures. At 77°F, a fully charged unit held a 400 W resistive load for 62 minutes.

As a scan only, the overnight question returns “no runtime data provided.” As a screenshot of that page, OCR may recover “62,” but “400 W” and “77°F” drop out, and the model writes “about 62 minutes of runtime,” stripped of its conditions.

As paragraph, table, and original:

A third-party lab tested a production sample at 77°F under a 400 W resistive load: 62 minutes of output before shutdown. The March 2026 run is valid through March 2027; the 12-page report includes the discharge curve and pass criteria.

Then a table — load, temperature, charge, runtime, batch, report number, units in every cell — and the original link. Three precisions, one answer.

Four steps from inventory to citable page

Step	Do this	Owner	Passes when
1 Inventory	Point each 90-day buyer question at an existing file	Content, support	Misses are the gaps
2 Order	Rank by “would a buyer screen us out?” and convert the top ten	Category, growth	Shortlist deciders go first
3 Convert	Conclusion paragraph, fields in a table, original as a link	Content, engineering	Values readable without JavaScript
4 Verify	Ask a model to fill a field table from the page alone	Growth	Four of six correct; misses are structure bugs

Step 4 is the only falsifiable one; a wrong fill means the field name exists only in your head. Sample more than once; one screenshot is an anecdote, which is why AI visibility baselines repeat a question.

Where this breaks

First, the original cannot be rewritten. Certificates and lab reports are issued by a third party: index them, never alter a conclusion or turn “sample tested” into “full range certified.”

Second, other people’s rules win: some markets prescribe how claims and warnings appear, and Amazon or Shopee run their own field rules, where the work is feed completeness, not HTML.

Third, some categories do not decide on parameters: fit of apparel, scent, hand of fabric. Buyers read images and reviews; conversion returns nothing.

Fourth, bulk conversion is the usual misuse: hundreds of pages through OCR into one wall of text deletes the boundaries that made anything quotable. A sentence that stands alone beats a change of address for a file — the same problem as HTML semantics and paragraph boundaries.

Evidence is one of four conditions behind a recommendation; the other three are in four trust prerequisites, and this line’s neighbors sit on the technical foundation hub.

This month, do one thing: take the file buyers ask about most and put your three most-asked fields into a three-row HTML table on that product page — units in every cell, original link below. Ask the same question again a week later.