SetIQ

Context

Every site team asks the same question when the architect re-issues drawings: what actually changed, and what did we miss? Document controllers rebuild registers by hand, and changes the architect never clouded are found on site, late. I spent years in construction project management, so this one is personal.

What I built

SetIQ takes a PDF drawing issue, renders each sheet, reads the title blocks with a vision model and builds the drawing register itself, working out which sheets supersede which across partial re-issues. Where a sheet has been revised it compares the two renders and writes a plain-English changelog with a category, a severity and whether the change was clouded. Unclouded changes are flagged as unannounced. Questions about the set are answered with citations to a sheet and revision, and the server drops any citation that was not among the retrieved sheets.

• Data store
• Model or agent
• Check or gate
• Person

A grounding check requires the extracted sheet number to appear in the page text; anything unsure goes to a review queue rather than being guessed. Every table carries a tenant identifier enforced at the repository layer, and every AI-generated artefact carries a note to verify before relying on it.

Outcome

A working multi-tenant application with 68 API endpoints, 19 screens, 22 passing tests, Docker packaging, a pilot handover document and a public demo site. Processing a three-issue sample set cost nine cents in model calls. It has not yet been run on a real client’s drawings.

What I’d do differently

Measure diff accuracy on real, messy drawing sets before polishing the interface; the evaluation harness exists but its fixtures are placeholders. Render title blocks at a higher resolution, since small-text misreads are visible in the demo. And make it responsive from the start. It is desktop-first and the register is unusable on a phone.