Write us on Telegram@Odilient

AI & AUTOMATION

Opus Magnum

An AI-driven building onboarding platform from UMHackathon 2026: a GLM model verifies compliance documents in city-specific workflows, then publishes each building as a 3D listing.

UM Hackathon 2026
Client
Real Estate
Industry
3 days
Duration
2026
Year
Where it started

The Challenge

Opening a new building means proving it to the city: ownership deeds, fire-safety approvals, zoning clearances and floor plans, each in its own format and each city wanting something slightly different. Owners file paperwork they do not fully understand and resubmit after slow feedback, while the public has no easy way to see what is newly approved. The hackathon also required a GLM reasoning model at the center of the system.

What we did

The Solution

We built a config-driven workflow engine. City admins author onboarding templates from six primitives, stored as JSON in Postgres and compiled into a checkpointed LangGraph state graph for every run. GLM reads each uploaded document, verifies it against plain-English criteria, cross-checks facts across documents and logs every decision. Once approved, the building is published as a 3D page with an assistant grounded in the owner's content documents.

Built with
PythonFastAPILangGraphPostgreSQLGLM-5.1 (ILMU)Next.jsReact Three FiberReact FlowTailwind CSSTesseract OCR
Inside the build

How It Came Together

An agentic workflow platform for building onboarding

Opus Magnum is an AI-driven building onboarding platform built for UMHackathon 2026, in the AI Systems & Agentic Workflow Automation domain. It turns a city's building paperwork into one guided workflow: an AI model reads the documents an owner submits, checks them against that city's rules, raises contradictions and, once everything passes, publishes the building as a public 3D listing. Buildings are the demo domain, but the engine applies to any regulated onboarding, from suppliers to licenses.

We built it in three days as part of a five-person team. The code is Apache-2.0-licensed and public on GitHub, with a pitch video on YouTube.

Three roles, one engine

  • City admin — authors onboarding templates in a UI; the model drafts a starter template from a one-line description and explains any field on request.
  • Building owner — runs the city's workflow, fills forms and uploads compliance documents for verification, which are never shown publicly, and content documents for the listing, then resolves any contradictions and publishes.
  • Visitor — browses published buildings in a 3D scene and asks an assistant questions answered only from the owner's content documents.

Key features

  • Templates as data — a workflow is an ordered list of six primitives: collect form, upload compliance, upload content, cross-check, human review and publish. A stricter city simply adds steps, such as separate fire, zoning and ownership uploads.
  • Resumable runs — templates compile into a LangGraph StateGraph with a checkpointer, so an owner who leaves mid-flow picks up at the same step.
  • Verification with reasons — the model extracts fields from each document and judges them against the city's criteria, with a verdict and evidence per criterion; a failed step loops back for re-upload.
  • Cross-document checks — a contradiction, such as a floor count that differs between the form and the floor plan, pauses the run with an explanation.
  • Decision log — every model call writes to a per-step log for auditability.
  • Live workflow canvas — owners watch their run as a React Flow graph while each file moves through parsing, extraction and verification over Server-Sent Events.

Architecture and tech stack

The backend is FastAPI and Pydantic with SQLAlchemy over Postgres in production and SQLite in development. The model is ilmu-glm-5.1, called through the OpenAI SDK against the OpenAI-compatible ILMU API, using JSON mode and function-calling tools for template drafting, document extraction, criteria checks, cross-checks, review summaries and visitor answers.

Processing is kept separate from reasoning: PDFs with a text layer go through pypdf, and scans fall back to Tesseract OCR. Our first capability probe showed the model answered image prompts with text only, so OCR became the baseline instead of vision.

The frontend is Next.js 16.2 with React 19.2, TypeScript, Tailwind CSS 4 and shadcn/ui, with React Flow for the workflow canvas and react-three-fiber and drei for the 3D building pages. Pytest covers template compilation, the workflow graph, HTTP flows, document processing and a live model smoke test. The stack deploys as one Render Blueprint with Postgres, backend and frontend, reseeding a demo city on startup.

The demo scenario

An admin creates the city of Shah Alam and has the model draft its template from one sentence. An owner then onboards a demo tower: a fire-safety certificate with the wrong address is rejected in plain language, a corrected one passes, a floor-count mismatch is caught at the cross-check, and the published building opens in 3D for visitors' questions.

Our role

We led the backend and AI integration, covering the model client and tool schemas, the database and seed data, the LangGraph engine and its primitives, the document and OCR pipeline and the deployment. We co-built the admin, owner and visitor interfaces and wrote the content of the submitted requirements, system analysis, architecture and QA documents.

For another system where AI works inside strict verification steps, see Keystone. Opus Magnum is part of our AI integration and automation and web app development work.

Let's Build

Want something like Opus Magnum?

Tell us what your product needs to do. We'll shape the scope, map a timeline and send a fixed price — free, and with no obligation to proceed.

Free consultation No commitment Fast reply