Modelo Operativo — Concepto y Principios

1. Propósito y alcance

Esta sección define el modelo operativo del área de Tecnología de Prism en su nivel conceptual: por qué existe, sobre qué principio se construye, qué reglas lo protegen y qué comportamientos prohíbe. Es la sección de referencia primaria para todo miembro del equipo; el resto de la documentación permanente la asume como leída.

Delimitación: los roles humanos y la relación humano–agente se documentan en la sección 03; el roster de agentes y su detalle operativo, en la 04; el flujo de trabajo por fases y los dos pipelines, en la 05; la arquitectura de información, en la 06.

2. Por qué existe este modelo

El conocimiento almacenado donde el trabajo no ocurre, muere. Un documento que ningún paso del flujo diario obliga a consultar no se lee; un documento que ningún paso del flujo obliga a actualizar pierde vigencia. Ambos efectos son sistemáticos, no fallas de disciplina individual: ningún equipo sostiene por voluntad lo que su proceso no exige.

En Prism este fenómeno se manifestó por las dos caras a la vez, y ambas eran el mismo problema visto desde extremos opuestos:

• Desde la dirección: la documentación no se producía ni se actualizaba. Al momento del rediseño (julio 2026), 63 tarjetas terminadas — cerca de la mitad de todo el trabajo completado en la historia del tablero — esperaban en una columna llamada Pending Documentation una documentación que nunca llegaba.
• Desde el equipo: al recibir una tarea nueva, el contexto necesario no llegaba. El desarrollador reconstruía a mano: preguntaba, buscaba, asumía. El contexto existía — en documentos de Word fuera del flujo, en el historial de tarjetas, en la memoria de las personas — pero no fluía hacia el punto donde se necesitaba.

El diagnóstico de fondo: no era un problema de almacenamiento, sino de flujo. Construir un archivo mejor organizado no lo resuelve; solo reubica el problema. La solución requiere que mover el contexto sea parte del trabajo mismo — y el costo manual de hacerlo (ensamblar el contexto relevante para cada tarea, capturar lo aprendido al cerrarla, mantener los documentos al día) es exactamente lo que hizo inviable todo intento anterior. Ese costo es el que los agentes de IA absorben. Por eso este modelo existe ahora y no antes: la tecnología volvió económicamente viable un principio que siempre fue correcto.

3. La Base de Conocimiento

Definición. La Base de Conocimiento es el conjunto de documentos estructurados, verificados por humanos, con fecha y fuente, que alimentan cada tarea de trabajo. Reside en Git, se modifica por Pull Request y es la fuente única desde la cual se generan todas las vistas para lectores humanos.

Cinco propiedades la definen; ninguna es opcional:

1. Verificada. Ningún contenido entra sin validación humana. Un agente puede redactar el borrador; un humano responde por su exactitud.
2. Fechada y con fuente. Todo archivo declara last_verified, owner y sources en su front-matter. El contenido más antiguo que el umbral definido se entrega marcado como no verificado.
3. Versionada. Vive en Git y cambia por PR. Tiene historia, autoría y capacidad de reversión — las mismas garantías que el código.
4. Consumida por agentes. Su lector principal no es humano: los agentes que producen y verifican contexto (③ Spec Writer, ④ Independent Reviewer, ⑦ Publisher) la consultan como fuente, sin fatiga y sin omisiones. Las vistas humanas (documentación técnica del sitio, guías de usuario) se generan desde ella.
5. Sin duplicación. No copia datos que viven estructurados en SeaTable (inventario, tarjetas, resultados); los referencia. La copia es la vía por la que la desactualización reingresa.

La consecuencia que sostiene todo el modelo: cuando el lector principal es un agente que consulta la Base para armar el contexto de cada tarea, un documento desactualizado produce un efecto visible e inmediato — un Plan incorrecto hoy — en lugar de una deuda invisible que alguien descubre meses después. Esto invierte el incentivo histórico de la documentación: mantenerla al día deja de ser una tarea diferible y se convierte en condición de funcionamiento del flujo diario. Escribir y curar la Base es, en términos prácticos, programar la capa de IA del equipo.

4. El ciclo del contexto

El modelo se construye sobre una regla única:

Toda unidad de trabajo inicia recibiendo contexto y termina devolviendo contexto.

Una tarjeta sin su paquete de contexto no está lista para comenzar; una sesión que no devolvió lo aprendido no está terminada. La documentación deja de ser un subproducto del pipeline y se convierte en el medio a través del cual el pipeline fluye.

El contexto no lo transporta un agente dedicado: lo transporta el sistema, como función distribuida entre los artefactos del flujo. El contexto llega con la tarjeta condensado en el Plan — el documento que ② Product Architect inicia (el Requirement) y ③ Spec Writer enriquece (el Tech Spec) — y regresa al cerrar cada sesión mediante el wrap-up y, semanalmente, la promoción. “Los agentes son mensajeros del contexto” describe esa función del sistema, no el nombre de un agente.

El ciclo tiene cinco momentos:

1. Ensamblaje. El contexto se condensa en el Plan durante el Pipeline A: ② redacta el Requirement (qué y por qué) y ③ lo completa con el Tech Spec leyendo la Base de Conocimiento (narrativa) y SeaTable (hechos estructurados, en vivo), sin duplicar ninguno. El Plan es el paquete de contexto de la tarjeta.
2. Consumo activo. El desarrollador arranca la tarjeta desde el Plan: valida sus vacíos declarados, resuelve sus preguntas abiertas y solo entonces construye. Cada sesión de Build retoma el Plan y las notas de sesión previas de la tarjeta.
3. Retorno efímero. Al cerrar cada sesión, ⑤ Session Wrap-up registra la nota de sesión en la tarjeta: qué se hizo, qué se decidió, qué sigue. Esta nota sirve a la sesión siguiente y expira con la tarjeta.
4. Curaduría. Semanalmente, ⑩ Knowledge Curator propone qué aprendizajes de las notas efímeras merecen volverse permanentes. Los humanos deciden en un ritual de diez minutos.
5. Promoción. Solo lo aprobado entra a la Base — y queda disponible para todos los Plan futuros. El conocimiento del equipo se compone, sesión tras sesión.

4.1 Anatomía del contexto de una tarjeta

El contexto que una tarjeta necesita tiene una estructura conceptual estándar, realizada en el Plan (Requirement + Tech Spec). La especificación técnica de la plantilla corresponde a la sección 04:

Componente	Contenido	Parte del Plan · Fuente
Identificación	Tarjeta, aplicación, alcance	Requirement · SeaTable
Problema y criterios de experiencia	Qué se resuelve y qué resultados verificables se esperan	Requirement
Contrato	Criterios de aceptación congelados (Capa 1) + enmiendas autorizadas, si existen	SeaTable
Contexto narrativo	Notas del módulo afectado, decisiones aplicables con fecha, restricciones e integraciones	Tech Spec · Base de Conocimiento
Inventario	Servidores, bases, automatizaciones y APIs que la tarjeta toca	Tech Spec · SeaTable (en vivo, referenciado)
Fuentes consultadas	Lista de documentos usados, con su fecha de verificación	Tech Spec
Vacíos de cobertura	Áreas de la tarea sobre las que no existe documentación	Tech Spec
Preguntas abiertas	Lo que el desarrollador debe verificar antes de construir	Tech Spec

Tres reglas de integridad: el Tech Spec declara sus límites (los vacíos y preguntas son secciones obligatorias, no opcionales); marca como no verificado el contenido que excede el umbral de antigüedad; y jamás incluye secretos — transmite el enlace de 1Password correspondiente, nunca su contenido.

5. Los seis principios de diseño

Cada principio existe como respuesta a un modo de falla identificado en el diseño del modelo. Conocer el razonamiento es parte de conocer el principio.

P1 · Lanzamiento estrecho, Base primero

Regla. La automatización nunca precede al conocimiento verificado. Se activa un agente sobre un dominio solo cuando la Base que lo cubre fue construida y validada por humanos; la expansión a nuevas aplicaciones es siempre Base primero, agentes después. Su corolario operativo: sin repo de app —con su Base— no hay documentación ni agentes sobre ella.

Razonamiento. El modelo muere en el arranque si el primer contexto es superficial o incorrecto: un desarrollador que recibe un Plan inútil concluye que el sistema no aporta y vuelve a la arqueología manual, pagando el costo del modelo sin su beneficio. La primera impresión es determinante y no se recupera.

Prohíbe. Activar agentes sobre documentación no verificada; extender agentes a una aplicación cuya Base no existe; tratar la construcción de la Base como tarea paralela “que se irá completando”.

P2 · El contexto declara sus límites

Regla. Todo Tech Spec incluye fuentes consultadas, vacíos de cobertura y preguntas abiertas. El contexto recibido enmarca la investigación del desarrollador; no la reemplaza.

Razonamiento. El riesgo del retrieval no es entregar información falsa, sino omitir la restricción crítica proyectando cobertura total. Un contexto que aparenta completitud entrena al lector a no verificar; un contexto honesto sobre lo que no sabe entrena exactamente el comportamiento contrario. Además, este principio contiene el riesgo de pasividad: si el Plan respondiera todo, el desarrollador dejaría de construir criterio propio sobre el sistema.

Prohíbe. Tech Spec sin sección de vacíos; construir sobre un vacío declarado sin verificarlo primero; tratar el Plan como verdad completa en lugar de mapa con zonas sin cartografiar.

P3 · Todo dato lleva fecha y fuente

Regla. Cada archivo de la Base declara cuándo fue verificado por última vez, por quién y de dónde proviene. El contenido vencido se entrega marcado como no verificado. Corregir un dato erróneo detectado es una obligación inmediata (aproximadamente cinco minutos), no un elemento de backlog: registrarlo es de quien lo detecta, y aplicarlo a la Base de quien tiene el carril de escritura sobre ella (03 §7.5.3).

Razonamiento. El contexto desactualizado entregado con autoridad es más dañino que la ausencia de contexto: suprime la pregunta que lo habría corregido. Un documento muerto en un archivo es inofensivo porque nadie lo lee; ese mismo documento servido a cada tarea propaga el error a todo el equipo, con confianza. La fecha visible y el ritual de corrección son el sistema inmunológico de la Base.

Prohíbe. Archivos sin front-matter; postergar el registro de una corrección detectada; dejar sin escalar un dato erróneo material, que no puede esperar al siguiente release; entregar contenido vencido sin marcarlo.

P4 · Dos tipos de escritura de vuelta

Regla. Las notas de sesión son efímeras: residen en la tarjeta, sirven a la sesión siguiente y expiran. El conocimiento durable entra a la Base únicamente por promoción — una decisión humana deliberada, tomada en el ritual semanal sobre candidatos que ⑩ Knowledge Curator propone.

Razonamiento. El cierre de sesión es el peor momento psicológico para escribir con calidad; si todo lo escrito ahí entrara a la Base, esta acumularía resúmenes de bajo valor que contaminarían el retrieval — se habría reemplazado un cementerio central por uno distribuido y en crecimiento. La promoción invierte la carga: la Base no crece por acumulación sino por selección.

Prohíbe. Volcado automático de notas de sesión a la Base; promover sin decisión humana; usar CLAUDE.md o cualquier documento de la Base como diario de sesión.

P5 · Criterios congelados, con vía de enmienda ágil

Regla. Los criterios de aceptación (Capa 1) se congelan cuando la tarjeta cruza el Ready gate. El mapa de ejecución (Capa 2, verification criteria) sí se actualiza contra lo realmente construido. Toda diferencia entre lo construido y la Capa 1 sin enmienda autorizada es una Deviation: se reporta y la resuelve el Lead; nunca se absorbe en silencio. La enmienda legítima toma cinco minutos: nota de cambio de alcance en la tarjeta y fecha. Quién la concede depende de su dirección, porque las dos direcciones no corren el mismo riesgo:

• Ampliar — el dueño del Requirement agrega un criterio. La decide él y se le comunica al Lead. No corrompe la verificación: la endurece. Lo único que el Lead decide es en qué tarjeta cae, que es secuencia y no autoridad.
• Relajar, quitar o ajustar un criterio — típicamente pedido desde la ejecución. Exige el visto bueno del Lead. Es la dirección que este principio existe para vigilar: la que acomoda el contrato a lo que salió.

Razonamiento. Sin congelamiento, la verificación se corrompe: se ajusta a lo que se construyó y valida cualquier cosa, incluidas las suposiciones que el desarrollador tomó sin consultar. El congelamiento convierte esa suposición en una Deviation visible antes de que QA la apruebe. Y la vía de enmienda de cinco minutos existe porque la disciplina que estorba se abandona: si formalizar un cambio de alcance legítimo fuera costoso, el equipo editaría la Capa 1 informalmente y el mecanismo de Deviations moriría sin ruido.

Prohíbe. Editar la Capa 1 fuera de la vía de enmienda; que ⑤ QA Runner ajuste criterios para que coincidan con lo construido; que quien pide una enmienda que relaja un criterio se la conceda a sí mismo; aprobar QA con Deviations sin resolución del Lead.

P6 · Autonomía por calibración, no por diseño

Regla. Todo agente inicia produciendo borradores que un humano revisa (L1; los estrictamente mecánicos y verificables de inmediato, en L2). La autonomía se amplía únicamente con evidencia observada, y puede descender.

Razonamiento. La confianza declarada en el diseño es una apuesta; la confianza calibrada es un dato. Lanzar agentes con autonomía alta ahorra semanas y puede costar el modelo completo: un solo error autónomo temprano — un ticket mal cerrado, un review equivocado — destruye más adopción que la que cien aciertos construyen. El costo de revisar borradores durante la calibración es el precio de la evidencia.

Prohíbe. Lanzar un agente nuevo por encima de su nivel inicial por conveniencia; ampliar autonomía sin datos de calibración; mantener el nivel tras incidentes (ver §6).

6. La escalera de autonomía

Marco único para decidir cuánto puede hacer un agente sin intervención humana. Aplica a cada agente individualmente y su nivel vigente consta en el registro de agentes (sección 04).

Nivel	Definición	En la práctica
L0 — Sugiere	Produce análisis u opciones; no genera artefactos de trabajo	Su salida informa a un humano que hace el trabajo
L1 — Borrador	Produce el artefacto completo (documento, plan, comentario de review); un humano lo revisa y aprueba antes de que tenga efecto	Nivel inicial por defecto de todo agente
L2 — Actúa con confirmación	Ejecuta la acción (crear tarjetas, hacer push, mover una tarjeta) previa confirmación humana puntual	Nivel inicial solo para agentes mecánicos cuya salida es verificable de inmediato (⑤ Session Wrap-up, ⑨ Ops-Health Monitor)
L3 — Autónomo	Ejecuta sin intervención; los humanos auditan a posteriori	Ningún agente lo tiene al lanzamiento; requiere historial L2 sostenido

Ascenso. Lo propone el dueño del agente con evidencia de calibración: volumen mínimo de ejecuciones revisadas y tasa de corrección humana por debajo del umbral que el dueño y el Lead acuerden para ese agente. Se formaliza como cambio de configuración — es decir, por PR con aprobación del Lead — y se refleja en el registro de agentes. Nunca se asciende más de un nivel por vez.

Descenso. Un incidente atribuible al agente (contexto erróneo entregado sin marcar, Deviation absorbida, acción ejecutada fuera de alcance) provoca el descenso inmediato de un nivel y una revisión de configuración antes de cualquier nuevo ascenso. El descenso no es sanción: es recalibración.

7. Antipatrones

Comportamientos que el modelo prohíbe de forma explícita. Reconocerlos es parte de la competencia esperada de todo miembro del equipo.

A1 · Pregunta–respuesta–listo. Usar la IA como oráculo puntual: preguntar, copiar la respuesta, cerrar. No recibe contexto del sistema ni le devuelve nada; el conocimiento generado muere en la conversación. Comportamiento correcto: toda sesión de trabajo con IA opera dentro del ciclo — inicia con el Plan, cierra con el wrap-up.

A2 · CLAUDE.md como diario. Registrar en CLAUDE.md (o en cualquier documento de la Base) el recuento de la sesión: qué se hizo, decisiones del día, próximos pasos. CLAUDE.md es constitución — convenciones estables que aplican a toda sesión; un diario dentro de la constitución degrada cada sesión futura con contexto vencido. Comportamiento correcto: la nota de sesión vive en la tarjeta (efímera); lo durable se promueve (P4).

A3 · Documentación como archivo pasivo. Producir documentos que ningún paso del flujo consulta ni actualiza — el patrón que generó las 63 tarjetas. Un documento sin punto de contacto con el flujo diario está muerto al nacer, sin importar su calidad. Un verification criteria en una hoja de cálculo que nadie está obligado a consumir es una forma de este antipatrón. Comportamiento correcto: todo documento nuevo nace dentro de la Base, con front-matter y un consumidor definido (un agente, una vista generada); si no lo tiene, se cuestiona su existencia.

A4 · Absorción silenciosa de Deviations. Ajustar criterios, plan o documentación para que coincidan con lo que se construyó, sin enmienda autorizada. Valida retroactivamente decisiones que nadie tomó. Comportamiento correcto: la diferencia se reporta como Deviation y la resuelve el Lead (P5).

A5 · El Plan como sustituto de la investigación. Construir directamente sobre el Plan sin validar sus vacíos ni resolver sus preguntas abiertas. Produce desarrolladores que consumen contexto pero no construyen criterio — y errores exactamente donde la documentación no llegaba. Comportamiento correcto: el Plan es el punto de partida de la verificación, no su reemplazo (P2).

A6 · Duplicación entre sistemas. Copiar a la Base datos que viven estructurados en SeaTable (servidores, credenciales, inventario), o viceversa. Toda copia se desactualiza por diseño y reintroduce el problema original. Comportamiento correcto: la narrativa referencia el registro; el Tech Spec une ambos en tiempo de ensamblaje.

A7 · Trabajo invisible. Resolver un hotfix, un ajuste rápido o un cambio de emergencia sin captura retroactiva de contexto. Los incidentes son el conocimiento de mayor valor futuro y el que con más frecuencia se pierde. Comportamiento correcto: ninguna tarjeta de Ops Health cierra sin su captura retroactiva (qué falló, causa raíz, qué cambió), asistida por ⑤.

A8 · Conocimiento cautivo en la herramienta. Alojar conocimiento durable en superficies propietarias del proveedor de IA — historial de chat, “memoria” del producto, proyectos de la plataforma, o un CLAUDE.md escrito a mano como fuente — en lugar de en la Base (Git/SeaTable). Esas superficies son espacio de trabajo, no registro: si la cuenta del proveedor se cerrara, el conocimiento se perdería o habría que rescatarlo a mano — el mal original (documentación fuera del flujo) reaparecido en una superficie nueva. La misma lógica aplica a las herramientas de publicación y de board: son capas intercambiables sobre contenido que vive en Git y SeaTable, no depósitos de conocimiento. Comportamiento correcto: todo conocimiento durable vive en la Base; las superficies del proveedor son efímeras por definición; CLAUDE.md es una proyección generada desde la Base, no una fuente. El régimen completo de independencia de herramienta (contrato portable / implementación intercambiable) se define en la sección 08.

8. Relación con el resto de la documentación

Para conocer	Sección
Quiénes componen el equipo, qué responde cada rol y la política de onboarding	03 · Estructura Organizacional
Qué agentes existen, quién es dueño de cada uno y su detalle operativo	04 · Roster de Agentes
Cómo fluye una tarjeta por los dos pipelines y dónde interviene cada agente	05 · Flujo de Trabajo
Dónde vive cada tipo de conocimiento y sus reglas de mantenimiento	06 · Arquitectura de Información
Las reglas de decisión del modelo (PRs de configuración, rituales, enmiendas, independencia de herramienta)	08 · Gobernanza
Las políticas normativas vigentes	09 · Políticas Vigentes

---

Historial de versiones

Versión	Fecha	Cambio
v3.3	2026-09-04	P5: la vía de enmienda se parte por dirección. Ampliar un criterio lo decide el dueño del Requirement y se comunica al Lead; relajarlo, quitarlo o ajustarlo exige su visto bueno — es la dirección que el principio existe para vigilar. El texto anterior no distinguía quién pedía la enmienda ni hacia dónde iba, y con eso ponía una ampliación del Director bajo aprobación ajena. Corregida además la numeración de ⑥ a ⑤ QA Runner en las prohibiciones.
v3.2	2026-09-04	P3 precisado por las fronteras de escritura: la obligación inmediata es registrar la corrección; aplicarla a la Base es de quien tiene el carril (03 §7.5.3). Se prohíbe explícitamente dejar sin escalar un dato erróneo material.
v3.1	2026-09-03	Corrección de coherencia: §3 propiedad 4 nombraba al agente ⑦ Release & Docs Updater, disuelto en la reforma de septiembre; hoy es ⑦ Publisher.
v3.0	2026-09-01	Reforma de la sesión 2026-09-01. Ciclo del contexto reescrito: el contexto lo transporta el sistema vía el Plan (Requirement + Tech Spec), no un agente Courier — ⑤ Context Courier disuelto (§4, §4.1). Diagrama del ciclo regenerado en Mermaid (sin ⑤). Nomenclatura de sistema en inglés, prosa en español. Renumeración del roster a 1–10. §4.1 pasa de “anatomía del brief” a “anatomía del contexto de una tarjeta”. P2/P5 actualizados (Tech Spec, Deviation, Ready gate, verification criteria). §6: L2 inicial = ⑤ y ⑨. A3 incorpora el caso del verification criteria pasivo; A7 referido a Ops Health. A8 conservado (texto de v2.1) y ampliado a herramientas de publicación y board. Front-matter YAML; destino docs/internal/.
v2.1	2026-07-20	Antipatrón A8 (conocimiento cautivo en la herramienta), en soporte del principio de independencia de herramienta (contrato portable / implementación intercambiable, sección 08).
v2.0	2026-07-03	Desarrollo a nivel de consulta 1A: razonamiento permanente (§2), principios desarrollados con razonamiento/ejemplo/prohibición (§5), escalera de autonomía completa (§6), antipatrones (§7), anatomía del brief (§4.1). Sustituye las secciones conceptuales del documento fuente integrado (T0).
v1.x	2026-07-02	Versiones del documento fuente integrado.