Visual diagram of the DOMA pipeline: case file, phase 1, phase 2, and report

Product pipeline: case file → admissibility → regulatory analysis → report and control center.

Public

DOMA

Urban planning review product for architecture firms in Chile: case-file upload, two-phase LLM analysis, live progress narrative, and professional PDF reports.

Stack

FastAPI · Docker Compose · Supabase · Regulatory RAG · PDF reports · Vite · TypeScript · Tailwind · Cloudflare Pages

Artifacts

Public landing and app; repository visibility pending

Constraints

  • Public case based on visible information and the internal roadmap brief.
  • Usage metrics, client figures, and repository links are not published until visibility is confirmed.

TL;DR

  • Commercial product in production for reviewing urban planning files and generating actionable reports.
  • Two-phase pipeline: admissibility first, regulatory analysis second.
  • Connects document upload, regulatory retrieval, progress narrative, final PDF, and DOM control center.

Reusable patterns

  • Split document review into explicit phases to make progress auditable and reduce ambiguity.
  • Combine regulatory RAG with report generation to close the loop from case file to deliverable artifact.
  • Design the experience as an operating product, not a one-off demo: state, retries, reports, and control.
  • Use a parent platform (Vector Público) to turn a reusable capability into specific verticals.

Context

Urban planning review combines heterogeneous documents, regulation, and criteria that need to be explained in a professional report.

DOMA turns that flow into a product: case-file upload, intelligent checklist, automated two-phase analysis, and PDF report delivery.

Vector Público acts as the parent platform; DOMA is the first public vertical built on that document and regulatory analysis capability.

Decisions

  • Split the analysis into two phases: Phase 1 for admissibility and Phase 2 for regulatory analysis.
  • Separate backend services in Docker Compose (fase1, fase2, chat_indexador, health) to isolate operational responsibilities.
  • Keep a retrieval/RAG layer over regulation so the analysis can be grounded in consultable sources.
  • Generate a live progress narrative so users understand what is happening instead of only waiting for a final result.
  • Close the workflow with professional PDF reports and a DOM control center for follow-up.

Architecture

DOMA architecture: upload, indexer, phase 1, phase 2, state, and reports
Document upload → indexing/retrieval → admissibility phase → regulatory analysis → Supabase state + PDF reports.
  • FastAPI coordinates specialized services for analysis and indexing.
  • Supabase keeps case-file state, outputs, and operational control.
  • The public landing runs on Cloudflare Pages; the app is served as a separate user-facing surface.

Outcome

  • Anchor case for the site: it shows a data product being built and operated, not just an analysis or dashboard.
  • The phased design makes document analysis easier to explain and separates admissibility from regulatory review.
  • The architecture turns a general document AI capability into a concrete vertical for architecture firms.

Links