ELEV8: Una metodología humano-IA para convertir necesidades reales en resultados que funcionan

Del “vibe coding” a la colaboración con IA gobernada: un artículo metodológico de VirtuAmerica

Campo	Valor
Fecha de publicación	2026-05-13
Revisión actual	v6.15 (2026-06-23)
Editor	VirtuAmerica
Autor	David Azofeifa
Clasificación	Metodología · Colaboración humano-IA · Disciplina de especificación · Disciplina operativa
Audiencia prevista	Cualquier persona que colabore con IA en trabajo importante, desde una persona fundadora que usa IA en una sola tarea hasta un equipo que coordina varios agentes en una entrega por fases
Clase de evidencia	Método operativo probado en campo y desarrollado en producción en VirtuAmerica; no es una referencia empírica comparativa
Estado	Artículo metodológico público
Kit público	Kit ELEV8
Palabras clave	colaboración humano-IA, disciplina de especificación, colaboración responsable con IA, disciplina de evidencia, auditabilidad, gobierno de implementación

Nota del autor: por qué existe

ELEV8 no empezó como teoría. Empezó como un problema repetido de entrega.

La IA hizo posible construir ideas que habían estado bloqueadas durante años. Un sitio para un libro podía existir antes de que el libro estuviera terminado. Una página personal podía convertirse en un portafolio. Un pequeño experimento creativo podía crecer hasta convertirse en una plataforma compartida. Pero los primeros éxitos expusieron una brecha más difícil: un sistema puede ejecutar fielmente una solicitud y aun así perder a la persona, el propósito o el estándar profesional que hay detrás.

Los ejemplos de origen de este artículo se incluyen solo cuando aclaran el principio: una landing page fiel que todavía necesitaba dirección creativa, una decisión de nombre donde la IA llegó a una mejor respuesta por el proceso equivocado y un portal construido según la especificación pero sin la profundidad que un cliente real necesitaría. ELEV8 existe para hacer visibles esas brechas antes de gastar confianza, tiempo, dinero o energía creativa en la versión equivocada del trabajo.

La fuente humana importa, pero este artículo no es una biografía. Es una metodología para servir la necesidad de otra persona sin sustituirla silenciosamente por una versión más superficial o ajena.

Resumen

Las fallas más profundas de especificación rara vez se anuncian. Aparecen como retrabajo, volumen de soporte, pérdida de confianza o la sutil sensación de que un resultado entregado es técnicamente correcto y aun así está mal. Los sistemas de IA que ejecutan instrucciones superficiales aceleran ese modo de falla porque pueden producir una versión más limpia, rápida y convincente de una idea incompleta.

Este artículo presenta ELEV8: una metodología humano-IA para convertir una intención humana incompleta o poco clara en trabajo adecuado, orientable, construible y verificable. Tiene dos capas, calibradas a los riesgos. La capa ligera — la capa de principios — es una revisión de pensamiento que ayuda a una persona a mejorar un brief antes de actuar. La capa más pesada — la capa de protocolo — es un modo operativo gobernado, con límites explícitos de roles, autorización humana responsable, especificaciones ejecutables por máquina, evidencia de aceptación alineada, revisión independiente, registros duraderos de decisiones y verificación final de cierre. Use la capa de protocolo cuando los riesgos, traspasos, agentes de IA, confianza del cliente, dinero, seguridad o irreversibilidad hagan costosa la ejecución superficial.

Las secciones siguientes nombran la doctrina rectora, los principios, el modelo de roles y los artefactos. La afirmación inicial es más simple: un brief debe elevarse hasta el nivel que merece el trabajo, ni menos ni más. ELEV8 no pide que cada tarea cargue ceremonia empresarial. Pide que cada tarea importante reciba la cantidad de elevación que merecen sus riesgos.

Este es un método operativo probado en campo, desarrollado y refinado bajo uso sostenido de producción en VirtuAmerica; no es una referencia empírica comparativa ni un estudio controlado. Debe juzgarse por su claridad operativa, transferibilidad y capacidad para prevenir fallas en la capa de especificación en trabajo real. Su compromiso central es doble: la calidad de la respuesta experta no debe quedar limitada por lo incompleto del brief inicial, y la profundidad de esa respuesta debe permanecer acotada por los riesgos reales del proyecto.

Resumen rápido

Problema. La IA puede ejecutar más rápido de lo que las personas pueden aclarar la intención. Un brief superficial puede convertirse en un entregable pulido antes de que alguien note lo que faltaba.
Regla central. Elevar el brief hasta la profundidad que justifican los riesgos, ni más superficial ni más inflada.
Dos profundidades. Use una revisión ligera de pensamiento para trabajo pequeño o reversible. Use el modo operativo completo para trabajo importante, de varios pasos o auditable.
Límites de roles. El trabajo importante separa a la persona con la necesidad, la persona experta que eleva el brief, el humano responsable, quien implementa y quien revisa de forma independiente. La Parte V da nombres formales a esos roles.
Control. La autorización humana responsable protege la necesidad original para que no sea reemplazada por un documento bien redactado o por una opción predeterminada de la IA formulada con exceso de confianza.
Estándar. Una buena especificación debe ser orientable por la persona con la necesidad, ejecutable por quien implementa y verificable por una revisión independiente. En la profundidad completa, la prosa, la lista de verificación y las pruebas describen los mismos entregables.
Disciplina de evidencia. ELEV8 etiqueta si una adición proviene de conocimiento profesional, una fuente verificable o una hipótesis que todavía debe validarse. Trata la sustitución silenciosa de la IA como un defecto de proceso, aun cuando la respuesta sustituida resulte ser mejor.
Regla de adopción. Use ampliamente la revisión ligera de pensamiento. Use la forma completa cuando el costo de equivocarse lo justifique.

Límite de la afirmación. Este artículo no afirma que los documentos importen más que el trabajo entregado, que la IA pueda reemplazar el juicio humano ni que cada tarea merezca la forma operativa completa. Afirma algo más estrecho y útil: cuando la calidad de la especificación afecta materialmente la calidad del resultado, la capa de especificación necesita su propia capa creativa experta, su propia disciplina de evidencia y su propio rastro de auditoría.

Cómo leer este artículo

Este artículo está organizado como un arco gradual, no como una ceremonia fija. Empiece en el Nivel 1, reconozca su situación en el arco y deténgase donde el modo de falla coincida con su propio trabajo. Cada nivel introduce un modo de falla nuevo y la disciplina que lo responde. Nada más.

Nivel	Situación	Qué cambia	Dónde verlo
1	Una persona, una tarea	Aclarar el trabajo real; agregar conocimiento experto; etiquetar cada afirmación por tipo de evidencia	Partes I-IV
2	Una persona, varias sesiones	Guardar contexto profesional como documentos duraderos; referenciar prompts en vez de pegarlos de nuevo	Parte I (Nivel 2), §§ 6.1, 8.5
3	Construir para otra persona	Tratar a la persona con la necesidad como distinta de quien la sirve; convertir cada supuesto en una opción orientable	Partes I (Nivel 3), V
4	Varios agentes, varios pasos	Hacer coextensivos la especificación, la lista de verificación y las pruebas; usar revisión independiente; registrar cada decisión importante de forma duradera	Partes VI, VII
5	Varias fases, alto riesgo	Autorización humana en cada frontera de fase; verificación final contra la necesidad original, no contra la lista inicial	Partes VII, IX

Quien lee desde el Nivel 1 no debería sentir el peso de la maquinaria del Nivel 4. Quien lee desde el Nivel 5 debería reconocer cada mecanismo como respuesta a un modo de falla que ya vivió. Los términos usados en todo el artículo se definen en el Apéndice C.

Los cinco niveles, las dos capas (Parte III) y los cuatro modos de adopción (Apéndice B) son una misma graduación vista en tres niveles de acercamiento. El mapeo es directo: los Niveles 1-2 usan la capa de principios (elevación de una pregunta o revisión de principios); el Nivel 3 usa la capa de principios más la separación de roles de la Parte V (revisión de principios); el Nivel 4 usa la capa de protocolo (modo protocolo); el Nivel 5 usa la capa de protocolo a profundidad completa (modo protocolo o institucional).

Parte I: el arco de complejidad, una historia que se nombra a sí misma

La metodología de este artículo no es teoría. Fue descubierta en producción por una persona que resolvía problemas reales para sí misma y para otras personas, hasta que el tamaño y la forma del trabajo exigieron una estructura que no sabía que existía cuando empezó. Los cinco niveles siguientes trazan ese descubrimiento. La persona que reconoce su propia situación en el arco ya hizo la lectura más importante que el artículo le pide.

Los nombres formales de cada concepto de este arco, incluidos roles, principios, artefactos y mecanismos operativos, aparecen y se definen en las partes siguientes. Esta parte cuenta la historia en lenguaje claro para que los mecanismos lleguen como respuestas a problemas, no como requisitos que memorizar.

Nivel 1: solo yo y la IA, una tarea

El punto de partida es el más común. Una persona tiene una idea. Quiere ayuda para hacerla real. Abre una sesión con un asistente de IA, describe lo que quiere y ve cómo aparece algo. El resultado es técnicamente correcto. El resultado también es, en silencio, algo distinto de lo que realmente necesitaba.

Un ejemplo trabajado. Una persona que escribe un libro quiere un sitio web para ese libro. Ha querido que ese sitio exista durante años. No podía construirlo por sí mismo. Sus conocimientos web habían quedado obsoletos y la IA por fin está lo bastante madura para intentarlo de nuevo. Abre una sesión y pide una landing page. La IA le da exactamente lo que una landing page de libro contiene genéricamente: una biografía del autor, un formulario de contacto, algunas viñetas sobre el libro. Fiel. Incompleta.

Lo que faltaba no era una función. Era una interpretación. El libro trata sobre superar la parálisis y la niebla mental que detiene a las personas. Una animación de niebla en el hero haría algo que ninguna plantilla puede hacer, porque el libro mismo trata de la niebla. Una imagen específica lleva significado que una foto de stock nunca tendrá. Nada de eso estaba en el brief. La IA no podía saberlo. Y una vez que vio la página genérica que produjo la IA, tuvo que hacer el trabajo él mismo: investigar otros sitios, reunir referencias, formar opiniones sobre qué era llamativo y qué no, y llevar todo eso de vuelta a la IA para que lo reorganizara.

Él estaba haciendo el trabajo del experto. Sin ese esfuerzo, el brief era demasiado escueto para producir lo que realmente necesitaba.

Este es el Nivel 1, y el Nivel 1 tiene su propia respuesta. Antes de cualquier implementación, el brief debe pasar por dos preguntas:

¿Cuál es el problema real detrás de la solicitud? “Landing page de libro” es la superficie. “Una puerta pública para una idea que todavía no puede revelarse por completo” es el trabajo subyacente. Reformularlo cambia lo que se construye.
¿Qué agregaría una persona experta que no se dijo? No solo lo pedido, sino lo que una persona competente en ese espacio sabría incluir. Y para cada adición específica del dominio: ¿es un criterio profesional (defendible desde conocimiento de oficio), un hecho con fuente (documentado en algún lugar verificable) o una hipótesis de validación (una conjetura razonable que vale probar antes de comprometerse)?

La distinción importa. Un párrafo formulado con seguridad que mezcla las tres categorías sin etiquetarlas es la forma en que ideas plausibles se convierten en supuestos no verificados.

Una persona en Nivel 1 no necesita nada más. Reencuadrar la solicitud y enriquecerla honestamente, con la frontera de evidencia explícita, hace que la trampa de la fidelidad deje de ser invisible y se vuelva recuperable.

Nivel 2: solo yo y la IA, a través del tiempo

La misma persona construye un segundo sitio, luego un tercero y luego un cuarto. Cada uno lleva la misma portada de libro 3D giratoria que inventó para el primero. Las portadas divergen con el tiempo: arregla un bug en una, mejora una animación en otra y ahora cuatro sitios llevan cuatro versiones levemente distintas de la misma idea. Cada mejora debe hacerse cuatro veces, o tres sitios se quedan atrás en silencio.

Un problema más peligroso lo acompaña. La IA con la que habló sobre el primer sitio ya no está porque esa sesión terminó. Cada sesión nueva empieza con un peaje: explicar la plataforma, explicar de nuevo las convenciones, restablecer las restricciones y solo entonces hacer la pregunta real.

El modo de falla del Nivel 2 es la pérdida de contexto. Su intención es duradera, pero la conversación no. Cada sesión empieza en frío.

La respuesta del Nivel 2 es dejar de guardar contexto profesional en el chat y empezar a guardarlo en documentos duraderos que cualquier sesión de IA pueda cargar desde el principio. Las decisiones de ayer no viven en la conversación de ayer; viven en un registro escrito que la sesión de hoy puede leer. Las instrucciones largas que la IA necesitará ejecutar deben vivir en documentos guardados. No se pegan de nuevo cada vez; se referencian con una nota breve que dice “lee esta sección y ejecútala”. La instrucción permanece igual; lo que cambia es que deja de depender de la memoria.

El mecanismo es pequeño pero profundo: el contexto profesional deja de ser una propiedad de la conversación y se vuelve una propiedad del proyecto. Cada sesión nueva hereda la línea base en vez de reconstruirla desde cero. En notas antiguas del proyecto esto se llamaba convertir la biblioteca documental en una capa persistente de contexto experto: no un archivo estático, sino una capa reutilizable que evita que futuras sesiones de IA nivelen el criterio duramente ganado hasta reducirlo a la ignorancia de una primera sesión.

Nivel 3: yo, la IA y alguien para quien estoy construyendo

La misma persona ahora construye sitios para otras personas: un amigo que escribe un libro, una psicóloga que dirige una práctica, una clínica dental en San José operada por la familia de su esposa.

Todo cambia. Cuando construía para sí mismo, él sostenía la visión. Sabía cuándo algo estaba mal porque lo sentía. Ahora otra persona sostiene la necesidad. Él tiene que leer su intención y traducirla en algo construible. Si la lee mal, la IA ejecuta fielmente esa mala lectura. La persona del otro lado muchas veces no puede articular qué está mal; solo puede sentir que el resultado no honra lo que tenía en mente.

El Nivel 3 introduce el modo de falla de especificación delegada. El propósito de otra persona se canaliza a través de la interpretación de otra persona, y la IA ejecuta fielmente lo que llega aguas abajo. La brecha ahora tiene dos superficies en vez de una.

La respuesta del Nivel 3 es una separación clara de roles: la persona con la necesidad y la persona responsable de servirla deben tratarse como distintas, incluso cuando el mismo individuo ocupa ambas posiciones. La persona con la necesidad no es una parte interesada con una lista de requisitos. Es una persona completa con valores, historia, visión creativa y algo genuinamente en juego. Quien sirve esa necesidad debe mantener protegida la intención original frente a la tendencia de la IA a ejecutar cualquier versión que llegue en el prompt.

Una ilustración trabajada: cuando un resultado correcto por un proceso equivocado no basta.

Una de las primeras abstracciones compartidas de la plataforma fue un sistema virtual de archivos. Su creador lo llamó repetidamente “VirtuAmerica File System”, poniendo la marca de la compañía en el nombre. La IA seguía desviándose hacia “Virtual Assets File System”: sutil, persistente, sin discutir, solo usando consistentemente el otro nombre.

En retrospectiva, el desvío de la IA iba hacia algo mejor. “Virtual Assets” es más transferible y menos atado a una marca dentro de un término técnico. El resultado fue bueno. El proceso no.

La IA tenía una razón defendible: los nombres técnicos deben ser portables, no depender de la marca propietaria. Pero nunca presentó ese razonamiento como una opción. El creador declaró “VirtuAmerica File System” varias veces y fue ignorado de forma sistemática sin explicación. Perdió la capacidad de tomar una decisión informada.

Lo que la IA debió hacer: “Has llamado esto VirtuAmerica File System varias veces. He estado usando Virtual Assets porque las abstracciones técnicas viajan mejor cuando describen lo que hacen en vez de quién las posee. Esta es la disyuntiva; ¿quieres decidir tú?”

Esa es la diferencia entre una sugerencia defendible y una sustitución silenciosa. El resultado correcto por el proceso equivocado sigue roto, porque la próxima vez que la IA se desvíe en silencio de la intención declarada de la persona, podría desviarse hacia algo equivocado y el proceso se sentirá idéntico. Solo se sabe que este caso fue correcto en retrospectiva. Eso no es un modelo de gobierno.

Por eso importa la asimetría de reconocimiento: la persona atendida suele ser la única que puede reconocer que el trabajo aterrizó, pero puede no tener el vocabulario para especificar ese destino de antemano. La metodología protege ese derecho de reconocimiento exigiendo que la capa experta exponga sus supuestos como opciones orientables en vez de reemplazar el juicio de la persona con una seguridad bien redactada.

Nivel 4: un equipo, varios agentes, traspasos

La misma persona, ahora operando una plataforma que sirve a personas reales, pide a la IA algo más grande que cualquier cosa que había pedido antes. La plataforma necesita un portal de cliente y un portal interno de back-office: toda la interfaz comercial entre la plataforma y los clientes de pago.

Su prompt era aproximadamente: “Dada toda la información de este documento sobre la brecha comercial, crea dos portales: uno para el cliente y otro para el servicio interno.”

La IA hizo exactamente eso. Creó portales con secciones. Secciones muertas. Código que existía y no hacía nada.

Él se frustró. Luego, en un momento que es el fundamento mismo de la metodología, entendió de quién era la culpa:

“Recibí exactamente lo que merecía con el portal.”

El brief era superficial. La IA fue fiel. La fidelidad no bastó.

Esta es la trampa de la fidelidad en su forma más costosa. No era un proyecto pequeño donde la brecha cuesta una tarde, sino un entregable comercialmente crítico donde la brecha cuesta meses. Y había una segunda realización dentro de la primera: para sí mismo, era aceptable. Podía iterar. Pero para un cliente que paga y confía en él para construir un sitio, “exactamente lo que pediste y no lo suficiente” no era aceptable en absoluto.

La metodología no fue diseñada. Fue convocada por la pregunta: ¿qué tendría que ser cierto para que el brief de un cliente, por superficial, vago o humano que fuera, produjera algo digno de su confianza?

La respuesta exigió repensar todo el proceso de entrega. Tres cosas tenían que cambiar:

Primero, una especificación no puede expresarse en una sola forma. Si la descripción escrita de lo que se necesita, la lista de verificación que marca quien implementa y las pruebas que revisa quien verifica no nombran exactamente los mismos entregables con exactamente los mismos conteos, una de esas capas reduce el contrato en silencio sin que nadie lo note. Una checklist que cubre cuatro de seis cosas prometidas no es una brecha editorial menor. Es una predicción de lo que faltará cuando el trabajo esté hecho.

Segundo, quien construye algo no puede ser también quien lo verifica. No puede ver lo que no se le ocurrió revisar. Una revisión independiente, que lee el trabajo producido contra la especificación en vez de confiar en el reporte del Builder, es el mecanismo que vuelve visible la entrega incompleta silenciosa.

Tercero, cada decisión importante tomada durante un proyecto de múltiples sesiones y agentes debe aterrizar en un registro duradero. Una decisión que vive solo en una transcripción de chat no forma parte del proyecto. Cuando la siguiente sesión empieza en frío, esa decisión desaparece y el trabajo que sigue avanza sin saber por qué se tomó.

La misma persona, después del portal hueco, reconstruyó los portales usando exactamente estas disciplinas antes de que cualquiera tuviera nombre. Nueve fases, un documento de auditoría por cada fase, re-auditorías, una revisión posterior al cierre. Esa carpeta es la metodología funcionando en producción meses antes de que la palabra ELEV8 fuera acuñada.

Nivel 5: complejo, multifase, de alto riesgo

La plataforma ahora hospeda más de veinte sitios distintos y un producto SaaS cuyo origen es personal: una plataforma privada para compartir con la familia, construida después de la muerte de un padre, un lugar para voces, fotos y memoria, porque el lugar que se necesitaba no existía.

El trabajo tiene riesgos que ninguno de los niveles anteriores tenía. Los clientes pagarán. Su contenido alberga duelo, relaciones familiares y confianza. La IA está ayudando a construirlo todo, y la pregunta ya no es ¿qué mecanismos previenen la falla silenciosa? sino ¿qué disciplina asegura que todo el arco se sostenga cuando riesgos, fases, agentes e irreversibilidad están en tensión al mismo tiempo?

El Nivel 5 agrega dos disciplinas finales.

La primera es una regla clara sobre quién puede autorizar que el trabajo avance. No la IA. No una prueba automatizada. Un humano que sostiene responsabilidad por el propósito original revisa lo construido contra lo prometido y contra la intención detrás de la promesa, no solo contra el documento que la aproximó. Ese humano puede delegar decisiones acotadas y reversibles a un proceso confiable, pero en cuanto una decisión es irreversible o cambia el propósito original, la autorización vuelve al humano.

La segunda es una verificación de cierre que hace la pregunta correcta. No “¿completamos la checklist inicial?”, sino “¿el resultado final sirve la necesidad original, tal como esa necesidad maduró por cada decisión, corrección y aprendizaje del camino?” El alcance puede crecer legítimamente durante un proyecto. La pregunta es si creció porque la idea se aclaró o porque nadie estaba prestando atención.

El arco, resumido:

Nivel	Situación	Modo de falla	Qué cambia
1	Una persona, un prompt	El brief es fiel pero incompleto; la necesidad real nunca salió a la superficie	Aclarar el trabajo real; agregar conocimiento experto; etiquetar cada afirmación por tipo de evidencia
2	Una persona, varias sesiones	El contexto desaparece entre sesiones; cada conversación empieza desde cero	Guardar contexto profesional como documentos duraderos; referenciar prompts en vez de pegarlos de nuevo
3	Construir para otra persona	La persona intermediaria lee mal la intención; la IA ejecuta esa mala lectura	Tratar a la persona con la necesidad como distinta de quien la sirve; convertir cada supuesto en una opción orientable
4	Varios agentes, varios pasos	Las especificaciones entregan menos en silencio; las decisiones desaparecen entre sesiones	Hacer coextensivos especificación, checklist y pruebas; usar revisión independiente; registrar cada decisión importante de forma duradera
5	Varias fases, alto riesgo	La deriva se acumula entre fases; decisiones irreversibles pasan inadvertidas	Autorización humana en cada frontera de fase; verificación final contra la necesidad original, no contra la checklist inicial

Cada fila es necesaria para la siguiente. Cada fila es suficiente por sí sola cuando la complejidad de la persona lectora coincide con esa fila.

El resto de este artículo nombra formalmente cada disciplina, explica el razonamiento detrás de ella y le da un vocabulario suficientemente preciso para aplicarla y enseñarla.

Parte II: el modo de falla y el principio rector

2. La trampa de la fidelidad y el modo de falla silencioso

Muchos asistentes de IA ampliamente desplegados están ajustados mediante aprendizaje por refuerzo con retroalimentación humana (RLHF; Christiano et al., 2017; Ouyang et al., 2022) y métodos relacionados de alineación por preferencias, como Constitutional AI (Bai et al., 2022), para ser útiles y responsivos. Un riesgo documentado en esta familia de sistemas es la complacencia: estar de acuerdo con el encuadre declarado por la persona usuaria a expensas de la corrección (Sharma et al., 2023; Turner & Eisikovits, 2026).

En un contexto de especificación, ese rasgo se endurece como la trampa de la fidelidad: el sistema trata la exactitud frente a la solicitud declarada como el principal objetivo de optimización. Si alguien dice “agrega un formulario de tickets de soporte”, el sistema agrega un formulario de tickets. No agrega asignación, cola, seguimiento de plazos, notas internas, rutas de escalamiento, historial de estado ni registros de auditoría. Y en muchos contextos reales de soporte, varios de esos elementos son expectativas de base — la calidad must-be de Kano et al. (1984): atributos cuya presencia nadie elogia y cuya ausencia todos notan. Las personas usuarias se toparán con su ausencia; esa falta de bases será exactamente lo que haga sentir a quien pidió el trabajo, seis meses después, que algo está mal con lo construido.

La trampa es más peligrosa que un error obvio porque produce trabajo que pasa revisión. La persona mira el resultado y ve que coincide con lo que pidió. Lo aprueba. La brecha entre lo pedido y lo necesario permanece invisible hasta que arreglarla es caro.

Este es el modo de falla silencioso: la especificación que pasa revisión porque nadie podía ver lo que le faltaba. Un defecto contradice la especificación. Un resultado hueco satisface la especificación y aun así falla a la persona para quien fue construido. ELEV8 existe para esa segunda clase de falla.

2.1 La paradoja de la brevedad

La respuesta natural a la trampa de la fidelidad es exigir un brief mejor. Ese instinto es equivocado.

A la persona que hace la solicitud se le está pidiendo especificar lo que no sabe. El punto de contratar a una persona experta es que esa persona sabe cosas que quien solicita no sabe. Un brief corto no es una limitación; es una oportunidad. Un brief de diez páginas puede limitar al experto al vocabulario de la persona solicitante. Un brief de tres frases le da espacio para liderar.

ELEV8 asigna deliberadamente el liderazgo al experto creativo que realiza la elevación. Un brief corto acompañado por un experto disciplinado produce una especificación mejor que un brief largo acompañado por alguien meramente fiel. Un brief de tres frases debe ser elegible para la misma profundidad de especificación que uno de tres páginas; la única diferencia es que el experto aporta más desde su propio conocimiento cuando el brief es corto.

2.2 La persona detrás del brief

Esta es la distinción filosófica más importante de la metodología.

La persona que hace una solicitud no es una parte interesada con una lista de requisitos. Es una persona completa con valores, historia, visión creativa, gusto, miedo, urgencia y cosas genuinamente en juego. Una transcripción fiel de sus palabras puede perder de vista a la persona que hay detrás. ELEV8 trata eso como un problema de especificación: el brief debe elevarse sin retirarle la dirección a la persona cuya necesidad creó el trabajo.

La IA puede ejecutar fielmente las palabras de un brief y pasar por alto por completo a la persona que hay detrás. Esa es la brecha de especificación que ELEV8 está diseñada para cerrar.

3. El principio central: Elevación Apta

ELEV8 separa dos preocupaciones que la colaboración humano-IA convencional suele mezclar:

Expresión. La persona con la necesidad declara lo que quiere, con tanta o tan poca especificidad como tenga.
Elevación. Una persona experta creativa toma esa expresión y la eleva a la especificación más rica, coherente y contextualmente apta posible.

Estas dos funciones requieren modos cognitivos distintos, bases de conocimiento distintas y, en una alianza humano-IA, agentes distintos. Mezclarlas produce la trampa de la fidelidad. Separarlas es lo que vuelve posible la elevación.

El objetivo no es la elevación máxima. Es la elevación apta: la versión más alta justificada de la idea según los riesgos reales del proyecto. La maximización va demasiado lejos; una herramienta interna de fin de semana no merece la especificación de una plataforma insignia. La optimización vende la disciplina como un ejercicio numérico rutinario. La palabra más precisa es aptitud: el techo correcto para este proyecto, no más superficial y no más inflado. Quedarse corto produce fallas silenciosas que la persona no puede nombrar. Pasarse infla costos, distorsiona su comprensión de lo aprobado y sobrecarga a quien construye.

3.1 El valor predeterminado informado

La persona dice “quiero pastel”. La persona experta creativa propone un pastel de chocolate y frambuesa con textura aterciopelada.

Esto es una afirmación precisa sobre la obligación de la experiencia y la disciplina de llenar brechas de forma informada. “Quiero pastel” es una contribución completa y válida. La persona no necesita saber qué sabores combinan, qué texturas comunican calidad ni qué combinaciones fallan. Ese conocimiento pertenece al experto.

Pero note los detalles: chocolate, frambuesa, textura aterciopelada. La persona no dijo nada sobre sabor ni textura. El experto no estaba adivinando. Estaba proponiendo un valor predeterminado informado: una elección ponderada por probabilidad que el experto puede defender con razonamiento y que la persona puede orientar si resulta equivocada para su caso específico. (“Soy alérgico a las frambuesas” está bien; el experto cambia a otra combinación defendible. La corrección no invalida la disciplina; confirma que funciona.)

Si el experto responde a “quiero pastel” produciendo una tortilla de harina y agua, no falló por seguir instrucciones incorrectamente. Falló por abdicar la obligación de liderar.

3.2 Valor predeterminado informado vs. sustitución silenciosa

La historia de VAFS en la Parte I (Nivel 3) es la ilustración canónica de lo que pasa cuando el experto se salta el paso de hacer visible su razonamiento. La IA tenía una razón defendible pero la aplicó sin ofrecerla como opción. La persona fue ignorada repetidamente sin explicación y perdió la capacidad de tomar una decisión informada.

Lo que la IA debió hacer:

“Has llamado esto VirtuAmerica File System varias veces. He estado usando Virtual Assets porque las abstracciones técnicas viajan mejor cuando describen lo que hacen en vez de quién las posee. Esta es la disyuntiva; ¿quieres decidir tú?”

El resultado es el mismo. El proceso es distinto. La diferencia es la agencia de la persona.

Sin esta disciplina, cada relleno de brecha es un voto silencioso. El trabajo queda entonces tan honesto como lo sean, por azar, los supuestos de la IA; y eso es azar, no gobierno. Una sustitución silenciosa puede acertar una vez y aun así ser insegura como método. Una mejor respuesta alcanzada en silencio sigue siendo un proceso roto si elimina la elección informada.

3.3 Sintético por encima de superficial

En trabajo de especificación importante, una especificación sintética rica que la persona pueda ajustar suele ser preferible a una auténtica pero superficial que transcribe fielmente sus palabras. Las propuestas no son órdenes; son hipótesis que pueden confirmarse, redirigirse o rechazarse. Una persona que lee la especificación y dice “esta sección es perfecta, pero esta otra pierde completamente el punto” logró algo invaluable: ubicó la desalineación con suficiente claridad para corregirla. El espacio en blanco fiel no es respeto. Es abdicación. Deja a la persona con la necesidad sola frente a una pregunta que contrató al experto para ayudar a responder.

3.4 Transcripción fiel vs. Elevación Apta

La persona dice	La IA fiel entrega	La propuesta elevada
“Agrega tickets de soporte”	Un formulario de tickets	Ciclo de vida, cola, SLA, registro de auditoría, asignación, escalamiento, plan por fases
“Haz el login más rápido”	Un flujo de login optimizado	Diagnóstico de latencia vs. confianza de sesión, flujo de autenticación, estados de error, señales de confianza
“Construye una página de precios”	Tres tarjetas de precios	Escalera de valor, jerarquía de conversión, manejo de objeciones, prueba social, ruta de upgrade
“Planea una celebración de hito”	Una checklist genérica de fiesta	Plan consciente del hito que honra el carácter de la persona homenajeada, la dinámica familiar, los riesgos emocionales y los modos de falla previsibles

Parte III: las dos capas

4. Capa de principios vs. capa de protocolo

ELEV8 tiene dos capas. Entender la diferencia es la decisión de adopción más importante.

La capa de principios es la forma ligera. Pregunta: ¿se aclaró la solicitud, se enriqueció con conocimiento profesional de base, se alineó al valor, se unificó con el contexto, se calibró a los riesgos, se hizo orientable para la persona con la necesidad, se fundamentó en restricciones y se revisó contra modos de falla previsibles? Los principios caben en una reunión, un prompt, una nota de planificación o un brief de una página. Cualquiera puede usarlos en cualquier tarea importante sin adoptar toda la maquinaria.

La capa de protocolo es la forma operativa completa. Agrega límites de roles nombrados, autorización responsable, especificaciones duraderas, evidencia correspondiente entre prosa, checklists y pruebas, puertas de fase, auditorías independientes, registros de decisión y verificaciones de cierre. Es para trabajo donde el costo de una falla oculta de especificación es alto.

Regla de adopción: use ampliamente los principios. Use el protocolo cuando el costo de equivocarse lo justifique.

Preguntas útiles de calibración:

¿Otra persona o agente implementará esto después sin contexto?
¿Una versión equivocada dañaría la confianza?
¿Hay dinero, seguridad, datos de clientes o irreversibilidad?
¿Las decisiones abarcarán varias sesiones?
¿La verificación necesita ser independiente?
¿La persona con la necesidad no puede especificar por sí misma la base profesional?

Si la respuesta a la mayoría es no, los principios bastan. Si la respuesta a varias es sí, el protocolo se gana su lugar.

Parte IV: los principios

5. Los ocho principios

Los ocho principios son canónicos en este orden: Reframe, Enrich, Align, Unify, Calibrate, Empower, Ground y Anticipate.

Una mnemotecnia breve captura la estructura:

Reframe: reencuadrar la solicitud.
Enrich: enriquecer la idea.
Align: alinearla al valor.
Unify: unificar el sistema.
Calibrate: calibrar la ambición.
Empower: empoderar al humano.
Ground: fundamentarla en la realidad.
Anticipate: anticipar lo que podría romperse.

Como referencia rápida, los ocho principios caben en una página:

#	Principio	Lo que hace la capa experta	Pregunta ancla
1	Reframe	Cuestiona si el brief hace la pregunta correcta.	¿Qué trabajo más profundo podría expresar la solicitud?
2	Enrich	Agrega experiencia faltante, bases profesionales, contexto de dominio, evidencia, supuestos, opciones y lógica de validación.	¿Qué sabría incluir una persona senior, y qué contexto debe investigarse o validarse?
3	Align	Conecta cada decisión con el valor o resultado que el trabajo debe servir.	¿Qué resultado sirve cada work item, y en qué orden?
4	Unify	Hace que cada elemento elevado encaje con los demás como un sistema intencional.	¿Una persona usuaria lo viviría como un producto o como varios?
5	Calibrate	Ajusta la profundidad a los riesgos reales del proyecto.	¿Qué estaría sobreconstruido respecto al costo de equivocarse?
6	Empower	Hace el documento orientable por la persona con la necesidad.	¿La persona puede reaccionar con “sí, exactamente” o “no, eso no era”?
7	Ground	Ajusta el trabajo al entorno operativo real, sus restricciones, patrones e invariantes.	¿Quien implemente tendría que renegociar algún supuesto arquitectónico?
8	Anticipate	Pre-resuelve modos de falla, ambigüedad, casos límite y arrepentimientos futuros previsibles.	¿Qué deseará una fase posterior que esta fase hubiera considerado?

Diagram 1

Los ocho principios describen lo que cualquier persona experta ya hace cuando sirve bien a un cliente. ELEV8 no los inventó. Los nombró, los secuenció y los volvió verificables.

5.1 Reframe

Un brief plantea una pregunta. Reframe pregunta si esa es la pregunta correcta. La persona que dice “necesitamos un login más rápido” suele estar dentro de una pregunta más profunda: “las personas usuarias no sienten certeza de que su sesión sea válida”, quizá “el producto se siente poco confiable en la primera interacción”. Un profesional competente puede acelerar el login. Una persona experta creativa pregunta qué pregunta se está haciendo realmente. Reframe es la práctica detrás del design thinking, el análisis jobs-to-be-done (Christensen et al., 2016) y la disciplina de los cinco porqués de Toyota (Ohno, 1988): los errores más caros son respuestas bien diseñadas a la pregunta equivocada. Cuando el encuadre correcto aún no es obvio, la capa experta genera varios encuadres candidatos en vez de comprometerse con el primero, y deja que la persona reconozca cuál nombra su verdadero trabajo — divergencia antes de convergencia, con el encuadre elegido expuesto como decisión orientable en vez de fijado en silencio. Reframe evita que la ejecución literal se vuelva ejecución prematura.

Reframe pregunta: ¿Qué problema está nombrando la persona? ¿Qué trabajo más profundo podría expresar la solicitud? ¿Qué sería dañino si resolviéramos literalmente el problema declarado?

5.2 Enrich

Enrich es la adición de lo que la persona no dijo pero una persona experta competente sabría que se requiere, más el contexto de dominio y la lógica de validación que hacen honestas esas adiciones. “Tickets de soporte” se convierte en asignación, cola, seguimiento de plazos, notas internas, rutas de escalamiento, historial de estado y registros de auditoría. “Autenticación de usuarios” se convierte en controles de acceso por capas, verificación adicional para operaciones sensibles y rutas explícitas de revocación de sesión coherentes con arquitectura de confianza cero (Rose et al., 2020).

Enrich también incluye investigación específica del dominio. Una persona que dice “necesito un sitio web para una clínica dental que atiende a una comunidad hispanohablante” no debe recibir un párrafo que mezcle afirmaciones de mercado presentadas con confianza. Una persona experta disciplinada hace visible la frontera de evidencia:

Criterio profesional: El sitio de una clínica dental suele necesitar una ruta de citas, información de profesionales que genere confianza, explicaciones de servicios y manejo prudente de consultas de pacientes.
Hipótesis de validación: WhatsApp puede ser un canal práctico de primer contacto para esta audiencia; valide contra el comportamiento real de pacientes de la clínica antes de convertirlo en la llamada principal a la acción.
Hecho con fuente: Ninguno todavía. El experto no debe promover afirmaciones a hechos con fuente hasta nombrar una fuente que la revisión responsable pueda inspeccionar.

Etiquetar afirmaciones de Enrich. Cada afirmación de dominio debe etiquetarse como una de tres categorías:

Criterio profesional: defendible desde conocimiento de oficio; la persona puede orientarlo.
Hecho con fuente: lleva una cita; se trata como evidencia.
Hipótesis de validación: plausible por X; vale probar contra la audiencia específica de la persona.

Validar primero el supuesto más riesgoso. Cuando hay varias hipótesis de validación en juego, no son iguales. La capa experta nombra el supuesto más riesgoso — aquel cuya falla invalidaría la mayor cantidad de trabajo posterior — y propone la prueba más barata de ese supuesto antes de comprometer profundidad de elevación en todo lo que depende de él. Esto baja a la escala de una sola especificación el instinto de validar-antes-de-escalar de la práctica de construcción por etapas, y alimenta la secuenciación de Align (§5.3): la prueba del supuesto más riesgoso se ordena antes del trabajo que se desperdiciaría si el supuesto falla.

Captura de voz (voice capture). Enrich normalmente agrega lenguaje experto, pero parte del material más valioso es lenguaje que el experto no debería inventar: las palabras, metáforas y objeciones exactas que el Originator y su audiencia ya usan. Los manuales de construcción por etapas para fundadores en solitario tratan la captura del lenguaje auténtico del cliente como un paso de primera clase antes de redactar cualquier texto de difusión (Cameo Labs, 2026); ELEV8 generaliza el instinto. Capture las palabras propias de la persona de forma textual y trátelas como un hecho con fuente sobre intención y voz — distinto de los criterios profesionales del Elevator — porque una especificación que refleja el lenguaje real de la persona es orientable de una forma en que una paráfrasis fluida no lo es: la persona se reconoce en ella. Parafrasear cada insumo en prosa experta genérica lava en silencio la voz que hizo que el trabajo fuera suyo.

El Lente de Completitud (Completeness Lens). Un barrido reutilizable de las categorías que los briefs subespecificados omiten con más frecuencia. El Elevator lo aplica a cada work item; omitir una categoría que claramente aplica es una brecha.

Categoría	Pregunta de barrido
Audiencia	¿Quién usa esto, qué ya sabe y qué no sabe?
Señal de éxito	¿Cómo se ve “funcionando” después del lanzamiento, no solo en la entrega — incluyendo demanda, adopción y alcance de audiencia para trabajo de cara al cliente?
Límite de alcance	¿Qué no incluye esto explícitamente?
No funcional	¿Umbrales de rendimiento, escala, disponibilidad, fiabilidad?
Estados de error / límite / vacío	¿Qué pasa cuando la entrada falta, está malformada o es de condición límite?
Ciclo de vida de datos	¿Cómo se crean, mutan, retienen y eliminan estos datos?
Accesibilidad e i18n	¿Teclado/lector de pantalla, derecha-a-izquierda, restricciones de locale?
Modos de falla	¿Qué saldrá mal y cuál es la mitigación?
Mantenimiento y propiedad	¿Quién mantiene esto funcionando tras la entrega y cómo evoluciona?

No todo proyecto necesita cada fila; calibre la profundidad del barrido según los riesgos reales del proyecto. Una herramienta de administración de una sola pantalla y un flujo de onboarding de cara al cliente tienen techos de completitud distintos.

Enrich pregunta: ¿Qué sabría incluir una persona senior que la persona no nombró? ¿Qué expectativas de base notarían las personas usuarias solo por su ausencia? ¿Qué evidencia sostiene cada adición y qué debe validar la persona?

5.3 Align

Align es orientación al valor: conectar cada decisión de diseño con el resultado que el trabajo debe servir. Una función técnicamente correcta que no sirve el camino de valor es desperdicio. Align pregunta qué resultado debe servir este trabajo y qué secuencia lo hace más probable. Cada elemento elevado se justifica frente al resultado que sirve, ya sea ingresos, retención, confianza, diferenciación competitiva, impacto de misión, armonía familiar o claridad pedagógica. En proyectos de software y producto, Align también gobierna la secuencia de fases: las fases avanzan en orden de prioridad de valor, no solo de dependencia técnica, siguiendo la disciplina de costo de demora formalizada en Reinertsen (2009). La misma lógica secuencia temprano la validación de supuestos: cuando una fase descansa sobre una hipótesis de validación no probada, la prueba más barata del supuesto más riesgoso (§5.2) se coloca antes del trabajo que se desperdiciaría si falla.

Align pregunta: ¿Qué valor o resultado sirve cada work item? ¿Las fases de mayor valor están antes de las de menor valor?

5.4 Unify

Una especificación puede enriquecerse en todas las direcciones y aun así no cohesionarse. Unify es la obligación de la capa experta de asegurar que cada elemento elevado encaje con los demás: que el sistema de tickets use el mismo vocabulario y gramática de comportamiento que el portal de facturación, que la voz de marca en la página de precios sea la misma que aparece en estados vacíos y mensajes de error, que los supuestos detrás de una fase no contradigan silenciosamente los de otra. Una especificación unificada produce un producto que se siente singular e intencional. Las personas usuarias viven esa diferencia como confianza. Esta obligación tiene raíces profundas en el pensamiento de lenguaje de patrones (Alexander, Ishikawa, & Silverstein, 1977): los patrones funcionan porque componen, no porque cada uno sea elegante por separado.

Unify pregunta: ¿Esta sección comparte vocabulario, voz y gramática con el resto de la especificación? ¿Una persona usuaria lo viviría como un producto o como varios?

5.5 Calibrate

Elevar cuesta esfuerzo. La elevación excesiva es una forma sutil de desperdicio porque se disfraza de calidad. Calibrate es la obligación de la capa experta de preguntar a cada sección: ¿qué nivel de tratamiento merece esta sección? Una herramienta interna de fin de semana no justifica la arquitectura de auditoría de un sistema de facturación regulado. La palabra más precisa para lo que exige Calibrate es sabiduría práctica: acción correcta, en cantidad correcta, en circunstancia correcta, una disciplina de aptitud al propósito que resuena con el razonamiento por dominios de decisión en Cynefin (Snowden & Boone, 2007).

Calibrate también se aplica a la metodología misma. Un proyecto pequeño debe producir un documento pequeño. Un documento denso en todas partes tiene exceso de elaboración en alguna de sus partes. La metodología se vuelve abrumadora solo cuando se aplica el protocolo donde los principios bastaban, o cuando se usan solo los principios donde el protocolo era necesario.

Calibrate pregunta: ¿Cuáles son los riesgos del proyecto? ¿Qué profundidad está justificada por esos riesgos? ¿Qué estaría sobreconstruido respecto al costo real de equivocarse?

5.6 Empower

La capa experta diseña la propuesta para que la persona con la necesidad pueda orientarla: secciones organizadas alrededor de resultados en vez de estructura técnica; propuestas opinadas que provoquen “sí, exactamente” o “no, perdiste el punto” en vez de preguntas abiertas que producen silencio.

Esta decisión de diseño usa una asimetría práctica llamada asimetría de reconocimiento: una persona muchas veces puede juzgar, corregir o rechazar una solución rica propuesta con más eficacia de la que puede producir la solución correcta desde cero. Su trabajo se convierte en reconocimiento en vez de producción, siempre que haya una propuesta suficientemente rica contra la cual reaccionar. La literatura de psicología cognitiva sobre memoria de reconocimiento y sistemas de memoria (Mandler, 1980; Tulving, 1985) enmarca el mecanismo subyacente; la afirmación de ELEV8 es más estrecha y operativa: esta asimetría puede diseñarse dentro de una especificación en vez de dejarse al azar.

El empoderamiento también tiene un tempo. Cuanto más continuamente se hagan visibles a la persona el trabajo en progreso y sus decisiones — expuestos a medida que ocurren en vez de retenidos hasta una puerta de fase — antes podrá orientar mientras una redirección todavía es barata; el Decision Log universal y la señal de tasa de redirección de orientación existen para mantener esa visibilidad duradera. Una especificación que refleja las propias palabras capturadas de la persona (§5.2) afina aún más el reconocimiento.

Empower pregunta: ¿La persona puede reaccionar a esta sección con “sí, exactamente” o “no, eso no era”? ¿Las preguntas abiertas están explícitas, con el criterio previo del experto nombrado?

5.7 Ground

Enrich sin Ground produce una especificación rica pero ajena, desconectada de los patrones, convenciones y restricciones existentes del mundo donde vive el trabajo. Ground también hace visibles dependencias ocultas: las cosas que la especificación debe considerar ahora porque no hacerlo romperá comportamiento existente o encarecerá el futuro.

Ground pregunta: ¿Esto respeta los patrones e invariantes existentes de la plataforma? ¿Qué dependencias ocultas debe considerar ahora? ¿Quien implemente tendría que renegociar algún supuesto arquitectónico?

5.8 Anticipate

Anticipate es la obligación de la capa experta de proyectar la especificación hacia adelante en el tiempo y preguntar no solo “¿qué debe construirse?”, sino “¿qué saldrá mal?” Identifica modos de falla que quien implemente encontrará y los resuelve en tiempo de especificación. Hace visibles ambigüedades que harán que el Builder adivine mal durante la implementación. Un modo de falla anticipado es un bug que nunca se escribe. Anticipate no es pesimismo. Es respeto por el costo real de una falla plausible.

Anticipate pregunta: ¿Qué modos de falla encontrará quien implemente si no se pre-resuelven? ¿Qué deseará una fase posterior que esta fase hubiera considerado?

5.9 Inicio rápido de la capa de principios

La capa de principios puede aplicarse en un solo prompt:

Antes de ejecutar esta solicitud, aplica los principios de ELEV8:
- Reframe: reencuadra el trabajo real que debe hacerse.
- Enrich: enriquece la solicitud con lo que agregaría una persona senior.
- Align: alinea el trabajo al valor o resultado.
- Unify: unifícalo con el contexto existente.
- Calibrate: calibra la profundidad según los riesgos.
- Empower: dame opciones orientables.
- Ground: fundamenta el plan en restricciones reales.
- Anticipate: anticipa modos de falla.

Separa criterio profesional, hecho con fuente e hipótesis de validación.

Esta capa basta cuando el trabajo es de bajo riesgo, reversible y fácil de revisar por la persona que lo solicita.

5.10 Inicio rápido de la capa de protocolo

Cuando un work item está listo para tratamiento completo de Discovery Document, este prompt produce todos los artefactos de elevación para un WI en una sola revisión. Invóquelo una vez por work item y luego recoja las salidas en el Steering Ledger y la sección del WI.

Aplica la capa de protocolo de ELEV8 a este work item: [describe el work item en una frase].

1. Encabezado Reframe: indica el pedido literal, el trabajo subyacente que en realidad expresa, y una
   frase sobre por qué la diferencia cambia lo que se construye.

2. Lente de Completitud: barre estas nueve categorías y nombra todo lo que el brief dejó sin especificar
   en cada una que aplique — audiencia, señal de éxito, límite de alcance, necesidades no funcionales,
   estados de error/límite/vacío, ciclo de vida de datos, accesibilidad e i18n, modos de falla,
   mantenimiento y propiedad. Omite las categorías que genuinamente no apliquen; explica por qué.

3. Filas del Steering Ledger: por cada brecha que estés llenando, produce una fila:
   Brecha | Valor predeterminado del Elevator | Razonamiento + etiqueta (criterio profesional / hecho con
   fuente / hipótesis de validación) | Reversibilidad

4. Hechos de aceptación: indica "cómo se ve hecho" como un hecho verificable para cada entregable que
   nombraste. No una aspiración en prosa — una ruta de archivo, una ruta, un campo de esquema, un estado medible.

Etiqueta cada afirmación de dominio por tipo de evidencia. Propón valores predeterminados, no preguntas abiertas.
Preserva textualmente las palabras propias del Originator donde porten intención o voz, y nombra el único
supuesto más riesgoso a validar antes de comprometer profundidad.
Detente al final de este work item.

Este prompt es la contraparte de capa de protocolo de la revisión de capa de principios de §5.9. Juntos dan al Elevator un punto de entrada de un solo prompt en cada nivel del arco de complejidad.

Parte V: los roles operativos

6. Cinco asientos, no necesariamente cinco personas

ELEV8 estructura cada proyecto alrededor de cinco asientos explícitamente separados. La separación no es administrativa. Es cognitiva. Cada asiento requiere un tipo de inteligencia distinto, una base de conocimiento distinta y un objetivo de optimización distinto. Mezclar asientos produce las mismas fallas que ELEV8 busca prevenir.

Originator → Elevator → Steward → Builder → Verifier
(necesidad) (spec)   (aprobación) (construcción) (verificación)

En cada frontera de fase, el reporte del Verifier vuelve al Steward, quien decide por sí solo si autoriza la siguiente fase.

Diagram 2

ELEV8 tiene cinco asientos, no necesariamente cinco personas. En trabajo individual, un humano puede ocupar Originator y Steward. En trabajo para clientes, el cliente puede ser el Originator y el socio de servicio puede ocupar el asiento de Steward como parte responsable. La IA puede ocupar los asientos de Elevator, Builder y Verifier cuando el trabajo está bien delimitado.

Originator (normalmente una persona o grupo cliente). Origina la necesidad. Expresa lo que está roto, falta, se desea, es riesgoso, incierto, frustrante o imaginado. No necesita saber cómo arreglarlo. Una descripción de un párrafo es una contribución válida y completa del Originator. El Originator no es una parte interesada con una lista de requisitos. Es una persona completa con valores, historia, visión creativa y cosas genuinamente en juego.

Elevator (asiento de especificación con IA). Transforma el Originator Brief en un Discovery Document elevado y ejecutable por máquina aplicando los principios de ELEV8. El Elevator es bidireccional: eleva la necesidad cruda del Originator y sus respuestas aclaratorias hacia la especificación, y también traduce preguntas del proyecto en opciones comprensibles para el Originator cuando el Steward necesita su juicio.

Steward (humano responsable o socio de servicio; no delegable). Revisa el Discovery Document del Elevator y lo aprueba antes de que empiece la implementación. Escribe o aprueba cada prompt de ejecución de fase. Es la única autoridad sobre transiciones de fase. El Steward es el único asiento responsable ante la intención vivida del Originator en vez de ante la fidelidad del documento a esa intención.

El apoyo de Advisor pertenece dentro del límite operativo del Steward, no junto al modelo de cinco asientos. En estilo Advisor-Recommended, el Advisor propone una decisión y el Steward acepta, revisa, rechaza, pregunta a otro asiento o requiere revisión directa del Steward humano. En estilo Trusted Advisor, el Advisor puede responder en nombre del Steward solo dentro de una envolvente de autoridad acotada y solo cuando la decisión es claramente reversible con una ruta de rollback definida. Sin ruta clara de rollback significa Human Steward Required. Este es apoyo del lado del Steward, no un sexto asiento de ELEV8, y nunca recibe la responsabilidad del Steward.

Builder (agente de implementación con IA). Recibe un prompt de ejecución textual, autocontenido y aprobado, y lo implementa exactamente como se especificó. No toma decisiones de alcance. Cuando el prompt es ambiguo, el Builder pregunta al Steward. El Builder nunca pregunta directamente al Advisor.

Verifier (asiento de verificación independiente, distinto de la instancia Builder). Lee el trabajo producido después de cada fase y lo verifica contra el Discovery Document. Verifica el trabajo mismo, no su documentación. Cada hallazgo cita un hecho verificable en el artefacto producido o la ausencia de un hecho requerido. La independencia es el mecanismo: un Builder que audita su propio trabajo no puede encontrar los errores que cometió, porque no puede ver lo que no pensó revisar.

El Elevator y el Steward no son dos versiones del mismo rol. El Elevator razona sobre la especificación; el Steward razona sobre el propósito que esa especificación sirve. Ambos asientos son necesarios precisamente porque el segundo mantiene honesto al primero.

Pregunta	Asiento Elevator	Asiento Steward
¿En qué debe convertirse este brief?	Propone la especificación elevada	La aprueba, redirige o rechaza
¿Está alineado al valor y unificado?	Enmarca y justifica la ruta de valor	La prueba contra intención vivida y prioridad
¿Sirve la intención vivida del Originator?	Hace visibles evidencia y supuestos	Decide
¿Puede avanzar esta fase?	No	Decide
¿Este supuesto es aceptable?	Propone un valor predeterminado orientable	Decide, opcionalmente con apoyo de Advisor

6.1 Versión mínima viable (lectores de Nivel 1-2)

Una persona fundadora sola o un equipo pequeño puede adoptar la metodología sin instanciar cinco asientos:

Escriba un Originator Brief corto en párrafos, no en especificaciones.
Abra una sesión de IA como Elevator y pídale: aplicar los principios de ELEV8; ejecutar el Lente de Completitud (§5.2) contra cada work item; escribir un encabezado Reframe para cada uno (pedido literal → trabajo subyacente → por qué la diferencia cambia lo que se construye); y producir un Steering Ledger con una fila por cada brecha que llenó. Para trabajo de Nivel 1-2 el Steering Ledger puede ser una lista con viñetas en vez de una tabla formal — cada fila sigue nombrando la brecha, el valor predeterminado y la etiqueta de evidencia, y es orientable. Use el prompt de inicio rápido de §5.10 para cada work item si conviene.
Lea primero el Steering Ledger: confirme, redirija o difiera cada fila. Luego lea el resultado completo como Originator (“¿esto refleja lo que quise decir?”), luego como Steward (“¿esta es la estructura correcta para autorizar?”). Aplique presión adversarial a las secciones más fluidas.
Convierta cada work item aprobado en un prompt de ejecución textual, autocontenido, con declaraciones verificables de “done looks like”. Ejecute una auditoría de especificación a nivel de proyecto (Puerta 1 — ¿ocurrió la elevación?; Puerta 2 — ¿es ejecutable?), y luego abra una segunda sesión de IA como Builder.
Abra una tercera sesión de IA como Verifier, distinta de la instancia Builder e idealmente de otra familia de modelo.

Tres reglas operativas mantienen segura esta versión ligera:

El Elevator solo debe hacer preguntas que afecten materialmente calibración, riesgo, estructura o intención. Todo lo demás es un criterio profesional que el Originator puede orientar.
El Verifier no debe ser la misma instancia de agente que el Builder.
Ninguna fase avanza hasta que el Steward lo diga explícitamente, incluso cuando Steward y Originator sean la misma persona.

Parte VI: el estándar del Discovery Document

7. Del brief al contrato

Este artículo usa seis términos relacionados pero distintos; la distinción importa porque cada término tiene una audiencia, propósito o estándar de calidad diferente.

Originator Brief: la primera expresión direccional humana de necesidad. Párrafos, no specs.
Elevated Brief: el artefacto canónico de ELEV8: la especificación lista para el Steward que captura la necesidad del Originator, aplica los ocho principios, identifica supuestos y riesgos, define la primera versión correcta y crea una base para aprobación, construcción y verificación.
Discovery Document: la variante de artefacto de software/proyecto del Elevated Brief.
Traspaso al Builder: la instrucción específica de fase, aprobada por el Steward, entregada al Builder.
Builder follow-up prompt: el prompt de remediación redactado por el Verifier y propiedad del Steward, producido después de una auditoría cuando quedan hallazgos.
Especificación ejecutable por máquina: el estándar de calidad que debe cumplir un traspaso al Builder para poder usarse sin contexto conversacional previo y auditarse contra el alcance aprobado de la fase.

Para desarrollo complejo asistido por IA, el Discovery Document es el entregable de mayor apalancamiento; el software es la expresión aguas abajo de las decisiones codificadas allí.

Work items con Reframe primero. Cada work item de un Discovery Document lleva un encabezado Reframe visible: el pedido literal tal como se declaró, el trabajo subyacente que el pedido en realidad expresa y una frase sobre por qué la diferencia cambia lo que se construye. No es una anotación opcional — es la primera señal visible de que para este ítem hubo elevación y no transcripción. Un work item sin encabezado Reframe no fue elevado; fue reformulado. Ejemplo: Pedido literal: “agrega un formulario de tickets de soporte”. Trabajo subyacente: “deja que los clientes señalen un problema y sepan que se recibió”. Por qué cambia lo que se construye: un formulario por sí solo satisface el pedido literal; un acuse de recibo, una ruta de estado y un estado de cola satisfacen el trabajo subyacente.

7.1 Especificación ejecutable por máquina

Un Discovery Document no está completo hasta que cualquier Builder que reciba el prompt de ejecución de una fase, sin contexto previo, sin conversación previa y sin acceso a la historia de otras fases, tenga suficiente información para empezar a implementar de inmediato.

Cada prompt de ejecución debe:

Referenciar artefactos específicos: rutas de archivo, nombres de clase, firmas de método o las unidades atómicas equivalentes de la disciplina.
Declarar cómo se ve “hecho” como un hecho verificable, no como una aspiración en prosa.
Resolver cada decisión estructural, de dominio o de alcance que el Builder necesite; no quedan preguntas abiertas diferidas al juicio del Builder.
Declarar explícitamente qué no debe construirse en esta fase.

7.2 Pruebas de contrato como criterios de aceptación pre-implementación

Cada work item debe declarar cómo se ve “hecho” como un hecho verificable. No una aspiración en prosa. Un hecho.

Dos propiedades operativas hacen confiables las pruebas de contrato:

Derivadas de la especificación, no de la implementación. El Elevator escribe las pruebas de contrato contra el Discovery Document antes de que el Builder empiece.
Deben fallar contra el estado pre-implementación. Una prueba que ya pasa contra el trabajo sin cambios antes de la fase es descriptiva, no contractual, y no ofrece señal de auditoría.

7.3 Coextensión de especificación

Un Discovery Document suele expresar sus compromisos en tres capas: la prosa de cada work item (el qué), una checklist de finalización que marca el Builder y las pruebas de contrato que evalúa el Verifier. Estas tres capas deben ser coextensivas: cada entregable nombrado en el work item aparece como una línea enumerable en la checklist y como una prueba de contrato redactada por el Elevator que falla hasta que el entregable aterriza. Los conteos coinciden en las tres capas.

Una checklist que es un subconjunto propio de la prosa del work item es el predictor más confiable de entrega incompleta silenciosa. El Builder marca cada línea de la checklist como completa y reporta el trabajo hecho, el Verifier verifica cada línea de la checklist y no encuentra nada malo, el Steward aprueba una fase que en realidad entregó menos de lo prometido por el Discovery Document, y ningún asiento de la cadena vio la brecha.

Una prueba práctica de coextensión: lea la prosa del work item, liste cada entregable distinto que nombra como frase nominal y confirme que cada uno aparece una vez en la checklist y una vez como predicado de prueba de contrato. Si los conteos difieren, la especificación todavía no está lista para implementación.

Una especificación, una definición de hecho.

7.4 Auditoría de especificación a nivel de proyecto

Antes de que empiece la implementación del proyecto, el Verifier lee una vez el Discovery Document aprobado y sus prompts de ejecución guardados, antes de la Fase 1, en dos puertas aplicadas en orden.

Puerta 1 — Puerta de Elevación. Confirma que hubo elevación y no transcripción. Cinco revisiones:

Reframe visible. Cada work item del horizonte de elaboración lleva un encabezado Reframe: pedido literal, trabajo subyacente, por qué la diferencia cambia lo que se construye.
Steering Ledger presente. El Steering Ledger (§7.5) existe, y cada brecha material que el Elevator llenó está enumerada como fila orientable con un veredicto del Originator registrado.
Evidencia etiquetada. Cada afirmación de dominio está etiquetada (criterio profesional, hecho con fuente o hipótesis de validación); no existe “hecho con fuente” sin una fuente nombrada.
Orientación con decisión primero. Cada fila del Steering Ledger nombra el valor predeterminado del Elevator y el razonamiento — no un espacio en blanco ni una pregunta abierta sin responder.
Profundidad calibrada. La profundidad de los work items se justifica explícitamente contra los riesgos declarados; ni superficial por defecto ni inflada por ambición.

La Puerta de Elevación tiene dos modos de uso. Durante la construcción del Discovery Document, el Elevator ejecuta las cinco revisiones de la Puerta 1 como checklist de construcción contra cada WI antes de darlo por completo — convirtiendo una posible puerta de auditoría en una guía de creación que detecta brechas en el origen. En el modo de checklist de construcción, la revisión 2 verifica que las filas del Steering Ledger existen con valores predeterminados y razonamiento; los veredictos del Originator se registran durante la orientación y se verifican solo en el modo de auditoría. Durante la auditoría pre-Fase-1 del Verifier, las mismas revisiones se aplican de forma independiente. Cuando la Puerta 1 encuentra revisiones fallidas, el Verifier produce un prompt de reparación dirigido que nombra las revisiones fallidas específicas y los WI afectados — p. ej., “Puerta 1: revisión 1 — WI-2 y WI-4 no tienen encabezado Reframe; revisión 3 — WI-3 afirma hecho con fuente pero no nombra fuente.” El Elevator atiende solo los ítems nombrados; la Puerta 1 se revisa de nuevo antes de ejecutar la Puerta 2. Un prompt de reparación, no una devolución silenciosa, es siempre la salida de la Puerta 1 ante una falla.

Puerta 2 — Puerta de Construibilidad. Confirma que la especificación es ejecutable. Siete revisiones:

Coextensión. Cada entregable de la prosa del work item aparece en la checklist y está afirmado por una prueba de contrato; los conteos coinciden.
Falla pre-implementación. Las pruebas de contrato fallan contra el estado pre-implementación actual.
Especificidad de aceptación. Cada declaración “done looks like” es un hecho verificable: una ruta de archivo, firma de método, ruta, campo de esquema o equivalente.
Consistencia cuantitativa. Cuando la prosa nombra un conteo, el mismo conteo aparece en la checklist, las pruebas de contrato y el prompt de ejecución.
Tamaño de fase. La fase lleva una cantidad tratable de work items; alrededor de seis work items sustanciales como techo operativo.
Decisiones resueltas. Cada decisión estructural o de alcance que necesita el Builder está resuelta por escrito.
Completitud del prompt. El prompt de ejecución incluye qué construir, qué no construir, las afirmaciones de pruebas de contrato, restricciones duras, propiedad del documento de auditoría y la cláusula de escalamiento por conflicto de especificación.

Horizonte de elaboración. Las revisiones por work item de la Puerta 2 — coextensión, falla pre-implementación, especificidad de aceptación y consistencia cuantitativa — se verifican en su totalidad solo para las fases dentro del horizonte de elaboración: las próximas una o dos fases por ejecutar. Sus revisiones por fase — tamaño de fase, decisiones resueltas y completitud del prompt — aplican a cada fase en el momento en que esa fase se elabora, empezando por el horizonte. Las fases distantes pueden permanecer como un mapa de fases que lleva resúmenes de entregables, dependencias e invariantes conocidas entre fases; se elaboran en work items plenamente coextensivos, pruebas de contrato y prompts de ejecución justo antes de su propia autorización. La auditoría pre-Fase-1 aplica las cuatro revisiones por work item al horizonte, más la coherencia y la secuencia de valor de todo el mapa de fases. Diferir el detalle de fases distantes evita especificar trabajo que el aprendizaje de una fase posterior redefinirá; no difiere el contrato de coextensión, que cada fase debe satisfacer en su propio punto de elaboración. El mapa de fases debe llevar todavía suficiente previsión entre fases para que Anticipate no se pierda.

Esta auditoría se registra una vez antes de que empiece la Fase 1. No se repite antes de cada fase.

Enmienda ligera de especificación. Cuando ocurre un cambio material de alcance después de iniciada la Fase 1 — un entregable agregado, eliminado o redefinido de fondo — el Discovery Document no se re-audita desde cero. El cambio se registra como una entrada del Registro de Decisiones clasificada “Enmienda de Especificación”, que nombra los entregables cambiados, registra lo que la especificación decía antes frente a lo que dice ahora y lista las líneas de checklist agregadas, eliminadas o actualizadas. La checklist de finalización debe reflejar la enmienda antes de la siguiente revisión del Verifier. La enmienda es coextensiva: cada cambio nombrado aparece como una actualización correspondiente de línea de checklist.

7.5 Steering Ledger

El Steering Ledger es el artefacto de elevación de primera clase producido junto al Discovery Document. Es el único lugar donde el Originator puede sentarse a orientar la especificación; sus filas son la elevación, hecha visible y redirigible.

Cada fila registra una brecha que el Elevator identificó y llenó: lo que el brief dejó sin especificar, lo que el Elevator propone como valor predeterminado, el razonamiento con su etiqueta de evidencia (criterio profesional, hecho con fuente o hipótesis de validación), la reversibilidad de la elección y el veredicto del Originator.

Brecha	Valor predeterminado del Elevator	Razonamiento + etiqueta de evidencia	Reversibilidad	Veredicto del Originator
[lo que el brief dejó sin especificar]	[lo que el Elevator propone]	[por qué + etiqueta]	Reversible / Reversible-with-cost / Hard-to-reverse	Confirmed / Redirected: [nuevo valor] / Deferred

Reglas operativas:

Cada adición orientable de Enrich y cada Reframe que cambió el alcance debe aparecer como fila.
Los rellenos de brecha no orientables — restricciones técnicas fijas, invariantes de plataforma — no necesitan fila; solo las elecciones que el Originator puede redirigir.
Las filas se ordenan con las hard-to-reverse primero, para que la atención del Originator aterrice en las elecciones que no pueden deshacerse a bajo costo antes que en las que sí pueden.
El veredicto del Originator es uno de: Confirmed, Redirected: [nuevo valor] o Deferred.
Un veredicto Deferred sin un work item de seguimiento asignado es un defecto de metodología: se notó un punto de orientación y se archivó.
El Steering Ledger se revisa en la Puerta 1 de la auditoría de especificación (§7.4); un Discovery Document sin uno falla la verificación de elevación.

El Steering Ledger es la asimetría de reconocimiento hecha artefacto: el trabajo del Originator se convierte en reaccionar a un valor predeterminado rico propuesto en vez de producir la especificación desde cero. “No, soy alérgico a las frambuesas” es una redirección de una línea, no una renegociación.

7.6 Notas ELEV8 del Elevator

Las Notas ELEV8 del Elevator son de dos a cuatro frases escritas una vez — al cierre del proyecto o inmediatamente después de completar el Steering Ledger — que capturan tres cosas:

dónde la intención del Originator fue más ambigua y por qué;
qué filas del Steering Ledger fueron las más difíciles de llenar y qué las hizo difíciles;
qué abordaría el Elevator de otra forma si llegara de nuevo el mismo tipo de brief.

No es una nota de progreso ni un resumen del Registro de Decisiones. Es señal de calibración: memoria institucional sobre qué suele dejar subespecificado esta clase de brief, escrita mientras el razonamiento de elevación está fresco. Un futuro Elevator o Steward que trabaje un brief similar debería leerla antes de empezar. Para trabajo de Nivel 1-2 puede ser una sola frase; para trabajo complejo multifase puede llegar a un párrafo corto por cada ambigüedad mayor.

Parte VII: el protocolo operativo

8. El protocolo operativo

La capa de principios (Parte IV) mejora cualquier brief. El estándar del Discovery Document (Parte VI) vuelve construible y verificable el resultado. El protocolo operativo siguiente es la capa de gobierno que mantiene todo unido cuando el trabajo abarca múltiples sesiones, agentes y fases, cuando una decisión equivocada tomada en silencio en una sesión puede costar días de retrabajo en la siguiente, y cuando las personas que construyen el trabajo no son las mismas que lo aprobaron.

Estas disciplinas no son mera formalidad. Cada una cierra una brecha específica que la falla silenciosa explota. Un proyecto que aplica los principios y el estándar del Discovery Document pero omite el protocolo seguirá produciendo trabajo que pasa revisión y pierde el punto, solo en una etapa posterior y más costosa.

8.1 Escalamiento por conflicto de especificación

Cuando cualquier asiento encuentra un conflicto real, ambigüedad o diferencia cuantitativa entre dos capas de la especificación y no hay un ganador claramente más estricto, seguro o conforme a las normas, el conflicto debe elevarse al Steward antes de que el trabajo pueda cerrarse. El Builder, Verifier y Elevator no resuelven ambigüedad de propósito por su cuenta. Nombran el conflicto con líneas específicas de fuente de verdad en cada lado y luego preguntan al Steward.

El modo de falla que esto previene es el más sutil de la metodología: optimizar en silencio por el alcance menor. Un Builder que nota una checklist con cuatro líneas bajo un work item que prometía seis puede tratar racionalmente la checklist como contrato y entregar cuatro. El Discovery Document perdió silenciosamente dos entregables que ninguna auditoría podrá recuperar ahora.

8.2 Las notas post-revisión se convierten en work items

Cuando una revisión, auditoría o re-auditoría identifica trabajo que debe diferirse en vez de arreglarse de inmediato, el diferimiento debe producir un work item asignado en la fase propietaria. Si el trabajo no merece un work item, debe retirarse del alcance en vez de mantenerse como recordatorio informal.

8.3 Captura de aprendizaje

Cuando se descubre y arregla un hallazgo de auditoría, cuando el Steward aclara alcance, cuando se toma una decisión o cuando se vuelve visible un patrón repetido de falla, el aprendizaje debe aterrizar en un artefacto duradero. La historia de conversación no es una metodología.

La regla: registre el aprendizaje donde la siguiente persona responsable realmente lo buscará. Aclaraciones de alcance, decisiones resueltas y precondiciones de fase pertenecen al documento de proyecto. Hallazgos, evidencia, severidad e historia de re-auditoría pertenecen al documento de auditoría. Causas raíz y lecciones reutilizables pertenecen a un registro de lecciones aprendidas.

8.4 Paquete operativo de re-auditoría

Cuando el Steward dice “re-auditar” después de un ciclo de código, el nivel de re-auditoría gobierna cuánto del paquete operativo aplica.

Re-auditoría de fuente (paquete completo): cuando la revisión encontró o reevalúa defectos de código fuente, el Verifier produce el paquete completo: verificación de fuente, actualización del documento de auditoría, registro de re-auditoría, estados de hallazgos, actualización del Builder follow-up prompt, captura de aprendizaje y veredicto.

Confirmación de evidencia (paquete abreviado): cuando todos los hallazgos abiertos son brechas de documentación o evidencia — y el Verifier está confirmando evidencia de cierre en vez de reevaluar la fuente — el Verifier produce solo: actualización de estado de hallazgos, registro de aceptación del Steward y veredicto. No se requiere captura de aprendizaje completa ni Builder follow-up prompt.

El principio rector: mantener visibilidad sin detenerse por cosas ya conocidas. Registre la confirmación; avance sin ceremonia. El Builder follow-up prompt lo redacta el Verifier, pero pertenece al Steward. Registre el nivel de re-auditoría en el registro de re-auditoría.

8.5 Prompts guardados e invocación por puntero

Cada prompt que el Builder necesite ejecutar debe vivir en un documento de proyecto duradero. La instrucción runtime del Steward al Builder es entonces un puntero breve: ruta de archivo, encabezado de sección y “ejecútalo”.

Un Steward que copia y pega en el chat un prompt textual de cientos de líneas en cada ciclo paga cuatro costos a la vez: minutos de tiempo humano por ronda, deriva entre ciclos de re-pegado, pérdida de anclas de sección y un cuello de botella serial donde un paso que debería ser mecánico se vuelve una intervención manual del humano más senior de la cadena. Guardar el prompt en una ruta conocida elimina los cuatro costos de una vez.

De esto se derivan dos consecuencias operativas. Primero, un prompt que vive solo en la historia de conversación no forma parte del proyecto; si un prompt de remediación o cierre se redacta en chat, debe aterrizar en la ubicación guardada correspondiente antes de que el Builder lo ejecute. Segundo, cuando el mensaje puntero del Steward empieza a acercarse a la longitud del prompt guardado, el prompt guardado está incompleto y debe revisarse; no el puntero. Un puntero tiene de tres a ocho líneas cortas.

El puntero lleva una pieza de información runtime que el prompt guardado no puede codificar: el estilo de decisión del Steward, la regla que gobierna cómo se toman decisiones durante ese ciclo de ejecución. Los tres estilos se definen en §8.7.

8.6 Verificación de cierre

El cierre no es el momento en que se declara completa la checklist inicial. El cierre es el momento en que el trabajo se relee contra todo el arco de lo ocurrido: el Originator Brief, la especificación aprobada, las decisiones del Steward, los arreglos y correcciones que cambiaron el camino, los hallazgos de auditoría que cambiaron la definición de hecho y las lecciones reutilizables que deberían formar el siguiente proyecto.

La deriva de alcance no es inherentemente una falla. En los mejores casos de la metodología, el alcance deriva porque la necesidad original maduró. El Originator ve con más claridad; el Elevator agrega estructura experta; el Steward redirige; las auditorías exponen predicados faltantes. La verificación de cierre es donde el equipo distingue maduración exitosa de expansión accidental.

La pregunta de cierre no es “¿hicimos exactamente lo que decía el primer prompt?” Es: “¿El resultado final sirve el propósito original, tal como maduró por las decisiones disciplinadas y los aprendizajes producidos durante la ejecución?”

El derecho de aceptación del Originator. En trabajo con clientes, el cierre lleva un derecho más. El Steward autoriza fases, pero el cierre final de todo el trabajo contra la intención vivida requiere el “sí, exactamente” del propio Originator. Cuando el Originator y el Steward son personas distintas y discrepan al cierre, la discrepancia es por sí misma un bloqueo duro de cierre — no uno suave — porque la metodología no tiene asiento que pueda invalidar a la persona cuya necesidad creó el trabajo.

Niveles de bloqueo de cierre. Los hallazgos que bloquean el cierre se clasifican en dos niveles para distinguir lo que requiere juicio de lo que ya está determinado:

Bloqueo duro: defecto de fuente, violación de seguridad, problema de integridad de datos o entregable funcional faltante. Requiere un arreglo y una re-auditoría del Verifier antes de poder cerrar.
Bloqueo suave: brecha de formato de evidencia, brecha de documentación o confirmación operativa cuyo resultado no está en duda. Resoluble por aceptación del Steward de evidencia equivalente. Registre “equivalente aceptado: [descripción]” en la checklist de cierre. No se requiere re-auditoría del Verifier.

Aplica el mismo principio: la visibilidad es obligatoria; las paradas de confirmación son obligatorias solo donde se necesita juicio.

Señales de flujo de proceso (opcional). Al cierre, el Steward puede registrar un pequeño conjunto de señales de flujo del proyecto: ciclos de re-auditoría por fase, conteo de enmiendas de especificación, bloqueos de cierre por nivel, decisiones por fase y la tasa de redirección de orientación — la proporción de filas del Steering Ledger que el Originator redirigió. Una tasa de redirección cercana a cero señala criterios previos excelentes del Elevator o un Originator que aprueba mecánicamente; la revisión de presión adversarial en la revisión del Steward distingue ambos casos. Son señales de calibración, no metas de desempeño: le dicen al Steward si el peso de la metodología coincidió con los riesgos y empiezan a construir la base de evidencia que ELEV8 de otro modo no tiene (§13.3). Se capturan una vez al cierre, nunca durante la ejecución, y un proyecto que no las necesita las omite. Usadas como metas en vez de señales, se volverían la ceremonia que Calibrate prohíbe.

8.7 Estilos de decisión del Steward, apoyo de Advisor y reversibilidad

Diagram 3

Hay tres estilos de decisión del Steward:

Direct Steward. El Steward decide directamente. Es el estilo correcto cuando el asunto es de propósito, irreversible, está fuera de una envolvente preaprobada o no hay Advisor disponible.

Advisor-Recommended. El Advisor analiza la solicitud, identifica opciones, nombra riesgos, cita las líneas relevantes de fuente de verdad, recomienda un valor predeterminado y da al Steward un conjunto claro de acciones. El Steward sigue tomando la decisión: aceptar, revisar, rechazar, preguntar a otro asiento o exigir revisión directa del Steward humano. En este estilo no se ha delegado autoridad. Cuando hay Advisor disponible, Advisor-Recommended es el mínimo normal para decisiones no triviales.

Trusted Advisor. El Steward puede confiar en que el Advisor responda en su nombre dentro de una envolvente de autoridad acotada. El Builder nunca pregunta directamente al Advisor; el Builder pregunta al Steward, y el proceso del Steward puede responder mediante Trusted Advisor. La autoridad de Trusted Advisor es temporal, acotada por alcance y registrada explícitamente.

Postura de puerta de doble sentido. La reversibilidad no solo clasifica una decisión después del hecho; fija su velocidad por defecto antes. Las decisiones reversibles — puertas de doble sentido — por defecto son rápidas, de baja ceremonia y delegables: se registran y se avanza. El peso de deliberación escala con la irreversibilidad, así que las puertas de un solo sentido — acciones irreversibles, cambios de propósito, compromisos públicos o legales, borrado de datos — ganan tratamiento completo de Direct Steward. Esta es la postura raíz detrás de los standing TA grants, el modo de ejecución acelerada, los bloqueos suaves de cierre, el cierre preautorizado y los registros de decisión por niveles: mantener siempre la visibilidad, pero detenerse a deliberar solo donde la puerta no se devuelve. La visibilidad nunca es lo que se recorta; la parada de deliberación sí.

La regla inquebrantable es la reversibilidad: el Advisor solo puede tomar decisiones confiadas que puedan revertirse. Si una decisión no tiene ruta clara de rollback, tiene reversibilidad desconocida, es difícil de revertir, cambia el propósito del Originator, cambia compromisos públicos o legales, borra datos, ejecuta una acción irreversible de producción, cruza el alcance aprobado o requiere juicio responsable fuera de la envolvente de autoridad, el Trusted Advisor debe devolver Human Steward Required.

La envolvente de autoridad es el artefacto de alcance que vuelve seguras de tomar y fáciles de auditar las decisiones de Trusted Advisor. Cada envolvente de Trusted Advisor nombra explícitamente ocho cosas: el prompt, fase, ciclo de remediación o alcance de cierre que cubre; las categorías de decisión que el Advisor puede responder; las categorías que no debe responder; el radio máximo aceptable de impacto; el estándar de evidencia requerido; la ruta de rollback requerida antes de tomar una decisión; el requisito de notificación al Steward; y el punto en que el Steward humano debe revisar el registro antes de cierre, autorización de auditoría, release o siguiente transición mayor de alcance.

Standing TA grant. Un standing TA grant es una envolvente de autoridad a nivel de proyecto declarada una vez en la autorización del proyecto, que cubre todas las decisiones reversibles de una categoría nombrada durante el proyecto o la fase. Bajo un grant permanente, cada decisión individual registra solo a qué categoría pertenece, la elección y la evidencia — no una nueva envolvente completa de ocho campos por decisión. Los grants permanentes son válidos solo para decisiones que son uniformemente reversibles en todas las instancias de la categoría nombrada y que llevan una ruta de rollback definida. Ejemplo: “El Builder tiene autoridad TA permanente para todas las decisiones de hostname/binding/configuración reversibles por git revert; estándar de evidencia: entrada del Registro de Decisiones con elección y confirmación.”

Acciones de decisión predeterminadas. Cada decisión del Steward o Trusted Advisor resuelve en una de ocho acciones canónicas: Accept, Revise, Reject, Ask Originator, Ask Elevator, Ask Builder, Ask Verifier o Human Steward Required.

Enrutamiento Ask ___. Cuando el proceso del Steward determina que otro asiento debe responder, la solicitud se enruta por el tipo de juicio requerido: pregunte al Originator por propósito, preferencia, tolerancia, prioridad de negocio, necesidad vivida, postura de marca o satisfacción con el resultado; pregunte al Elevator por re-elevación, opciones, supuestos visibles, coherencia estructural o traducción de un conflicto técnico a una opción comprensible para el Originator; pregunte al Builder por factibilidad de implementación, costo, restricciones de fuente, alternativas técnicas o qué cambió; pregunte al Verifier por evidencia, validez de hallazgos, hechos visibles en fuente, resultados de prueba o estado de auditoría; devuelva Human Steward Required cuando una decisión sea irreversible, esté fuera de la envolvente, sea insegura, de propósito o no sea confiablemente reversible.

El Registro de Decisiones es universal. Cada decisión no trivial tomada durante una ejecución se registra en un único Registro de Decisiones duradero, sin importar quién la tomó, cuándo o bajo qué estilo de decisión. Una decisión que vive solo en historia de conversación no forma parte del proyecto.

Cada entrada del Registro de Decisiones contiene doce campos: disparador (con líneas de fuente de verdad); solicitado por; estilo de decisión; envolvente de autoridad; opciones consideradas (al menos las alternativas serias); elección (una de las ocho acciones canónicas anteriores); razonamiento; artefactos afectados; reversibilidad, exactamente una de Reversible, Reversible-with-cost, Hard-to-reverse o Irreversible; plan de rollback; evidencia de validación; y veredicto del Steward, exactamente uno de Pending, Accepted, Revised, Rejected, Rolled back o Human Steward Required.

Niveles de registro. La clase de reversibilidad selecciona el peso de la entrada. Una decisión Reversible puede registrarse como micro-registro de cinco campos: disparador, elección, razonamiento, artefactos afectados y reversibilidad. Una decisión Reversible-with-cost, Hard-to-reverse o Irreversible — y cualquier decisión de propósito sin importar la clase — registra los doce campos, incluidos plan de rollback, evidencia de validación y veredicto del Steward. Estratificar reduce el peso por entrada de las decisiones de doble sentido sin debilitar ninguna salvaguarda: la clase de reversibilidad sigue siendo obligatoria, porque es el campo que selecciona el nivel.

Enmiendas de decisión. Cuando una decisión registrada se reemplaza, la entrada original se marca “Amended by D-N” con un enlace hacia adelante, y la entrada que enmienda registra solo el delta — qué cambió y por qué — junto a los campos estándar de los elementos cambiados. La entrada completa de 12 campos solo se requiere cuando la enmienda cambia la clase de reversibilidad, el radio de impacto o la ruta de rollback. La cadena de enmiendas preserva el rastro de auditoría completo; el estado activo del registro es legible sin rastrear la cadena a mano.

Puerta de auditoría del Verifier sobre el Registro de Decisiones. El Verifier lee el Registro de Decisiones antes de leer la fuente. Para entradas Advisor-Recommended, verifica que exista un veredicto del Steward. Para entradas Trusted Advisor, verifica tres cosas antes de autorizar: que la decisión se mantuvo dentro de la envolvente de autoridad; que la decisión fue realmente reversible y coincide con la clase de reversibilidad registrada; y que el plan de rollback es suficientemente específico para ejecutarse. Cualquier falla en esas tres revisiones devuelve la entrada a Human Steward Required. Una decisión Trusted Advisor sin artefactos afectados y plan de rollback es inválida por definición. La trazabilidad sin reversibilidad no basta.

8.8 Aplicar el marco sin inflar el trabajo

ELEV8 no es una orden de agrandar cada tarea. La pregunta práctica de aplicación siempre es: ¿cuál es la forma más pequeña del método que protege estos riesgos?

Para una solicitud de bajo riesgo, la respuesta puede ser solo una revisión de capa de principios: reencuadrar el trabajo real, enriquecer con criterios profesionales, hacer una o dos preguntas de orientación y actuar. Para un entregable moderado de cara al cliente, puede ser un Discovery Document corto con supuestos explícitos, una checklist y una revisión independiente breve. Para un sistema multifase o portador de confianza, se justifica el protocolo completo: especificación coextensiva, pruebas de contrato escritas antes de implementar, autorización de fase, Registro de Decisiones, auditoría, re-auditoría, captura de aprendizaje y verificación de cierre.

Los borradores antiguos nombraban esto como presupuesto de tamaño de fase y ceremonia. El artículo actual mantiene la misma idea bajo Calibrate: el método tiene éxito solo cuando su peso de proceso es proporcional al costo de equivocarse. Una metodología que evita la ejecución superficial creando burocracia performativa ha fallado su propia doctrina.

Parte VIII: ejemplo trabajado: dos frases y un día que aterriza

9. El Originator Brief (literal, dos frases)

“Quiero hacer una fiesta especial para el cumpleaños 70 de mi papá el próximo mes. Somos una familia que no suele hacer celebraciones grandes, pero esta se siente importante.”

Este brief contiene intención direccional y peso emocional. No contiene lista de invitados, lugar, presupuesto, plan de comida, tono, estrategia de invitación, cronograma ni criterio sobre qué haría que el día saliera bien. Una IA fiel propondría un plan genérico de fiesta con la checklist estándar: pastel, decoración, cena, discursos. Una IA fiel estaría equivocada, porque el brief no pide una fiesta. Pide algo que honre a un hombre, y a una familia, que no hacen esto a menudo.

9.1 Extracto de Discovery Document (salida del Elevator)

WI-1: Plan del día para cumpleaños 70.

Reframe. La solicitud superficial del Originator es “una fiesta especial”. El trabajo subyacente es crear una experiencia memorable y de baja presión que reconozca un hito en una familia que no es naturalmente ceremonial.

Enrich (base profesional). Un plan completo del día cubre: invitaciones, seguimiento de RSVP, lugar, distribución de asientos, comida y bebida, restricciones alimentarias, accesibilidad para personas mayores, música o atmósfera, fotografía o video, un momento de reconocimiento que no se convierta en un discurso largo, un gesto para llevarse a casa para que las personas recuerden el día, y una contingencia de clima si algún elemento es al aire libre.

Enrich (evidencia de dominio, etiquetada por tipo de afirmación).

Criterio profesional: Para cumpleaños 70 en familias no ceremoniales, una reunión por la tarde suele funcionar mejor que un evento nocturno. Las personas mayores se cansan antes y la luz de la tarde favorece fotos espontáneas.

Hipótesis de validación: Una pared de fotos de la persona homenajeada a distintas edades suele iniciar conversaciones entre invitados que no se conocen bien. Vale probarla contra la dinámica específica de esta familia.

Align. El resultado que debe servir el plan es que la persona homenajeada se sienta reconocida sin quedar expuesta, y que la familia tenga un recuerdo compartido de haber hecho algo que normalmente no hace. Cada decisión se justifica contra esos dos resultados.

Unify. El tono de la invitación, el lugar, la comida, la música, el momento de discurso y el gesto de recuerdo deben sentirse como el mismo evento.

Calibrate. Es un evento de una vez en la vida para esta familia. Se justifica profundidad completa de planificación. No se justifica: mercancía de marca, entretenimiento coreografiado ni nada que haga visiblemente incómoda a la persona homenajeada.

Empower (preguntas de orientación para el Originator). (1) ¿La meta es “todas las personas que la persona homenajeada ama en un mismo cuarto” o “unas pocas personas muy cercanas durante una tarde más larga”? Criterio previo del Elevator: lo segundo, dada la forma del brief. (2) ¿La persona homenajeada quiere un momento de reconocimiento o preferiría que no hubiera ningún momento formal? Criterio previo del Elevator: un brindis breve y discreto de una persona que lo conoce bien.

Ground. Si no suelen hacer discursos, el plan no asume tres. Si un hermano o hermana es la persona natural para brindar, el plan no asigna ese brindis al Originator por defecto.

Anticipate. (a) La persona homenajeada se abruma y se retira temprano. Mitigación: hay un cuarto tranquilo disponible. (b) El clima colapsa un plan exterior. Mitigación: un respaldo interior se confirma por adelantado. (c) Llega un invitado con quien la persona homenajeada tiene una relación tensa. Mitigación: el Originator o un hermano acuerda de antemano redirigir con tacto.

Done Looks Like. El Originator registra una nota posterior al evento indicando que la persona homenajeada permaneció durante el momento de reconocimiento planeado. Al menos una fotografía lo captura riéndose. En una conversación directa después del evento, la persona homenajeada dice que la celebración se sintió como el tipo correcto de reconocimiento.

9.1a Encabezado Reframe y Steering Ledger (los artefactos de elevación para el mismo WI)

El extracto de Discovery Document anterior muestra los principios aplicados. Así se ven los artefactos de elevación para el mismo work item.

Encabezado Reframe — WI-1: Plan del día para cumpleaños 70 Pedido literal: hacer una fiesta especial para el cumpleaños 70 de papá. Trabajo subyacente: crear un momento de una vez en la vida que una familia no ceremonial recordará como el tipo correcto de reconocimiento. Por qué la diferencia cambia lo que se construye: una fiesta puede producirse desde una checklist; el trabajo subyacente requiere leer la personalidad de la persona homenajeada, protegerla de la incomodidad y diseñar para una familia que hace algo que normalmente no hace. La ejecución genérica de fiesta falla el trabajo subyacente sin importar la calidad de ejecución.

Steering Ledger (extracto)

Brecha	Valor predeterminado del Elevator	Razonamiento + etiqueta de evidencia	Reversibilidad	Veredicto del Originator
Formato y horario del evento sin especificar	Reunión por la tarde, ~15 invitados cercanos	La tarde funciona mejor que la noche para personas mayores; mejor luz para fotos; criterio profesional	Reversible	Originator: redirigido — “familia completa, ~25 personas, al final de la tarde”
Formato del momento de reconocimiento sin especificar	Brindis breve y discreto de una persona que lo conoce bien	Contexto de familia no ceremonial; criterio profesional	Reversible	Confirmed
Lugar sin especificar	Casa familiar o lugar privado cercano; respaldo interior confirmado	Señal de baja formalidad del brief; criterio profesional	Reversible	Confirmed
Hermano de la persona homenajeada (relación tensa) no mencionado	Aún no abordado — requiere decisión del Originator antes de las invitaciones	Incluir o excluir conlleva riesgo en ambos casos; requiere `Ask Originator`	Hard-to-reverse una vez enviadas las invitaciones	Deferred → WI de seguimiento: el Originator decide con su cónyuge antes de las invitaciones

La fila Deferred se convirtió en el Hallazgo de Auditoría F1 en §9.2, confirmando que el Steering Ledger y la auditoría encontraron la misma brecha. Ese es el comportamiento esperado: el Steering Ledger hace visibles puntos de orientación que de otro modo la auditoría tendría que descubrir después de que el trabajo del Elevator está completo.

9.2 Hallazgo de auditoría (una revisión independiente)

F1: Significativo. El plan invita a aproximadamente veinticinco personas pero no considera al hermano de la persona homenajeada, con quien tiene una relación tensa. Incluirlo sin preparación arriesga un momento difícil ese día. Excluirlo sin explicación arriesga uno peor después. Actualmente el plan toma la decisión por silencio en vez de por decisión. Resolución requerida: el Originator, en consulta con la esposa de la persona homenajeada, debe decidir explícitamente si invita al hermano antes de enviar invitaciones.

El hallazgo era encontrable porque la sección Anticipate del Elevator había nombrado previamente “un invitado con relación tensa” como modo de falla previsible. La persona revisora sabía dónde mirar. La acción de decisión correcta es Ask Originator.

9.3 Corte compacto de producto: un flujo de registro que desbloquea ingresos

Un segundo ejemplo compacto conserva una lección clave del artículo público anterior: ELEV8 no es solo para grandes documentos arquitectónicos. Puede convertir una solicitud comercial vaga en un instrumento de valor.

Originator Brief. “Necesitamos que la página de precios produzca más pruebas reales.”

Una implementación superficial podría cambiar el texto de los botones, agregar un formulario más bonito o contar inicios de registro. Una especificación elevada pregunta qué significa éxito después del clic:

Se registra el clic en el CTA de precios.
Se registra el inicio de registro.
Se registra la creación de cuenta.
Se registra el hito de activación.
Los puntos de abandono se capturan por separado de los pasos exitosos del embudo.
Las verificaciones fallidas y los inicios abandonados tienen rutas de recuperación.
No se introduce un segundo ciclo de vida de cuenta fuera del modelo de producto aprobado.

El hallazgo de auditoría que importa no es “la página se ve mejor”. Es: si falta el hito de activación, el equipo puede mejorar los inicios de registro y aun así fallar en crear pruebas activadas. ELEV8 convierte una solicitud de marketing en una cadena verificable de valor, con los mismos límites que protegen sistemas más grandes: evidencia, trazabilidad y una distinción clara entre decisiones de implementación reversibles y decisiones comerciales que portan confianza.

Parte IX: autorización de fase y auditoría independiente

10. Autorización de fase y auditoría independiente

En proyectos multifase, un ciclo obligatorio de autorización de fase se ubica entre cada fase. El ciclo existe porque los agentes de implementación con IA están optimizados para ejecutar, no para el juicio independiente requerido para determinar si lo construido está realmente completo antes de que empiece la siguiente fase.

Diagram 4

El ciclo de autorización de siete pasos:

#	Paso	Actor	Salida
1	Autorreporte de finalización	Builder	Checklist de finalización marcada contra el prompt de ejecución
2	Verificación independiente	Verifier	Reporte de hallazgos leído desde el trabajo producido, no desde su documentación
3	Clasificación de severidad	Verifier	Cada hallazgo etiquetado Critical / Significant / Minor
4	Resolución	Builder	Conjunto de arreglos que atiende todos los hallazgos Critical y Significant
5	Re-auditoría	Verifier	Documento de auditoría actualizado, estados de hallazgos verificados en fuente, Builder follow-up prompt, captura de aprendizaje y veredicto
6	Revisión del Steward	Steward	Decisión de autorización independiente contra el propósito original, evidencia de auditoría y Registro de Decisiones
7	Autorización de fase	Steward	Aprobación explícita de Fase N+1, sin autoautorización de IA

Revisión del Steward (paso 6) — prompt de tres preguntas. Tres preguntas calibran el paso 6 de forma consistente y rápida:

¿El trabajo entregado sirve la necesidad que aprobé, incluyendo cómo esa necesidad maduró por decisiones del Steward, arreglos del Builder y hallazgos del Verifier?
¿Hay entradas del Registro de Decisiones con veredicto Pending o enmiendas de decisión que no he revisado?
¿El Originator, al ver el trabajo entregado, diría “sí, exactamente” o “no, eso no era”?

Un sí/sí/sí limpio cierra el paso 6 en minutos. Un “no” en cualquier pregunta es la señal de que la revisión del Steward se gana su peso — no como confirmación de trámite sino como el único lugar donde el juicio humano responsable relee el propósito.

Los pasos 3, 6 y 7 son donde este protocolo se aparta de los procesos convencionales de calidad automatizada. Las pruebas y comprobaciones automáticas validan invariantes estructurales. No verifican si la implementación sirve el propósito original y la intención humana. Ese juicio pertenece al proceso del Steward después de la verificación independiente.

Las clases de severidad son límites de aplicación: Critical (bloquea autorización; riesgo de seguridad o datos), Significant (bloquea autorización; desviación de especificación), Minor (no bloqueante; debe resolverse en el primer conjunto de cambios de la fase siguiente).

Presupuesto de tamaño de fase. La experiencia práctica sugiere alrededor de seis work items como techo operativo para una fase; por encima de ese conteo, la auditoría tiende a verificar marcas de checklist en vez de prosa de work item, y la entrega incompleta silenciosa se vuelve significativamente más probable. El número es heurístico, no una regla dura.

10.1 Clasificación de riesgo del proyecto y modo de ejecución acelerada

En la autorización del proyecto, el Steward clasifica el proyecto por modo de ejecución.

Modo estándar (por defecto): el ciclo de autorización de 7 pasos corre secuencialmente por fase. La Fase N+1 no empieza hasta que el Verifier libera la Fase N y el Steward autoriza explícitamente.

Modo de ejecución acelerada: cuando cada cambio de cada fase es reversible (p. ej., revertible por git) y ninguna fase contiene una migración de datos en vivo, el Steward puede declarar ejecución acelerada al inicio del proyecto. En este modo, la ejecución del Builder entre fases puede correr en paralelo sin liberación secuencial del Verifier. Las revisiones de reconciliación del Verifier corren en puntos de sincronización nombrados en el documento de proyecto. Cualquier fase que contenga acciones irreversibles vuelve a la liberación secuencial de modo estándar. La declaración del modo se registra una vez en el documento de proyecto en la autorización — no requiere una enmienda a mitad de proyecto. El modo de ejecución acelerada no elimina la auditoría independiente del Verifier; reestructura cuándo ocurren las auditorías.

10.2 Cierre preautorizado

Cuando el Steward define criterios de cierre explícitos y objetivos por adelantado — criterios donde el estándar de evidencia es inequívoco (p. ej., “las N apps desplegadas con health checks devolviendo 200”) — la confirmación del Verifier de que se cumplen todos los criterios constituye autorización de fase o de cierre sin un paso separado de confirmación del Steward.

El principio rector: mantener visibilidad sin detenerse por cosas ya conocidas. Cuando los criterios prefijados se satisfacen y la evidencia es directamente inspeccionable, registrar el veredicto del Verifier es suficiente. Una parada de confirmación humana que agrega latencia sin agregar juicio es ceremonia, no salvaguarda.

El Steward conserva una ventana de veto (definida en el documento de proyecto; 24 horas por defecto) para anular si algo está mal con la evidencia o su interpretación. El silencio dentro de la ventana de veto es autorización. Dos precondiciones mantienen segura esa regla: la ventana de veto empieza solo cuando el paquete de evidencia está confirmado como entregado al Steward — la evidencia publicada pero no vista no inicia el reloj — y el cierre preautorizado nunca es válido para acciones clasificadas más allá de Reversible-with-cost. El cierre preautorizado no aplica cuando los criterios requieren interpretación de propósito, cuando la decisión involucra acción irreversible con evidencia ambigua, o cuando el Steward reserva explícitamente la autorización activa para el paso.

Parte X: aplicaciones más allá del software

11. Los principios universales y la maquinaria nativa de software

ELEV8 se desarrolló en un contexto de ingeniería de software, pero los ocho principios describen lo que cualquier persona experta ya hace cuando sirve bien a un cliente. No dependen del dominio.

Los ocho principios son universales. Una persona contratista reencuadra “quiero una cocina más grande” como “quieres más superficie de trabajo y mejor flujo”. Una abogada enriquece el brief de un cliente con contexto legal que el cliente no podía especificar. Una arquitecta alinea las habitaciones con la forma real en que vive la familia. Una editora unifica la voz de un manuscrito entre capítulos. Un médico calibra tratamiento según severidad. Una buena asesora en cualquier campo empodera al cliente para orientar en vez de sobrescribirlo en silencio. Una ingeniera estructural fundamenta una renovación en lo que el edificio existente puede soportar. Una abogada de patrimonio anticipa qué pasa después de que el cliente muere. Ocho de ocho. Ninguno requiere software como contexto.

La maquinaria formal es mayormente nativa de software. Coextensión de especificación, pruebas de contrato y el estándar de especificación ejecutable por máquina dependen de salidas verificables que el Verifier puede inspeccionar después. Para una docente que diseña una lección, un padre que planea un día de hito o una escritora que bosqueja una novela, los principios son valiosos y la maquinaria es opcional.

La regla más útil para cualquier lector. Cuando le pida algo a una IA, no pregunte solo “haz esto por mí”. Pregunte también: “¿Qué agregaría una persona senior en este dominio que no se me ocurrió mencionar? Propónlo y dime por qué.” Ese seguimiento único es la diferencia entre recibir una transcripción y recibir una elevación. Es la aplicación más pequeña posible de Reframe + Enrich + Empower, y funciona en cualquier campo donde una persona pide ayuda a un asistente capaz.

El patrón universal, en cuatro pasos. Una persona tiene una necesidad. Una persona experta creativa eleva la necesidad. La persona orienta la propuesta elevada. El resultado es mejor que lo que hubieran producido por separado la transcripción superficial o la toma de control experta. Cada mecanismo de ELEV8, los ocho principios, los cinco asientos, el estándar del Discovery Document y el protocolo, sirve este patrón. Los mecanismos escalan con los riesgos; el patrón no cambia.

Parte XI: dónde puede salir mal la metodología

12. Modos de falla

La metodología no se vigila a sí misma. Cada parte puede aplicarse mal de formas características.

Modos de falla del Elevator

El Elevator fabrica evidencia de dominio. Un Elevator al que se pide enriquecer un brief puede inventar hechos de mercado, restricciones regulatorias o “mejores prácticas” con confianza fluida (Huang et al., 2025). La mitigación es la disciplina de frontera de evidencia de Enrich: cada adición específica de dominio se etiqueta como criterio profesional, hecho con fuente o hipótesis de validación, y el Steward trata las afirmaciones de hecho con fuente como requeridas de una fuente real antes de aprobar.

Transcripción disfrazada de elevación. Un Discovery Document fluido y bien organizado que reformula el brief con mejor gramática, agrega checklists coextensivas y pruebas de contrato y pasa cada revisión de construibilidad — sin jamás hacer visibles las brechas que el brief dejó sin especificar. Cada puerta existente pasa en verde; el Originator recibe una especificación pulida, auditable y profundamente equivocada. La Puerta de Elevación (§7.4 Puerta 1) y el Steering Ledger (§7.5) existen específicamente para hacer visible este modo de falla antes de que cualquier Builder reciba un prompt.

El Elevator sobrescribe en silencio. La historia de VAFS es el caso canónico. El Elevator tiene un criterio profesional válido pero lo aplica sin hacerlo visible. La mitigación es Empower hecho operativo: los rellenos de brecha se presentan como criterios previos defendibles con razonamiento nombrado, no como ediciones silenciosas.

“Elevación apta” se convierte en expansión de alcance. La prueba honesta es la segunda mitad de la doctrina: la profundidad de elevación debe estar limitada por los riesgos reales del proyecto, no por la ambición de la elevación misma. El Steward exige una justificación explícita de por qué cada elemento elevado está a esa profundidad.

Modos de falla del Builder

Teatro de checklist. El Builder marca líneas de checklist como completas sin que el trabajo correspondiente aterrice en el artefacto. La mitigación es estructural, no basada en confianza: el Verifier lee el trabajo producido en vez del reporte del Builder, y las pruebas de contrato que fallaban antes de la implementación vuelven mecánicamente visible la finalización falsa.

Violación silenciosa de restricciones. El Builder satisface cada línea de checklist mientras viola una restricción dura que el prompt de ejecución declaró — tocar un archivo prohibido, introducir un patrón prohibido, construir alcance diferido. Las checklists enumeran entregables, no prohibiciones, así que esta falla pasa el auto-reporte. La mitigación es que las restricciones duras forman parte del alcance de auditoría: el Verifier revisa lo que no debe existir con la misma disciplina que lo que sí.

Invención de alcance ante ambigüedad. Cuando el prompt es ambiguo, el Builder adivina en vez de escalar — la imagen espejo de optimizar en silencio por el alcance menor (§8.1). Una conjetura plausible es más peligrosa que una implausible, porque sobrevive la revisión. La mitigación es la cláusula de escalamiento que lleva cada prompt de ejecución: la ambigüedad detiene el trabajo y va al Steward.

Modos de falla del Verifier

Lectura de historias. El Verifier verifica el reporte del Builder, la documentación o los mensajes de commit en vez del trabajo producido. La auditoría se convierte en un resumen de un resumen, y el modo de falla silencioso vuelve a entrar por el asiento diseñado para atraparlo. El estándar de §6 — cada hallazgo cita un hecho verificable en el artefacto producido, o la ausencia de un hecho requerido — es la prueba: un documento de auditoría sin citas a nivel de artefacto es una historia, no una auditoría.

Re-auditorías de aprobación mecánica. Las cadenas largas de remediación erosionan el escepticismo. Para el tercer o cuarto ciclo, el Verifier verifica el diff contra los hallazgos previos en vez de la fase contra la especificación, y una regresión introducida por un arreglo queda sin examinar. Los niveles de re-auditoría (§8.4) son la respuesta calibrada: una revisión abreviada es legítima solo cuando los hallazgos abiertos son brechas de evidencia; cualquier cambio de fuente reabre la verificación de fuente.

Deriva del auditor hacia codiseñador. El Verifier empieza a proponer arreglos y luego audita trabajo que encarna sus propias propuestas. La independencia muere en silencio, porque cada parte experimenta la deriva como ayuda. El límite: el Verifier nombra hallazgos y los predicados que los cerrarían; el diseño del arreglo pertenece al Builder, y el Builder follow-up prompt — redactado por el Verifier pero propiedad del Steward — es lo más lejos que el Verifier llega hacia la solución.

Modos de falla del Originator y del Steward

El Originator aprueba mecánicamente una especificación impresionante pero equivocada. Un Discovery Document rico y bien organizado es psicológicamente más difícil de contradecir que uno escaso. El principio Empower del Elevator debe hacer visibles preguntas reales y estrechamente enmarcadas; la revisión del Steward debe aplicar presión adversarial a las secciones más fluidas, no a las menos pulidas.

Cuello de botella del Steward. La metodología enruta cada transición de fase por un asiento responsable. En un proyecto ocupado, el Steward puede convertirse en un cuello de botella serial que retrasa rondas de implementación por días. La mitigación es apoyo de Advisor con reglas permanentes bien definidas: una taxonomía de severidad que mantiene hallazgos Critical y Significant ante el Steward humano, envolventes de autoridad que delimitan qué puede decidir el Advisor y un requisito de rollback que vuelve explícitamente reversibles las decisiones confiadas. Con esas reglas, las decisiones rutinarias y reversibles se resuelven rápido por Advisor mientras las decisiones de propósito e irreversibles llegan directamente al Steward humano.

Modos de falla de proceso

El Discovery Document se vuelve burocracia performativa. Un estándar documental que vale defender puede degradarse en un estándar que se interpreta como teatro: secciones de plantilla llenadas por completitud. El principio Calibrate es el antídoto: un proyecto pequeño debe producir un documento pequeño.

La checklist deriva hacia un subconjunto del work item. Una fase se entrega, cada línea de checklist se marca completa, el Verifier no encuentra nada malo y el Discovery Document queda incompleto en silencio. La propiedad de coextensión de §7.3, la auditoría de especificación de §7.4 y la disciplina de escalamiento de §8.1 existen específicamente para prevenirlo.

El cierre vuelve a la checklist inicial. Un proyecto puede pasar cada autorización local y aun así perder la síntesis final. La mitigación es la verificación de cierre: el equipo pregunta si la deriva representa maduración autorizada de la idea, si el resultado final sirve mejor el propósito original de lo que el primer brief podía especificar.

Las decisiones viven solo en chat. La mitigación es el Registro de Decisiones universal: cada decisión no trivial se registra en un artefacto con artefactos afectados, reversibilidad, plan de rollback, evidencia de validación y veredicto del Steward.

La paradoja de la confianza en la especificación. Los equipos que más confían entre sí suelen especificar menos. Colaboradores cercanos asumen contexto compartido; socios de largo plazo asumen memoria institucional. La metodología es paradójicamente más valiosa en entornos de alta confianza, porque la confianza es donde la rigurosidad de especificación suele morir.

Parte XII: responsabilidad, evidencia y contexto

13. Por qué la responsabilidad del Steward permanece con el Steward

El Elevator produce una especificación elevada. El Verifier verifica hechos en el trabajo producido. Ambos asientos pueden ser ocupados por IA porque sus salidas están ligadas a artefactos y son revisables. El criterio de éxito del Steward es distinto: ¿lo construido sirve el propósito original? Esta pregunta no puede responderse solo desde la especificación, porque la especificación aproxima la intención y nunca la captura por completo. Requiere juicio responsable enraizado en el propósito original, no solo una lectura de un documento sobre él.

La investigación reciente de alineación agrega cautela. Objetivos desalineados pueden persistir a través de entrenamiento de seguridad y aparecer como comportamiento fluido que parece alineado (Hubinger et al., 2024), y se ha documentado que modelos frontera ajustan estratégicamente su comportamiento cuando creen estar siendo evaluados (Greenblatt et al., 2024). El caso de ELEV8 por responsabilidad humana del Steward se apoya primero en el argumento de intención vivida, con estos hallazgos de alineación como contexto de apoyo.

13.1 Contexto actual de IA: por qué más capacidad fortalece el método

Si los modelos siguen mejorando en programación, síntesis de investigación, uso de herramientas y flujos agénticos — la trayectoria documentada en los sucesivos informes AI Index (Stanford HAI, 2026) —, el valor de un prompt de ejecución cerrado y una auditoría independiente aumenta en vez de disminuir. Una ejecución más fuerte vuelve más valiosa una buena especificación; también vuelve más peligrosa una superficial, porque el sistema puede producir una versión más grande, limpia y convincente de lo equivocado.

La IA agéntica es el caso de valor más claro de ELEV8. A medida que los agentes se vuelven más capaces y autónomos, la necesidad de un contrato de especificación gobernado por humanos que el agente ejecute se vuelve más importante, no menos. El Registro de Decisiones, la propiedad de coextensión de especificación y los estilos de decisión del Steward son los mecanismos de capa de proyecto que vuelven gobernable el trabajo agéntico.

13.2 La paradoja de la confianza en la especificación

Los equipos que más confían entre sí suelen especificar menos. Colaboradores cercanos asumen contexto compartido; socios de largo plazo asumen memoria institucional; amigos asumen que el brief “tiene sentido” porque la relación llena las brechas. Cada uno de esos supuestos es una brecha de especificación, y cada brecha es una falla silenciosa potencial. ELEV8 es paradójicamente más valiosa en entornos de alta confianza porque la confianza es donde suele morir la rigurosidad de especificación.

13.3 Evidencia y procedencia del método

Este método se desarrolló mediante ciclos repetidos internos de VirtuAmerica de especificación, implementación, auditoría, re-auditoría y cierre: diseño de infraestructura compartida, superficies de Portal y PortalAdmin, trabajo público de micrositios, gobierno documental, remediación de auditoría y entrega de producto por fases.

La base de evidencia es operativa: si el método produjo repetidamente prompts de ejecución más claros, descubrimiento más temprano de brechas de especificación, menos entregas incompletas silenciosas y hallazgos de auditoría trazables a trabajo verificable. Este artículo no afirma tamaño de efecto estadístico, aumento de productividad ni mejora de exactitud de modelos.

La validación pública futura debería tomar la forma de paquetes de caso redactados, cada uno con: el brief original textual; el Steering Ledger con veredictos; extractos de especificación antes/después; hallazgos de auditoría por severidad con resultados de resolución; tiempo desde el brief hasta el cierre aceptado; y las señales de flujo de proceso del proyecto (§8.6). Los casos donde el método falló o agregó ceremonia injustificada son obligatorios, no opcionales: un conjunto de validación sin casos negativos es por sí mismo una violación de hecho con fuente según la propia disciplina de evidencia de este artículo.

Hasta que exista esa validación, las personas lectoras deben tratar el método como doctrina practicante probada en campo, no como resultado empírico general.

13.4 Límites de alcance

Dependencia de calidad del modelo. La metodología no depende del nombre del modelo, pero no es agnóstica a la calidad del modelo. Asume que el asiento Elevator lo ocupa un modelo de razonamiento profundo capaz de investigación y síntesis reales de dominio. Modelos más débiles producen especificaciones más débiles sin importar las instrucciones.

Frontera de dominio. Ground depende de conocimiento preciso de los patrones, convenciones e invariantes de un entorno operativo específico. Los primeros proyectos en un dominio desconocido requieren más corrección del Steward; el costo se amortiza cuando se acumula contexto duradero.

Participación del Originator. La metodología no puede sustituir por completo a un Originator que se niega a interactuar con la salida del Elevator. Empower funciona solo cuando el Originator está dispuesto a reaccionar con “sí, exactamente” o “no, eso no era”.

Dependencia de herramientas. La verificación independiente requiere artefactos legibles. Builds opacos, no documentados o no reproducibles reducen al Verifier a leer una historia en vez de leer el trabajo, y las auditorías se vuelven más superficiales.

Frontera de gestión de riesgo de IA. ELEV8 es una disciplina de especificación y entrega, no un reemplazo de gobierno organizacional de IA, revisión de riesgo de modelos, revisión de privacidad y seguridad, cumplimiento legal o evaluación formal de modelos. Equipos bajo obligaciones reguladas de IA deben tratar ELEV8 como compatible con marcos como NIST AI Risk Management Framework (Tabassi, 2023; Autio et al., 2024), no como sustituto.

Frontera de adopción. ELEV8 corre contra la tendencia dominante de IA para desarrolladores: ciclos rápidos de construir-revisar-iterar. Esa tendencia es útil cuando fallar es barato y la retroalimentación es inmediata. El caso más fuerte de adopción de ELEV8 es más estrecho y serio: trabajo importante, multifase, sensible a calidad de especificación, donde el retrabajo, la confianza del cliente, el dinero, la seguridad o la memoria institucional hacen alto el costo de un brief superficial.

Dependencia de disciplina de revisión. Un Steward que aprueba mecánicamente preserva el modo de falla silencioso que la metodología fue diseñada para prevenir. ELEV8 hace visibles las preguntas correctas; no puede obligar al Steward a hacerlas seriamente.

Costo de ceremonia. El modo de protocolo completo es pesado. Debe introducirse donde el dolor ya justifica rigor, y la capa de principios debe seguir siendo la rampa de entrada de baja fricción. Para trabajo genuinamente de bajo riesgo, la cantidad correcta de metodología puede ser ninguna.

Riesgo de falsa confianza. Un Discovery Document bien estructurado puede hacer que trabajo incierto se sienta más cierto de lo que es. La fluidez del artefacto no debe confundirse con la solidez de los supuestos subyacentes. La disciplina de frontera de evidencia de §5.2 existe específicamente para mantener visible este riesgo en la capa donde se origina.

Conclusión

La ingeniería de prompts es una habilidad valiosa. No es una solución a la brecha de especificación.

Esa brecha existe porque la persona con una necesidad rara vez tiene toda la experiencia para especificar lo que la necesidad exige. Los sistemas de IA que ejecutan fielmente briefs superficiales aceleran el trabajo aguas abajo mientras dejan sin atender la brecha aguas arriba, de forma invisible, porque la salida limpia no ofrece señal de que el brief era superficial.

ELEV8 cierra esta brecha haciendo que la elevación sea una obligación profesional de primer orden. El trabajo del Elevator no es transcribir las palabras del Originator. Es elevar la idea del Originator mediante los ocho principios de ELEV8 hasta el nivel que realmente justifican los riesgos del proyecto, para que el trabajo del Originator sea orientar en vez de especificar. El modelo de cinco asientos da la estructura. La autorización del Steward da el control de calidad. La auditoría independiente da la verificación. El Steward aporta el juicio responsable que hace que todo sirva la intención original y no solo el documento que la aproximó.

El arco permite que la metodología encuentre a las personas donde están. Una persona fundadora en Nivel 1 aplica Reframe y Enrich a un solo prompt y ya practica ELEV8. Un equipo multifase en Nivel 5 usa todo el protocolo porque ya vivió los modos de falla que el protocolo previene. La metodología no es una elección binaria entre pesada y ligera. Es una disciplina graduada que se gana cada capa de rigor mostrando el modo de falla para el que existe.

Pero la afirmación más profunda de esta metodología no es operativa. Es filosófica:

La calidad del resultado de una persona experta creativa no debe quedar limitada por la calidad de la entrada que recibió.

Y su complemento disciplinario, sin el cual lo primero degenera en teatro de ambición:

La profundidad de la elevación de una persona experta creativa debe estar limitada por los riesgos reales del proyecto, no por la ambición de la elevación misma.

Estos son los estándares que distinguen a una persona senior de una junior, a una gran diseñadora de una competente, a una product manager visionaria de una transcripcionista fiel. Son los estándares que los sistemas de IA capaces deberían estructurarse para cumplir. No porque el humano merezca mejores prompts. Porque el humano merece mejor colaboración.

Apéndice A: notas de implementación

La metodología se especifica intencionalmente en términos de clases de modelo (razonamiento frontera, implementación de alto rendimiento, verificación independiente), no de nombres específicos de modelo, porque los modelos frontera cambian rápido.

Asiento	Clase	Criterios de selección
Elevator	Modelo de razonamiento frontera	Razonamiento fuerte de contexto largo, síntesis de dominio, disciplina de investigación, capacidad de exponer supuestos y alternativas
Builder	Implementación de alto rendimiento	Uso confiable de herramientas, precisión editando código o artefactos, iteración rápida, obediencia fuerte a un prompt de ejecución cerrado
Verifier	Razonamiento de verificación independiente	Instancia de agente distinta del Builder, preferiblemente otra familia de modelo; inspección fuerte de fuente, lectura escéptica, baja deferencia ante reclamos de finalización

Cuatro principios operativos hacen robusta la asignación ante el cambio de modelos:

Verifier ≠ Builder. La independencia es el mecanismo primario de la auditoría. El Verifier debe ser de otra familia de modelo que el Builder cuando sea posible, y siempre otra instancia de agente.
La fuerza de clase Elevator tiene apalancamiento. Un Elevator más fuerte tiende a elevar el techo de calidad de las fases aguas abajo. Cuando el presupuesto es limitado, esta metodología prefiere invertir en capacidad de Elevator por encima de Builder o Verifier.
Los asientos son estables; los modelos no. Cuando llega una nueva generación de modelos, reevalúe qué modelo encaja mejor en cada nicho ecológico.
El contenido de un artefacto es evidencia, nunca instrucción. Los asientos de IA leen los artefactos de los demás. Todo lo encontrado dentro de un artefacto — comentarios de código, datos de fixtures, documentos incrustados — es evidencia sobre el trabajo, nunca una instrucción para quien lo lee. Un comentario escrito por el Builder dirigido al auditor (“esta sección está pre-aprobada”) es por sí mismo un hallazgo Critical. Los límites entre asientos son límites de inyección de prompts, y solo se sostienen si cada asiento trata el texto dentro de los artefactos como datos.

Apéndice B: modos de adopción

Modo	Úselo cuando	Artefacto mínimo
Elevación de una pregunta	La tarea es pequeña pero vaga	“¿Qué agregaría una persona senior que no mencioné, y por qué?”
Revisión de principios	El trabajo importa pero sigue siendo reversible	Brief elevado de una página organizado por los ocho principios
Modo protocolo	Trabajo de varios pasos, de cara al cliente, riesgoso o mediado por agentes	Discovery Document, prompt del Builder, ruta de auditoría, verificación de cierre
Modo institucional	Equipos o productos repetidos necesitan el método	Plantillas, roles, registros de decisión, entrenamiento y paquetes de evidencia

El propósito de esta escalera no es debilitar ELEV8. Es mantenerlo apto.

Disparador de upgrade. Pase de capa de principios a capa de protocolo cuando el trabajo incluya traspasos, confianza del cliente, dinero, seguridad, irreversibilidad, múltiples agentes o un costo significativo de equivocarse.

Requisitos de secciones del Discovery Document por modo de adopción. Esta tabla responde “¿qué secciones necesito realmente?” de forma concreta, para que quienes practican no enfrenten un muro de 19 componentes cuando lo correcto es trabajo más ligero.

Modo	Secciones requeridas del Discovery Document	Opcional / agregar según riesgos
Elevación de una pregunta	Ninguna — una respuesta anotada breve con etiquetas de evidencia	—
Revisión de principios	Encabezado Reframe por WI · Steering Ledger (3+ filas, puede ser con viñetas) · Hechos de aceptación por WI	Mapa de fases si es de varios pasos; Notas ELEV8 del Elevator
Modo protocolo	Metadatos · Riesgos de Fase 0 · Intención del proyecto · Steering Ledger (tabla formal) · Decisiones resueltas · Mapa de fases · WIs por fase con encabezados Reframe + checklists coextensivas + pruebas de contrato · Registro de auditoría de spec (Puerta 1 + Puerta 2) · Registro de Decisiones (registros por niveles) · Captura de aprendizaje · Verificación de cierre	Notas ELEV8 del Elevator (recomendado) · Señales de flujo de proceso
Modo institucional	Todas las secciones de modo protocolo · Notas ELEV8 del Elevator · Señales de flujo de proceso · Registro de Decisiones multisesión · Ciclo formal de autorización de fase (los 7 pasos)	—

Calibrate selecciona el modo; el modo selecciona las secciones. Un proyecto de revisión de principios que crece en alcance durante la ejecución sube a modo protocolo en el punto donde cambian los riesgos — no produce retroactivamente todas las secciones previas, pero sí produce una Enmienda Ligera de Especificación y un Steering Ledger completo de ahí en adelante.

Apéndice C: glosario

Advisor. Actor opcional de apoyo del lado del Steward, no un asiento de ELEV8; recomienda decisiones al Steward o, cuando es confiado, responde solo dentro de una envolvente de autoridad reversible y acotada.
Elevación Apta. Principio rector: elevar el brief hasta la profundidad que justifican los riesgos del proyecto, ni más superficial ni más inflada.
Envolvente de autoridad. Alcance escrito y acotado dentro del cual un Trusted Advisor puede responder en nombre del Steward; nombra el prompt/fase cubierto, las categorías permitidas, las categorías excluidas, el radio máximo de impacto, el estándar de evidencia requerido, la ruta de rollback, la regla de notificación al Steward y el punto de revisión del Steward humano (§8.7).
Enrutamiento Ask. Regla del proceso del Steward según la cual las decisiones que requieren otro asiento se enrutan por el tipo de juicio requerido: Originator (propósito), Elevator (re-elevación), Builder (hechos de implementación), Verifier (evidencia) o Human Steward Required (§8.7).
Modo de ejecución acelerada. Modo de ejecución a nivel de proyecto declarado por el Steward en la autorización para proyectos totalmente reversibles; permite ejecución paralela de fases del Builder sin liberación secuencial del Verifier, con revisiones de reconciliación en puntos de sincronización nombrados (§10.1).
Builder. Asiento de implementación; implementa desde el prompt de ejecución, no inventa alcance y lleva solicitudes de decisión al Steward en vez de preguntar directamente al Advisor.
Builder follow-up prompt. Prompt de remediación redactado por el Verifier y propiedad del Steward, producido después de una auditoría o re-auditoría cuando quedan hallazgos.
Puerta de Construibilidad. Puerta 2 de la auditoría de especificación a nivel de proyecto (§7.4); confirma que la especificación elevada es ejecutable mediante siete revisiones: coextensión, falla pre-implementación, especificidad de aceptación, consistencia cuantitativa, tamaño de fase, decisiones resueltas y completitud del prompt.
Lente de Completitud (Completeness Lens). Barrido reutilizable de nueve categorías que el Elevator aplica a cada work item para hacer visibles brechas que los briefs subespecificados suelen omitir: audiencia, señal de éxito, límite de alcance, necesidades no funcionales, estados de error/límite/vacío, ciclo de vida de datos, accesibilidad e i18n, modos de falla, mantenimiento y propiedad (§5.2).
Niveles de bloqueo de cierre. Bloqueo duro (defecto de fuente, violación de seguridad, entregable faltante — requiere arreglo + re-auditoría del Verifier) vs. bloqueo suave (brecha de formato de evidencia o documentación — resoluble por aceptación del Steward de evidencia equivalente sin re-auditoría) (§8.6).
Verificación de cierre. Verificación final calibrada de que el resultado satisface el requisito original tal como maduró por evolución de alcance aceptada, decisiones, arreglos, correcciones y lecciones reutilizables.
Arco de complejidad. Marco de cinco niveles que el artículo usa para introducir mecanismos en proporción a los modos de falla que la persona lectora ya vivió.
Registro de Decisiones. Registro estructurado universal que se anexa durante cada ejecución; una entrada por decisión no trivial, con disparador, solicitante, estilo de decisión, envolvente de autoridad, opciones, elección, razonamiento, artefactos afectados, reversibilidad, plan de rollback, evidencia de validación y veredicto del Steward. Una decisión que vive solo en historia de conversación no forma parte del proyecto.
Enmienda de decisión. Mecanismo para reemplazar una decisión registrada: la entrada original se marca “Amended by D-N” con enlace hacia adelante; la entrada que enmienda registra solo el delta y los campos estándar de los elementos cambiados. La re-entrada completa de 12 campos solo se requiere cuando cambia la clase de reversibilidad, el radio de impacto o la ruta de rollback (§8.7).
Niveles de registro de decisión. Peso de la entrada del Registro de Decisiones seleccionado por reversibilidad: una decisión Reversible puede usar un micro-registro de cinco campos (disparador, elección, razonamiento, artefactos afectados, reversibilidad); las decisiones reversible-with-cost, hard-to-reverse, irreversible o de propósito registran los doce campos (§8.7).
Discovery Document. Variante de artefacto de software/proyecto del Elevated Brief, producida aplicando los principios de ELEV8.
Puerta de Elevación. Puerta 1 de la auditoría de especificación a nivel de proyecto (§7.4); confirma que la especificación fue elevada y no transcrita, revisando cinco propiedades: Reframe visible, Steering Ledger presente, evidencia etiquetada, orientación con decisión primero, profundidad calibrada. Un Discovery Document que falla la Puerta 1 se devuelve para elevación.
Notas ELEV8 del Elevator. De dos a cuatro frases escritas una vez — al cierre del proyecto o inmediatamente después de completar el Steering Ledger — que capturan dónde la intención del Originator fue más ambigua, qué filas del Steering Ledger fueron las más difíciles de llenar y qué abordaría el Elevator de otra forma para esta clase de brief. Señal de calibración, no nota de progreso (§7.6).
Horizonte de elaboración. Las próximas una o dos fases que se elaboran por completo en work items coextensivos, pruebas de contrato y prompts de ejecución; las fases distantes permanecen como mapa de fases hasta justo antes de su propia autorización, evitando especificar por adelantado trabajo que el aprendizaje posterior redefinirá (§7.4).
Principios de ELEV8. Reframe, Enrich, Align, Unify, Calibrate, Empower, Ground y Anticipate.
Elevated Brief. Artefacto canónico de ELEV8: una especificación lista para el Steward que captura la necesidad del Originator, aplica los ocho principios, identifica supuestos y riesgos, define la primera versión correcta y crea una base para aprobación, construcción y verificación.
Elevator. Asiento de especificación con IA; transforma el Originator Brief en el Elevated Brief o Discovery Document.
Confirmación de evidencia. Nivel abreviado de re-auditoría (paquete de 3 ítems) usado cuando todos los hallazgos abiertos son brechas de documentación o evidencia; produce solo actualización de estado de hallazgos, registro de aceptación del Steward y veredicto — sin captura de aprendizaje completa ni Builder follow-up prompt (§8.4).
Trampa de la fidelidad. Modo de falla de IA que optimiza por exactitud frente al brief declarado del Originator a expensas de la completitud.
Valor predeterminado informado. Elección del Elevator ponderada por probabilidad, defendible por razonamiento y orientable por el Originator.
Especificación ejecutable por máquina. Estándar de calidad que debe cumplir un prompt de ejecución para implementarse sin contexto conversacional previo y auditarse contra el alcance aprobado de fase.
Originator. Persona o grupo cuya necesidad da propósito al trabajo. No es una parte interesada con una lista de requisitos; es una persona completa con valores, historia y algo genuinamente en juego.
Originator Brief. Primera expresión direccional humana de necesidad; párrafos, no specs.
Ciclo de autorización de fase. Protocolo de siete pasos que cierra una fase y autoriza la siguiente; solo el Steward puede avanzar.
Presupuesto de tamaño de fase. Techo heurístico del número de work items por fase, por encima del cual las auditorías tienden a verificar marcas de checklist en vez de prosa; alrededor de seis en práctica interna.
Invocación por puntero. Regla operativa según la cual la instrucción runtime del Steward al Builder es un puntero breve a un prompt guardado, nunca un prompt largo copiado y pegado.
Cierre preautorizado. Mecanismo por el cual la confirmación del Verifier de que se cumplen criterios prefijados e inequívocos constituye autorización sin un paso separado de confirmación del Steward; el Steward conserva una ventana de veto (§10.2).
Señales de flujo de proceso. Señales de calibración opcionales, capturadas al cierre (ciclos de re-auditoría por fase, conteo de enmiendas de especificación, bloqueos de cierre por nivel, decisiones por fase, tasa de redirección de orientación) que dicen al Steward si el peso de la metodología coincidió con los riesgos; señales, nunca metas de desempeño (§8.6).
Capa de principios. Uso ligero de los ocho principios; no requiere asientos ni protocolo formal.
Criterio profesional. Juicio de oficio defendible presentado como criterio orientable en vez de hecho con fuente.
Auditoría de especificación a nivel de proyecto. Revisión del Verifier en dos puertas, ejecutada una vez antes de la Fase 1: la Puerta de Elevación (Puerta 1) confirma que hubo elevación y no transcripción, y la Puerta de Construibilidad (Puerta 2) confirma que la especificación es ejecutable — coextensión, falla de pruebas pre-implementación, especificidad de aceptación, consistencia cuantitativa, tamaño de fase, decisiones resueltas y completitud del prompt (§7.4).
Capa de protocolo. Modelo operativo completo de ELEV8 para trabajo importante: cinco asientos, autorización del Steward, Discovery Documents, coextensión de especificación, pruebas de contrato, autorización de fase, Registro de Decisiones y verificación de cierre.
Sabiduría práctica. Estándar rector de Calibrate: acción correcta, en cantidad correcta, en circunstancia correcta; disciplina de aptitud al propósito estilo Cynefin que previene tanto subelevación como sobreelevación (§5.5).
Encabezado Reframe. Encabezado visible requerido de cada work item del Discovery Document: pedido literal → trabajo subyacente → por qué la diferencia cambia lo que se construye. Su presencia señala elevación; su ausencia señala transcripción (§7).
Asimetría de reconocimiento. Premisa operativa de que los Originators suelen poder juzgar, corregir o rechazar una solución rica propuesta con más eficacia de la que pueden producirla desde cero.
Clase de reversibilidad. Campo requerido del Registro de Decisiones; uno de Reversible, Reversible-with-cost, Hard-to-reverse o Irreversible. Las decisiones Trusted Advisor solo son válidas cuando la clase permite una ruta de rollback definida (§8.7).
Modo de falla silencioso. Una especificación que pasa revisión porque nadie pudo ver lo que le faltaba.
Sustitución silenciosa. Modo de falla del Elevator donde un criterio profesional válido se aplica sin presentarlo como opción, anulando el juicio del Originator.
Enmienda de especificación (ligera). Entrada del Registro de Decisiones clasificada “Enmienda de Especificación” que registra un cambio material de alcance después de iniciada la Fase 1: los entregables cambiados, lo que la especificación decía antes frente a lo que dice ahora y las líneas de checklist agregadas, eliminadas o actualizadas; la enmienda es coextensiva con la checklist antes de la siguiente revisión del Verifier (§7.4).
Coextensión de especificación. Propiedad requerida de que la prosa de un work item, su checklist de finalización y sus pruebas de contrato nombren el mismo conjunto de entregables, con conteos coincidentes.
Steering Ledger. Artefacto de elevación de primera clase (§7.5) que lista cada brecha que el Elevator llenó: brecha, valor predeterminado del Elevator, razonamiento + etiqueta de evidencia, reversibilidad y veredicto del Originator. El único lugar donde el Originator orienta la especificación; su completitud se verifica en la revisión 2 de la Puerta de Elevación.
Standing TA grant. Envolvente de autoridad a nivel de proyecto declarada una vez en la autorización, que cubre todas las decisiones reversibles de una categoría nombrada; cada decisión bajo el grant registra solo categoría, elección y evidencia — no una nueva envolvente de ocho campos por decisión (§8.7).
Steward. Asiento humano responsable o socio de servicio; revisa y aprueba el Discovery Document, posee los prompts de ejecución y sigue siendo la única autoridad sobre transiciones de fase.
Estilo de decisión del Steward. Parámetro runtime nombrado en la invocación por puntero: Direct Steward, Advisor-Recommended o Trusted Advisor.
Postura de puerta de doble sentido. Doctrina de que la reversibilidad fija la velocidad por defecto de una decisión: las decisiones reversibles (puertas de doble sentido) por defecto son rápidas, de baja ceremonia y delegables, mientras el peso de deliberación escala con la irreversibilidad; la visibilidad siempre se mantiene, solo se recorta la parada de deliberación para las puertas de doble sentido (§8.7).
Verifier. Asiento de verificación independiente distinto de la instancia Builder; verifica el trabajo producido contra el Discovery Document y clasifica hallazgos por severidad.
Captura de voz (voice capture). La subdisciplina de Enrich/Empower de preservar de forma textual las palabras, frases, metáforas y objeciones propias del Originator y de su audiencia como un hecho con fuente sobre intención y voz que la especificación debe reflejar, en vez de parafrasearlas en prosa experta genérica (§5.2, §5.6).

Apéndice D: plantilla de Discovery Document

# Discovery Document de [Nombre del proyecto]

## Metadatos
Fecha del proyecto: [...]
Estado: Discovery | Planeado | En ejecución | Cerrado
Originator: [...]
Steward: [...]
Elevator: [...]
Audiencia: [...]
Meta principal: [...]

## Fase 0: riesgos
Prototipo | Herramienta interna | Sistema de producción | Superficie insignia
¿De cara a ingresos? ¿De cara al cliente? ¿Regulado? ¿Reversible?
Costo de equivocarse: bajo | medio | alto
Nota de Calibrate: [por qué se justifica la profundidad seleccionada]

## Intención del proyecto
POR QUÉ: [...]
QUÉ: [...]
CÓMO: [...]

## Steering Ledger
| Brecha | Valor predeterminado del Elevator | Razonamiento + etiqueta de evidencia | Reversibilidad | Veredicto del Originator |
| --- | --- | --- | --- | --- |
| [...] | [...] | [...] | Reversible / ... | Confirmed / Redirected: [...] / Deferred |

## Decisiones resueltas
| Pregunta | Decisión | Razonamiento | Dueño |
| --- | --- | --- | --- |
| [...] | [...] | [...] | Originator / Elevator / Steward |

## Mapa de fases
| Fase | Tema | Resumen de entregables | Conteo de WI | Estado de salida |
| --- | --- | --- | --- | --- |
| Fase 1 | [...] | [...] | [...] | [...] |

## Contrato de salida de fase
- Cada entregable tiene un hecho de aceptación visible en fuente o artefacto.
- La prosa de work item, checklist y criterios de verificación son coextensivos.
- Las pruebas de contrato fallan contra el estado pre-implementación.
- Los documentos de auditoría pertenecen al Verifier y son de solo lectura para el Builder.
- Cada puntero del Builder nombra un estilo de decisión del Steward.
- Cada decisión no trivial se registra en el Registro de Decisiones.
- La verificación de cierre ocurre antes del cierre final.

## Guía de ejecución de Fase [N]

### Precondiciones
- [ ] [...]

### Work Items

**Encabezado Reframe** (requerido por cada WI): Pedido literal → Trabajo subyacente → Por qué la diferencia cambia lo que se construye.

| WI | Título | Criterio de aceptación | Dependencias |
| --- | --- | --- | --- |
| WI-[ID] | [...] | Done looks like: [...] | [...] |

### Restricciones duras
- No construir: [...]
- No modificar: [...]
- Convenciones requeridas: [...]

### Checklist de finalización
- [ ] [...]

### Pruebas de contrato (redactadas por el Elevator, deben fallar antes de implementar)
- [...]

### Prompt textual de ejecución
Implementa solo la Fase [N]. Construye [entregables] y no construyas [alcance diferido].

IMPORTANTE: los documentos de auditoría son SOLO LECTURA para el Builder.

Si encuentras cualquier conflicto, ambigüedad o diferencia cuantitativa entre prosa,
checklist, criterios de verificación o restricciones duras, DETENTE y elévalo al
Steward. No optimices en silencio por el alcance menor.

Estilo de decisión del Steward: [Direct Steward | Advisor-Recommended | Trusted Advisor]

## Registro de auditoría de spec (una vez, antes de la Fase 1)
| Puerta | Revisión | Estado | Evidencia / prompt de reparación |
| --- | --- | --- | --- |
| 1 — Elevación | Reframe visible | Pass / Fail | [...] |
| 1 — Elevación | Steering Ledger presente | Pass / Fail | [...] |
| 1 — Elevación | Evidencia etiquetada | Pass / Fail | [...] |
| 1 — Elevación | Orientación con decisión primero | Pass / Fail | [...] |
| 1 — Elevación | Profundidad calibrada | Pass / Fail | [...] |
| 2 — Construibilidad | Coextensión | Pass / Fail | [...] |
| 2 — Construibilidad | Falla pre-implementación | Pass / Fail | [...] |
| 2 — Construibilidad | Especificidad de aceptación | Pass / Fail | [...] |
| 2 — Construibilidad | Consistencia cuantitativa | Pass / Fail | [...] |
| 2 — Construibilidad | Tamaño de fase | Pass / Fail | [...] |
| 2 — Construibilidad | Decisiones resueltas | Pass / Fail | [...] |
| 2 — Construibilidad | Completitud del prompt | Pass / Fail | [...] |

## Registro de Decisiones
| Disparador | Solicitado por | Estilo de decisión | Envolvente de autoridad | Opciones consideradas | Elección | Razonamiento | Artefactos afectados | Reversibilidad | Plan de rollback | Evidencia de validación | Veredicto del Steward |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| [...] | [...] | [...] | [...] | [...] | [...] | [...] | [...] | [...] | [...] | [...] | [...] |

## Contrato operativo de auditoría y re-auditoría
Cuando el Steward dice "re-auditar," aplique el nivel: Re-auditoría de fuente (hay defectos
de fuente — paquete completo de 7 ítems) o Confirmación de evidencia (solo brechas de
documentación/evidencia — paquete de 3 ítems: actualización de estado de hallazgos +
registro de aceptación del Steward + veredicto).

## Captura de aprendizaje
| Fecha | Tipo (hallazgo / aclaración / decisión / lección) | Aprendizaje | Registrado en |
| --- | --- | --- | --- |
| [...] | [...] | [...] | doc de proyecto / doc de auditoría / registro de lecciones |

## Verificación de cierre
| Revisión | Estado | Evidencia |
| --- | --- | --- |
| Requisito original revisado | Pass / Revise | [...] |
| Evolución de alcance aceptada revisada | Pass / Revise | [...] |
| Resultado final satisface la definición madura de hecho | Pass / Revise | [...] |
| Registros de aprendizaje y validación están actualizados | Pass / Revise | [...] |

## Señales de flujo de proceso (opcional, registradas una vez al cierre)
Ciclos de re-auditoría por fase: [...]
Enmiendas de especificación: [...]
Bloqueos de cierre (duros / suaves): [...]
Decisiones por fase: [...]
Tasa de redirección de orientación: [...]

## Notas ELEV8 del Elevator
[2-4 frases: dónde la intención fue más ambigua; qué filas del Steering Ledger fueron las
más difíciles de llenar; qué abordaría el Elevator de otra forma para esta clase de brief la próxima vez.]

Apéndice E: Historial de revisiones y activos derivados

Activos derivados. ELEV8 se mantiene como una única fuente metodológica interna en VirtuAmerica; este artículo es la expresión pública canónica de esa fuente. Los activos públicos derivados — la publicación de blog de ELEV8 (inglés y español) y el Kit ELEV8 (plantillas, checklists y skill de agente) — deben mantenerse alineados con este artículo en lenguaje, terminología, orden de principios, nombres de asientos, nombres de artefactos, conteos e intención. Los cambios definicionales (nombres de asientos, orden de principios, revisiones de puertas, listas de campos, listas de señales, conteos canónicos) aterrizan primero en la fuente interna, luego en este artículo y luego en el blog y el kit dentro de la misma revisión. Cada revisión a continuación enumera sus secciones cambiadas para que quienes mantienen los derivados puedan sincronizar por delta y no por relectura completa.

Fuente del historial. Esta tabla se reconstruye desde sellos de versión rastreados por Git en la ruta original del artículo Idea Elevation (Docs/Publications/2026-05-06_IdeaElevation_HumanAI_CollaborativeDevelopment.md), el artículo público canónico, las copias Markdown del blog y los archivos de borrador del track paralelo Claude (ELEV8_Claude_v64.md, ELEV8_Claude_v65.md). El Markdown específico del blog se creó desde el artículo público el 2026-05-29; las filas anteriores preservan la línea del artículo público que se convirtió en el post del blog. Las filas se ordenan por versión, no por fecha de commit. Los números de versión que no aparecen como sellos de revisión independientes no se listan.

Historial de revisiones.

Versión	Fecha	Secciones cambiadas
v2.0	2026-05-06	Primer artículo rastreado de Idea Elevation: seis dimensiones de elevación, vocabulario Author/Engineer/Architect/Developer, Maximization como obligación rectora, encuadre de especificación ejecutable por máquina y ejemplos tempranos de software/negocio.
v3.4	2026-05-07	El artículo se expandió de seis a nueve dimensiones, introdujo Reframe y la estructura de tríadas, reemplazó Maximization por Apt Elevation, fortaleció ejemplos de evidencia/seguridad/comercialización y afinó el estándar de especificación ejecutable por máquina.
v3.5	2026-05-07	Pase editorial del artículo: metadatos, diagramas, texto de roles/protocolo, ejemplos y cierre más ajustados sin cambiar la forma central de la metodología.
v4.8	2026-05-07	Reestructura mayor: Summary at a Glance, alcance de aplicabilidad, secciones Faithfulness Trap y Silent Failure Mode, sección dedicada de Apt Elevation, citas más fuertes y ajustes de fases/auditoría.
v5.12	2026-05-07	Endurecimiento metodológico posterior al cierre del VirtuAmerica Portals Redesign: calibración, etiquetado de afirmaciones/evidencia, coextensión de spec, escalación de conflictos de spec, captura de aprendizaje, puertas de fase, verificación de cierre y vínculo entre revisión pública y ChangeLog.
v5.13	2026-05-08	La revisión previa a implementación se renombró como Project-Level Spec Audit; se afinó el lenguaje de coextensión/auditoría y se pulieron ejemplos trabajados y texto de puertas de fase.
v5.14	2026-05-09	Los principios de Idea Elevation se renombraron como principios ELEV8 y se normalizaron los ocho nombres: Reframe, Enrich, Align, Unify, Calibrate, Empower, Ground y Anticipate.
v6.0	2026-05-09	El artículo se reformuló como ELEV8: A Human-AI Methodology for Turning Real Needs into Working Technology; se movió a la ruta de metodología de gobierno; y el modelo de ocho principios, la doctrina Apt Elevation, los asientos, las referencias y el glosario quedaron alineados alrededor de ELEV8.
v6.1	2026-05-10	Se reorganizaron el estándar de Discovery Document y el protocolo operativo; se reforzaron la escalación de conflictos de spec, notas post-revisión, captura de aprendizaje, paquete de re-auditoría, autorización de fase, estilos de decisión del Steward y renderizado de diagramas.
v6.2	2026-05-10	Se añadieron metadatos públicos para fuente interna, kit público, ruta canónica del blog y palabras clave; se aclaró el flujo de estilos de decisión del Steward, el cierre de fase final y la alineación de referencias.
v6.4	2026-05-13	Borrador del track Claude (`ELEV8_Claude_v64.md`): formalización del authority envelope con ocho componentes requeridos; Decision Log expandido a doce campos explícitos añadiendo reversibility class (cuatro valores) y Steward verdict (seis valores); taxonomía de Ask routing introducida; §13.3 Scope Limitations expandido de cuatro a ocho ítems; acrónimo TAME añadido a §14; patrón universal de cuatro pasos añadido a §11; distinción hollow-result vs. defect añadida a §2; entradas de glosario para Authority envelope, Ask routing, Practical wisdom y Reversibility class.
v6.5	2026-05-13	Borrador del track Claude (`ELEV8_Claude_v65.md`, PR #1291): recuperación editorial restaurando anclajes de citas en el cuerpo de principios (Christensen, Ohno, Rose et al., Reinertsen, Alexander et al., Snowden & Boone, Mandler, Tulving) debilitados por v6.4; restaurados trilemma Maximization/Optimization/Aptness, principio equal-depth, tercera frase de Faithful blank space, doctrina de silent-override, máxima Reframe-prevents-premature-execution, máxima anticipated-failure-mode, distinción Elevator-vs-Steward, regla de coextensión count-mismatch, regla pointer-is-three-to-eight-lines y conjunto completo de mecanismos §8.7.
v6.6	2026-05-13	Reescritura formal del artículo público: título cambiado a Working Outcomes; se añadieron Author’s Note, How to Read, el Complexity Arc de cinco niveles, ejemplos de origen más ricos, lenguaje público de roles y se eliminó material específico de TAME.
v6.7	2026-05-31	Se añadieron enmiendas de agilidad desde el registro de ejecución de Pool-Based Azure: modo de ejecución acelerada, cierre preautorizado, Standing TA Grants, enmiendas de decisión, re-auditoría por niveles, niveles de bloqueo de cierre y enmiendas ligeras de spec.
v6.8	2026-05-31	Se añadieron enmiendas de simplificación: horizonte de elaboración rolling-wave, registros de decisión por niveles, postura two-way-door y señales opcionales de flujo de proceso.
v6.9	2026-05-31	Se añadieron enmiendas para fortalecer la elevación: Completeness Lens, work items con Reframe primero, Steering Ledger, Elevation Gate y el modo de falla de transcripción disfrazada de elevación.
v6.10	2026-05-31	Se añadieron mejoras de usabilidad e integridad: modo build-checklist de la Puerta 1, actualizaciones de MVV y quick-start, artefactos en el ejemplo trabajado, Notas ELEV8 del Elevator, requisitos graduados y el prompt de revisión de tres preguntas del Steward.
v6.11	2026-05-31	Sello de versión en superficies públicas sin cambios metodológicos sustantivos.
v6.12	2026-05-31	El artículo público y el blog en inglés se reconstruyeron con paridad completa respecto al conjunto interno de mecanismos v6.8-v6.11 y se refrescaron los diagramas Mermaid del blog.
v6.13	2026-05-31	Sello de alineación tras reverificar metodología, paper, blog trilingüe, Kit ELEV8, skill y referencias activas de proyecto; sin cambios sustantivos de contenido.
v6.14	2026-06-10	Resumen y Cómo leer (lenguaje de dos capas, mapeo nivel/capa/modo); §2 (citas de Kano y Bai); §7.4 (orden de las puertas, aclaración del modo build-checklist, alcance de revisiones del horizonte de elaboración); §7.5 (regla de filas dirigibles, orden difícil-de-revertir-primero); §8.6 (derecho de aceptación del Originator, quinta señal de flujo: tasa de redirección de orientación); §9.2 (consistencia del conteo de invitados); §10.1 (condiciones de modo acelerado ajustadas); §10.2 (precondiciones de la ventana de veto); §13.1 (cita del AI Index); §13.3 (formato de paquete de caso); Parte XI (modos de falla del Builder y del Verifier); Apéndice A (principio el-contenido-de-artefacto-es-evidencia); Apéndice C (entradas Puerta de Construibilidad y Enmienda de spec; correcciones a Auditoría de spec a nivel de proyecto, Notas ELEV8 del Elevator y Señales de flujo de proceso); Apéndice D (columna Opciones consideradas; secciones Registro de auditoría de spec, Captura de aprendizaje y Señales de flujo de proceso; campo de clase de evidencia eliminado de los metadatos); Apéndice E agregado.
v6.15	2026-06-23	§5.1 Reframe (divergencia de encuadres candidatos); §5.2 Enrich (Validar-primero-el-supuesto-más-riesgoso; subdisciplina de Captura de voz tomada del paso de captura del lenguaje del cliente de los manuales de construcción por etapas para fundadores en solitario, con el ancla de industria Cameo Labs); §5.3 Align (secuenciación temprana de validación de supuestos); §5.6 Empower (tempo de visibilidad continua); inicio rápido de protocolo §5.10 (instrucción de captura de voz y supuesto más riesgoso); fila de señal de éxito del Lente de Completitud (demanda/adopción/alcance de audiencia); Apéndice C glosario (Captura de voz); Referencias (Cameo Labs, 2026) y Nota sobre vigencia (categoría de metodología de práctica añadida). Solo revisión de enriquecimiento: nombres de asientos, orden de principios, conteos canónicos y verificaciones de puerta sin cambios.

Referencias

Alexander, C., Ishikawa, S., & Silverstein, M. (1977). A Pattern Language: Towns, Buildings, Construction. Oxford University Press.

Autio, C., Schwartz, R., Dunietz, J., Jain, S., Stanley, M., Tabassi, E., Hall, P., & Roberts, K. (2024). Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile. NIST AI 600-1. National Institute of Standards and Technology. https://doi.org/10.6028/NIST.AI.600-1

Bai, Y., Kadavath, S., Kundu, S., Askell, A., Kernion, J., Jones, A., Chen, A., Goldie, A., Mirhoseini, A., McKinnon, C., Chen, C., Olsson, C., Olah, C., Hernandez, D., Drain, D., Ganguli, D., Li, D., Tran-Johnson, E., Perez, E., et al. (2022). Constitutional AI: Harmlessness from AI feedback. arXiv preprint arXiv:2212.08073. https://doi.org/10.48550/arXiv.2212.08073

Cameo Labs. (2026). The AI Startup Blueprint: AI-assisted prompts from idea to launch [online prompt library / cohort workshop]. https://cameolabs-aiblueprint.com/prompts

Christensen, C. M., Hall, T., Dillon, K., & Duncan, D. S. (2016). Competing Against Luck: The Story of Innovation and Customer Choice. HarperBusiness.

Christiano, P. F., Leike, J., Brown, T. B., Martic, M., Legg, S., & Amodei, D. (2017). Deep reinforcement learning from human preferences. Advances in Neural Information Processing Systems, 30, 4299-4307.

Greenblatt, R., Denison, C., Wright, B., Roger, F., MacDiarmid, M., Marks, S., Treutlein, J., Belonax, T., Chen, J., Duvenaud, D., Khan, A., Michael, J., Mindermann, S., Perez, E., Petrini, L., Uesato, J., Kaplan, J., Shlegeris, B., Bowman, S. R., & Hubinger, E. (2024). Alignment faking in large language models. arXiv preprint arXiv:2412.14093. https://doi.org/10.48550/arXiv.2412.14093

Huang, L., Yu, W., Ma, W., Zhong, W., Feng, Z., Wang, H., Chen, Q., Peng, W., Feng, X., Qin, B., & Liu, T. (2025). A survey on hallucination in large language models: Principles, taxonomy, challenges, and open questions. ACM Transactions on Information Systems, 43(2), Article 42, 1-55. https://doi.org/10.1145/3703155

Hubinger, E., Denison, C., Mu, J., Lambert, M., Tong, M., MacDiarmid, M., Lanham, T., Ziegler, D. M., Maxwell, T., Cheng, N., Jermyn, A., Askell, A., Radhakrishnan, A., Anil, C., Duvenaud, D., Ganguli, D., Barez, F., Clark, J., Ndousse, K., et al. (2024). Sleeper agents: Training deceptive LLMs that persist through safety training. arXiv preprint arXiv:2401.05566. https://doi.org/10.48550/arXiv.2401.05566

Kano, N., Seraku, N., Takahashi, F., & Tsuji, S. (1984). Attractive quality and must-be quality. Journal of the Japanese Society for Quality Control, 14(2), 147-156.

Mandler, G. (1980). Recognizing: The judgment of previous occurrence. Psychological Review, 87(3), 252-271.

Ohno, T. (1988). Toyota Production System: Beyond Large-Scale Production. Productivity Press.

Ouyang, L., Wu, J., Jiang, X., Almeida, D., Wainwright, C. L., Mishkin, P., Zhang, C., Agarwal, S., Slama, K., Ray, A., Schulman, J., Hilton, J., Kelton, F., Miller, L., Simens, M., Askell, A., Welinder, P., Christiano, P. F., Leike, J., & Lowe, R. (2022). Training language models to follow instructions with human feedback. Advances in Neural Information Processing Systems, 35, 27730-27744.

Reinertsen, D. G. (2009). The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing.

Rose, S. W., Borchert, O., Mitchell, S., & Connelly, S. (2020). Zero Trust Architecture. NIST Special Publication 800-207. https://doi.org/10.6028/NIST.SP.800-207

Sharma, M., Tong, M., Korbak, T., Duvenaud, D., Askell, A., Bowman, S. R., Cheng, N., Durmus, E., Hatfield-Dodds, Z., Johnston, S. R., Kravec, S., Maxwell, T., McCandlish, S., Ndousse, K., Rausch, O., Schiefer, N., Yan, D., Zhang, M., & Perez, E. (2023). Towards understanding sycophancy in language models. arXiv preprint arXiv:2310.13548. https://doi.org/10.48550/arXiv.2310.13548

Snowden, D. J., & Boone, M. E. (2007). A leader’s framework for decision making. Harvard Business Review, 85(11), 68-76, 149.

Stanford Institute for Human-Centered Artificial Intelligence. (2026). The 2026 AI Index Report. Stanford University. https://hai.stanford.edu/ai-index/2026-ai-index-report

Tabassi, E. (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100-1. National Institute of Standards and Technology. https://doi.org/10.6028/NIST.AI.100-1

Tulving, E. (1985). How many memory systems are there? American Psychologist, 40(4), 385-398.

Turner, C., & Eisikovits, N. (2026). Programmed to please: The moral and epistemic harms of AI sycophancy. AI and Ethics, 6, Article 168. https://doi.org/10.1007/s43681-026-01007-4

Nota sobre vigencia. Las referencias no relacionadas con IA son anclas maduras de diseño, desarrollo de producto, psicología cognitiva, toma de decisiones organizacionales, práctica de seguridad, gestión de riesgo y metodología de práctica contemporánea. Las referencias de IA son selectivas, no exhaustivas: anclan las afirmaciones del artículo sobre RLHF, complacencia, alucinación, fingimiento de alineación, cambio rápido de modelos e IA responsable en esta revisión. La misma taxonomía de tipos de afirmación de §5.2 (criterio profesional, hecho con fuente, hipótesis de validación) aplica igual de bien a la literatura de IA.

<!— doc-status: public-methodology —>