que ninguna herramienta de ingeniería del caos en producción hoy en día puede responder: ¿Su último experimento probó lo correcto?
No "¿Se mantuvo dentro del presupuesto?" Eso es lo que maneja la activación del presupuesto de errores de SLO. No: "¿Sobrevivió el sistema?" Eso es lo que miden las condiciones de aborto. La pregunta es si el experimento fue diseñado para validar una creencia específica sobre el comportamiento de su sistema y si su resultado cambió lo que su equipo sabe sobre la propagación de fallas a través de su pila.
Si su respuesta honesta es "terminamos algunas cápsulas y se recuperaron", realizó un experimento seguro. Si aprendió algo útil es una pregunta aparte que las herramientas actuales no plantean.
Este artículo presenta un argumento concreto: la ingeniería del caos tiene una capa de seguridad madura y una capa de intención casi inexistente. La seguridad te dice cuánto romper. La intención te dice lo que te enseñará romperla. Estos son problemas de diseño diferentes que requieren herramientas diferentes, y combinarlos es la razón por la cual los programas caóticos a escala tienden a acumular guiones sin acumular conocimiento.
El argumento se basa en la arquitectura que desarrollé y patenté (US12242370B2, Ingeniería del caos basada en intenciones para sistemas distribuidos) y en observaciones de profesionales de Intuit, GPTZero, Insurance Panda, Fruzo y Coders.dev que han diagnosticado de forma independiente la misma brecha estructural. Les mostraré la arquitectura, recorreré el modelo de datos con código y explicaré por qué se trata de un problema de IA, no solo de orquestación.
1. La capa de seguridad es buena. También está incompleto.
Empiece por darle al modelo actual lo que le corresponde. El marco de presupuesto de errores SLO, popularizado por la práctica SRE de Google, le dio a la ingeniería del caos su primer mecanismo de seguridad basado en principios. Vincular la ejecución del experimento al presupuesto de error restante significa que no inyecta fallas en un sistema que ya está consumiendo su margen de confiabilidad.[3]. Las condiciones de parada de AWS Fault injection Service, la puntuación de confiabilidad de Gremlin y las políticas Rego de Harness ChaosGuard representan implementaciones maduras y listas para producción de esta idea.
Estas herramientas responden a una pregunta bien planteada: dado el estado actual de mi sistema, ¿es seguro ejecutar un experimento ahora mismo? La respuesta es computable, automatizable y razonablemente precisa. La pregunta que no responden es igualmente importante: dado el estado actual de mi sistema, ¿qué experimento sería más informativo para ejecutar ahora?
La seguridad y la información son ortogonales. Un experimento puede satisfacer todas las restricciones de seguridad, mantenerse dentro del presupuesto, no provocar abortos, no causar ninguna degradación mensurable y aun así no producir nada útil. Si probó un componente que no se encuentra en la ruta crítica de ningún comportamiento de cara al usuario, no gastó su presupuesto en aprender nada. Si repitió un modo de falla, su sistema sobrevivió una docena de veces sin actualizar su comprensión de la ruta de propagación, el mismo resultado.
Distinción fundamental: un experimento es seguro cuando se mantiene dentro de un costo aceptable. Un experimento es informativo cuando su resultado actualiza su modelo del comportamiento de falla del sistema. Estos requieren diferentes criterios de diseño, y sólo el primero tiene herramientas maduras.
Hay un segundo problema estructural. Los guiones son estáticos en el momento de la autoría. Codifican suposiciones sobre la topología del servicio, los patrones de tráfico y el comportamiento de dependencia que pueden ser precisas cuando se escriben y silenciosamente erróneas seis meses después. A medida que las arquitecturas de microservicios cambian semanalmente, se acumula la deriva del script a la realidad. El script todavía se ejecuta. Pone a prueba un mundo que ya no existe.
2. Cómo describen los profesionales el techo
Las siguientes observaciones fueron recopiladas de profesionales a través de Qwoted, una plataforma que conecta a expertos en el campo con investigadores y periodistas. Una encuesta intersectorial realizada a ingenieros que han creado programas caóticos en la producción converge en la misma brecha estructural desde diferentes ángulos.
Abhishek Pareek, fundador y director de Coders.dev, crea herramientas para sistemas distribuidos. Su encuadre es el diagnóstico más claro del problema:
"Lo que no tenemos es una comprensión de la resiliencia basada en la intención. Las herramientas existentes se basan principalmente en secuencias de comandos, y necesitamos crear herramientas que puedan modelar los efectos de una falla específica en una gran cantidad de microservicios antes de ejecutar el experimento. Necesitamos una IA que comprenda el razonamiento detrás de la falla, además de la mecánica de la falla". — Abhishek Pareek, fundador y director, Coders.dev[6]
La palabra "razonamiento" está haciendo un verdadero trabajo aquí. Un script captura la mecánica: finaliza estos pods, inyecta esta latencia. No capta el razonamiento: estamos ejecutando este experimento porque creemos que el disyuntor de caja debería dispararse antes de que las tasas de error del usuario superen el 0,1%, y queremos saber si realmente es así. Ese razonamiento, la hipótesis, es lo que hace que un experimento sea informativo. Cuando vive sólo en la cabeza del ingeniero, se evapora a medida que cambian los equipos y los sistemas.
Edward Tian, director ejecutivo de GPTZero, ejecuta una infraestructura de inferencia de IA a escala y ha desarrollado un lenguaje preciso para lo que falta:
"Las herramientas de caos actuales inyectan puntos de falla arbitrarios, pero no brindan ninguna dirección significativa para el usuario en términos de lo que intentan validar. La próxima evolución del caos implicará abordar preguntas específicas sobre la resiliencia: '¿pueden nuestros sistemas soportar una degradación en la recuperación de datos?' o '¿somos capaces de tolerar que un modelo no esté disponible debido a un tiempo de espera?', en lugar del uso de un guión único para todos”.
– Edward Tian, fundador y director ejecutivo, GPTZero[7]
"¿Pueden nuestros sistemas sufrir una degradación en la recuperación de datos?" es una hipótesis conductual. Nombra una conducta objetivo, una condición de fracaso y un criterio de éxito implícito. Esa es más información de la que cualquier herramienta del caos actual acepta como entrada. Es la información mínima necesaria para diseñar una prueba que responda a la pregunta.
3. La arquitectura basada en la intención
La patente estadounidense 12242370B2 describe un sistema en el que los parámetros del experimento del caos se derivan de especificaciones de intención de comportamiento en lugar de estar codificados por ingenieros. Así es como funciona la arquitectura.
3.1 Descripción general del sistema
El sistema tiene cuatro capas. Cada capa hace algo que el modelo basado en script no puede hacer. El generador de experimentos reemplaza "elegir un guión" por "obtener el experimento correcto a partir de lo que desea aprender". El evaluador de seguridad agrega contexto de comportamiento al cálculo del radio de explosión. El registrador de resultados convierte los resultados del experimento en actualizaciones del modelo en lugar de notas post mortem.
3.2 La especificación de intención
La especificación es la entrada que el sistema requiere antes de generar cualquier experimento. A continuación se muestra un ejemplo concreto de una prueba de resiliencia del pago:
Listado 1: Especificación de intención para un experimento de resiliencia en el pago
# intent_spec.yaml intent: id: exp-checkout-inv-2025-01 target_behavior: checkout_completion hipótesis: > El flujo de pago se completa dentro del SLO cuando el servicio de inventario experimenta una latencia de lectura elevada (p99 > 500 ms). El disyuntor en inventario_read se activa antes de que la tasa de error del usuario supere el 0,1%. criterios_de_aceptación: checkout_p99_latency_ms: 400 checkout_error_rate_pct: 0.1 slo_budget_fraction: 0.001 # máximo 0.1% del presupuesto de error diario exclusion_zones: – pago_auth – fraude_detección – session_management min_steady_state_window: 15m # requiere una línea de base estable antes de la inyección max_experiment_duration: 20m
Observe lo que esto codifica que un guión de caos convencional no codifica: la hipótesis es una afirmación falsificable sobre el comportamiento del sistema, no una descripción de lo que se romperá. Los criterios de aceptación definen lo que significa "aprobar" en términos de comportamiento. Las zonas de exclusión y la ventana de estado estable imponen restricciones que la mayoría de los equipos manejan de forma manual y de manera inconsistente.
3.3 De la especificación a los candidatos a experimentos
El generador de experimentos atraviesa el gráfico de dependencia del servicio para encontrar todos los componentes en la ruta crítica del comportamiento objetivo. Aquí hay un bosquejo simplificado de Python de ese recorrido:
Listado 2: recorrido de ruta crítica simplificado utilizando un gráfico de dependencia ponderada
al escribir import List, Dict importar networkx como nx def get_critical_path_components (gráfico: nx.DiGraph, target_behavior: str, exclusion_zones: List[str]) -> List[Dict]: candidatos =[]para el nodo en nx.descendants(graph, target_behavior): si el nodo en exclusion_zones: continuar edge_data = graph.edges[target_behavior, node] candidatos.append({ 'component': nodo, 'call_frequency': edge_data.get('call_freq', 0), 'degradation_sensitivity': edge_data.get('sensitivity', 0), 'in_blast_radius_of': lista (nx.ancestors (gráfico, nodo)) }) retorno ordenado (candidatos, clave = lambda x: x ['degradation_sensitivity'] * x ['call_frequency'], reverso = Verdadero)
Los pesos de los bordes, la frecuencia de llamada y la sensibilidad de degradación se aprenden de experimentos anteriores y de la telemetría de observabilidad (rastros, métricas de malla de servicios). Un componente que se encuentra en cada solicitud de pago Y cuya degradación históricamente se propaga a errores que enfrentan los usuarios ocupa el primer lugar. Uno que tiene un trabajo en segundo plano tiene una clasificación cercana a cero.
4. Evaluación de seguridad en tiempo real: más allá de los umbrales estáticos
Ishu Anand Jaiswal, líder senior de ingeniería de Intuit, identifica el componente que hace que la evaluación de seguridad sea realmente inteligente en lugar de simplemente automatizada:
“Lo que falta para un caos verdaderamente inteligente es un planificador de IA que comprenda la topología en vivo y el 'presupuesto de resiliencia'. Debería estimar continuamente cuánta latencia adicional, pérdida o agotamiento de recursos puede absorber el sistema, luego seleccionar y secuenciar experimentos que maximicen el aprendizaje mientras se mantienen dentro de ese presupuesto, actualizando su modelo en cada ejecución y en incidentes reales”. — Ishu Anand Jaiswal, líder sénior de ingeniería, Intuit[8]
El concepto de 'presupuesto de resiliencia' es diferente del presupuesto de error de SLO. El presupuesto de error mide cuánta confiabilidad ya ha consumido durante este período. El presupuesto de resiliencia es prospectivo: dado el estado actual del sistema, ¿cuánta tensión adicional de un tipo específico puede absorber antes de que comportamientos fuera del alcance del experimento comiencen a degradarse?
La Tabla 1 a continuación muestra cómo se compara el umbral estático con la puntuación de resiliencia en tiempo real en cinco señales clave:
La fila de la señal de aborto es donde el marco conductual produce su diferencia más concreta. En lugar de detenerse cuando la latencia del servicio cruza un umbral, un experimento consciente de la intención se detiene cuando el comportamiento objetivo, la finalización del pago, se degrada más allá del criterio de aceptación. Un pico de latencia en un componente irrelevante no detiene el experimento. Un pico de latencia en la ruta crítica de pago lo detiene inmediatamente, independientemente de lo que muestren los paneles de infraestructura.
5. El problema del contexto del usuario que las métricas de infraestructura no pueden resolver
Isabella Rossi, CPO de Fruzo, ha construido mecanismos de caos sobre señales de comportamiento en lugar de métricas de infraestructura. Su observación se dirige a un problema que el control del radio de explosión no puede abordar:
"Las herramientas de ingeniería del caos generalmente tratan la resiliencia del sistema como una propiedad estática. Inyectan estrés según la hora del día o los umbrales de carga, lo que pasa por alto cuán frágil puede ser un sistema en un contexto de usuario y perfectamente estable en otro. Un tiempo de espera de la base de datos durante el registro es catastrófico. El mismo tiempo de espera durante una característica opcional apenas se nota. Las herramientas actuales no hacen esa distinción". – Isabella Rossi, directora de productos, Fruzo[9]
Esto es técnicamente preciso, no sólo intuitivo. Un tiempo de espera de escritura en la tabla de registro de usuarios durante un flujo de registro finaliza una sesión. Un tiempo de espera de escritura en una caché de lectura de indicadores de funciones durante una página de preferencias vuelve a los valores predeterminados de forma silenciosa. Ambos eventos parecen idénticos en los paneles de infraestructura, tasa de tiempo de espera elevada en un grupo de conexiones de base de datos. Su impacto en el usuario difiere en órdenes de magnitud.
La Tabla 2 ilustra cómo la misma falla, en el mismo componente, produce una gravedad del radio de explosión muy diferente dependiendo del comportamiento del usuario que esté activo:
Una herramienta de caos basada en secuencias de comandos no tiene forma de completar la columna "Contexto de usuario". No sabe qué comportamientos de usuario están activos cuando se ejecuta el experimento. Un sistema basado en intenciones puede hacerlo, porque la especificación de intenciones nombra el comportamiento objetivo y el generador del experimento solo considera los componentes en la ruta crítica de ese comportamiento bajo el tráfico actual.
6. La extensión Business-Signal: radio de explosión en dólares
Una vez que se anclan los experimentos a comportamientos en lugar de a componentes, la extensión lógica de ese principio va más allá de lo que llega la mayoría de las prácticas de ERE en la actualidad.
James Shaffer, director general de Insurance Panda, ha reconstruido todo su caos programa en torno a señales de ingresos:
"Los scripts estáticos son basura. No respetan el estado actual de la red. Vinculamos nuestro motor de inyección de fallas directamente a las métricas comerciales en vivo, no solo a las cargas del servidor. Si las cotizaciones activas completadas caen incluso en un dos por ciento, la prueba se cancela instantáneamente. Es un interruptor automático basado en los ingresos, no en la latencia. Lo que falta en las pruebas de caos genuinamente inteligentes no es una mejor IA para romper cosas. Es la IA la que entiende el radio de explosión en cantidades de dólares. Una falla en un microservicio podría parecer una "Un corte catastrófico para un SRE. Pero si no impide que un usuario compre una póliza de automóvil, ¿a quién le importa? El caos inteligente necesita aprender la diferencia entre el ruido técnico y la sangría financiera real". — James Shaffer, director general de Insurance Panda[10]
El interruptor de Shaffer, activado por una caída del 2% en las cotizaciones finalizadas, es una implementación directa en producción de un criterio de aceptación conductual. La señal de cancelación es la tasa de transacciones comerciales, no un umbral de latencia p99. Así es como se ve eso en el modelo de datos de resultados:
# result_record.yaml resultado: experiment_id: exp-checkout-inv-2025-01 hipótesis_resultado: SOPORTADO # disyuntor disparado según lo previsto abort_reason: null # experimento ejecutado hasta su finalización # señales de comportamiento (criterios de aceptación) checkout_p99_latency_ms: 312 # aprobado: < 400ms checkout_error_rate_pct: 0.04 # aprobado: < 0.1% checkout_completion_rate_delta: -0.3% # superado: <2% umbral # radio de explosión: pronosticado vs real predicted_blast_radius: – inventario_read_service actual_blast_radius: – inventario_read_service – cart_service # Dependencia DESCUBIERTA, no en el modelo gráfico presupuesto_consumed_pct: 0.00083 # señales de actualización del modelo Graph_updates: – add_edge: [compra, cart_service] sensibilidad_peso: 0,34 blast_radius_prediction_error: 0,34
La línea más valiosa de este registro es la dependencia descubierta: cart_service no estaba en el modelo gráfico, pero el experimento reveló que responde a la degradación de inventario_lectura. Esa actualización se propaga hacia adelante, el próximo experimento de pago incluirá cart_service en su evaluación de radio de explosión. Así es como el modelo de sí mismo del sistema mejora con el tiempo, sin curación humana.
7. Por qué se trata de un problema de IA y no sólo de orquestación
La objeción razonable en este punto es que todo lo descrito anteriormente suena a trabajo de ingeniería, recorrido de gráficos de dependencia, comparación de umbrales y registro estructurado. ¿Realmente necesitamos IA para esto, o simplemente una mejor plomería?
La plomería maneja decisiones deterministas: si la tasa de combustión excede X, aborta. Si la latencia cruza Y, deténgase. Estas son las barreras que implementan las herramientas actuales. Son valiosos y cerrados bajo supuestos conocidos. Los problemas que requieren modelos aprendidos son aquellos en los que el espacio de decisión no es enumerable:
Predicción del radio de explosión en topologías novedosas. Predecir los efectos de segundo orden de una falla en componentes a los que no se dirige directamente requiere una generalización a partir de patrones de comportamiento en experimentos anteriores. No se pueden enumerar todos los gráficos de servicios posibles en el momento de la creación. Generación de hipótesis. Traducir 'resiliencia de verificación de prueba bajo degradación de inventario' en una lista clasificada de tipos de fallas ordenados por la informatividad esperada no es ejecución de reglas. Requiere razonamiento sobre las relaciones semánticas entre comportamientos de servicio. Aprendizaje del peso por sensibilidad. Los pesos de los bordes en el gráfico de dependencia no son propiedades estáticas. Cambian con los patrones de tráfico, el comportamiento del almacenamiento en caché y los cambios en la implementación. Es necesario aprenderlos continuamente a partir de resultados experimentales. Atribución de anomalías durante los experimentos. Cuando varias señales se mueven simultáneamente durante un experimento, determinar qué movimiento es causado por la falla inyectada versus las condiciones preexistentes requiere un modelo contrafactual. Ése es un problema de inferencia causal.
Este último punto es donde el campo está más lejos de una solución. Las herramientas de caos adaptativo son decentes para correlacionar señales, pero no pueden explicar por qué una falla específica se produce en cascada de la manera en que lo hace a través de una topología determinada.[4]. Desarrollar esa capacidad requiere algo que ninguna herramienta del caos actual intenta: un modelo causal de propagación de fallas que pueda actualizarse a partir de los resultados del experimento e interrogarse con consultas contrafactuales.
8. El contraargumento, tomado en serio
Los equipos maduros ya escriben declaraciones de hipótesis. Los principios de la Ingeniería del Caos de Basiri et al. (2016) requieren definir el comportamiento en estado estacionario antes de la inyección[2]. Netflix, Google e Intuit ejecutan programas disciplinados en los que los ingenieros documentan lo que esperan que suceda antes de realizar experimentos. ¿Es la "ingeniería del caos basada en la intención" sólo una descripción de lo que ya hacen los profesionales cuidadosos?
La objeción es parcialmente correcta. Los equipos maduros mantienen declaraciones de hipótesis. El problema es que los mantienen en documentación, no en herramientas. La hipótesis existe en una página de Notion. La herramienta del caos que ejecuta el experimento no tiene acceso a él. Esto crea cuatro brechas específicas:
• La herramienta no puede verificar que el diseño del experimento realmente pruebe la hipótesis establecida; nunca se detecta una discrepancia entre la intención documentada y la falla configurada.
• La herramienta no puede adaptar el experimento basándose en el estado del sistema en tiempo real en relación con la hipótesis; se ejecuta independientemente de si las condiciones actuales hacen que la prueba sea significativa.
• La herramienta no puede actualizar un modelo de dependencia basado en el delta entre el radio de explosión previsto y real, esa señal se pierde en un documento post mortem
• La herramienta no puede evitar que la misma hipótesis se pruebe de forma redundante, las bibliotecas de scripts crecen, la información no
La diferencia entre "los equipos hacen esto manualmente" y "las herramientas lo hacen de forma computable" es la diferencia entre una práctica que escala con el equipo y otra que no. Cuando el ingeniero que escribió la hipótesis se marcha, también se marcha la intención. Cuando la topología del sistema cambia, es posible que la hipótesis ya no corresponda a ningún diseño de experimento real, y nada capta eso.
9. Tres cosas que el campo necesita construir
La arquitectura existe. Las primitivas de seguridad de las que depende están maduras. La infraestructura de observabilidad que requiere está ampliamente implementada. Quedan tres brechas específicas entre dónde se encuentra el campo y hacia dónde debe ir.
Brecha 1: un esquema de especificación de intención estándar
Cada equipo que realiza ingeniería del caos basada en hipótesis utiliza su propio formato, una plantilla de Notion, una sección de runbook, un tipo de ticket JIRA. Ninguno de estos es legible por máquina mediante herramientas del caos. Los cinco campos del Listado 1 anterior (objetivo_comportamiento, hipótesis, criterios_de_aceptación, fracción_presupuestaria, zonas_de_exclusión) capturan la estructura esencial. La estandarización de este esquema, de manera análoga a cómo OpenAPI estandarizó las descripciones de la interfaz de servicio, permitiría que las herramientas absorbieran, validaran y actuaran según hipótesis en lugar de ignorarlas.
Brecha 2: datos de resultados de experimentos estructurados
La predicción del radio de explosión requiere datos de entrenamiento. Actualmente, casi ningún equipo registra los resultados de los experimentos en un formato estructurado y consultable. Los resultados se encuentran en hilos de Slack y documentos post mortem. El esquema de resultados del Listado 4 es un punto de partida. Instrumentar las herramientas de caos existentes para emitir resultados estructurados automáticamente y almacenarlos en un formato consultable junto con el gráfico de dependencia generaría la señal de entrenamiento que necesitan los modelos predictivos.
Brecha 3: Evaluación de la calidad de las hipótesis
Los programas del caos actualmente se evalúan en función de la cobertura (cuántos servicios se han probado) y la supervivencia (si el sistema se mantuvo). Ninguno de los dos mide si los experimentos fueron informativos. Una puntuación de la calidad de la hipótesis (¿cambió el resultado de esta ejecución la creencia del equipo sobre el sistema y en qué medida?) daría a los profesionales una señal para mejorar el diseño del experimento en lugar de simplemente acumular guiones. Ninguno de estos requiere nuevas investigaciones. Requieren que el campo acuerde representaciones e invierta en la infraestructura de datos que haga que el aprendizaje de los experimentos sea computable en lugar de anecdótico.
Conclusión
La ingeniería del caos tiene las primitivas de seguridad adecuadas. Lo que le falta es un enfoque igualmente basado en principios sobre la informatividad. Sin una capa de intención, los programas caóticos tienden a dos modos de falla: guiones que prueban las mismas cosas repetidamente y experimentos que se mantienen dentro del presupuesto sin producir nada que valga la pena aprender.
La arquitectura basada en intenciones que se aborda en este artículo no reemplaza los mecanismos de seguridad que el campo ha creado. Agrega una capa que hace que esos mecanismos sean más significativos, cimentándolos en lo que el operador realmente está tratando de aprender, derivando experimentos de especificaciones de comportamiento en lugar de folklore de ingeniería, y acumulando un modelo de la dinámica de fallas del sistema que mejora con cada ejecución.
La brecha es real, estructural y solucionable. La pregunta es si el campo construye la infraestructura para cerrarlo o sigue escribiendo guiones.
Referencias
[1]MP Amador, KP Annamali, S. Jeuk, S. Patil, MFK Wielpuetz, Creación de niveles de caos basada en intenciones para entornos de prueba variables, US12242370B2 (2025), Cisco Technology Inc., Oficina de Patentes y Marcas de Estados Unidos
[2]A. Basiri, N. Behnam, R. de Rooij, L. Hochstein, L. Kosewski, J. Reynolds, C. Rosenthal, Chaos Engineering (2016), IEEE Software, 33(3), 35–41
[3]B. Beyer, C. Jones, J. Petoff, NR Murphy, Ingeniería de confiabilidad del sitio: cómo ejecuta Google los sistemas de producción (2016), O'Reilly Media
[4]D. Kikuta, H. Ikeuchi, K. Tajiri, ChaosEater: Ingeniería del caos completamente automatizada con modelos de lenguaje grandes (2025), arXiv:2501.11107
[5]LC Opara, ON Akatakpo, IC Ironuru, K. Anyaene, BO Enobakhare, Chaos Engineering 2.0: una revisión de la resiliencia impulsada por la IA y guiada por políticas para sistemas multinube (2025), Journal of Computer, Software, and Program, 2(2), 10–24
[6]A. Pareek, Respuesta de un profesional experto sobre la resiliencia basada en la intención (2025), Qwoted — Coders.dev
[7]E. Tian, Respuesta de un profesional experto sobre ingeniería del caos basada en hipótesis (2025), Qwoted — GPTZero
[8]IA Jaiswal, Respuesta de un profesional experto sobre planificación de IA y presupuestos de resiliencia (2025), Qwoted — Intuit
[9]I. Rossi, Respuesta del profesional experto sobre la resiliencia del contexto del usuario (2025), Qwoted — Fruzo
[10]J. Shaffer, Respuesta de un profesional experto en ingeniería del caos con métricas empresariales (2025), Qwoted — Insurance Panda