Saisit
Turning 848-page Saudi Building Code PDFs and 2D CAD drawings into automated, trustworthy compliance verdicts.
SAISIT
Building Code Compliance
- Rule Extraction
- 98%
- DWG Fidelity
- 100%
- Compliance Agents
- 6
- Client
- Saisit
- Industry
- Construction Tech · Saudi Arabia
- Engagement
- Full-stack platform + multi-agent compliance pipelines
- Status
- In Progress · MVP Integration
- Duration
- January 2026 – Ongoing
- Scope
- Compliance Checker live · Advisor + Generator on roadmap
01 Overview
Who is the client?
Saisit is a compliance platform for the Saudi construction market, where every building permit must demonstrate conformity with the Saudi Building Code — a family of regulation documents (SBC 201, 301, 401, 501, 601/602, 701–704) covering fire safety, structural requirements, egress, and MEP. SBC 201 alone runs 848 pages. The product vision is three tools in one: a Compliance Checker, a Compliance Advisor, and a Submission Generator — the engagement so far has focused on the first, the technical foundation for the other two.
One market reality shaped the whole build: despite Saudi Arabia's BIM-first mandate, most architects still work in AutoCAD. So the platform can't be IFC-only — it has to accept 2D DWG files too, and reconstruct enough building understanding from them to run real code checks.
02 Problem Statement
What problem were they facing?
Checking a building design against the code is currently a manual, expert-driven process — slow, expensive, and inconsistent enough that two reviewers can reach different conclusions on the same drawing.
848 pages of regulation, zero structure
SBC documents are long PDFs full of tables, cross-references between documents ("per SBC 701 Section 3.2..."), and applicability conditions scattered across three levels — document, section, and rule. A project is checked against whichever SBC version was in force at permit time, so the corpus has to stay versioned.
Drawings don't carry the data checks need
A 3D IFC model carries explicit walls, doors, and spaces. A 2D DWG carries lines and text — the fire rating of a door isn't in the drawing at all, it's in a schedule, sometimes a separate PDF, linked only by a tag like "DR-1000."
Most of the market still draws in AutoCAD
Despite Saudi Arabia's BIM-first mandate, the platform can't be IFC-only. It has to extract real building understanding from the 2D CAD files architects actually produce.
A hallucinated PASS is worse than no tool
Any system using an LLM for compliance judgments faces an obvious trust problem — false confidence on a fire-safety rule is a liability, not a feature.
03 Solution
How did we solve it?
What exists today is a full pipeline from regulation PDF to interactive compliance report, built as a Go modular monolith orchestrating Python computation workers over gRPC, with every workflow driven through Redis queues rather than request handlers.
Regulations become data. An admin uploads an SBC PDF; Docling parses it into pages and a table of contents; a structure agent maps the document, then chunked extraction tasks fan out through a rate-limited queue consumer, and an extractor/verifier agent pair pulls out each rule with its text, applicability, cross-references, and source location. Rules land in Postgres for admin review and approval — the pipeline runs end to end at roughly 98% extraction accuracy against SBC 201.
Buildings become data. IFC files go through an IfcOpenShell worker that extracts full topology. For DWG, extraction is built on Aspose.CAD and pulls rooms, unit counts, door and window positions and tags, wall thicknesses, and storey heights — verified 100% against Autodesk's own output on real project files, including one with eight building types in a single drawing.
Checking is a team of agents, not one prompt. A compliance run flows through six specialized agents — classifier, rule loader, deterministic math checker, LLM checker, recommender, and aggregator — with draft → review → retry loops keeping hallucinated verdicts out of interpretive results. Findings come back as a PDF report with rendered screenshots, a BCF file that opens directly in Revit or Navisworks, and JSON that powers an in-browser 3D viewer built on ThatOpen/Three.js.
- GO Go Backend Orchestrator + Queues chi routerasynq queuesSSE events
- PY Python Workers gRPC Satellites IfcOpenShellAspose.CADBlender
- LLM Agent Pipelines Regulation + Compliance Geminidraft → review → retry
- Go
- chi
- Python
- gRPC
- PostgreSQL
- Redis + asynq
- MinIO
- IfcOpenShell
- Aspose.CAD
- Docling
- Gemini
- Next.js
- ThatOpen / Three.js
Live pages — the rebuilt UX, mock-data-driven
04 Project Timeline
Key milestones and duration
Phase 1 Jan 25 – Feb 1, 2026
Validation Spikes
Tested the riskiest assumptions first: rule extraction from SBC 201, IFC topology for real checks, and the extraction pipeline design. The LLM quality spike (Jan 29–30) turned the compliance checker from zero determinations into real PASS/FAIL verdicts.
Phase 2 Feb 1 – 12, 2026
Core Pipelines
Go backend with seven queue-driven workers, Python geometry and rendering services, the six-agent compliance flow, PDF/BCF report generation, and the regulation ingestion pipeline running end to end. Complete inventory by Feb 12: 31 API endpoints, two production pipelines, one 3D viewer.
Phase 3 Feb 12 – 26, 2026
DWG Capability
A two-week investigation into 2D CAD support — nine documented spike sessions against real Saudi project files, ending with the LibreDWG-to-Aspose.CAD decision and a designed architecture for DWG-based compliance.
Phase 4 March 1, 2026 – Ongoing
UX-First MVP Rebuild
The product surface redesigned from scratch: 11 flow groups covering 107 user flows, each through spike → mock implementation → code review → live browser verification. All 11 groups built and verified by March 10; remaining work covers design-system alignment and wiring the new frontend to the live backend.
05 Challenges & Resolutions
What obstacles did we face, and how did we overcome them?
The LLM that wouldn't commit
problemThe pipeline ran end to end, but the model returned SKIPPED for all 62 interpretation rules — technically working, practically useless.
resolutionDiagnosed five compounding causes — no temperature control, no worked examples, 62 rules crammed into one request, an easy escape hatch, and thin element data. Fixing all five turned the checker into something that actually renders verdicts.
Trusting an LLM with compliance verdicts
problemA report full of confident-sounding but wrong verdicts is worse than no automation at all, especially on fire-safety and life-safety rules.
resolutionRules reducible to a table lookup go through a deterministic math checker where the LLM never gets a vote. Interpretive rules pass through draft, review, and retry stages. Where data is insufficient, the platform locks the check — no force-run option.
DWG support nearly didn't survive its first library
problemThe initial extraction approach came up short on real files, including a drawing with eight building types in one file.
resolutionRather than patch around it, the team ran a structured two-week spike series against actual Saudi project drawings before switching to Aspose.CAD and verifying its output entity-by-entity against Autodesk's.
An 848-page PDF doesn't fit through an LLM in one piece
problemA single regulation document is too large and too dense to extract reliably in one pass, and cross-references between SBC documents need to resolve correctly.
resolutionThe ingestion pipeline chunks documents, fans chunks out through a rate-limited queue consumer, and runs an extractor/verifier agent pair per chunk so one model's output is checked by another before a rule is stored.
State discipline in an asynchronous system
problemA system this asynchronous — Go orchestration, stateless Python workers, real-time UI updates — needed a clear rule for who owns what, or state would end up everywhere.
resolutionGo owns all state and orchestration; Python workers are stateless computation reached over gRPC; the API never triggers workflows directly. Real-time updates ship as one SSE stream per project with typed events, not a tangle of per-operation connections.
06 Before & After
Comparison of the situation before and after the project
| Before | After |
|---|---|
| Regulations: 848-page PDFs, human lookup | Structured, versioned, queryable rules with applicability and cross-references (~98% extraction accuracy) |
| Rule review: no dedicated workflow | Admin pipeline: upload, extraction progress, rule table, edit and approve |
| IFC checking: manual expert review | Automated topology extraction + six-agent compliance run |
| DWG support: not machine-readable in practice | Verified extraction of rooms, areas, units, doors, windows, walls, storeys — 100% parity with Autodesk on test files |
| Missing drawing data: chased manually across schedule PDFs | Schedule import with tag matching, review drawer, and questionnaire fallback |
| Trust in LLM verdicts: none established | Deterministic checks where possible, draft-review-retry where not, hard locks where data is insufficient |
| Deliverables: written review notes | PDF report with renders, BCF for Revit/Navisworks, interactive 3D viewer with highlighted findings |
| Product surface: engine-first prototype UI | 107 redesigned flows across 11 groups: tenancy, projects, gaps, versioning, runs, library, export, admin |
07 Client Benefits & Outcomes
What value did the client gain?
- Extraction Accuracy
- 98%
- vs SBC 201, measured not estimated
- DWG Fidelity
- 100%
- parity vs Autodesk on real files
- API Endpoints
- 31
- as of Feb 12, 2026
- UX Flows Rebuilt
- 107
- 11 flow groups, all verified
A validated technical core for a genuinely hard product
The two riskiest claims — that code PDFs can become reliable structured rules, and that usable building data can be extracted from the 2D CAD files the market actually produces — have both been proven against real documents and real project drawings, with measured accuracy rather than optimism.
The agent architecture is the durable asset
Regulation ingestion and compliance checking are built as composable agent pipelines with verification stages — the Compliance Advisor and Submission Generator on the roadmap reuse the same rules, the same extracted geometry, and the same agents pointed at different questions.
Outputs meet the industry where it is
BCF files open in the tools architects already use, PDF reports serve the permit process, and the 3D viewer gives non-BIM stakeholders a way to see findings in context — adoption doesn't require anyone to change their toolchain.
Protected against knowledge loss
Every session is logged, every architectural decision recorded with its reasoning, every spike's findings written up — for an R&D-heavy build, that documentation discipline is worth as much as the code.
08 Key Learnings & Takeaways
What did we learn from this project?
Spike the scary parts first
The two assumptions the whole product rests on — extractable rules, extractable drawings — were tested in week one and week four respectively, before heavy investment. The DWG spike changed the chosen library; better in week four than in month six.
When an LLM underperforms, audit the boring things
The all-SKIPPED failure wasn't a model limitation — it was temperature, prompt structure, batch size, an easy escape hatch, and thin input data, stacked. Each fix was small; the diagnosis was the work.
Don't let the LLM do what a table can
Splitting deterministic rules from interpretive ones shrank the surface where hallucination is even possible, and made the remaining LLM judgments cheaper to safeguard.
Honest refusal beats confident noise
Locking regulations that lack sufficient data — with no override — is a product decision, not a technical one, and it's the difference between a compliance tool and a liability.
Mocks-as-spec is a real methodology
Rebuilding UX against mock data with the explicit contract that every mock becomes an API spec kept design moving during a backend blocker and produced backend requirements grounded in actual screens instead of guesses.
Write everything down
Session logs, decision records, and spike findings meant that a project spanning dozens of working sessions never depended on anyone's memory of why a choice was made.
How it actually runs · queue to queue
The Pipeline
Two flows power the platform: regulations becoming structured rules, and buildings getting checked against them.
- 01 PDF Upload Admin uploads an SBC regulation document
- 02 Docling Parse Pages and table of contents extracted
- 03 Structure Agent Maps document → sections → rules
- 04 Chunked Extraction Rate-limited queue, fanned out per chunk
- 05 Extractor / Verifier Agent pair pulls each rule, cross-checked
- 06 Admin Review Approve or edit — 98% accuracy vs SBC 201
- 01 Classifier Determines which rules apply to this building
- 02 Rule Loader Loads applicable rules and conditions
- 03 Math Checker Deterministic table lookups — no LLM vote
- 04 LLM Checker Draft → review → retry for interpretive rules
- 05 Recommender Turns failures into prioritized actions
- 06 Aggregator Compiles the PDF, BCF, and 3D viewer output
Built screens · mock-data-driven, live against the redesigned UX
The Product
From project login to platform admin — every screen shown here is a real render of the running app. Click any to expand.
