diff --git a/README.md b/README.md
index 9c2a9b0..c57463e 100644
--- a/README.md
+++ b/README.md
@@ -175,12 +175,6 @@ he optado por no incorporarlas.
 Las pruebas más interesantes son las de reglas de negocio y validación, lo que
 viene a ser los servicios y dominio.
 
-## LLMS
-
-He usado Claude para la toma de decisiones y ayuda con el _boilerplate_, que no
-es poca cosa, además también se ha usado para la generación de las pruebas
-unitarias, además de resolución de algunos problemas complejos.
-
 ## Generadores y otras librerías
 
 Existen generadores de código para Golang, de hecho, se fomenta su desarrollo,
@@ -210,4 +204,61 @@ sí, pero la prueba no consiste en eso.
 
 También se ha planteado incorporar la librería _testify_, descartado porque para
 comprobar si existe el error y algunas comparaciones no era necesario meter una
-dependencia más.
\ No newline at end of file
+dependencia más.
+
+## Diagrama
+
+![diagrama app](./assets/app-architecture.jpg)
+
+El diagrama explica básicamente la estrucutra del proyecto en términos generales,
+se demuestra que el dominio sensors solo se comunica al exterior mediante el
+NATS y el _logger_.
+
+Amarillo: exterior.
+Morado: infraestructura.
+Verde: dominio
+Blanco: simulador, los _handlers_ está conectado sólo para llamar a la
+gorutina, pero en la realidad debería ir independiente.
+
+## Conclusión y cierre
+
+Interesante reto donde realmente lo que más me ha costado son la realización
+de pruebas unitarias, hay veces que me cuesta coger el concepto. Tengo la teoría
+muy clara, pero a la hora de la verdad se me complica un poco las cosas. Además 
+que _mockear_ el sistema de mensajería debe tener su especial complejidad.
+También ha sido algo complejo entender la concurrencia y los canales, no es algo
+que haya trabajado en profundidad pero sí que se le ha puesto bastante empeño,
+cariño y nivel de detalle.
+
+He puesto mucho en valor la arquitectura limpia con un toque personal, no es DDD
+puro ya que hay elementos que no deberían estar en dominio, pero en el proyecto
+que estoy trabajando ahora mismo se está diseñando de la misma manera y está
+funcionando muy bien.
+
+También se ha evitado todo lo posible el uso de LLMs para la generación de
+código, y su uso ha sido para la toma de decisiones arquitectónicas, discusión y
+lectura rápida sobre los distintos funcionamientos de algunas librerías. En más
+de una ocasión he cuestionado las respuestas que da, teniendo que verificar con
+la documentación oficial. Pongo en valor mi capacidad para aprovechar la IA de
+la mejor forma posible, verificando la información, además recalco que justo el
+proyecto actual es una migración de un código en PHP completamente hecho con IA,
+y se puede ver patrones y errores comunes que comete.
+
+Soy consciente de que hay margen de mejora, por ejemplo con los tests o con la
+documentación, se ha puesto especial esfuerzo y atención a que los nombres de
+las funciones, variables, métodos, estructuras y paquetes sean lo más 
+autodescriptivos posibles. Se han puesto algunos comentarios. También hay
+esfuerzo por permitir ejecutar el proyecto por primera vez con la mínima
+intervención.
+
+Un problema interesante que tuve que resolver, que como el sensor puede mandar
+un valor ausente, el tipo `float64` al hacer el `unmarshal` se establece a 0.0, 
+con lo que se puede considerar válido, con lo cual su solución fue el uso de
+puntero, si se descubre que es `nil` se considera no válido.
+
+Digamos que este proyecto resuelve el problema que se propone, un sistema que 
+permite registrar y actualziar un sensor. Se puede ver su estado y los datos que
+se recogen (simulados) se guardan en una base de datos.
+
+Espero que el proyecto sea de vuestro agrado y podamos tener una siguiente
+reunión.
\ No newline at end of file
diff --git a/assets/app-architecture.jpg b/assets/app-architecture.jpg
new file mode 100644
index 0000000..d705c54
Binary files /dev/null and b/assets/app-architecture.jpg differ