DEV Community: Cristian Gormaz

READY Is Not Done: What a Partial Verification Actually Proves

Cristian Gormaz — Fri, 09 Oct 2026 16:47:09 +0000

A lesson from building Cognitive Suite about implementation, observed evidence, and the limits of technical claims.

A software project can reach READY at an internal checkpoint without demonstrating that the complete system works.

That distinction may sound obvious. But when developing complex software, it is easy to turn a successful checkpoint into a much broader claim than the evidence supports.

I encountered this problem while working on Cognitive Suite, an experimental software project I am developing.

This is not a story about a finished system. It is about how to communicate partial technical results without overstating what they prove.

Implemented does not mean fully verified

In a frozen development cut identified as P1, Greys-v3 was the main executable implementation of Cognitive Suite.

Within that cut, it included mechanisms for case management, work selection, record retention, epistemic controls, and conditioning sensitive operations on human authorization.

But the presence of those mechanisms did not establish that the entire system had been integrated and validated end to end.

These are different kinds of statements:

Implementation: a mechanism exists within a defined code snapshot.
Observed execution: a particular operation or stage produced an observed result.
System-level conclusion: a broader property has been demonstrated under defined conditions.

Evidence for one does not automatically establish the others.

What happened with Gate B

One example comes from an internal staged process called Gate B.

During the P1 cut, its preliminary stages—GB0, GB1, and GB2—reached the internal status READY.

Those stages ran on the actual host, working with copies and without writing to the live database.

However, GB3 and GB4 were not executed within that cut.

Consequently, the durable adjudication intended by Gate B had not been demonstrated within the P1 cut.

This matters because READY was an internal status within a bounded process. It was not a declaration that Gate B was complete or that Cognitive Suite was ready for production.

What the evidence actually supports

I found it useful to separate each observation from the conclusions it does not establish.

Observation	What it supports	What it does not establish
Greys-v3 contained the described mechanisms within the P1 cut	The described mechanisms were present within that scope	Complete end-to-end integration
GB0–GB2 reached `READY` on copies	Those preliminary stages reached the reported internal status	Completion of Gate B
No writes were made to the live database during those stages	The observed work did not write to the live database	Successful operation against the live database
GB3 and GB4 were not executed within P1	The reported execution stopped before those stages	The durable adjudication intended by Gate B

The distinction is not merely about choosing cautious language.

It is about keeping a technical statement attached to the evidence that supports it.

An unexecuted stage is not necessarily a failed stage. But it is not a successfully demonstrated stage either.

A reporting template other developers can reuse

The same structure can be applied to a test suite, an AI agent, a deployment pipeline, or a staged verification process.

For each important technical statement, record three things:

Claim	Evidence or observation	Boundary
What are we claiming?	What did we actually inspect, execute, or observe?	What stronger conclusion is still unsupported?

Then ask:

1. What is implemented?

Identify the relevant mechanisms and the exact version or snapshot being discussed.

2. What was observed?

Describe the execution and its result, including the conditions under which it occurred.

3. What remains unproven?

State which operations were not performed and which conclusions require additional evidence.

This does not establish that the reporting method itself improves system reliability, or that it is better than other reporting practices.

It does, however, make the limits of a technical claim explicit and easier for another engineer to challenge.

Why communicate an incomplete result?

Because waiting until an entire system is finished is not always practical—or useful.

Partial results can reveal important engineering decisions, identify unresolved boundaries, and invite meaningful technical feedback.

The challenge is to share those results without turning:

An implemented mechanism into a fully integrated system.
An internal READY status into production-ready.
An execution on copies into a claim about live-state behavior.
An unexecuted stage into either a demonstrated success or a demonstrated failure.

Progress is worth communicating.

Its boundaries are part of the result.

An open question

When reviewing an AI system, agent workflow, or staged software process, what evidence would you require before treating an internal READY status as a demonstrated, persistent, end-to-end outcome?

I would be interested in how other developers draw that line in their own projects.

Scope and provenance: This article describes my interpretation of the bounded P1 development cut of Cognitive Suite. Technical reference: 5295aec, an identifier from the private development line. The public repository preserves a historical, sanitized snapshot from June 2026 and is not a mirror of the private P1 implementation. This is not an independently reproduced audit or a claim that Cognitive Suite is complete.

AI disclosure: This article was drafted and edited with AI assistance. The underlying development observations and records come from my work on Cognitive Suite. I take responsibility for its factual claims, scope limitations, and final wording.

El modelo encontró evidencia relevante y aun así falló: por qué “alucinación” se me quedó corta

Cristian Gormaz — Mon, 07 Sep 2026 22:52:25 +0000

Actualización / corrección: después de publicar este artículo, una pregunta técnica me llevó de vuelta al request.json primario preservado de la corrida. Verifiqué que el artefacto revisado corresponde byte a byte al original.

Las condiciones relevantes sí estaban presentes, pero no pude confirmar que la versión candidata fusionada estuviera incluida exactamente como la recordaba.

Por eso retiro la localización de este caso específicamente en Interpretación. El punto exacto donde ocurrió el fallo queda, por ahora, no determinado.

Estoy probando modelos locales en tareas de análisis de código y hace poco apareció un fallo que me obligó a revisar cómo estaba usando una palabra bastante común en IA:

“alucinación”.

El caso parecía sencillo.

El modelo encontró fragmentos relevantes del código.

No inventó otro archivo.
No citó evidencia inexistente.

Mi primera lectura fue que había encontrado la evidencia necesaria y luego la había entendido al revés.

Después de volver al artefacto primario, tuve que estrechar esa conclusión.

Ese detalle terminó siendo más interesante para mí que el error en sí.

Porque decir simplemente:

“el modelo alucinó”

me permite saber que algo salió mal.

Pero no me dice qué salió mal.

Encontrar la evidencia no es lo mismo que entenderla

Seguí revisando errores de este tipo dentro de una campaña más amplia de evaluación con modelos locales.

Y empecé a notar que estaba agrupando bajo una misma palabra problemas que, desde el punto de vista de ingeniería, requieren soluciones completamente diferentes.

Por ejemplo:

puede que la evidencia necesaria ni siquiera esté disponible;
puede que esté disponible, pero la respuesta no quede correctamente vinculada con ella;
puede que el modelo encuentre el fragmento adecuado y lo atribuya al objeto equivocado;
puede leer correctamente el fragmento, pero interpretar mal su significado;
puede interpretar bien la evidencia y aun así formular una afirmación que ya no está soportada;
o puede llegar a una afirmación correcta y estropearla al usarla en el siguiente paso.

Terminé representándolo provisionalmente así:

Evidencia
   ↓
Binding
   ↓
Atribución
   ↓
Interpretación
   ↓
Claim
   ↓
Transformación

No estoy proponiendo esto como una taxonomía universal ni definitiva.

Es simplemente una herramienta que surgió de mis propias pruebas y que me está ayudando a formular una pregunta mucho más útil:

¿en qué punto exacto se rompió el proceso?

Por qué importa distinguirlos

Supongamos que el modelo da una respuesta incorrecta.

Si la información necesaria nunca estuvo dentro del contexto disponible, el primer problema probablemente no es el modelo.

Podría ser el mecanismo que construyó ese contexto.

En cambio, si la evidencia correcta estaba presente y el modelo la identificó, pero después entendió al revés lo que significaba, arreglar el sistema de recuperación probablemente no resolverá nada.

Es otro fallo.

Y pide otra respuesta.

**En el caso que me llevó a escribir esto, hoy puedo sostener algo más estrecho:

las condiciones relevantes sí estaban presentes en el payload.

Lo que no pude confirmar al volver al artefacto primario fue que la candidata fusionada estuviera incluida exactamente como la recordaba.

Por eso ya no puedo localizar limpiamente este caso en Interpretación.

Y justamente por eso “alucinación” sigue pareciéndome demasiado gruesa como diagnóstico: saber que hubo un fallo no basta para saber dónde ocurrió.**

Ahí “alucinación” dejó de resultarme suficientemente útil como diagnóstico.

Del error del modelo al error del sistema

Esta distinción también cambió una pregunta que me hacía al evaluar modelos.

Antes era fácil reducir el resultado a algo parecido a:

ACIERTO
FALLO

Ahora me interesa mucho más conocer la ruta:

¿Tenía la evidencia?
        ↓
¿La vinculó correctamente?
        ↓
¿La atribuyó correctamente?
        ↓
¿Entendió lo que significaba?
        ↓
¿Su afirmación estaba soportada?
        ↓
¿Usó correctamente esa afirmación después?

Porque cada respuesta cambia qué componente debería revisar.

Tal vez necesito mejorar el contexto.

Tal vez el problema está en cómo enlazo las fuentes con la respuesta.

Tal vez necesito restringir la tarea.

O quizá el modelo simplemente no debería tener autoridad para realizar ese tipo concreto de juicio sin otra capa de validación.

Esa última posibilidad es especialmente importante para mí.

No estoy intentando construir sistemas donde el modelo siempre tenga razón.

Estoy mucho más interesado en sistemas donde podamos saber qué conservar cuando se equivoca.

Una palabra útil, pero demasiado gruesa

No creo que “alucinación” sea necesariamente una palabra incorrecta.

El problema aparece cuando se convierte en la explicación final.

Dos respuestas pueden ser igualmente incorrectas y tener causas completamente distintas.

Y si las causas son distintas, también deberían serlo nuestras mitigaciones.

Por eso, después de estas pruebas, estoy intentando separar:

el síntoma

el lugar donde ocurrió el fallo.

“Alucinación” puede seguir nombrando el primero.

Pero todavía necesito diagnosticar el segundo.

Me interesa especialmente contrastar esto con quienes estén evaluando LLMs sobre código, RAG, agentes o flujos donde el modelo recibe evidencia externa:

cuando evalúan un modelo que recibe evidencia externa, ¿cómo distinguen en qué parte del proceso ocurrió realmente el fallo?

Transparencia: utilicé modelos de lenguaje como asistencia para revisar y editar la redacción. El experimento y los registros provienen de mi propio trabajo. La interpretación técnica de este caso fue corregida después de volver al artefacto primario preservado.