3.1 Shadowing, AS-IS, glosario y reglas

Al terminar esta lección

• Registrar una sesión de shadowing separando observación, interpretación y pregunta para el debrief.
• Reconstruir handoffs y esperas a partir de observaciones y documentos, y dibujar un AS-IS que muestre quién decide y dónde hay vueltas.
• Detectar una colisión semántica en el vocabulario del cliente y resolverla en un glosario sin elegir una definición al azar.
• Formular reglas candidatas con identificador, condición, resultado, frontera, fuente, autoridad y estado, y detectar cuando una regla fue inventada en el código.

3. El negocio real aparece en los detalles

La entrevista te cuenta cómo la gente piensa que trabaja. La observación, los documentos y los casos excepcionales te muestran cómo el negocio realmente decide.

En el módulo anterior saliste de la primera reunión con un pedido concreto, el 48172, y con una lista de desconocidos con dueño. Ahora vas a buscar evidencia de otro tipo: mirar trabajo real, abrir las planillas que nadie mencionó y convertir lo que aprendiste en reglas que un desarrollador pueda implementar y un test pueda defender. El recorrido de esta lección sigue el orden en que se hace en campo:

1. Observar una ejecución real (shadowing).
2. Leer los documentos que esa ejecución usa (arqueología documental).
3. Dibujar el AS-IS cuando aparecen handoffs y vueltas.
4. Fijar el vocabulario para que dos áreas no hablen de cosas distintas con la misma palabra.
5. Escribir reglas verificables, con su fuente y su estado.
6. Triangular cuando dos fuentes se contradicen.

3.1 Shadowing: mirar el trabajo sin convertirlo en teatro

Problema que resuelve. En una entrevista, la vendedora te dice “cargo el pedido en el ERP y listo”. Cuando la mirás trabajar, abre WhatsApp Web, copia códigos a una hoja temporal, pega la lista en el ERP y, cuando dos códigos no existen, los busca en pedidos históricos del cliente. Nadie mintió: la entrevista captura el relato; el shadowing captura la secuencia. Cuando una tarea es frecuente o compleja, observar una ejecución real suele aportar más que una segunda hora de entrevista.

Definición operativa. Shadowing es observar una ejecución real de una tarea, sin dirigirla, registrando hechos con hora y dejando las preguntas para un debrief corto posterior. No interrumpís cada treinta segundos. Registrás tiempo, entrada, herramienta, decisión, handoff, espera, corrección y dato ausente. La pregunta aparece después del hecho, no antes: “Vi que abriste dos veces la planilla de descuentos, ¿qué estabas comparando? ¿Qué habría hecho que eligieras otro precio?”.

Ejemplo en Nexo. Así se ve una nota de campo útil. Fijate que cada línea de observado es algo que una cámara podría haber filmado, y que lo interpretado vive en otro campo, con una pregunta pendiente:

1id: NOTA-01
2sesion: shadowing-ventas-01
3observador: analista
4tarea: "Cargar un pedido que llegó por WhatsApp"
5eventos:
6  - t: "08:17"
7    observado: "Abre WhatsApp Web y copia 14 códigos a una hoja temporal."
8    herramienta: [whatsapp-web, excel-temporal]
9    tipo: entrada
10  - t: "08:21"
11    observado: "Pega la lista en el ERP. Dos códigos no existen; no los rechaza."
12    herramienta: [erp]
13    tipo: correccion
14    interpretacion: "Podría ser producto renumerado, abreviatura habitual o error real."
15    pregunta_debrief: "¿Cómo decidís si un código inexistente es un error o un producto renumerado?"
16  - t: "08:24"
17    observado: "Busca los dos códigos en pedidos históricos del mismo cliente."
18    herramienta: [erp, historial-cliente]
19    tipo: consulta
20    dato_ausente: "No hay tabla de equivalencias a mano."
21  - t: "08:42"
22    observado: "Abre PRECIOS_ESPECIALES_2026.xlsx y filtra por CUIT del cliente."
23    herramienta: [excel-precios-especiales]
24    tipo: consulta
25    pregunta_debrief: "¿Qué significa la columna OK y quién pone las iniciales?"
26espera_total_observada: null   # no se mide aún; no inventamos duraciones

Antipatrón. El shadowing se vuelve teatro cuando la persona observada actúa para vos (“así se hace según el procedimiento”) o cuando vos corregís mientras mira. También cuando tus notas mezclan lo que viste con lo que concluiste: “la vendedora no confía en el ERP” no es una observación, es una interpretación que necesita su pregunta de debrief.

Efecto observador. Que alguien te mire cambia cómo se trabaja: la persona se acerca al procedimiento ideal, va más despacio o evita los atajos que usa todos los días (es el llamado efecto Hawthorne). No se elimina; se reduce y se tiene en cuenta:

• Antes de empezar, explicá para qué observás y pedí permiso: venís a entender el proceso, no a evaluar a la persona.
• Observá más de una ejecución, y si podés en días distintos: los atajos reaparecen cuando la persona se acostumbra a tu presencia.
• Contrastá lo observado con rastros que no dependen de que estés ahí: horas del historial de WhatsApp, cambios de estado en el ERP, marcas en las planillas.
• Si una ejecución se ve mucho más prolija que lo que muestran esos rastros, anotalo como pregunta para el debrief, no como conclusión.

Cómo se verifica. Una nota de campo es buena si otra persona, sin haber estado, puede reconstruir la secuencia y señalar qué parte es hecho y cuál es lectura tuya. Probalo con este ejercicio:

3.2 Arqueología documental: las reglas que viven en Excel y PDF

Problema que resuelve. Los documentos operativos contienen conocimiento que nadie verbaliza en una entrevista. Una planilla puede revelar categorías de cliente, una fórmula puede codificar un descuento, un PDF puede mostrar estados reales y una cadena de WhatsApp puede revelar quién autoriza una excepción. El objetivo no es copiar esos artefactos al software, sino usarlos como evidencia del dominio.

Definición operativa. Arqueología documental es inventariar cada artefacto que interviene en una decisión y registrar, para cada uno: quién lo mantiene, cuándo se actualiza, qué decisión sostiene, qué semántica esconde y qué riesgo introduce. Un Excel no es una base de datos mal hecha que debamos copiar. Es evidencia de que alguien necesitó conservar cierto conocimiento. Mirá fórmulas, validaciones, columnas ocultas, colores, propietario, frecuencia de actualización y los casos que no entran en la estructura.

Ejemplo en Nexo. La planilla de acuerdos de precio, PRECIOS_ESPECIALES_2026.xlsx (la misma “planilla de acuerdos históricos” que apareció en la reunión 1), revela que algunos acuerdos tienen fecha de vencimiento, otros no, y varios se expresan como precio neto en lugar de porcentaje. Esa diferencia cambia el dominio y la autoridad del cálculo. Este es el inventario documental que sostiene esa afirmación:

1artefactos:
2  - id: DOC-01
3    nombre: PRECIOS_ESPECIALES_2026.xlsx
4    mantiene: "Responsable comercial"
5    actualizacion: "Manual, sin frecuencia fija"
6    sostiene_decision: "Precio de una línea cuando el cliente tiene acuerdo"
7    columnas: [CUIT, SKU, precio, vencimiento, OK]
8    semantica_oculta:
9      - "OK = 'lo habló alguien de dirección'; no siempre se sabe quién."
10      - "Algunas filas no tienen vencimiento; esos acuerdos se siguen aplicando 'hasta nuevo aviso'."
11      - "Algunos acuerdos son precio neto; otros son porcentaje sobre lista."
12    riesgo: "Precio incorrecto o vencido aplicado sin rastro de quién lo aprobó."
13    pregunta_abierta: "¿Qué fuente prevalece si contradice al ERP?"
14  - id: DOC-02
15    nombre: "Excel personal de equivalencias de SKU"
16    mantiene: "Cada vendedor (copia propia)"
17    ejemplo: "A-184 → A-184B desde 2026-05-01"
18    riesgo: "Cada copia puede divergir; no hay vigencia explícita en todas las filas."
19  - id: DOC-03
20    nombre: "Planilla de administración con columna 'comprometido'"
21    mantiene: "Administrativa"
22    actualizacion: "Cada mañana, desde un PDF de saldos del ERP"
23    la_consulta: "Laura (administración/crédito), antes de autorizar"
24    sostiene_decision: "Si un pedido entra o no en el límite de crédito"
25    riesgo: "Se desactualiza durante el día; los cheques se cargan al final."

Una vez que tenés el inventario, podés hacerle preguntas a los datos. Si el cliente te entrega una exportación del Excel, unos minutos de SQL exploratorio valen más que una hora de debate sobre cuántas filas “están mal”. Supongamos que la exportación se cargó en una tabla temporal de análisis (no del sistema futuro):

1-- Tabla de trabajo cargada desde PRECIOS_ESPECIALES_2026.xlsx (solo para análisis)
2-- precios_especiales(cuit text, sku text, valor numeric, vencimiento date, ok text)
3​
4-- 1. Acuerdos sin vencimiento: ¿cuántos y de qué clientes?
5SELECT cuit, count(*) AS acuerdos_sin_vencimiento
6FROM precios_especiales
7WHERE vencimiento IS NULL
8GROUP BY cuit
9ORDER BY acuerdos_sin_vencimiento DESC;
10​
11-- 2. Mismo cliente y SKU con más de un acuerdo vigente: ¿cuál gana?
12SELECT cuit, sku, count(*) AS acuerdos
13FROM precios_especiales
14WHERE vencimiento IS NULL OR vencimiento >= current_date
15GROUP BY cuit, sku
16HAVING count(*) > 1;
17​
18-- 3. ¿Precio neto o porcentaje? Heurística: un 'valor' menor a 100 parece porcentaje.
19--    Es una hipótesis para preguntar, no una regla.
20SELECT CASE WHEN valor < 100 THEN 'probable porcentaje' ELSE 'probable precio neto' END AS tipo,
21       count(*) AS filas
22FROM precios_especiales
23GROUP BY 1;
24​
25-- 4. Filas sin iniciales en OK: no se sabe quién las autorizó
26SELECT count(*) AS sin_aprobador
27FROM precios_especiales
28WHERE ok IS NULL OR btrim(ok) = '';

Ninguna de esas consultas decide nada. Producen preguntas con cifras para llevar a Comercial: “la consulta 2 devuelve filas, ¿cuál de los dos acuerdos aplica?”. El criterio de decisión sigue siendo de quien tiene autoridad sobre el precio.

3.3 Dibujar el AS-IS solo cuando ayuda a revelar handoffs

Nexo parece tener un flujo lineal hasta que lo recorremos con roles. El pedido puede saltar de ventas a crédito, volver a ventas, pasar a depósito, volver por una sustitución y recién entonces entrar en facturación. Un mapa AS-IS vale la pena porque permite discutir quién decide, dónde se espera y qué dato cruza cada handoff. No es UML; es un diagrama conceptual de proceso.

Un AS-IS útil cumple tres condiciones. Tiene carriles por rol, para que cada decisión tenga dueño visible. Tiene vueltas, es decir, flechas que regresan, porque el trabajo real vuelve atrás. Y no incluye todavía componentes del sistema futuro: si aparece una “API de precios” en el mapa, ya estás diseñando. Este es el pedido 48172 en forma de AS-IS conceptual:

Fijate qué muestra el diagrama que una lista de pasos esconde: hay un ciclo (d2 → v5 → c2 → v6 → d1), el pedido pasa dos veces por ventas, hay una espera de crédito con una bifurcación que nadie escribió (poca diferencia: Laura; mucha: Marta, como dijo la vendedora en la reunión 1), y la decisión de crédito depende de una planilla que no está en el ERP. Esas cosas son el tipo de hallazgo que mueve el software. El 48172 recorrió el camino “poca: sí”; las otras ramas salen de lo declarado en la reunión 1, no de este pedido.

Cómo se verifica. Otra persona tiene que poder seguir un episodio sobre el mapa, señalar quién decide cada bifurcación y marcar dónde faltan datos. Si el diagrama termina siendo una cadena limpia sin esperas ni vueltas mientras la operación real está llena de llamadas y correcciones, probablemente modelaste el procedimiento ideal y no el trabajo observado.

3.4 Construir un glosario porque la misma palabra puede esconder dos procesos

Problema que resuelve. El glosario no es un diccionario de términos técnicos. Es una herramienta para detectar colisiones semánticas. En Nexo, “pedido”, “reserva”, “confirmado”, “facturado” y “despachado” deben tener una definición que negocio y desarrollo puedan usar sin traducir mentalmente.

El caso de “confirmado”. La colisión apareció en la reunión 1: ventas llamaba “confirmado” al pedido aceptado comercialmente y depósito, al pedido “ya impreso”. El shadowing la confirma y la precisa: para ventas, “confirmado” es el pedido que ya pasó crédito; para depósito, es el que tiene la hoja impresa recibida y el stock verificado en la ubicación antes de preparar. Si desarrollo elige una definición sin hacer visible la colisión, los estados del sistema van a codificar una discusión no resuelta: el día que un pedido “confirmado” llegue a depósito sin stock físico, cada área tendrá razón según su definición.

Cuando dos áreas usan la misma palabra para cosas distintas, no se resuelve eligiendo una al azar: se documentan los dos conceptos y se negocia un nombre no ambiguo. Por ejemplo, CONFIRMADO_COMERCIAL y LISTO_PARA_PREPARAR, o cambiar el vocabulario hasta que todos reconozcan el mismo evento. Esos nombres son un ejemplo de cómo se resuelve la colisión; los estados definitivos del pedido se cierran más adelante, con el modelo de estados.

Una entrada de glosario con valor para el diseño tiene más campos que “término: definición”:

1terminos:
2  - termino: "pedido confirmado"
3    estado_del_termino: COLISIÓN
4    significados:
5      - area: Ventas
6        definicion: "El pedido pasó la evaluación de crédito (aceptado comercialmente)."
7        fuente: "Reunión 1 (vendedora); relato del pedido 48172"
8      - area: Depósito
9        definicion: "La hoja impresa llegó y el stock se verificó en la ubicación antes de preparar."
10        fuente: "Reunión 1 (operario de depósito: 'ya impreso'); shadowing en depósito"
11    propuesta_de_nombres: ["CONFIRMADO_COMERCIAL", "LISTO_PARA_PREPARAR"]
12    quien_decide: "Dirección, con ventas y depósito en la misma reunión"
13  - termino: disponible
14    estado_del_termino: COLISIÓN
15    significados:
16      - area: Ventas
17        definicion: "Stock on-hand que muestra la pantalla del ERP."
18      - area: Depósito
19        definicion: "Lo que se puede prometer después de descontar lo ya reservado (marcado a mano en la pizarra)."
20    nota: "Fórmula candidata: onHand - reservado. 'Reservado' hoy es una marca manual en la pizarra."

3.5 De una frase informal a una regla verificable

Problema que resuelve. Una regla existe con o sin software. El sistema la implementa o la asiste, pero no la inventa. El error frecuente es registrar “validar crédito” como regla; eso es una intención. La regla tiene que decir qué relación entre saldo, límite, categoría y monto produce qué resultado.

Definición operativa. Una regla de negocio candidata tiene: identificador, condición, resultado (las dos ramas cuando aplica), frontera (ejemplos límite, o qué falta para tenerlos), fuente, autoridad que la confirma o que autoriza su excepción, y estado de validación. El estado es uno de tres: confirmada (alguien con autoridad la validó), provisional (hay evidencia, pero falta validar algo; es lo que en las notas aparece como “a validar”) o BLOCKED (no puede avanzar hasta que alguien con autoridad la defina). Para que una regla pueda viajar hasta los tests necesita todos esos campos o una nota explícita de qué falta.

Esta es la anatomía, escrita como un registro:

1id: RN-01
2enunciado: "Un cliente ESTÁNDAR no puede confirmar un pedido si saldoDeudor + totalPedido supera limiteCredito."
3cuando: "categoria == ESTANDAR"
4entonces:
5  si_supera_limite: "el pedido no se confirma"
6  si_no_supera: "continúa la evaluación del pedido"
7frontera:
8  - "saldo + pedido == límite → permitido"
9  - "saldo + pedido == límite + 1 centavo → bloquea"
10fuente:
11  - 'Marta, reunión 1: política declarada ("No debería pasar")'
12  - "Laura, reunión 1: práctica mostrada en pantalla compartida"
13autoridad_que_confirma: "Laura (administración/crédito)"
14autoridad_de_excepcion: "Ver RN-02 para Platino; la autorización no modifica el límite permanente"
15pendiente: "Qué entra en saldoDeudor: la definición de exposición de crédito sigue abierta (U-01)"
16estado: confirmada   # fórmula y frontera; la definición de saldo sigue abierta

Fijate en lo que no figura como fuente: el pedido 48172. Su cliente es Platino, así que es evidencia de RN-02, no de una regla para clientes ESTÁNDAR. Usarlo para RN-01 sería tomar una excepción como prueba de la regla general.

La tabla canónica de reglas del caso Nexo, con su estado de validación al final de esta etapa, es la siguiente. Separa dos clases de reglas: las del proceso actual, que ya se observan en la operación, y las políticas o invariantes del sistema futuro, que se derivan del negocio pero hoy no existen en ningún lado. Que una regla sea una “invariante técnica derivada del negocio” describe su naturaleza, no su estado: el estado sigue siendo confirmada, provisional o BLOCKED.

RN-06 y RN-07 se incorporan en esta etapa porque la evidencia las pide. RN-06 aparece cuando mirás el WhatsApp de un cliente que reenvía la foto del pedido porque “no le contestaron”: sin una regla explícita, dos cargas del mismo pedido son dos pedidos. Pero no todo pedido repetido es un reenvío, y cómo distinguirlos es una pregunta para ventas. El mecanismo técnico que reconoce la misma intención (un identificador del pedido, el requestId) se define en el módulo de especificación; acá la regla queda en términos de negocio. RN-07 aparece con la evidencia del depósito (sección 3.7): si el negocio quiere sostener una reserva mientras se espera una autorización, el tiempo que puede sostenerla es una decisión que nadie tomó.

Cómo se ve una regla cuando llega a código

Una regla bien escrita se puede traducir sin adivinar. RN-01, con su frontera, es casi una función pura. Las cifras van en centavos enteros para que el “un centavo más” sea exactamente un centavo:

1export type CreditCheck =
2  | { kind: "within_limit" }
3  | { kind: "exceeds_limit"; excessCents: number };
4​
5/** RN-01: ESTÁNDAR no puede confirmar si saldo + pedido supera el límite. */
6export function checkStandardCredit(input: {
7  balanceCents: number;
8  orderTotalCents: number;
9  creditLimitCents: number;
10}): CreditCheck {
11  const exposure = input.balanceCents + input.orderTotalCents;
12  if (exposure <= input.creditLimitCents) return { kind: "within_limit" }; // frontera: igual al límite → permitido
13  return { kind: "exceeds_limit", excessCents: exposure - input.creditLimitCents };
14}

Compará ese <= con el texto de la regla: “igual al límite: permitido; un centavo más: bloquea”. Esa frontera es la que, más adelante, se convierte en dos tests: uno con saldo más pedido exactamente igual al límite y otro con un centavo más. Una regla sin frontera obliga al desarrollador a elegir < o <= por intuición.

Ahora el caso inverso: código que ya implementa “reglas” que nadie escribió. Revisalo contra la tabla de arriba.

3.6 Triangulación: cuando dos fuentes se contradicen

En una empresa nueva casi nunca existe una única fuente de verdad. El responsable comercial describe una política, el operador aplica una excepción aprendida por costumbre y el sistema heredado contiene una validación distinta. La tarea del analista no es elegir la versión que “suena más lógica”, sino registrar la contradicción y obtener evidencia suficiente para resolverla.

Para cada regla crítica buscá al menos dos fuentes independientes cuando sea razonable: entrevista + sistema, entrevista + documento, sistema + observación. Así se registra una contradicción, sin resolverla por cuenta propia:

1id: TRI-01
2tema: "Tolerancia de crédito de clientes PLATINO"
3afirmaciones:
4  - fuente: "Marta (reunión 1)"
5    tipo: DECLARACIÓN
6    texto: "No debería pasar."
7    contexto: "Respuesta a qué pasa si la cuenta está por encima del límite."
8  - fuente: "Vendedora (reunión 1, min 4)"
9    tipo: DECLARACIÓN
10    texto: "Con Platino, si es poco, se pide autorización. Ayer pasó."
11    evidencia_ligada: EV-03
12  - fuente: "Audio de autorización del pedido 48172 (cliente Platino)"
13    tipo: HECHO
14    texto: "Laura autorizó por audio un pedido que superaba el límite."
15  - fuente: "ERP (configuración de límites)"
16    tipo: HECHO
17    texto: "Existe un único campo de límite por cliente; no hay campo de tolerancia."
18contradiccion: "Política declarada por la dueña ('No debería pasar') vs. práctica relatada y documentada (un pedido Platino sobre el límite se autorizó por audio)."
19no_es_contradiccion: "El ERP sin campo de tolerancia no contradice a nadie: muestra que la excepción hoy vive fuera del sistema."
20quien_puede_cerrarla: "Dirección, con administración/crédito"
21estado_regla: "RN-02 BLOCKED"
22siguiente_paso: "Pedir a Laura tres autorizaciones recientes con montos y quién las dio."

La autoridad para resolver una contradicción depende del tema. Una regulación fiscal puede estar por encima del dueño. Un operador puede saber mejor cómo funciona el proceso actual. El responsable comercial puede decidir la política futura. Tu trabajo es identificar la naturaleza de la contradicción y llevarla a quien tiene legitimidad para cerrarla.

3.7 Nexo cambia otra vez: la reserva pasa a ser un requisito

Esta decisión cambia el problema. Hasta ahora la pizarra era evidencia de un workaround; ahora la reserva es un concepto del dominio y un requisito. Antes podíamos pensar que solo había que leer stock. Ahora sabemos que el sistema debe gobernar disponibilidad concurrente. También sabemos que el TTL de una reserva no está definido (RN-07). Eso bloquea una parte del diseño, pero no impide seguir modelando la invariante: la disponibilidad no puede quedar negativa (RN-05).

Con el pedido 48172 se ve la diferencia entre el dato del ERP y la realidad que gobierna la decisión. AX-442 tiene 8 unidades on-hand en el depósito CBA. Pero la pizarra del depósito tiene 6 unidades ya reservadas (marcadas a mano) para pedidos impresos que todavía no se prepararon, y el ERP no las descuenta. El pedido 48172 pide 3.

Ese faltante es una carrera digital entre pedidos, no un error de conteo: en el estante había 8, nadie mintió ni contó mal; faltaba el concepto de reserva. Más adelante vas a separar esto de la discrepancia física, cuando el stock del estante no coincide con ningún registro.

Errores frecuentes

• Síntoma: tus notas dicen “el vendedor no confía en el sistema” y nadie puede verificarlo. Causa: mezclaste interpretación con observación. Corrección: dividí la nota en observado, interpretacion y pregunta_debrief, y hacé la pregunta antes de usar la conclusión.
• Síntoma: el Excel se convierte en tabla con las mismas columnas. Causa: lo trataste como esquema y no como evidencia. Corrección: por cada columna anotá qué decisión sostiene, quién la mantiene y qué semántica esconde, antes de pensar en el modelo.
• Síntoma: desarrollo y depósito discuten por qué un pedido “confirmado” llegó sin stock. Causa: una colisión semántica no se hizo visible y alguien eligió una definición. Corrección: marcá el término como colisión y negociá dos nombres.
• Síntoma: la regla dice “validar crédito”. Causa: registraste una intención. Corrección: reescribila como condición, resultado, frontera y fuente; si falta alguno, anotá qué falta y quién lo resuelve.
• Síntoma: aparece una tolerancia “provisoria” en el código. Causa: se llenó un valor desconocido para destrabar el trabajo. Corrección: estado BLOCKED, parámetro sin valor productivo y pregunta con dueño.
• Síntoma: el AS-IS es una línea recta y la operación está llena de llamadas. Causa: modelaste el procedimiento ideal. Corrección: volvé a un episodio real y agregá las esperas, las vueltas y los carriles de quién decide.

Ejercicios

Del lenguaje del cliente a una regla

IA en esta fase

Un prompt de trabajo para extraer reglas candidatas sin que el agente las decida:

1Rol: asistente de discovery. No decidís reglas de negocio.
2​
3Fuentes (cada una con id, fecha y dueño):
4- NOTA-01: notas de shadowing de ventas (adjunto)
5- DOC-01: extracto de PRECIOS_ESPECIALES_2026.xlsx (adjunto, 30 filas)
6- ENT-01: transcripción abreviada de la primera reunión (adjunto)
7​
8Tarea:
91. Listá reglas candidatas en una tabla: id provisorio, condición, resultado,
10   fuente (NOTA/DOC/ENT + fragmento textual), ejemplo frontera si existe.
112. Si la fuente no alcanza para una condición o un valor, escribí
12   "FALTA: <qué> / pregunta: <a quién>". No completes el valor.
133. Listá contradicciones entre fuentes. No elijas una.
14​
15Restricciones: no inventes porcentajes, plazos ni umbrales. Si algo suena
16razonable pero no está en las fuentes, va en "FALTA".

Cómo revisar la salida. Primero buscá números: cada porcentaje, plazo o umbral en la respuesta tiene que tener una cita textual; si no la tiene, es una invención. Después verificá a mano tres filas al azar contra la fuente citada. Por último comprobá que las contradicciones estén listadas como pares de afirmaciones y no fusionadas en una “regla final”. Si el agente sintetizó una regla donde las fuentes se contradicen, descartá esa fila y volvé a preguntar al dueño de la decisión.

Para llevarte

• Una nota de campo separa lo observado de lo interpretado; las preguntas esperan al debrief y parten de un hecho.
• Un documento operativo es evidencia de una necesidad, no un esquema para copiar: anotá dueño, frecuencia, decisión que sostiene y semántica oculta.
• Un AS-IS útil tiene carriles por rol, esperas y vueltas, y no muestra componentes del sistema futuro.
• Si dos áreas usan la misma palabra para cosas distintas, el glosario registra la colisión y se negocian dos nombres.
• Una regla verificable tiene id, condición, resultado, frontera, fuente, autoridad y estado; lo que falta se marca BLOCKED con dueño, nunca se completa con una cifra “razonable”.
• La autoridad depende del dato: el ERP, la planilla, el operador y el responsable comercial mandan cada uno sobre cosas distintas.