The spec tables look clean. The local model is inventing numbers.

Note · KBMill · problem · tables

The PDF looks fine on screen. Rows, columns, units, default values — a parameters page a human can read in ten seconds. The on-prem model answers with a calm number that is wrong, or a bitmask that never appears in the manual. Nobody “hallucinated a scan.” The table looked clean. The package you searched was not. Call that the visual spreadsheet illusion.

How we see the problem

Dense tables are where wrong answers hurt most: loads, limits, radio settings, “section 2.2.3” style references. This is a known, reported failure across hosted and local stacks — not a hypothetical. A visual PDF can still be hallucination fuel under the hood.

Sometimes the table is honest text and the stall is still the same: the wrong neighbor won the search, or junk was never taken off the answer path. Confident. Wrong. Signed off by nobody.

What you already tried

Paste into chat / “table” extractors / RAG the markdown

You get a nicer looking dump. The model still invents a default, swaps min and max, or cites a row that belongs to a different parameter. Retrieval searched what you gave it. Extraction got words out. Neither left a package where a person can see which numbers were trustworthy and which were taken off the answer path.

How we mill it

Tables in PDFs are widely known as hard. We put real plant effort into them — not as a side hobby, as part of manufacture.

Recoverable grids

Text-layer PDF tables, structured HTML params, and the like — Camelot / pdfplumber (and peers) fuse structure into the brick so a model can retrieve cells without inventing the grid.

Image grids / OCR debris

When the “table” is really a scan picture, we do not fake a clean engineering grid. Mute what we cannot trust and list it (LIBRARY_CARD and muted chunk flags — the residual board). Docling may still recover readable markdown where it can — without inventing columns the source cannot support.

The leave-behind is still a knowledge brick: a portable ZIP you keep. You point your existing local model at that package. You do not buy a new stack. You do not start a chatbot. You pay only if we produce. We do not certify your numbers for flight or for the shop floor. Last word: your trusted people. Drop the bin — complexity stays in the plant.

An analogous brick (not your spec sheet)

We do not have your ICD. Open public stock and see the craft. The published gallery was remilled so the shelf matches this claim: tables recovered one path or another where the stock supports it — not a silent zero because a tool name looked installed.

Structured params

ArduPilot Plane Params — dense Values / Range / Default matrices a model is expected to “just know,” milled as searchable param stock (not a Camelot PDF-grid demo, and not a chat paste). See the retrieval demo and HF eval (ardupilot_plane_params) — method evidence, not a claim your airframe is covered.

Text-layer manuals

Ranger Handbook TC 3-21.76 and NASA 41st Aerospace Mechanisms — recoverable PDF grids fused into the brick (Camelot / markdown table blocks). Open the ZIP and look for them.

Scan that only looks like a table

TM 11-666 — image-only pages, no text layer for the grid tools. OCR / Docling recover many tables as readable markdown; untrusted residue stays listed. We do not invent a clean engineering grid the extract cannot support.

Same mill: Public brick shelf. Your sheet is a different job. The method is the same.

What this costs, when it is your pile

Table recovery is front-loaded manufacture — you pay compute and craft before anyone asks a question, not per chat token. A short clean params extract is often Small or Medium. Scan-heavy manuals and multi-file “ops + params” piles trend Medium or Hard — difficulty, not prestige. Why $10.

Drop the pile on the mill. You keep the ZIP. We purge after the download window (72 hours). No honest brick, no charge. We are not a vector database and not a data-science rewrite of your ICD.