Jev AI y Modelos System One - Arquitectura de microservicios y automatización de backend con TypeSafe AI

Arquitectura actual de la API y utilización de `POST /v1/systemone` para evaluaciones System One.

Consulta de modelos disponibles mediante `GET /v1/models`.

Autenticación mediante Bearer API Key.

`TypeSafeClient` como cliente oficial para aplicaciones JavaScript y TypeScript.

Carga de credenciales desde `TYPESAFE_API_KEY`.

`jev-latest` como alias predeterminado configurado actualmente por el SDK.

Método `systemOne()` para enviar state, questions y modelo opcional.

Inferencia TypeScript del resultado a partir de los tipos de preguntas definidos.

Helpers `choice`, `score` y `noul`.

ESM, CommonJS y declaraciones TypeScript disponibles en el paquete oficial.

Configuración de timeout, retry, headers y cancelación por petición.

Uso de `models.list()` para descubrimiento programático de modelos.

Encapsulación del cliente TypeSafe en una capa propia para evitar acoplar todo el dominio directamente al SDK.

Estrategia de versionado de la dependencia y pruebas antes de adoptar cambios incompatibles.

`state` como representación compacta de la información necesaria para realizar una decisión.

Uso de texto, objetos JSON y arrays como formatos de entrada soportados.

Modelado del estado a partir de eventos, requests, entidades, políticas y metadata.

Separación entre DTO recibido por el microservicio y estado realmente enviado al modelo.

Selección de campos útiles evitando transportar información que no modifica la decisión.

Normalización de fechas, códigos, enumeraciones, flags, importes y datos categóricos.

Uso de esquemas TypeScript para mantener contratos explícitos entre servicios.

Validación de state mediante bibliotecas de schemas antes de realizar una llamada externa.

Tratamiento de valores ausentes, inconsistentes o desconocidos.

Versionado del contrato de state cuando evolucionan productores y consumidores.

Compatibilidad hacia atrás en arquitecturas donde distintos servicios se despliegan independientemente.

Sanitización y minimización de contenido sensible.

Diseño de estados suficientemente explicativos sin introducir ruido semántico.

Control del tamaño de entrada como variable de coste y rendimiento.

Choice como primitiva para seleccionar una alternativa dentro de un conjunto cerrado.

Probabilidades por opción y selección de la alternativa con mayor probabilidad.

Uso de Choice para routing, clasificación y selección entre estrategias permitidas.

Score para situar un estado dentro de una rúbrica ordenada.

Probabilidades por nivel y puntuación ponderada como señal para reglas posteriores.

Noul para representar la probabilidad de que una afirmación sea verdadera.

Diferencia entre el valor Noul y el campo de confianza utilizado por Choice y Score.

`instructions` como definición concreta de la decisión solicitada.

`criteria` como mecanismo para especificar semánticamente las alternativas o niveles.

Choice con opciones mutuamente comprensibles y suficientemente diferenciadas.

Score con niveles ordenados y significados operativos claros.

Noul para gates probabilísticos y verificaciones previas.

Combinación de Choice, Score y Noul dentro de una única solicitud.

Uso del vector completo de probabilidades en lugar de limitarse al resultado principal.

Diseño de preguntas pequeñas y componibles frente a una única pregunta excesivamente compleja.

Separación entre Decision Service, servicios de dominio y componentes encargados de ejecutar acciones.

Jev como dependencia externa encapsulada detrás de una interfaz propia del sistema.

Patrón request → normalización → decisión → policy → action.

Evitación de llamadas directas a TypeSafe desde cada microservicio sin una estrategia arquitectónica común.

Decision Service centralizado frente a integración distribuida por bounded context.

Contratos síncronos para decisiones necesarias dentro de una petición HTTP.

Contratos asíncronos cuando la respuesta no condiciona inmediatamente al cliente.

Separación entre inferencia probabilística y autorización determinista.

Uso de Jev como advisory service en lugar de convertirlo en una autoridad universal.

Idempotencia de las operaciones que se ejecutan después de una decisión.

Correlation IDs para relacionar petición, decisión y acción.

Trazabilidad de la versión del modelo y política utilizada en cada ejecución.

Timeouts propios del servicio consumidor para evitar propagación ilimitada de latencia.

Bulkheads para limitar el impacto de saturación sobre otros servicios.

Diseño de una capa anti-corrupción para poder sustituir proveedor o modelo sin reescribir el dominio.

Routing de peticiones hacia servicios previamente autorizados mediante Choice.

Enrutamiento por tipo de incidencia, dominio, intención o categoría.

Selección entre distintos modelos, workflows o niveles de procesamiento.

Score para determinar severidad, prioridad o riesgo.

Noul para validar condiciones previas antes de continuar una operación.

Separación entre clasificación semántica y autorización final.

Matrices de decisión que combinan múltiples probabilidades con reglas deterministas.

Introducción de opciones explícitas como `unknown`, `manual_review` o `unsupported`.

Escalado automático cuando ninguna opción alcanza el nivel de confianza exigido.

Uso de diferentes thresholds según impacto de la decisión.

Prevención de routing circular entre microservicios.

Registro del vector de probabilidades para análisis posterior.

Detección de casos donde las respuestas se contradicen entre sí.

Reglas de fallback cuando el resultado no cumple criterios mínimos.

Evolución desde `if/else` basados en keywords hacia decisiones semánticas tipadas y medibles.

Integración de decisiones System One dentro de procesos dirigidos por eventos.

Diferencia entre comando, evento, decisión probabilística y acción de dominio.

Consumidores de colas que preparan state y ejecutan evaluaciones Jev.

Uso con Kafka, RabbitMQ, SQS, Service Bus u otros brokers sin acoplar la decisión al transporte.

Event-driven routing hacia consumidores especializados.

Clasificación de eventos antes de continuar el pipeline.

Priorización de mensajes basada en scores.

Filtrado de eventos mediante Noul y reglas deterministas posteriores.

Dead-letter queues para eventos que no pueden procesarse con seguridad.

Reprocesamiento de mensajes conservando información de la decisión original.

Deduplicación e idempotencia ante entregas repetidas.

Correlation y causation IDs para mantener trazabilidad distribuida.

Diferencia entre reevaluar un mensaje y reutilizar una decisión previamente almacenada.

Orden de eventos y consecuencias de procesamientos concurrentes.

Eventual consistency cuando la decisión modifica procesos distribuidos posteriores.

Rango extremo a extremo de 70–500 ms comunicado actualmente por TypeSafe para Jev y necesidad de medirlo desde la región real de despliegue.

Diferencia entre latencia del modelo, transporte, serialización, aplicación y pipeline completo.

Diseño de SLO propios en lugar de tratar el rango publicado por el proveedor como garantía contractual.

Medición de p50, p95 y p99.

Reducción del state a información semánticamente relevante.

Agrupación de preguntas sobre el mismo estado para aprovechar su evaluación paralela.

Evitación de llamadas secuenciales cuando las decisiones son independientes.

Reutilización de conexiones HTTP y optimización del cliente backend.

Concurrencia controlada frente a fan-out ilimitado.

Caching solo cuando estado, política y requisitos de frescura permiten reutilizar una respuesta.

Request coalescing para evitar evaluaciones idénticas simultáneas.

Cancelación de peticiones cuyo resultado ya no es necesario.

Time budgets para integrar Jev dentro del presupuesto total de respuesta del microservicio.

Backpressure cuando la velocidad de entrada supera la capacidad de procesamiento.

Load testing sobre la arquitectura completa antes de comprometer objetivos de latencia.

Clasificación de errores entre autenticación, contrato, rate limiting, sobrecarga, timeout y conectividad.

Tratamiento de errores de validación antes de consumir capacidad remota.

Retry exclusivamente sobre condiciones transitorias.

Exponential backoff y jitter para reducir reintentos sincronizados.

Límites máximos de retries para evitar tormentas de tráfico.

Configuración del SDK con timeout por intento.

Circuit Breaker para aislar degradaciones sostenidas del proveedor.

Estados Closed, Open y Half-Open dentro de una estrategia de circuit breaking.

Fallback hacia reglas deterministas cuando existe una alternativa segura.

Escalado a revisión humana cuando no es posible tomar una decisión suficientemente fiable.

Bulkheads para evitar que una saturación afecte a todos los workers.

Dead-letter handling para workflows asíncronos.

Diferenciación entre error técnico y respuesta válida con baja confianza.

SDK: retry configurable y timeout. Contrato System One y el cliente oficial para personalizar la política de transporte.

Runbooks para timeouts, sobrecarga, credenciales, schemas y degradación de calidad.

Restauración gradual del tráfico después de una incidencia.

Diferencia entre probabilidad emitida, confianza calculada y precisión observada en el negocio.

Necesidad de validar thresholds sobre datos representativos del dominio.

Dataset etiquetado para medir la calidad real de las decisiones.

Matriz de confusión en decisiones Choice convertidas a clases operativas.

Falsos positivos y falsos negativos según coste empresarial.

Brier Score para evaluar calidad probabilística en decisiones binarias.

Expected Calibration Error como métrica externa para estudiar alineación entre confianza y frecuencia de acierto.

Reliability diagrams para observar sobreconfianza o infraconfianza.

Thresholds diferentes por operación, segmento y nivel de riesgo.

Zona gris que activa revisión humana o un pipeline más costoso.

Detección de degradación cuando métricas de calibración abandonan los rangos aceptables.

Desactivación automática de una ruta probabilística cuando un quality gate crítico deja de cumplirse.

Fallback hacia versión anterior, reglas o modelo alternativo.

Recalibración de thresholds sin ocultar problemas estructurales del dato.

Registro de decisión, outcome real y feedback para evaluación continua.

API Keys almacenadas mediante variables de entorno o secret managers.

Prohibición de incorporar credenciales en repositorios, imágenes o configuración pública.

Uso exclusivamente server-side de las credenciales.

Separación entre autenticación frente a TypeSafe y autorización de negocio dentro del sistema.

Mínimo privilegio aplicado a los microservicios consumidores.

Validación de input antes de incorporarlo al state.

Sanitización y minimización de datos sensibles.

PII, secretos y datos regulados como información que requiere tratamiento específico.

Cifrado TLS durante el transporte.

Redacción de campos sensibles en logs y traces.

Seguridad de la supply chain de dependencias del microservicio.

Secret rotation sin necesidad de reconstruir toda la aplicación.

Controles deterministas antes de ejecutar acciones destructivas.

Jev como señal para guardrails, nunca como sustituto de una política de autorización.

Threat modeling de rutas donde una decisión probabilística puede producir efectos sobre sistemas reales.

Unit tests sobre normalización y construcción del state.

Contract tests sobre schemas enviados a TypeSafe.

Tests sobre mapas Choice, Score y Noul.

Golden datasets con casos de decisión conocidos.

Evaluación por clase, segmento y criticidad.

Casos fronterizos próximos a los thresholds.

Inputs ambiguos, incompletos y contradictorios.

Tests sobre baja confianza y rutas de revisión.

Simulación de timeouts, rate limiting y errores de red.

Mock del cliente TypeSafe para pruebas deterministas de lógica de negocio.

Integration tests contra un entorno real controlado.

Regression testing al modificar instrucciones, criteria, state o versión de modelo.

Comparación entre versiones antes de modificar el alias utilizado en producción.

Performance tests sobre concurrencia y latencia.

Quality gates que impidan promover cambios que degraden precisión, calibración o fiabilidad.

Pipeline CI para linting, type checking, unit tests y contract tests.

Validación de schemas JSON y contratos TypeScript.

Security scanning de dependencias, secretos e imágenes.

Construcción de imágenes Docker reproducibles.

Ejecución de regression datasets como parte del pipeline.

Evaluación de precisión y calibración frente a valores mínimos aceptables.

Performance budgets para detectar aumentos de latencia.

Tests de resiliencia sobre timeout y fallback.

Versionado conjunto de código, contratos, preguntas, criteria y configuración.

Entornos development, staging y production con credenciales independientes.

Canary deployment para limitar exposición de cambios probabilísticos.

Shadow evaluation para comparar una nueva configuración sin utilizar todavía su decisión.

Automated rollback cuando métricas técnicas o de calidad incumplen límites.

Evidencias de pipeline asociadas al artefacto desplegado.

Promoción controlada de cambios que modifican thresholds o comportamiento de routing.

Logs estructurados sobre request, modelo, pregunta, resultado y política aplicada.

Correlation IDs distribuidos entre gateway, Decision Service y servicios posteriores.

Métricas de latencia p50, p95 y p99.

Request rate, error rate y saturation como señales básicas de servicio.

Distribuciones de Choice, Score y Noul a lo largo del tiempo.

Monitorización de confidence y thresholds.

Drift en la composición de los estados recibidos.

Métricas de calibración cuando se dispone posteriormente del outcome real.

Porcentaje de decisiones automáticas frente a escaladas humanas.

Ratio de fallback por error técnico y por incertidumbre semántica.

OpenTelemetry para traces, metrics y logs dentro de la arquitectura distribuida.

Dashboards por servicio, ruta de decisión y dominio funcional.

Alertas diferenciadas para disponibilidad, latencia, calidad y calibración.

Detección de cambios bruscos que podrían indicar nuevas casuísticas o datos defectuosos.

SLI, SLO y runbooks específicos para el Decision Service.

Jev como capa de System One para decisiones acotadas y frecuentes.

LLM generativo para tareas abiertas de generación, síntesis o planificación.

Código determinista para reglas exactas, cálculos y permisos.

Jev como router entre modelos generativos previamente autorizados.

Noul para verificar si una acción necesita escalado antes de ejecutarse.

Choice para seleccionar tools o workflows dentro de una allowlist.

Score para priorizar tareas, alertas o candidates.

Guardrails probabilísticos complementados con políticas estrictas.

Agentes que utilizan Jev para resolver microdecisiones sin invocar razonamiento generativo completo.

Reducción de latencia y coste mediante routing escalonado.

Fallback desde Jev hacia un LLM cuando el dominio exige mayor razonamiento.

Fallback desde IA hacia revisión humana en escenarios críticos.

Evitación de utilizar una llamada de IA para reglas que pueden expresarse de forma exacta.

Separación entre decidir, autorizar y ejecutar.

Arquitectura por capas según velocidad, coste, riesgo y complejidad de la tarea.

Arquitectura de referencia basada en microservicios con un Decision Service especializado en System One.

Contrato TypeScript entre productores de eventos, Decision Service y servicios consumidores.

Modelo de state JSON versionado y validado antes de la inferencia.

Mapa de preguntas Choice, Score y Noul alineado con decisiones concretas de negocio.

Routing probabilístico hacia un conjunto cerrado de destinos autorizados.

Policy layer que transforme probabilidades en acciones, revisión o fallback.

SLO de latencia definido sobre métricas reales del entorno de despliegue.

Estrategia de concurrencia, timeout, retry, circuit breaker y bulkhead.

Flujo asíncrono con cola, idempotencia y dead-letter handling.

Gestión de secretos y credenciales separada del código y de las imágenes.

Modelo de observabilidad con logs, métricas y traces correlacionados.

Dataset de evaluación para precisión, falsos positivos, falsos negativos y calibración.

Thresholds asociados al riesgo de cada decisión.

Contingencia automática cuando calidad o calibración abandonan los límites aceptables.

Pipeline CI/CD con tests, quality gates, performance budgets, canary, rollback y trazabilidad de la versión desplegada.