MODELOS · DECISIONES · AUTOMATIZACIÓN
Jev no quiere conversar.
Quiere decidir.
TypeSafe presenta a Jev como el primer “System One Model”: recibe estado no estructurado y preguntas con respuestas definidas de antemano; devuelve valores tipados, probabilidades y confianza. Renuncia a generar texto para ocupar un lugar más pequeño y concreto dentro del software: esos if difíciles que hoy resolvemos con prompts, parsers y esperanza.
01 / LA INTERFAZ
Estado adentro.
Decisiones afuera.
La diferencia importante no es que el JSON sea más prolijo. Es que el espacio de salida existe antes de inferir.
Ticket, alerta, documento, traza o estado del producto
Choice · Score · Noul
Valores tipados + probabilidades + confianza
Un chat model también puede devolver JSON, especialmente con structured outputs. Pero sigue generando una secuencia: produce tokens, puede requerir validación o retries y su confianza no forma necesariamente parte del contrato. Jev plantea otra abstracción. La unidad de trabajo no es una respuesta textual sino una evaluación tipada contra un mismo estado.
Eso también recorta su alcance. No escribe un correo, no explica un diagnóstico, no genera código y no inventa una opción nueva. Si la respuesta válida no está en el esquema, el diseño del workflow —no el modelo— está incompleto.
02 / TRES PRIMITIVES
Preguntas atómicas.
Composición en código.
Cada pregunta debería poder responderse como un juicio rápido y bien delimitado. La política completa vive fuera del modelo.
Elegir una opción
Devuelve la opción elegida, la distribución de probabilidades y una medida de confianza.
Puntuar con una rúbrica
Devuelve un valor sobre una escala definida, más probabilidades y confianza.
Evaluar una afirmación
Devuelve un número entre 0 y 1: qué tan probable es que la afirmación sea verdadera.
“El cliente informa dos cargos iguales. La compra fue hoy y el segundo movimiento todavía figura como pendiente.”
duplicate_likely: Noul
urgency: Score(1..5)
route: Choice([wait, support, fraud])if confidence < 0.80:
send_to_human()
elif route == "fraud":
freeze_and_review()La decisión final sigue siendo determinística y auditable: el modelo estima; el programa combina umbrales, reglas, permisos y acciones.
03 / POR QUÉ IMPORTA EL PARALELISMO
No hay una oración
esperando a la anterior.
TypeSafe afirma que todas las preguntas se evalúan a la vez y de forma independiente contra el mismo estado.
t₁ → t₂ → t₃ → … → tₙ
Cada token depende de los anteriores. Más texto de salida significa más pasos secuenciales, más latencia y más superficie para desviarse del formato.
q₁ ∥ q₂ ∥ q₃ ∥ … ∥ qₙ
Las decisiones comparten el estado pero no una cadena de texto. Agregar preguntas apenas debería mover la latencia, según la documentación del proveedor.
La promesa es atractiva para workloads con muchas decisiones pequeñas: moderar cien atributos, puntuar señales de fraude, enrutar eventos o verificar una traza de agente. TypeSafe publica latencias end-to-end de 70–500 ms y un precio de entrada de USD 0,042 por millón de tokens, sin costo medido de salida.
Pero esos números son afirmaciones del proveedor y dependen del workload. Los evals publicados usan cuatro workflows propios y respuestas de modelos grandes como referencia, no una verdad de negocio independiente. Son evidencia útil para experimentar, no una garantía universal.
04 / DÓNDE ENCAJA
Al lado del LLM.
No en su lugar.
La especialización tiene valor cuando la frontera entre decidir y generar está bien dibujada.
Routing
Elegir qué cola, agente o modelo debería recibir un caso.
Triage
Priorizar alertas, tickets, reclamos o documentos según riesgo y urgencia.
Guardrails
Evaluar si una acción o respuesta cruza una política antes de ejecutarla.
Extracción cerrada
Mapear texto libre a estados y categorías que el programa ya conoce.
Jev puede decidir quién debería actuar; un LLM puede redactar; una herramienta puede ejecutar; una persona puede aprobar. Separar esos roles reduce libertad donde importa la confiabilidad sin renunciar a generación donde hace falta.
05 / LO QUE SABEMOS Y LO QUE NO
Una interfaz clara.
Una caja todavía opaca.
No hay que confundir un contrato de producto bien definido con una arquitectura públicamente demostrada.
- Estado no estructurado y preguntas tipadas como entrada.
- Choice, Score y Noul como formas de salida.
- Probabilidades, confianza y evaluación paralela.
- Entrenamiento llamado RLCD, orientado a decisiones calibradas.
- Arquitectura completa, tamaño y datos de entrenamiento.
- Receta reproducible de RLCD y ablations.
- Validación independiente amplia de calibración y benchmarks.
- Comportamiento fuera de los dominios evaluados.
LECTURA HONESTA“No puede alucinar” significa que no puede inventar una estructura fuera del esquema. No significa que la decisión dentro del esquema sea correcta. Un valor válido puede estar perfectamente equivocado; por eso importan calibración, thresholds, evals y fallback humano.
LA APUESTA
Menos lenguaje.
Más software.
La idea más valiosa de Jev quizá no sea un benchmark sino una frontera: usar modelos generativos para producir y modelos de decisión para juzgar; mantener la política, los permisos y la acción en código. Si la calibración sobrevive fuera de los demos, esa división puede volver a la AI más componible. Hasta entonces, Jev es una hipótesis técnica muy interesante que merece evals propios, no fe.
06 / FUENTES
Anuncio, contrato
y evidencia.
La fuente primaria describe el producto; la documentación fija la interfaz; los evals muestran la metodología y sus límites.
- 01Anuncio de System One Models y Jev · TypeSafe AI↗
- 02Documentación e interfaz de los tres primitives · TypeSafe AI↗
- 03Workflow evals, metodología y ejemplos · TypeSafe AI↗
- 04Video técnico que inspiró esta nota · Simone Rizzo↗
- 05System One Adapter para comparar LLMs · TypeSafe AI↗
Síntesis editorial basada en información pública disponible al 25 de septiembre de 2026. Las métricas de rendimiento y costo se atribuyen a TypeSafe porque todavía no constituyen validación independiente.