Diagrama visual del pipeline DOMA: expediente, fase 1, fase 2 e informe

Pipeline producto: expediente → admisibilidad → análisis normativo → informe y centro de control.

Público

DOMA

Producto de revisión urbanística para oficinas de arquitectura en Chile: carga de expedientes, análisis LLM en dos fases, narrativa de progreso e informes PDF profesionales.

Stack

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

Artefactos

Landing y app públicas; repositorio pendiente de confirmar

Restricciones

  • Caso público basado en información visible y en el brief interno del roadmap.
  • No se publican métricas de uso, clientes ni repositorio hasta confirmar visibilidad.

En breve

  • Producto comercial en producción para revisar expedientes urbanísticos y generar informes accionables.
  • Pipeline en dos fases: admisibilidad primero, análisis normativo después.
  • Conecta carga documental, retrieval normativo, narrativa de progreso, PDF final y centro de control DOM.

Patrones reutilizables

  • Separar revisión documental en fases explícitas para hacer auditable el progreso y reducir ambigüedad.
  • Combinar RAG normativo con generación de informes para cerrar el ciclo desde expediente hasta artefacto entregable.
  • Diseñar la experiencia como producto operativo, no como demo aislada: estado, reintentos, reportes y control.
  • Usar una plataforma matriz (Vector Público) para convertir una capacidad transversal en verticales específicas.

Contexto

La revisión de expedientes urbanísticos combina documentos heterogéneos, normativa y criterios que deben quedar explicados en un informe profesional.

DOMA convierte ese flujo en un producto: carga de expediente, checklist inteligente, análisis automatizado en dos fases y entrega de reportes PDF.

Vector Público funciona como plataforma matriz; DOMA es la primera vertical pública sobre esa capacidad de análisis documental y normativo.

Decisiones

  • Dividir el análisis en dos fases: Fase 1 de admisibilidad y Fase 2 de análisis normativo.
  • Separar servicios backend en Docker Compose (fase1, fase2, chat_indexador, health) para aislar responsabilidades operativas.
  • Mantener una capa de retrieval/RAG sobre normativa para fundamentar el análisis en fuentes consultables.
  • Generar narrativa de progreso en tiempo real para que el usuario entienda qué está ocurriendo, no solo espere un resultado final.
  • Cerrar el workflow con informes PDF profesionales y un centro de control DOM para seguimiento.

Arquitectura

Arquitectura de DOMA: carga, indexador, fase 1, fase 2, estado e informes
Carga documental → indexación/retrieval → fase de admisibilidad → análisis normativo → estado en Supabase + informes PDF.
  • FastAPI coordina servicios especializados para análisis e indexación.
  • Supabase mantiene estado de expedientes, resultados y control operativo.
  • La landing pública vive en Cloudflare Pages; la app se sirve como superficie separada para usuarios.

Resultados

  • Caso ancla del sitio: muestra construcción y operación de un producto de datos, no solo análisis o dashboards.
  • El diseño en fases hace más explicable el análisis documental y permite separar admisibilidad de revisión normativa.
  • La arquitectura convierte una capacidad general de IA documental en una vertical concreta para oficinas de arquitectura.

Enlaces