Start here: is the Bluebeam file still a head start?
Yes. Even though the API did not see objects on the plan, the first-crack PDF is still useful. Today the specialist starts from a blank Markups List. This file fills it.
One line per draft item. Real type codes stay the Subject (H2, TP3, IL.5). NEED / CHECK where info is missing. Off-sheet lines stay off the floor. They filter, delete, add, verify, then they sign. They do not re-type 69 lines.
That is the plus. It is a head start. It is not a take-off. Say both.
Ahlsell already left this door open: sometimes the answer is in the text on the sheet, not in the geometry. The jury also asked for dead ends. “We wanted object recognition; this API cannot do it; we stopped pretending; we put the text draft where they already work” is a result.
What we hoped vs what we got
We hoped the API would read the drawing the way a specialist does: see the hook, the WC, the shelf, and count them. After testing (Wilmer’s job on PLAN 09), that is not what happened.
The API is not smart enough to pick objects off the plan. It pulled from PDF notes and other text already in the file — type marks, the hatch table, room notes. File + page only. Not a pin on the fitting.
So it is useless as “AI looked at the drawing and counted.” Do not say that.
It is not useless as a first pass of what the sheet already writes down. Specialists already read H2, TP3, IL.5 off the same notes. The App job is: put that dump in Revu, let them add / remove / sign, do not make them start from zero.
What the API can reasonably do
- Read codes and notes on a vector PDF (
H2,TP3, hatch tableIL.*). - Return a JSON list with file + page (not an x/y on the room).
- Give you something to stamp into Revu so checking starts from a list, not a blank page.
What it cannot do
- Recognize drawn objects or symbols.
- Place a box on the fitting (only on the text hit, if we searched for the code).
- Know doors are another trade, or that a WC has no type code.
- Map a line to an Ahlsell article number.
- Produce a quote. A person still signs.
Keep still the demo
| Piece | Why it stays |
|---|---|
| First-crack PDF → open in Revu | Official route. No Bluebeam plugin needed. |
| Markups List as the take-off | They check / change / remove / verify there. |
| Real type codes as Subject | Do not rename H2 / H3 / IL.5. |
| NEED / CHECK | Fill missing info. Do not re-type coded lines. |
| Off-sheet panel (H3 / other floors) | Honest: not on PLAN 09. Do not invent a pin. |
| Compare after they save | Their edits come back. List and drawing stay in sync. |
| Customer request vs specialist draft (15 vs 69) | Two jobs, one pack. Customer did not invent a shopping list. |
| “You still sign” | Constraint from Ahlsell. Non-negotiable. |
Tweak same screens, honest wording
| Piece | Change |
|---|---|
| Specialist lead / PDF page 1 | Say: draft from sheet text, not object detection. First crack, not a quote. |
| Boxes on the drawing | Fine if they sit on text. Do not call them “detected fittings.” |
| Door / window / frame lines | Keep on the specialist list as other trade / CHECK. Do not sell them on the customer path. |
| Sanitary (WC, basin, support arm, slop sink) | Keep as NEED: listed from notes, no type code, API did not “see” them. |
| Catalogue | Lookup only. Do not imply the API chose those SKUs. |
Add jury-facing
- A short can / cannot strip: reads PDF text · does not recognize objects · specialist signs.
- The “check these first” list: other trade, no type code, not on this sheet, notes can overcount (
H1/H3also appear in sheet notes). - A badge per line if there is time: from text / no code / other trade / not on this sheet.
These three are already on the live demo. Keep them visible. Do not hide the limits.
Take away or hide so we do not oversell
| Remove or stop saying | Why |
|---|---|
| Any claim that the machine detected fittings from the plan | The API did not do that. |
| Any claim that 69 lines are complete or ready to send | They are a text dump plus gaps. |
| Fake pins on sanitary / doors as if they were found as objects | We do not have detection. |
| Invented article numbers | Pack forbids it. Quote numbers + the given article list only. |
| Building a symbol detector on hack day | App team was told not to. That is Capability’s job. |
| Re-running the same PLAN 09 files for a “better” API result | Same files return the cached job. You will not get a smarter list. |
What to say in one breath
We used the BoM API as a text first draft. It does not recognize objects. We put that draft in Bluebeam so the specialist starts from a Markups List, not a blank page. They check, change, remove, verify, and they sign. That is the useful slice. Object take-off is the dead end we are naming.
Capability team — do we get a better API?
They are improving take-off. They are not updating the hosted API we already called (takeoff.2hero.dev).
- App teams build on that API as a strong first draft. We do not build the engine.
- Capability teams use it as a reference to beat. They are judged on their own reading of the drawings.
- Polling the same job again, or sending PLAN 09 a second time, will not get a smarter list (same files come back free and unchanged).
- If Capability produce a better list, we can import that into the same Revu loop. That is a hand-off from them, not a new version of the shared API.