Que hace Sharingan y que NO hace: limites, contratos y responsabilidades
La confianza en un sistema no viene de lo que promete, sino de lo que define con precision. Este articulo explica que responsabilidades asume Sharingan, cuales rechaza explicitamente y por que esa distincion es la base de su fiabilidad.
Por que hablar de limites
Cuando evaluas un componente de infraestructura,
la pregunta mas importante no es que puede hacer.
Es que pasa cuando algo sale mal.
Un sistema que no define sus limites te deja dos opciones:
descubrirlos en produccion o asumirlos por tu cuenta.
Ninguna de las dos es aceptable para logica critica.
Sharingan trata los limites como decisiones de diseno,
no como carencias. Cada responsabilidad rechazada
es una garantia mas para el integrador:
si el kernel no lo hace, no puede romperlo.
Este articulo recorre las responsabilidades de Sharingan
con la misma precision con la que estan definidas internamente.
Sin promesas implicitas. Sin zonas grises.
Lo que Sharingan hace
Sharingan asume un conjunto concreto de responsabilidades.
Cada una esta respaldada por contratos explicitos
y comportamiento determinista.
Gestiona el ciclo de vida de ejecuciones
Sharingan opera con dos primitivas centrales: Jobs y Runs.
Un Job es una definicion de trabajo reutilizable.
Es inmutable una vez creado. Contiene configuracion e identidad,
pero ningun estado de ejecucion.
Un Job no se ejecuta. Define que se puede ejecutar.
Un Run es una instancia de ejecucion de un Job.
Tiene estados explicitos y transiciones controladas.
Mientras esta pendiente, puede mutar.
Una vez alcanza un estado terminal, es irreversible.
Esto significa:
- Un proceso completado no puede reabrirse.
- Un proceso fallido no se reintenta automaticamente.
- No existen estados intermedios ambiguos.
El integrador sabe en todo momento en que estado esta cada ejecucion.
No hay sorpresas. No hay procesos en limbo.
Ejemplo conceptual.
Un producto lanza una tarea de procesamiento de documentos.
Sharingan crea un Run asociado al Job correspondiente.
El Run pasa de
pendingarunningacompleted.Si falla, queda en
failed. Definitivo.El producto consulta el estado y actua en consecuencia.
Sharingan no decide que hacer con el fallo. Solo lo registra.
Diagrama sugerido: "Ciclo de vida de un Run"
>
Diagrama de estados lineal con bifurcacion:
>
`[pending] --> [running] --> [completed]
|
+--> [failed]
`>
Estados terminales (
completed,failed) marcados con borde dobley etiqueta: "Irreversible".
Flecha de retorno inexistente: no hay camino de
failedapending.
Registra eventos de uso
Cada operacion que pasa por Sharingan genera un evento de uso.
Estos eventos son observacionales: registran lo que paso,
no controlan lo que pasa despues.
El kernel no toma decisiones basadas en el uso.
No bloquea operaciones por exceso de consumo.
No aplica politicas de throttling.
Registra. Expone. El producto decide.
Esto es deliberado:
- Las politicas de uso son logica de negocio.
- La logica de negocio no pertenece al kernel.
- Si el kernel aplicara politicas, cada producto dependeria
de las decisiones del kernel en lugar de las suyas.
Ejemplo conceptual.
Un tenant consume 10.000 tokens en una hora.
Sharingan registra esos 10.000 tokens como eventos de uso.
El producto que integra Sharingan consulta esos eventos
y decide si bloquea al tenant, le envia un aviso o no hace nada.
Sharingan no sabe que existe un "limite". Solo sabe que hubo uso.
Aisla datos y operaciones por tenant
Cada tenant en Sharingan opera en un espacio logico separado.
Esta separacion es obligatoria, no configurable.
- Cada consulta incluye el identificador de tenant.
- No existe memoria global compartida entre tenants.
- El aislamiento se aplica a nivel de kernel,
no a nivel de producto.
Esto significa que un error en la logica de un producto
no puede provocar que los datos de un tenant
aparezcan en el contexto de otro.
El aislamiento no depende de la disciplina de cada equipo.
Depende del kernel.
Diagrama sugerido: "Aislamiento por tenant"
>
Dos columnas separadas por una barrera vertical gruesa.
>
Columna izquierda: "Tenant A"
- Jobs de A
- Runs de A
- Eventos de A
- Conocimiento de A
>
Columna derecha: "Tenant B"
- Jobs de B
- Runs de B
- Eventos de B
- Conocimiento de B
>
Barrera central etiquetada: "Aislamiento a nivel de kernel.
Sin filtración. Sin excepciones."
>
Ninguna flecha cruza la barrera.
Proporciona trazabilidad uniforme
Todo lo que pasa por Sharingan queda registrado:
creacion de Jobs, transiciones de Runs, eventos de uso.
La trazabilidad no depende de que cada producto
implemente sus propios logs. El kernel la proporciona
de forma uniforme para todo lo que gestiona.
Si algo paso, se puede saber que, cuando, quien lo pidio
y en que estado quedo.
Opera de forma determinista
Mismo input, mismo comportamiento. Siempre.
No hay estados internos ocultos que cambien el resultado.
No hay variaciones por contexto, por carga o por momento.
Los handlers son funciones puras:
reciben una peticion, producen una respuesta.
El determinismo no es una aspiracion.
Es un invariante del sistema.
Lo que Sharingan NO hace
Esta seccion es tan importante como la anterior.
Cada punto es una decision explicita,
no una limitacion temporal.
No toma decisiones de negocio
Sharingan no sabe que es "bueno" o "malo" para tu producto.
No prioriza. No filtra. No recomienda.
Si tu producto necesita decidir que tareas ejecutar primero,
que resultados mostrar o que usuarios bloquear,
esa logica es tuya.
El kernel ejecuta lo que se le pide.
No opina sobre si deberia hacerlo.
Ejemplo conceptual.
Dos tareas llegan al mismo tiempo: una urgente, una rutinaria.
Sharingan no sabe cual es urgente. Las ejecuta segun su contrato.
Si la prioridad importa, el producto debe gestionarla
antes de enviar la tarea al kernel.
No implementa heuristicas ni retries automaticos
Si una ejecucion falla, queda en estado failed. Definitivo.
Sharingan no reintenta. No analiza la causa del fallo.
No decide si "vale la pena" volver a intentar.
Esto es una garantia, no una carencia:
- Sin retries ocultos, no hay efectos secundarios inesperados.
- Sin heuristicas, no hay comportamientos que cambien
- Sin recuperacion automatica, cada fallo es visible
sin que el integrador lo sepa.
y el producto decide como responder.
Ejemplo conceptual.
Un Run falla porque el servicio externo no respondio.
Sharingan marca el Run como
failed.El producto detecta el fallo, espera 30 segundos
y crea un nuevo Run contra el mismo Job.
La decision de reintentar fue del producto, no del kernel.
No gestiona interfaz ni experiencia de usuario
Sharingan no tiene UI. No genera HTML.
No decide como presentar resultados.
No gestiona sesiones de usuario.
Es una capa de infraestructura.
Lo que el usuario final ve y experimenta
es responsabilidad completa del producto.
No implementa ingestion de conocimiento avanzada
Sharingan no hace chunking. No normaliza texto.
No genera embeddings. No aplica heuristicas de ingestion.
Si se utiliza Qdrant como memoria semantica auxiliar,
es exactamente eso: auxiliar. No es fuente de verdad.
No aplica permisos. No controla logica de negocio.
La ingestion avanzada, si se necesita,
pertenece a otra capa o a una fase futura.
No comparte estado con otros sistemas
Sharingan no lee ni escribe estado de otros repositorios.
No actua como cliente de otros servicios.
Su persistencia es a nivel de kernel.
Los datos que gestiona son suyos
dentro de su ambito de responsabilidad.
No expone datos de otros productos
ni asume propiedad sobre datos externos.
No tiene configuracion magica
No hay secretos hardcodeados.
No hay defaults implicitos.
Toda configuracion se inyecta explicitamente.
El entorno puede cambiar valores,
pero no cambia el significado de esos valores.
Un integrador sabe exactamente que esta configurando
y que efecto tiene cada parametro.
Como leer un contrato de kernel
Los puntos anteriores no son una lista de features
ni un documento de marketing.
Son un contrato.
Un contrato de kernel funciona asi:
Lo que esta dentro esta garantizado.
Si Sharingan dice que los estados terminales son irreversibles,
lo son. Sin excepciones. Sin "en la mayoria de los casos".
El integrador puede construir su logica
asumiendo que esa garantia se cumple.
Lo que esta fuera no es responsabilidad del kernel.
Si Sharingan dice que no aplica politicas de uso,
el integrador no debe esperar que lo haga.
Si necesita politicas, las implementa en su producto.
No hay zona gris.
Un sistema que "a veces" hace algo
no puede ser la base de una arquitectura fiable.
Sharingan hace exactamente lo que dice.
Ni mas, ni menos.
Diagrama sugerido: "Mapa de responsabilidades"
>
Tabla de dos columnas:
>
| Responsabilidad del kernel | Responsabilidad del producto |
|-------------------------------------|---------------------------------------|
| Ciclo de vida de Jobs y Runs | Que Jobs crear y cuando |
| Estados explicitos e irreversibles | Que hacer ante un fallo |
| Registro de eventos de uso | Politicas sobre el uso |
| Aislamiento por tenant | Logica de negocio por tenant |
| Trazabilidad uniforme | Presentacion de datos al usuario |
| Comportamiento determinista | Decisiones que dependen de contexto |
| Configuracion explicita | Valores de configuracion por entorno |
>
Linea divisoria central etiquetada: "Contrato."
Que gana el integrador
Cuando un kernel define limites claros,
el integrador gana tres cosas:
Previsibilidad
Sabe exactamente que va a pasar.
No hay comportamientos emergentes.
No hay "mejoras automaticas" que cambien la semantica.
Lo que funciona hoy funciona manana de la misma forma.
Autonomia
Las decisiones de negocio quedan en el producto.
El kernel no impone criterios sobre que es importante,
que es urgente o que debe bloquearse.
Cada equipo de producto controla su logica
sin depender de que el kernel "entienda" su caso.
Confianza auditable
Si alguien pregunta "que hizo el sistema",
la respuesta esta en los registros del kernel.
No en reconstrucciones. No en suposiciones.
En datos concretos, uniformes y verificables.
Cuando los limites generan mas confianza que las promesas
La tentacion en infraestructura es siempre la misma:
anadir una logica mas, un automatismo mas,
una "mejora" que ahorre trabajo al integrador.
Cada adicion de ese tipo tiene un coste:
- Reduce la previsibilidad.
- Anade un punto de fallo.
- Crea una dependencia implicita.
- Hace que el comportamiento sea mas dificil de auditar.
Un kernel que reintenta por su cuenta puede causar duplicaciones.
Un kernel que aplica politicas puede bloquear operaciones legitimas.
Un kernel que interpreta datos puede equivocarse
de formas que el integrador no puede predecir.
Sharingan elige no hacer esas cosas.
No porque no pueda.
Porque la fiabilidad se construye sobre lo que un sistema
elige no hacer, no solo sobre lo que hace.
Diagrama sugerido: "Coste de expandir un kernel"
>
Eje horizontal: "Responsabilidades del kernel" (de pocas a muchas).
Eje vertical: dos lineas.
>
Linea 1 (ascendente): "Funcionalidad aparente" — sube con mas responsabilidades.
Linea 2 (descendente): "Garantias reales" — baja con mas responsabilidades.
>
Punto de cruce etiquetado: "Zona de riesgo.
Mas funcionalidad que garantias."
>
Sharingan marcado en la zona izquierda:
pocas responsabilidades, maximas garantias.
Implicacion para el integrador
Antes de integrar Sharingan, conviene hacerse tres preguntas:
1. **Las responsabilidades que asume el kernel cubren lo que necesito
que sea uniforme y fiable en mi sistema?**
Ejecucion, uso, aislamiento, trazabilidad.
2. **Las responsabilidades que NO asume son cosas que mi producto
puede y debe gestionar por su cuenta?**
Negocio, UX, politicas, presentacion.
3. **Puedo construir sobre contratos explicitos
en lugar de sobre promesas implicitas?**
Si las tres respuestas son si,
el kernel encaja en tu arquitectura.
Si alguna es no,
es mejor saberlo antes de integrar.
Y eso tambien es parte del contrato.