Architecture / Engineering case
Arquitectura para asistir la lectura periódica de remarcadores de agua y calefacción.
DepaVision es un producto en desarrollo. Busca asistir el proceso periódico de lectura de remarcadores, reducir la transcripción manual y mejorar la trazabilidad. Hoy existe un baseline técnico materializado; los flujos operacionales y la inferencia visual siguen en desarrollo. Este case trata sobre decisiones de producto y arquitectura, no sobre un producto terminado.
La lectura de remarcadores de agua y calefacción es un proceso periódico. Cuando cada valor se lee y se transcribe a mano, el proceso acumula trabajo repetitivo y es difícil reconstruir después de dónde viene cada registro.
DepaVision busca asistir ese proceso para reducir la transcripción manual y mejorar la trazabilidad de las lecturas.
Una parte central del trabajo fue delimitar una primera versión (V1): qué problema resuelve, qué queda fuera y qué conviene validar antes de tomar decisiones difíciles de revertir.
DepaVision no se plantea como una automatización completa de la lectura. El objetivo es asistir el proceso sin eliminar el criterio humano.
El diseño no depende ciegamente de una inferencia visual. Cuando una lectura no puede resolverse de forma suficientemente confiable, una persona puede intervenir.
Es un criterio de diseño. El flujo de captura y la inferencia visual siguen en desarrollo.
Mi responsabilidad principal está en la definición del producto y en la arquitectura:
Este case no presenta como trabajo realizado modelos de machine learning, entrenamiento, OCR ni un pipeline de inferencia. Esas capacidades siguen en desarrollo.
La arquitectura separa cuatro responsabilidades: el cliente, un backend principal, los datos y un servicio especializado para capacidades de visión.
Diagrama abstracto. El cliente se comunica con un backend principal, que concentra las reglas de negocio y coordina tanto los datos como un servicio especializado de visión.
El servicio de visión existe en el baseline, pero la inferencia visual sigue en desarrollo (borde discontinuo).
El diagrama es conceptual: no representa interfaces ni infraestructura concretas.
El baseline técnico está organizado como un monorepo políglota, con un entorno de integración local reproducible basado en Docker que reúne Node, Python y PostgreSQL.
Angular · Ionic · CapacitorNestJS, con conectividad a PostgreSQLFastAPIDockerQue estas tecnologías estén presentes significa que la base existe y se integra. No significa que cada capa tenga ya lógica funcional completa.
Existe un baseline técnico real. El producto, los flujos operacionales y la inferencia visual siguen en desarrollo.
Baseline técnico materializado:
La lista describe la base técnica existente, no capacidades de producto terminadas.