The extracted equipment schedule is one column out of alignment

A schedule that comes back with values in the wrong columns is almost never an OCR problem. The characters were read correctly; they were assigned to the wrong field, because a drawn schedule is a picture of a table rather than a table. Its structure lives in line weights, merged cells, a header that spans two rows and a footnote symbol that looks like data. The confirming check is to take 3 rows you can verify by eye and compare them to the sheet by tag number, never by position — a shift is invisible if you only look at the first and last rows.

The reason to catch it before anything else happens is that a schedule is an input to ordering. A shifted column produces values that are of the right type and roughly the right magnitude, so nothing rejects them. They flow into a takeoff, a submittal comparison, or a purchase, and the error surfaces when a unit arrives that does not fit the opening.

Check three rows by tag, not by position

1. Pick 3 rows deliberately: the first row under the header, one row immediately after a merged cell or a section break, and the last row on the sheet. Those 3 positions catch the 3 different ways a parser loses its place.
2. Look each one up in the extracted output by its tag, not by its index. If the tag itself is wrong, stop — the shift has moved the identifier column and everything after it is unreliable.
3. Compare every field against the sheet, including the ones that look boring. Weight, mounting and remarks columns are where a shift hides, because nobody checks them.
4. Count the columns on the drawn table and the fields in one extracted row. A mismatch of exactly 1 usually means a footnote marker or a units row was consumed as a column.
5. Check whether the schedule continues on another sheet. If it does, run the same 3 checks on the continuation, because a repeated or missing header is the most common cause of a mid-set shift.
6. Count the rows. A drawn schedule with 24 tag rows that produced 22 records has lost 2 somewhere, and losing rows and shifting columns often have the same underlying cause.

Ten minutes of that tells you whether you have a systematic shift affecting every row, a local shift starting at a particular row, or a per-sheet problem in a multi-sheet schedule. Those three have different fixes and the same appearance in a spreadsheet.

Why a drawn table defeats a table parser

• Multi-row headers. A group heading spanning several columns above a row of sub-headings means the first data row can be read as a header, or a header row as data. Everything after it moves by one.
• Merged cells. A value that applies to 4 rows is drawn once in a tall cell. Read literally it belongs to one row and the other 3 are blank; read positionally it can shift the whole block left.
• Footnote markers. An asterisk or a superscript digit next to a value is a reference, and a parser that treats it as a separate token gains a phantom column in exactly the rows that carry a note.
• Continuation rows. A row whose text wraps onto a second line is one record drawn as two, and it is read as two records with most fields empty.
• Rotated and stacked text. Narrow columns get vertical headers, and text at 90 degrees is often dropped entirely, so the column exists on the sheet and not in the output.
• Leader lines and revision clouds crossing the table. Any linework over the grid confuses cell boundary detection, and a cloud drawn around a changed row is the most likely thing to be over it.

None of this is exotic. It is what a schedule looks like when it is drawn to be read by a person on a printed sheet, which is what it was designed for. The consequence is that extraction quality is a property of the consultant's drafting conventions rather than of the tool, and a pipeline tuned on one practice's sheets will behave differently on another's.

The blank cell that means as above

In a drawn schedule, an empty cell in a run of similar units almost always means the value above still applies. Sometimes it is a dash, sometimes a ditto mark, sometimes genuinely nothing. An extractor returns null for all three, and a downstream system reads null as unknown, which is a different claim from same as the row above.

Resolve it explicitly rather than by inference. Forward-fill only within a visibly grouped block — a merged cell, a section rule, a shared tag prefix — and record for every filled value that it was inferred rather than read. If a cell cannot be resolved, leave it unresolved and raise it. An ambiguous schedule cell is exactly the kind of thing that becomes a formal question, and it belongs in the register that an RFI log which still means something later is built to hold, rather than being silently guessed by a pipeline.

Units live in the header and values live in the cell

A drawn schedule states the unit once, at the top of the column, and never again. Extract a row on its own and the number arrives naked. Every consumer downstream then applies its own assumption, and the assumptions differ by region and by discipline.

The rules that run before anyone prices it

The deliverable from this diagnosis is not a better parser. It is a set of assertions that run on every extraction and fail loudly, because the failure you are defending against is silent and plausible.

The characters were read correctly. They were filed in the wrong drawer, and a value in the wrong field looks exactly like a value in the right one.

What the plan symbol count is for

The last rule in that table is the most useful and the least used. A schedule and the plan it belongs to are two independent statements about the same set of equipment, so counting the symbols on the plan gives you a second source at no extra cost. Thirty-two diffusers on the plan against 28 rows in the schedule is a real finding — either the extraction lost rows, or the drawing set genuinely disagrees with itself, and both are worth knowing before anyone orders.

Two neighbouring jobs are deliberately outside this page. Turning schedule quantities into a priced takeoff is estimating work with its own rules. And the tag in the identifier column has a life after the drawing: it becomes the label on the physical unit, which is where the choice between barcode and Bluetooth tags on a live site starts mattering. A schedule extracted with shifted tags poisons that chain at its first link.

Three practical habits keep this from recurring. Re-extract on every reissue and diff the schedules rather than the sheets, which is a natural output of comparing two issues of a sheet set properly. Cross-check product descriptions against the specification, since the spec is prose and extracts far more reliably — the method is in turning a spec book into a submittal list. And check the input before blaming the model, because a schedule on a poor scan fails for reasons covered in extraction that works on issued sheets and fails on scans.

The build is small and worth owning: an extraction step, a rules file per schedule type, a review queue for flagged rows, and a record of which sheet issue each row came from. That is the kind of narrow tooling we scope under internal tools and ops. This page sits inside drawings, specs and construction document intelligence, part of our construction and contracting work.

• document ai
• schedules
• extraction
• validation