A live project runs to hundreds of drawings. Every one carries the same facts in the box in its corner: the number, the revision, the title, the scale, the date and who issued it. Those facts have to end up in a register, because that register is how anyone knows whether the sheet on site is the current one.
Schedules are worse. A door schedule, a window schedule, a finishes schedule: each is a table sitting inside a PDF, often across several pages, holding the detail that pricing and procurement both depend on. Nobody can use a table until it is data, so somebody retypes it.
This is not difficult work. It is slow, repetitive, and done by people who are expensive to have doing it, and it happens again on every revision. It is also the point where errors enter a project quietly, because a mistyped revision or a transposed door reference does not announce itself until something is built wrong.
We build the AI inside APSIS Business Components, a construction software platform. Two of the capabilities we built into it read the drawing set itself.
Drawing extraction takes a batch of drawings, reads those details off each sheet, and produces a register with every field populated and every sheet traceable back to the file it came from. It handles every drawing you give it in one go, because drawings never arrive one at a time.
Schedule extraction pulls the tables out. You tell it which pages to look at. A schedule sitting on pages 40 to 47 of a long document is pulled out without touching the rest, and what comes back is data rather than a picture of a table.
Anyone can demo AI reading a drawing. The question a construction business should ask is what happens when it gets one wrong, because on a project that data feeds procurement and pricing, and a wrong revision is a real cost.
So the design decision underneath all of this is that the AI's answer is never the final word. Every field it fills in can be corrected. When someone does, the system records four things: what the model said, what the value was before, what it was changed to, and who changed it.
That gives you three things nothing else does. A reviewer can see at a glance which fields a human has touched and which are still as the model left them. A dispute about where a number came from has an answer. And over time you can see exactly where the model is weak, because the corrections cluster, which is how the thing gets better rather than staying at whatever accuracy it launched with.
It is the same pattern across every document capability in the platform: extraction, comparison and analysis all keep the model value beside the human value rather than overwriting it.
The obvious saving is the hours. Two hundred drawings is a day of somebody's week, and it happens again every time the drawings are updated, so a project loses weeks of skilled time to typing.
The saving that matters more is the errors that never happen. A register is only useful if it is right. A hand-typed one is wrong in small ways almost immediately. A revision nobody updated. A sheet issued and never logged. A door reference transposed between the schedule and the order. None of those look serious on the day. They become serious when something is ordered against the wrong revision, or when a claim depends on proving which sheet was current in March.
There is a third effect that only shows up later. Once the register is data rather than a spreadsheet somebody maintains, the questions change. What has been superseded and not reissued. Which schedules moved between revisions. Which sheets have never been picked up on site. Those questions are unaskable when the answer lives in a document, and routine when it does not.
Data pulled off a drawing has value because of what happens next. Once a schedule is structured, it can be priced. Once a register is populated, a revision can be checked against what is on site. Once a document is readable, it can be questioned.
So these sit inside a platform rather than standing alone as separate tools. The same document handling, projects, permissions and audit trail run underneath everything else. That includes estimating and quoting and procurement document processing, built with APSIS over more than a year.
Three design choices separate this from a demo. It takes the whole set at once, because that is how drawings arrive. It takes a page range, so a schedule inside a two-hundred-page document does not require processing the lot. And extraction runs as a task with a status you can watch, retry and assign, rather than a button that either works or silently does not.
None of that is glamorous. All of it is the difference between something a project team uses on Monday morning and something that gets abandoned after the pilot.
Tell us where your team loses the most time. We will tell you honestly whether AI pays there, what it takes to build, and what we have already delivered for businesses like yours.
We use cookies to measure how the site is used and, if you allow it, for advertising. Nothing is set until you choose. Privacy policy.