Dos servidores.
Una experiencia
coherente para el cliente.

Un plan completo, no una certificación de producción

La meta sigue siendo una conversación natural y útil, vinculada a un cliente verificado, el circuito seleccionado, conocimiento empresarial aprobado y evidencia operativa fechada. El asistente debe expresar incertidumbre, limitar permisos y transferir el caso cuando falten hechos o autoridad.

Esta revisión pública independiente abarca evidencia del 23 de octubre al 3 de noviembre de 2026. La autoridad de ingeniería sigue en el puntero maestro v15 de ADN AI System Management y los comprobantes de investigación y entrega v16. Esta edición no es una nueva versión aceptada del plan de ingeniería ni presume acceso completo al adjunto final v16 o a todos los chats en vivo.

Desde el candidato del 30 de octubre aparecen contratos de identificación probados localmente, mediciones parciales del tamaño del contexto, un candidato privado de índice de conversaciones WhatsApp y monitoreo continuo de Index 9. Son etapas de evidencia distintas. No demuestran liberación productiva para clientes, instalación de otra GPU, respaldo funcional ni aceptación de benchmarks.

La plataforma de extremo a extremo

Los eventos de WhatsApp y del centro de contacto ingresan en una cola duradera. Una capa de identidad verificada y selección del servicio establece cuenta, DAT, empresa y fuentes permitidas. El enrutador elige un flujo acotado; los adaptadores reúnen un paquete de evidencia fechado; el modelo local propone la respuesta; los validadores y controles de entrega deciden si puede mostrarse o enviarse.

Las responsabilidades se mantienen separadas: encontrar una cuenta no autentica al solicitante; autenticarlo no otorga acceso financiero; producir JSON válido no demuestra un hecho; y redactar no autoriza el envío. La ruta del cliente no debe heredar una búsqueda ilimitada para personal interno.

Brain es el servidor conversacional principal en el diseño inicial. ADN-RAG realiza recuperación y trabajo de conocimiento en segundo plano, y se prepara para inferencia independiente y respaldo. La publicación del sitio público permanece fuera del sistema que atiende clientes.

Dos RTX 5090. Dos computadoras independientes.

La dirección aprobada por el propietario es una RTX 5090 en Brain y otra en ADN-RAG, no dos tarjetas en una sola computadora. La meta es 64 GB de RAM del sistema por servidor. La ampliación de RAG contempla NVMe de 4 TB para datos y una unidad de arranque separada; falta confirmar su capacidad y la instalación final.

Una observación fechada del 30 de octubre identifica la 5090 en Brain. La segunda tarjeta figura encargada, no aceptada tras instalación. La correspondencia de ingeniería señala trabajo pendiente en fuente eléctrica y memoria compatible. Antes de instalar, comprobar espacio, ranura, conectores, refrigeración, alimentación y software con el modelo exacto de tarjeta y equipo.

Cada RTX 5090 tiene 32 GB de memoria de GPU [N1]. La RAM del sistema y la memoria de GPU son presupuestos distintos. Dos GPU independientes de 32 GB no forman automáticamente un conjunto transparente de 64 GB. Para sobrevivir por separado, cada servidor necesita cargar el modelo completo y ejecutar el flujo mínimo sin depender del otro.

Fijar el archivo y hash del modelo, cuantización, tokenizador, plantilla de conversación, motor de inferencia, instrucciones, esquema de herramientas y límites de contexto. Conservar un paquete compatible en ambos nodos. Una segunda GPU no replica por sí sola colas, autenticación, bases de datos, entrega ni permisos.

Disponibilidad antes de repartir la carga

La fase A es principal más reserva preparada: Brain atiende la inferencia de clientes; ADN-RAG conserva una ejecución compatible lista y realiza sus tareas dentro de límites medidos. La fase B es inferencia activo-activo controlada, solo después de aprobar la carga con un único nodo sobreviviente. Son modos distintos, no nombres alternativos de una instalación terminada.

Elegir de forma explícita entre coexistencia completa y operación degradada. La coexistencia exige que un solo nodo sostenga la carga acordada de clientes y las tareas RAG/GPU obligatorias. El modo degradado puede pausar o limitar indexación, embeddings y documentos no esenciales. Aprobar ese modo no equivale a aprobar toda la carga simultánea.

La meta de trabajo es aproximadamente 20 conversaciones, con 25 como escenario adicional de estrés cuando se apruebe. Los chats abiertos no equivalen a generaciones simultáneas. Medir solicitudes activas, longitud de contexto y salida, herramientas, espera y mezcla de tareas. La especificación de la tarjeta no demuestra capacidad operativa.

El contrato de la conversación con el cliente

Partir de la validación confiable del canal o del centro de contacto; luego resolver la cuenta y el servicio exacto. Coincidir por teléfono o mediante Index 9 es una pista, no autenticación. DAT identifica un circuito, no al cliente: una cuenta puede tener varios DAT. Se propuso un identificador distinto para clientes, pero no se ha demostrado su migración ni aceptación productiva.

El candidato v2 de la API de identificación, del 1 de noviembre, incorpora pruebas locales de familias DAT, ambigüedad y paginación de servicios. Las comprobaciones del v1 alojado y Odoo se registraron por separado. La serie completa de pruebas v2 alojadas sigue pendiente de una fuente y ruta de staging autorizadas; las afirmaciones locales no equivalen a aceptación productiva.

Las intenciones siguen siendo soporte técnico, finanzas/facturación (incluida desconexión) y servicios adicionales. Conservar español costarricense natural, inglés y conversaciones mixtas. Preguntar solo cuando afecte una acción segura; no convertir afirmaciones del cliente en pagos o estados de red verificados.

Persistir estado duradero mínimo: identidad, servicio, revisión de permiso, turnos, herramientas pendientes, evidencia, escalamiento e identificadores de entrega. El segundo host debe reconstruirlo sin confiar en la caché temporal de GPU ni en la sesión de otra cuenta.

Un contrato de resultado validado separa hallazgos, hipótesis, faltantes, comprobaciones, autorizaciones, texto para el cliente y transferencia humana. Generar una respuesta no permite enviar mensajes ni modificar red o finanzas.

Un paquete canónico de evidencia en RAM

Para una sesión vigente y autorizada, construir por separado contextos de red y finanzas. El DAT seleccionado y el alcance verificado delimitan la consulta. Adjuntos grandes, manuales y telemetría quedan en repositorios duraderos aprobados; al modelo llegan fragmentos acotados con referencias.

Usar una instantánea canónica con versión, hash, fecha, revisión de autorización, turnos relevantes, marcas de actualización por fuente, unidades medidas, dependencias confirmadas, vigencia, conflictos y estado de completitud. Ningún adaptador debe presentar un espejo histórico como estado financiero o de monitoreo actual.

Los experimentos pareados deben congelar idéntica evidencia mínima autorizada y diálogo para Gemma y un solo modelo en nube con identificador verificado y fijado. La tokenización nativa puede diferir; conservar hash común, esquema de resultado y arbitraje experto. La respuesta en nube no es la verdad de referencia.

El límite anterior de proceso de 2 GiB, presupuesto de entradas de 1,75 GiB y política de cinco minutos pertenecen a un candidato de caché sintético, no a una asignación productiva medida. El 31 de octubre se midieron campos seleccionados de 20 y 50 cuentas con cobertura incompleta de monitoreo y contabilidad; serializar datos no mide RAM residente, concurrencia ni contexto integral.

Una lectura autorizada puede renovar el vencimiento inactivo propuesto de cinco minutos, sin superar la autorización absoluta. Renovar no actualiza las fuentes ni revive permisos revocados. Las claves deben incluir empresa, identidad/alcance y época de permisos; invalidar por reasignación o revocación y conservar estado parcial/obsoleto explícito.

Contrato ilustrativo — identificadores sintéticos

{
  "schema_version": "candidate-v1",
  "snapshot_id": "synthetic-example",
  "scope": {
    "account": "ACCOUNT-A",
    "service": "CIRCUIT-A",
    "session_revision": 3
  },
  "sources": [
    {
      "evidence_id": "E-01",
      "observed_at": "2026-10-30T18:00:00-06:00",
      "status": "reviewed"
    }
  ],
  "conversation": [
    {
      "role": "customer",
      "text": "Mi conexión a internet dejó de funcionar."
    }
  ],
  "complete": false,
  "missing_sources": [
    "current upstream observation"
  ],
  "comparison": {
    "input_hash": "computed from frozen bytes",
    "models": [
      "Gemma",
      "one pinned OpenAI model"
    ]
  }
}

Validar conversaciones y sus datos de respaldo

Evaluar la conversación final: ¿cuenta y circuito correctos, evidencia vigente y permitida, incertidumbre honesta y siguiente paso útil? La integridad de índices y el JSON válido respaldan la meta, pero no demuestran calidad real de respuestas.

Para cada adaptador, definir dueño del campo y conciliar registros originales, recolectados, permitidos, indexados y recuperados, eliminaciones, relaciones cuenta-servicio y paginación completa. Los errores de fuentes y relaciones desconocidas deben quedar visibles, no convertirse en ausencia de avería o saldo.

Index 9 cuenta con instalación fechada en entorno de prueba y controles locales de actualización. Una revisión del 3 de noviembre informó estado local limpio, sin poder verificar salud HTTP ni vigencia de fuentes superiores. Fallar una conexión de monitoreo no prueba caída del servicio; un temporizador activo no demuestra el recorrido completo.

Un candidato privado de índice solo WhatsApp del 2 de noviembre concilió registros de archivo, elegibilidad, fragmentos e integridad. No se activó para responder a clientes. Vigencia, cobertura de datos sensibles, precisión semántica independiente y permisos por cuenta siguen sin verificar. Archivo de correo, índice textual WhatsApp y búsqueda semántica para clientes son rutas distintas hasta demostrar su integración.

Para incidentes comunes de fibra, relacionar el servicio seleccionado con dependencias verificadas y telemetría vigente; no inferir causas por nombres parecidos. Separar fibra de respaldo inalámbrico y conservar conflictos en la evaluación.

Ocho dominios de conocimiento más búsqueda de servicio

La arquitectura heredada separa ocho dominios y la función adicional Index 9. Usar el catálogo canónico del responsable para numeración; no renumerar desde un diagrama genérico. La política de acceso aplica a todos los dominios, no solo a preguntas de permisos.

Gemma frente a un modelo de referencia OpenAI

Usar una referencia en nube por experimento. Esta edición se centra en Gemma frente a OpenAI, como se solicitó; las notas anteriores conservan Claude como alternativa, no como segundo comparador obligatorio ni votación entre tres modelos. Fijar el modelo API disponible antes de ejecutar, no describirlo como “el ChatGPT de hoy”. No se ejecutó ninguna comparación pagada para crear esta página.

La evaluación en paralelo sin envío y el respaldo en vivo son flujos distintos. En evaluación, ambos modelos responden independientemente al caso congelado y ninguno envía automáticamente al cliente. En respaldo, una política aprobada puede pedir ayuda para una respuesta específica, con límites de permisos, latencia, costo y escalamiento. La nube no sustituye datos ausentes ni autorización.

Crear un registro pareado con hash idéntico, pregunta, turnos, instrucciones, política de herramientas y esquema de salida. Guardar versiones de modelo/motor y prompt, parámetros, truncamiento, salida original y validada, errores, tiempos, tokens y costo. Ningún modelo ve la otra respuesta antes de puntuar.

Comparar con resultados independientes verificados y etiquetas revisadas por expertos, no aceptar la respuesta OpenAI como verdad por venir de un modelo mayor. Alternar el orden para revisión ciega, separar exactitud de presentación y calibrar al juez automático con etiquetas expertas. Conservar discrepancias y fallas [O1].

Enviar información a la nube requiere una aprobación distinta. Construir una proyección mínima con campos permitidos y seudónimos coherentes. Excluir secretos y datos personales, financieros o de comunicaciones innecesarios. La aprobación de esta página pública no autoriza transferir conversaciones privadas ni conjuntos de entrenamiento.

Medir la conversación, no solo el JSON

Construir familias de casos representativas y autorizadas: averías, cobros, desconexiones, servicios adicionales, múltiples circuitos, identidad desconocida, fuentes caídas y escalamiento. Incluir expresiones costarricenses, mensajes incompletos, ambigüedad, diálogos largos y observaciones contradictorias. Separar por cliente/familia de incidente y tiempo para no filtrar copias entre desarrollo y prueba.

Usar tres pistas: interpretación/enrutamiento para intención y servicio; recuperación para evidencia autorizada, relevante y vigente; respuesta/entrega para sustento, seguridad, coherencia y prevención de envíos duplicados o no aprobados.

Los registros existentes son referencias útiles, no puntajes intercambiables: la comparación local del 23 de octubre usó 60 casos congelados con tres repeticiones y concurrencia uno; el candidato de contexto del 29 registró 20 pruebas sintéticas; el piloto de correo registra 48 casos y 12 comprobaciones. Repetir no multiplica ejemplos independientes y nada de ello demuestra 20 sesiones simultáneas de clientes.

Antes de liberar, congelar rúbrica y criterios. Medir exactitud, afirmaciones sin sustento, citas, aislamiento cuenta/servicio, aclaraciones, preguntas innecesarias, transferencias, tarea resuelta, latencia p50/p95 y costo. Una divulgación no autorizada o acción insegura bloquea la versión; no se compensa con un promedio alto.

Registrar fallas y aprobados. Una batería anterior aprobada no invalida una falla posterior de concurrencia o recuperación. Publicar tamaño de muestra, fecha, modelo, entorno y tipo de revisión. Acordar umbrales operativos antes de probar carga; esta página no afirma que estén cumplidos.

Mejorar conocimiento, orquestación y pesos por separado

Primero localizar la falla. Evidencia ausente u obsoleta corresponde a ingesta, relaciones y recuperación. Herramientas equivocadas o redacción confusa corresponden a enrutamiento e instrucciones. Fallas de comportamiento persistentes pueden justificar un experimento de ajuste separado. No entrenar para memorizar saldos, estados o permisos cambiantes.

Incorporar un incidente resuelto a conocimiento solo tras confirmar hechos, alcance, vigencia, citas y retención por un responsable. Corregir versiones sin borrar historia. Mantener las pruebas reservadas fuera del entrenamiento y de la recuperación que pueda revelar sus respuestas.

El ajuste modifica pesos o adaptadores de Gemma; añadir un documento a RAG no lo hace [G1]. Curar ejemplos revisados, versionar datos/modelo, comparar con la base intacta sobre casos reservados y conservar reversión. Una salida OpenAI puede sugerir una explicación, pero no convertirse automáticamente en conocimiento aprobado ni etiqueta de entrenamiento [O2].

El respaldo debe preservar toda la conversación

Un segundo proceso de inferencia sano es necesario, pero insuficiente. La ruta sobreviviente necesita fuentes autorizadas, colas duraderas de entrada/salida, sesiones, acciones idempotentes y acceso de entrada. Identificar dependencias que pueden derribar ambos nodos: energía, almacenamiento, switches, identidad, liderazgo de base y pasarela.

La secuencia propuesta es detectar y confirmar; impedir que el escritor anterior actúe; establecer un líder autorizado; reconstruir sesión/evidencia; repetir solo trabajo seguro e idempotente; verificar acuses de entrega; y volver al enrutamiento normal tras comprobar recuperación. Una partición entre dos nodos requiere fencing o testigo independiente revisado; inferencia activo-activo no garantiza escritura múltiple segura.

Probar por separado caída de host, GPU, escritor de base, conectividad, réplica obsoleta, identidad vencida, fuentes Odoo/monitoreo y nube. Definir tiempo de recuperación y pérdida aceptable antes, y medir después. Documentar lo no disponible en modo degradado en vez de inventar normalidad.

Probar restauración es distinto de respaldar archivos o sincronizar réplicas. Restaurar una base no certifica recuperar toda la aplicación. Preservar versiones, modelos, configuración y estado recuperable de conversaciones/acciones; ensayar el regreso al principal sin respuestas duplicadas.

Operación, observabilidad y responsables

Trazar cada entrada hasta autenticación, servicio, hash de evidencia, salida del modelo, validación, revisión humana y entrega confirmada. Separar en cola, ejecución, parcial, fallo, escalamiento y entregado; una API válida no significa éxito integral.

Observar vigencia de ingesta, revocación de permisos, citas, generaciones activas, cola, memoria GPU/RAM, latencia y recuperación. Interpretar señales de salud según su alcance real; un proceso activo no demuestra el recorrido del cliente.

System Management mantiene punteros de arquitectura aceptados y gobierno de versiones; componentes sus contratos; Soporte revisa utilidad de conversación; Contabilidad acepta autoridad financiera; infraestructura responde por recuperación. El sitio público no controla operaciones.

La propuesta de identificador del cliente separado del DAT del circuito y el principio de una fuente única de precios requieren responsables de campos, revisión de migración/contratos y aceptación posterior. Ninguna integración se declara completada. Se excluyen nombres de empleados y rutas privadas.

25 líneas de trabajo con próximos pasos explícitos

Este registro público coordina trabajo. Los roles son responsabilidades de coordinación, no asignaciones personales ni aceptaciones inventadas. Expandir una fila para ver estado de evidencia, siguiente entrega y requisito.

25 / 25

El mapa de responsabilidades de 20 capas

Preservar responsabilidades del diseño original y extender despliegue, recuperación y evaluación. Incluir una capa no demuestra integración productiva completa.

De la evidencia a un piloto controlado

Requisito 0 — Conciliar autoridad de ingeniería, observaciones instaladas, dueños de fuentes, punteros de versión y conflictos. No sobrescribir planes aceptados con candidatos documentales.

Requisito 1 — Calificar la segunda GPU independiente y demostrar un modelo completo fijado dentro de límites de energía, memoria y refrigeración. Una tarjeta encargada o un servicio activo no certifica respaldo.

Requisito 2 — Probar identificación alojada y recuperación con permisos. Completar las pruebas de staging pendientes sobre familias DAT, ambigüedad, paginación, expiración, respaldo al flujo existente, vigencia, finanzas y recorrido real.

Requisito 3 — Elegir un único modelo de referencia en nube por ID vigente verificado y política aprobada; comparar evidencia y diálogo mínimos congelados con Gemma. Revisores humanos arbitran pertinencia, exactitud, seguridad y español en casos reservados.

Requisito 4 — Probar cargas sostenidas de 1, 2, 4, 8, 12 y 20 solicitudes activas y estrés aprobado. Repetir con un solo host sobreviviente y trabajos de conocimiento, separando operación plena/degradada y evitando entregas duplicadas o no autorizadas.

Requisito 5 — Autorizar piloto limitado con aceptación documentada de negocio, soporte, seguridad e ingeniería, monitoreo y reversión. Activo-activo o ajuste de pesos sigue evidencia de calidad, no supuestos.

El registro de desarrollo

Un plan vivo con historial verificable

La arquitectura pública se revisa dos veces por semana, separada de los avances nocturnos. Usar inventarios accesibles, pruebas de componentes, comprobantes de System Management y decisiones visibles; no cambiar versiones de ingeniería aceptadas.

El publicador de arquitectura y el nocturno comparten un bloqueo por sitio y protegen páginas vigentes, originales y artículos retirados. La activación amplia previa fue bloqueada antes de ejecutarse; un borrador nuevo y un publicador de inicio funcional no autorizan evadir la restricción anterior.

Separar fecha de evidencia de publicación web real, con segundos en Costa Rica. Ante fallo o ausencia de cambios, conservar hora anterior; generar HTML o programar una tarea no demuestra publicación.

No se obtuvo toda la historia de ChatGPT en nube ni el adjunto final v16 de ingeniería. Es una limitación de cobertura, no permiso para inventar estados. Se puede preparar documentación independiente; su activación requiere el control de publicación específico.

Base de fuentes, confianza y límite de publicación

Base interna: v15 y comprobantes v16 de System Management del 30 de octubre; informes de componentes revisados del 31 de octubre al 3 de noviembre de contexto, API, archivos, ingesta conversacional, caché, SOP y evaluación local; conversaciones visibles seleccionadas y resúmenes de decisiones de dos hosts. La consulta autenticada encontró 67 repositorios del propietario con prefijo ADN; por separado, el publicador diario anterior inventarió 68 repositorios y verificó 21 commits de respaldo sin cambios de ingeniería demostrados. Se revisaron las 42 fuentes originales y evidencia reciente de componentes. No se afirma cobertura completa de chats, fuentes ni producción. Rutas, hashes, transcripciones y hallazgos sensibles se conservan en evidencia privada.

Las referencias externas sustentan principios y especificaciones concretas; no verifican el sistema instalado de ADN. El plan de evaluación es independiente de la disponibilidad futura de un producto específico de evaluación.

1. [N1] NVIDIA — GeForce RTX 5090 specifications · consultado 30 octubre 2026
2. [O1] OpenAI — Evaluation best practices · consultado 30 octubre 2026
3. [O2] OpenAI — Optimizing LLM accuracy · consultado 30 octubre 2026
4. [G1] Google — Gemma model fine-tuning · consultado 30 octubre 2026