Transform 2D Plans Into Structured Data for Construction and Insurance Projects

A floor plan carries every dimension you need to price a job, but it carries them as ink on a page. To do anything useful with a wall length or a door count, someone has to read it off the sheet, set a scale, and type it into a spreadsheet. That gap between what a drawing holds and what a system can use is where most of the time and most of the errors live.

The same gap shows up in insurance. An adjuster estimating reconstruction cost is working from the same architectural sheets a contractor used to build the place, and they are re-deriving room areas and assembly counts by hand. Two people measure the same plan and get two different answers.

Kamai's models read those drawings and return the measurements as structured data: quantities, dimensions, and the spatial detail behind them, in a format estimating software, claims systems, and analytics tools can actually consume.

Why a PDF is not data

A set of plans is built for a person standing at a desk, not for a database. Open a sheet and the information is all there - wall runs, fixture counts, slab areas - but it lives as geometry and linework with no labels a machine can query. You cannot filter it, total it, or push it downstream until someone interprets it first.

In a contractor's office that interpretation happens over and over. The estimator takes off quantities to put a bid together. Procurement re-checks them against the same sheets when it is time to buy material. The field team measures again during execution. Each pass depends on whoever is holding the scale that day, which is why two estimators rarely produce the same numbers from the same plan set.

Insurance runs the same loop. Validating a claim or pricing a rebuild means reviewing floor plans and drawings by hand, and the lack of a consistent underlying data set is exactly what leads to claims that drag and assessments that get disputed.

What structured data changes

When a drawing becomes structured data, the quantities stop being something you eyeball and become something you can sort, total, and route. A wall schedule is a list you can query instead of a region of a sheet you have to trace.

For a contractor, that means the takeoff feeds the next step directly. Quantities pulled once flow into estimating, procurement, and project management without being re-keyed, so the numbers in the bid are the numbers the buyer works from. When estimating and procurement read from the same data set, the discrepancies that usually surface late stop appearing.

For an insurer, structured quantities give an assessment a defensible basis. Room areas and assembly counts pulled the same way every time let a carrier standardize how it evaluates a loss across regions and adjusters, instead of leaning on whoever happened to review the file.

How Kamai reads the drawing

Kamai's models work directly on the plan set you already have. They identify architectural and structural elements, read dimensions, and pull quantities without anyone tracing lines or tallying symbols by hand. The output comes back as clean structured data, and the input is the same PDF you would have sent to a printer.

Nothing about your drawing format has to change. You do not redraw sheets or restructure files to fit the tool. The model meets the plans where they are and returns measured quantities and the spatial context behind them, consistently enough to run the same way across a small remodel or a multi-building set.

Estimating: the takeoff stops being the bottleneck

On the construction side, the estimate is usually gated by how long it takes to get quantities off the sheets. Kamai cuts the measurement step so estimators spend their hours on scope, pricing, and the judgment calls that actually win or lose a bid, rather than on counting.

Because the quantities come out as data, they carry forward. A takeoff done at bid time is the same data set procurement buys against and the team builds to, instead of three separate counts that have to be reconciled. For a contractor running multiple jobs or several estimators, that shared data set is what keeps the numbers consistent from one project to the next.

If you want to interrogate the takeoff rather than just read it, the AI assistant inside the app lets you ask about the quantities in plain language and pull what you need without hunting through the sheets.

Claims and reconstruction: one basis for the number

Insurance work turns on the assessment, and a manual review of plans is both slow and inconsistent. Pulling quantities straight from the drawings gives a claims team a measured starting point for a repair or rebuild estimate instead of a hand count that the next reviewer may not reproduce.

That has two payoffs. Claims move faster because the underlying measurements are already in hand. And underwriting and risk teams get a structured read of the property's layout and exposure they can analyze, rather than a PDF they have to interpret one file at a time. When the plan interpretation is consistent, the resulting decision is easier to stand behind.

Reading plans at scale

Agencies overseeing construction, infrastructure, or insured assets sit on large volumes of plans and almost no way to work through them quickly by hand. Turning those drawings into structured data lets a public-sector team review and report on plan sets at scale, which matters most where timelines, budgets, and compliance are all being tracked at once.

Accuracy and rework

The point of reading a drawing into data is that the data matches the drawing, so extracted quantities have to line up with what is actually on the sheet. That alignment is what keeps the result out of the rework pile - if the numbers hold, you are not re-measuring to double-check them, and the time saved on the takeoff is not handed back during verification.

Fitting your existing tools

The structured output is built to drop into the software you already run. Quantities from a plan set can move into estimating, claims, and analytics systems through exports to Excel and PDF, with JSON available when you want to wire the data straight into another tool. For developers, the API and MCP make the same data programmatically accessible.

That lets a team modernize one step at a time. You can pull structured takeoffs into your current stack without swapping tools or retraining everyone, and the drawings you were already storing start producing data you can use.

From drawings to decisions

Plans are not going anywhere. The architectural, structural, and MEP sheets that have always defined a project will keep doing it, and they should. What changes is how much you can get out of them between the moment they land and the moment you have to commit to a price or a payout.

Reading those sheets into structured data closes that gap. The estimator stops re-measuring, the adjuster stops guessing, and the number everyone works from traces back to the same drawing. That is the part worth automating.