Enseñar a Davin a partir de lo que ocurrió después.

Muchos sistemas terminan en la recomendación: identifican algo, sugieren una acción y ahí se detienen. Lo que ocurre después —si se aceptó, qué pasó, cuánto valió realmente— queda fuera del sistema.

Eso tiene una consecuencia concreta: el sistema nunca sabe si acertó. Puede producir recomendaciones razonables durante años sin mejorar, porque nadie le devolvió el resultado.

Una recomendación es una hipótesis sobre lo que convendría hacer. Una acción es lo que alguien decidió hacer, que puede coincidir o no con la recomendación. Un resultado es lo que realmente ocurrió, y puede ser distinto de lo esperado incluso si la acción fue la recomendada.

Confundir los tres produce el error más corrosivo de un sistema que aprende: contar como éxito algo que solo fue una buena propuesta.

Un sistema mejora cuando cierra el ciclo: entiende, decide, ejecuta, verifica y aprende de lo verificado. Cuatro de esos pasos son comunes; el quinto es el que cambia su naturaleza, porque devuelve al sistema evidencia de lo que ocurrió.

Un outcome no es una sola cifra. Es el conjunto de señales que describen qué ocurrió después de una decisión: si la contraparte aceptó o rechazó, el precio que realmente se pagó, una penalización por contaminación, cuánto se recuperó, en qué se transformó, a dónde fue, cuánto tardó y si el proceso salió como se esperaba.

Estas señales pueden convertirse en información para el sistema. No afirmamos que todas estén disponibles hoy: cada una depende de que se capture en la operación.

Un outcome no se convierte en conocimiento por el solo hecho de guardarse. Primero se liga a la decisión que lo produjo, para saber qué lo originó. Después se normaliza contra la especificación del material, para poder compararlo con otros casos. Luego se compara con casos similares, y solo entonces pasa a ser una referencia para la siguiente evaluación.

Cada paso protege contra un error distinto: sin la liga a la decisión, no se sabe qué ajustar; sin normalización, se comparan cosas que no son comparables; sin comparación, un caso aislado parece una regla.

Un material se compara con un comprador potencial y la coincidencia parece buena. El comprador rechaza el lote por una especificación que no cumple. El motivo queda registrado. La próxima vez que aparezca un material similar, esa coincidencia ya no se evalúa igual: el sistema sabe que, en esas condiciones, esa especificación produjo un rechazo.

Ejemplo ilustrativo. No muestra una transacción real.

Esta es la parte de la arquitectura que más estamos construyendo. El modelo de evidencia de Davin ya distingue entre fuente, cálculo, hallazgo, hipótesis, acción y resultado, y un resultado exige una referencia verificable. Pero capturar resultados verificados dentro de la operación comercial es un trabajo en curso.

Por eso no afirmamos que los resultados de Ecohero retroalimenten hoy de forma automática a ningún modelo en producción. Afirmamos la dirección y la disciplina: separar recomendación, acción y resultado desde el diseño.

Capturar el resultado es un problema de operación, no solo de software. Alguien tiene que registrarlo, o debe ocurrir dentro del propio workflow; si depende de un paso adicional, se omite. Los rechazos suelen ser más informativos que las aceptaciones, porque dicen exactamente dónde falló la compatibilidad. Y el motivo importa tanto como el hecho.

No todos los outcomes se pueden verificar, y aprender de pocos casos puede llevar a conclusiones equivocadas. Por eso cada señal debe conservar su contexto y su nivel de respaldo, y la información de las contrapartes debe protegerse mientras se usa para aprender.

Ampliar la captura de outcomes, verificar más pasos del proceso y cerrar más ciclos. Cada ciclo cerrado deja a Davin con más contexto sobre qué funciona, y alimenta el grafo de inteligencia de materiales.