El documento y las capacidades

Una capacidad es una cosa que ELYRA sabe hacer: registrar una solicitud, consultar un estado, dar de alta a alguien. Y se configura entera en un solo sitio: el documento.

Por qué un documento y no un grafo

La primera respuesta que se le ocurre a cualquiera —y la que dan casi todas las herramientas del mercado— es un lienzo con cajas y flechas. Aquí se descartó a propósito. Un grafo obliga a quien configura a hacer de arquitecto: colocar nodos, tirar flechas, cuidar que no queden hilos sueltos. Y a la hora de leer, la forma no dice nada: dos flujos idénticos pueden dibujarse de veinte maneras.

El documento se lee de arriba abajo, como se lee una conversación, que es justo el orden en el que ocurre. Se recorre con la vista, se busca con Ctrl+F, y para saber qué hace no hay que reconstruir mentalmente ningún recorrido.

La regla de diseño detrás de estas decisiones: si hay que explicar una pantalla, está mal diseñada.

Qué hay dentro

El documento se arma con bloques, y cada bloque hace una cosa:

• preguntar algo y guardarlo con un nombre;
• entender lo que la persona dijo, cuando no basta con leerlo literal;
• decidir entre caminos según lo recogido;
• ejecutar una operación contra el sistema de negocio;
• contestar con un texto del catálogo;
• avisar a alguien más, arrancando otra capacidad hacia otra audiencia;
• cerrar la conversación.

Los bloques viven una sola vez, en un kit común. Añadir un bloque nuevo es escribirlo allí; nunca duplicarlo en la pantalla que lo usa.

Las variables

Lo que se recoge se guarda con un nombre y se vuelve a usar con {{llaves}}. Dos reglas que ahorran disgustos:

• Los nombres de variable van sin eñes ni tildes (anio, no año). La etiqueta que ve la persona sí lleva lo que tenga que llevar; el token no.
• Una {{llave}} que no se pudo resolver no sale. Se borra, y con ella el hueco que deja al irse. Una llave cruda no dice nada y además delata que algo está roto — y quien paga ese diagnóstico sería la persona que está conversando. Hacia un sistema es al revés: en una URL o en un cuerpo JSON, ver la llave sin resolver es el diagnóstico, y ahí se conserva.

Las condiciones

Se evalúan en orden y gana la primera que se cumple; el «si no» va siempre de último. Una condición rota no tumba nada: devuelve false, deja un aviso en el rastro y la conversación sigue.

Ante la duda, jamás el final destructivo

Cancelar, borrar o rechazar exigen certeza. No entender exige volver a preguntar, nunca cerrar. Un «si no» que acaba en «cancelado» convierte cualquier respuesta rara en una conversación perdida.

Versiones

Un documento se puede versionar y restaurar. Restaurar una versión avanza la línea de vida: crea una nueva a partir de la vieja. La línea nunca se reescribe, así que siempre se puede contar qué había en cada momento.

Lo que va por versiones es el documento: el menú, las capacidades y sus bloques. Una conversación que empezó con una versión la termina con esa misma. Las herramientas que se montan sobre la interacción —la IA, el portero y los comandos— no van por versiones: aplican en cuanto se guardan, a todas las conversaciones, y restaurar una versión no las cambia. Si la IA se apaga, por decisión propia o porque su proveedor falla, el documento sigue funcionando igual. Y un comando que lanza una capacidad recién creada funciona aunque la interacción todavía no se haya publicado.