CBCT · IOS · informe · fotos
El caso llega como modalidades que no se hablan: DICOM, STL/OBJ, PDF/TXT e imágenes JPG, PNG o HEIC.
3D Gaussian Splatting
3DGS representa una evolución en cómo funcionan los gráficos 3D tradicionales hechos de polígonos.
El 3D Gaussian Splatting es una técnica revolucionaria de representación volumétrica. En lugar de una malla de triángulos dura, representa la escena utilizando millones de gaussianas 3D.
Qué lleva cada gaussiana
Cada gaussiana es una pequeña mancha o elipsoide flotando en el espacio.
Al superponer millones de manchas de diferentes tamaños y colores, se forma una imagen 3D fotorrealista.
Una gaussiana del 3DGS estándar guarda color y opacidad: lo justo para dibujar. Las nuestras guardan además de dónde salió cada cosa. Y hay dos clases, porque miden cosas distintas.
Las de apariencia llevan el color medido del paciente, tomado de sus fotografías corona a corona y por tercios, más la oclusión y el relieve, separados del color para que una lectura de tono no se contamine de iluminación.
Las de densidad llevan density: la atenuación de rayos X que midió el CBCT, con el rango que la convierte a Hounsfield. Y origen, que dice si ese punto lo vio el escáner o el CBCT: uno mide la corona en micras, el otro ve la raíz bajo la encía.
Las dos llevan region_id, el código FDI de la pieza: enciende un diente entero sin necesitar ninguna superficie. Es inferencia, y el fichero lo declara.
Lo que dice el informe no va aquí. Un hallazgo, un número de raíces, un conducto: el informe los da por diente, no por punto del espacio. Repartirlos entre un millón y medio de gaussianas sería fabricar resolución que nadie midió.
La gaussiana lleva la llave, no la copia: gaussiana → region_id → informe
Pipeline
Cuatro fuentes clínicas entran en paralelo y salen como un twin 3DGS, exportable y medido.
Cuatro agentes traducen a contrato
mesh-agent, cbct-agent, report-agent e image-agent leen sus fuentes, calculan sha256, eliminan EXIF y escriben procedencia por valor.
El marco deja de vivir en una sesión
Dos fusiones geométricas registran escáner↔escáner e IOS↔CBCT. El segmentation-agent añade region_id por gaussiana y la fusión semántica cuelga los hallazgos del informe de códigos FDI.
registro IOS↔CBCT medido sobre paciente real: 0,452 mm
Una escena clínica consultable
El TwinSnapshot reúne campo gaussiano, superficie, fotos, observaciones regionales y provenance. Lo medido, lo inferido y lo pendiente quedan separados.
Cuatro salidas, todas verificadas
export-agent regenera STL, field-export-agent escribe PLY, render-export-agent produce PNG multivista y composite-export-agent genera una arcada imprimible.
el pipeline entrada → twin → fichero está probado de punta a punta
Visor web + revisión humana
El caso se abre en navegador, muestra odontograma y capas clínicas, y activa HITL cuando la confianza cae por debajo del umbral.
Agentes en el desarrollo
El pipeline de arriba lo ejecutan agentes. Este repositorio también se construyó con ellos.
research-agent
Harness de revisión de código
Revisión automática y control de calidad dentro del flujo, no como paso opcional al final.
Guardarraíles ejecutables
Un data guard bloquea el commit si intenta versionar datos clínicos o artefactos de compilación. No es una norma en un CONTRIBUTING que nadie lee: es un hook que para el commit.
UOS, el formato
Un caso dental es hoy tres cosas sueltas. UOS es esas tres cosas más las relaciones entre ellas, en un fichero.
Un escáner intraoral, un CBCT y un informe llegan en tres sistemas de coordenadas distintos. La relación no viaja con los datos. Cuando el caso pasa al laboratorio o a otra clínica, esa relación hay que rehacerla.
UOS es un contenedor abierto que no recodifica nada: referencia los formatos nativos intactos y declara las relaciones. Un ZIP sin comprimir con un manifiesto por delante, que un navegador abre sin instalar nada y sin subir nada a ningún servidor.
Cada relación lleva su error
El registro entre CBCT y escáner es un objeto de primera clase: la matriz 4×4, el método, el residuo y quién lo verificó. En el caso real, 0,666 mm y «sin verificar» — y el visor está obligado a decirlo.
Una alineación automática que nadie ha mirado y una firmada por un clínico no son lo mismo.
Lo medido y lo inferido no se mezclan
Todo lo que sale de un modelo vive solo bajo derived/, con su capa regulatoria y el hash de los pesos. Borrar ese directorio deja un .uos válido y completo.
Distribuir el caso donde el módulo de IA no está habilitado no requiere reexportar el caso.
Nada se edita, todo se versiona
Modificar un caso es escribir una versión nueva que apunta al hash de la anterior. Quien lo recibe puede comprobar si cambió y respecto a qué, sin fiarse de quien se lo envió.
El contenedor no solo tiene estructura: comprueba que lo que afirma coincide con los bytes del fichero.
Ampliable sin permiso
Una modalidad nueva —carga bacteriana por sitio, fuerza de mordida, periodontograma— entra declarando un asset, un marco, una extensión y un descriptor.
Un lector que no la conozca abre el caso igual y puede decir qué dejó sin leer.
Especificación completa publicada, con esquema JSON y validador. Cualquiera puede implementar un lector.
Demo
Un caso real abierto en tu navegador, sin registro y sin subir nada.
{{PENDIENTE: caso .uos de ejemplo publicable — sin dato identificativo}}
El visor no arranca solo. Cuando exista el contenedor, se cargará aquí bajo demanda explícita.