Datos, memoria y asistente (cuatro capas)
La promesa del producto es un cerebro de operaciones por cliente: recopilar los datos de cada cliente, acumular su memoria desde el día uno y luego ofrecer un chat en el negocio sobre esos datos — no un admin CRUD genérico. La arquitectura son cuatro capas, decididas en ADR-007 (ver Decisiones).
Un titular: un cerebro de operaciones por cliente en cuatro capas — SoR estructurado, ingesta dirigida por eventos, memoria por tenant (log de actividad ahora + pgvector después) y un asistente que es recuperación sobre SoR + memoria a través del motor existente.
Las cuatro capas
- Sistema de Registro — el "qué es" estructurado: datos de dominio por cliente (persona/
identidad ahora; oferta, inscripción, pago, certificado después), modelados en
@tedos/domain. Sustantivos y estado. Ver SoR del producto. - Ingesta — conectores + webhooks de entrada del tenant → upsert del SoR y append al log
de actividad, dirigida por eventos:
caja negra externa → webhook → upsert SoR → encolar objetivo. Sin un nuevo motor de máquina de estados — el estado vive en el SoR, las transiciones son objetivos cortos del motor. - Memoria — dos almacenes por tenant:
- un log de actividad por tenant — una tabla de eventos append-only, escrita en cada escritura del SoR. Construido desde el día uno, para que la memoria se acumule desde la primera escritura.
- memoria semántica pgvector — embeddings del contenido/eventos del cliente, en el mismo Postgres del producto (sin una BD vectorial separada). Construido en un esfuerzo posterior.
- Asistente — un chat por cliente sobre SoR + memoria, implementado como recuperación + el orquestador/evals/gate humano existente (sin un nuevo motor). Primero de cara al staff (el back-office del cliente); chat de usuario final después.
Decisiones fijadas (ADR-007)
| # | Decisión | Qué establece |
|---|---|---|
| D1 | Aislamiento esquema-por-cliente — un clúster, un esquema por proyecto, un esquema de control/registro para la lista de proyectos | Un accesor de BD con alcance por tenant selecciona el esquema; las tablas persona/identidad se vuelven la plantilla por cliente |
| D2 | pgvector en el Postgres del producto — sin BD vectorial separada | Los embeddings de memoria viven junto al SoR; una superficie operativa, un backup, una exportación |
| D3 | Log de actividad desde el día uno | El asistente es luego solo recuperación, no un proyecto de backfill |
| D4 | Chat = recuperación + el motor existente | Reutiliza el orquestador + evals + el gate humano; añade un paso de recuperación, nada más |
| D5 | Chat de staff antes que chat de usuario final | El back-office del cliente es el primer consumidor más seguro |
Por qué esquema-por-cliente
Esquema-por-cliente es la opción media deliberada en el espectro de aislamiento:
| Modelo | Aislamiento | Exportación | Veredicto |
|---|---|---|---|
BD compartida, columna tenant_id | el más débil | difícil (volcados filtrados) | rechazado — falla la promesa de exportación limpia |
| Esquema-por-cliente (un clúster) | fuerte (frontera de esquema) | limpia (volcado por esquema) | elegido |
| BD-por-cliente | el más fuerte | la más limpia | escalar después (residencia de datos / techo de escala) |
El accesor con alcance por tenant (D1) es la costura que hace que escalar a BD-por-cliente sea un movimiento mecánico, no una reescritura.
Reglas duras
- Los datos de tenant/cliente nunca entran al grafo del flujo de trabajo — el SoR del producto + la memoria son una base de datos separada del Plan Engine.
- El aislamiento por cliente se impone por la frontera de esquema, no por disciplina de consultas — todo acceso al SoR/memoria pasa por el accesor con alcance por tenant.
- Los secretos/PII nunca cruzan entre tenants y nunca entran al corpus de desarrollo; la PII fiscal permanece enmascarada.
Secuenciación
- Primero Capas 1–2: SoR esquema-por-cliente + contrato de ingesta + log de actividad.
- Memoria semántica pgvector después.
- Asistente más tarde (chat de staff primero).
- Conectores reales (Moodle, tienda, eventos, pagos/banco, CFDI, WhatsApp) aterrizan en esfuerzos posteriores; el contrato de ingesta entrega una costura de conector ahora. Ver Engine.