| OQ-CORE-01 | ¿Qué taxonomía vertical se entrega segunda? | PRD, FS-CORE-0012 | Retail. Es el vertical con más volumen de eventos y el que mejor ejercita el motor de reglas; salud y servicios traen datos sensibles que conviene abordar con el paquete legal ya revisado. |
| OQ-CORE-02 | ¿El historial de un contacto anónimo sobrevive si nunca se vuelve conocido? | PRD, FS-CORE-0006 | Se purga a los 90 días. Retener comportamiento de alguien que nunca se identificó es acumular dato personal sin finalidad, y la retención por plan es para clientes, no para visitantes. |
| OQ-CORE-03 | ¿Sembramos Centroamérica y México ahora? | FS-CORE-0001 | No. Sudamérica cubre el mercado objetivo; agregar un país es una fila más un normalizador, y hacerlo sin un tenant que lo necesite es código sin probar contra datos reales. |
| OQ-CORE-04 | ¿El email es único por tenant, o dos contactos pueden compartirlo? | FS-CORE-0002 | Pueden compartirlo. Los hogares y las casillas comerciales compartidas son reales. La unicidad que importa es la del documento; el email es un canal, no una identidad. |
| OQ-CORE-05 | ¿Normalizamos el teléfono a E.164 y rechazamos lo demás? | FS-CORE-0002 | Normalizar sí, rechazar no. Un teléfono mal formateado no impide operar como sí lo hace un documento inválido. Se guarda normalizado cuando se puede, en crudo cuando no, y se marca. |
| OQ-CORE-06 | ¿Una coincidencia de documento es identidad verificada por sí sola? | FS-CORE-0003 | Sí. Un documento con dígito verificador válido, dentro de un tenant, es la señal más fuerte que tenemos. Exigir una segunda señal deja fusiones legítimas sin hacer y llena la cola de revisión. |
| OQ-CORE-07 | Política de conflicto de campos al fusionar: ¿gana el más reciente o el superviviente? | FS-CORE-0003 | El no nulo más reciente. El superviviente se elige por antigüedad, no por calidad de datos; el dato más nuevo suele ser el correcto. Los descartados quedan en la fila de fusión igual. |
| OQ-CORE-08 | ¿Versionamos el texto de consentimiento, o es un string opaco del tenant? | FS-CORE-0004 | String opaco del tenant. El texto es suyo y su responsabilidad; versionarlo nosotros nos convierte en custodios de un contenido legal que no redactamos. |
| OQ-CORE-09 | ¿Encadenamos hashes en la auditoría ahora, o append-only más grants en F1? | FS-CORE-0005 | Append-only más grants en F1. La cadena de hashes protege contra un atacante con acceso de escritura a la base, que es un escenario donde ya perdimos. Es endurecimiento posterior, no F1. |
| OQ-CORE-10 | ¿Aceptamos eventos con occurred_at futuro, y con qué tolerancia? | FS-CORE-0006 | Sí, con 5 minutos de tolerancia. Los relojes de los POS se desincronizan. Más allá de eso se acepta el evento pero se estampa con received_at y se marca, para no corromper particiones ni ventanas. |
| OQ-CORE-11 | TTL de processed_job: ¿7 días, o más? | FS-CORE-0007 | 7 días. Excede con holgura la ventana máxima de reintentos (5 intentos con tope de 1 h). Más allá, la tabla crece sin comprar nada. |
| OQ-CORE-12 | ¿Un dead letter sin revisar escala tras N días? | FS-CORE-0007 | Sí, a los 7 días alerta con severidad mayor. Es la misma lógica que los referidos marcados: lo que no se revisa se olvida, y un dead letter olvidado es un efecto que nunca ocurrió. |
| OQ-CORE-13 | Profundidad y cantidad de nodos máxima en el DSL de segmentos | FS-CORE-0008 | Profundidad 5, 50 nodos. Suficiente para cualquier RFM realista, y acota el costo de la evaluación incremental para que un segmento no pueda degradar la ingesta. |
| OQ-CORE-14 | ¿Las plantillas RFM llegan con la taxonomía o como set aparte? | FS-CORE-0008 | Con la taxonomía. Son la razón por la que instalar una taxonomía vale la pena el primer día; separarlas convierte dos decisiones en lo que debería ser una. |
| OQ-CORE-15 | Duración de sesión de member: ¿30 días deslizantes, o menos? | FS-CORE-0009 | 30 días deslizantes, con re-prompt para canjear. El member entra poco y desde su teléfono; obligarlo a autenticarse cada vez mata el uso del portal. El canje sí vuelve a pedir. |
| OQ-CORE-16 | ¿El token exchange soporta refresh, o el tenant reintercambia? | FS-CORE-0009 | Reintercambia. El tenant ya tiene la sesión del member en su propio sistema; un refresh nuestro duplica un estado que él ya gobierna. |
| OQ-CORE-17 | ¿Se puede instalar más de una taxonomía, y cómo se resuelven colisiones? | FS-CORE-0012 | Sí, y una colisión de nombre de evento se rechaza nombrándola. Un retail con suscripciones es un caso real; resolver la colisión en silencio es peor que pedirle al tenant que elija. |
| OQ-CORE-18 | ¿Soportamos un tipo list (multivalor) en atributos personalizados? | FS-CORE-0011 | No en F1b. Multivalor complica el constructor de segmentos y la validación por un caso que casi siempre se modela mejor como taxonomía de eventos o como segmento. |