Customer Core

Schema core. No depende de ningún módulo y todos dependen de él (ADR-009). Es el único schema al que loyalty, messaging y crm pueden apuntar con una FK. La columna Forma es la de ADR-024: A dominio con alcance de tenant · B append-only · C catálogo paramétrico.

Catálogos de plataforma

Transversales a toda la suite. Sin tenant_id: son de plataforma y se cachean.

Tabla	Forma	De qué es dueña	Spec
`currency`	C	Las monedas ISO 4217. Toda columna de monto lleva su `currency_code` — nunca un monto suelto	FS-CORE-0001
`country`	C	Los países soportados, con su normativa aplicable	FS-CORE-0001
`national_id_type`	C	Los tipos de documento por país, con su regex y su algoritmo de dígito verificador donde exista	FS-CORE-0001
`notification_channel`	C	Los canales que la plataforma conoce: `email`, `in_app`, `webhook`, `push`, `sms`, `whatsapp`, `live_activity`. La fila existe desde el día 1 aunque su adaptador llegue después	FS-CORE-0001

El contacto

Tabla	Forma	De qué es dueña	Spec
`contact`	A	La persona o empresa en la base del tenant. `national_id` normalizado, enmascarado por defecto, y cada acceso al valor completo se audita. `contact_kind` distingue persona de empresa	FS-CORE-0002
`contact_identity`	A	Los identificadores por los que un contacto se reconoce: email, teléfono, id externo del tenant. Separada porque un contacto tiene varios y porque la resolución de identidad opera sobre ellos	FS-CORE-0003
`contact_merge`	B	Qué contacto se fusionó con cuál, cuándo y por qué. Append-only: una fusión no se edita, y sin este registro no se puede deshacer ni explicar	FS-CORE-0003
`merge_suggestion`	A	Las fusiones candidatas que esperan revisión humana. Tiene estado, a diferencia de `contact_merge` que es historia	FS-CORE-0013

Consentimiento

Tabla	Forma	De qué es dueña	Spec
`consent`	B	El consentimiento como historia, no como booleano: cada otorgamiento y cada revocación es una fila con su fecha, su canal y su prueba. El estado actual se deriva; la historia es lo que se le muestra a un regulador	FS-CORE-0004
`consent_purpose`	C	Para qué se pidió el consentimiento. Granular por propósito, porque “acepto todo” no es consentimiento bajo la Ley 21.719	FS-CORE-0004

Comportamiento

Tabla	Forma	De qué es dueña	Spec
`tracked_event`	B	Todo evento de comportamiento que entra por `track`. La tabla de mayor volumen de la suite, particionada mensual por `occurred_at`. Toda consulta debe llevar el predicado de partición	FS-CORE-0006
`event_taxonomy`	A	Las plantillas verticales de eventos, instalables por el tenant como datos. La primera: suscripciones y servicios	FS-CORE-0012
`event_definition`	A	La definición de un evento concreto dentro de una taxonomía, con el schema de sus propiedades	FS-CORE-0012
`attribute_definition`	A	Los atributos personalizados que un tenant agrega a sus contactos, con su tipo y su validación	FS-CORE-0011

Segmentos

Tabla	Forma	De qué es dueña	Spec
`segment`	A	La definición del segmento: un AST en JSON deliberadamente restringido, para que la evaluación incremental por evento sea posible (ADR-012)	FS-CORE-0008
`segment_member`	A	Qué contacto pertenece a qué segmento ahora. Tabla intermedia N-M y proyección: se puede reconstruir desde la definición y los eventos	FS-CORE-0008

Identidad de member

Tabla	Forma	De qué es dueña	Spec
`member_session`	A	La sesión del cliente final autenticado. Vive acá y no en `identity` porque un member es un contacto autenticado, y el contacto pertenece a `core` (ADR-010)	FS-CORE-0009

Plataforma

Tabla	Forma	De qué es dueña	Spec
`audit_log`	B	Toda escritura de estado de toda la suite: actor tipado, entidad, acción, diff completo old→new y `correlation_id`. Particionada mensual. Es lo que hace innecesarios los `created_by` por fila	FS-CORE-0005
`processed_job`	B	La valla de idempotencia de los workers: qué job ya se procesó. Sin esto, un reintento duplica efectos	FS-CORE-0007
`dead_letter`	A	Los jobs que agotaron sus reintentos. Tiene estado porque se revisan y se reprocesan — de ahí el runbook de replay	FS-CORE-0007
`usage_snapshot`	B	El consumo medido en deltas de 30 minutos. Particionada mensual. Es la base de la facturación, así que su integridad es un problema comercial, no técnico	FS-CORE-0010
`billable_metric`	C	Las métricas facturables y su unidad. La principal es el contacto comercializable: con consentimiento activo en al menos un canal y no suprimido (ADR-014)	FS-CORE-0010

Derechos del titular

Tabla	Forma	De qué es dueña	Spec
`subject_request`	A	La solicitud de acceso, rectificación, supresión o portabilidad, con su plazo legal y su estado. Es lo que hace demostrable el cumplimiento de la Ley 21.719	FS-CORE-0014

Importación

Tabla	Forma	De qué es dueña	Spec
`import`	A	La corrida de importación CSV con su estado y su resumen	FS-CORE-0013
`import_row`	B	Cada fila del archivo y qué pasó con ella. Append-only: es la evidencia de por qué un contacto quedó como quedó	FS-CORE-0013

Lo que este schema no tiene

Ninguna tabla de puntos, envío ni actividad. core es dueño del contacto y su comportamiento; qué se hace con eso pertenece a los otros módulos.
Ningún usuario de consola. Esos son de identity (ADR-022), y el límite es regulatorio: con ellos Softcrum es responsable, con los contactos es encargado.
Ninguna FK hacia otro schema. core es la base: apunta hacia abajo, nunca hacia los lados.

⌘I

El sistema de specs

Identity

Loyalty

Messaging

CRM

Customer Core — modelo de datos

Catálogos de plataforma

El contacto

Consentimiento

Comportamiento

Segmentos

Identidad de member

Plataforma

Derechos del titular

Importación

Lo que este schema no tiene

​Catálogos de plataforma

​El contacto

​Consentimiento

​Comportamiento

​Segmentos

​Identidad de member

​Plataforma

​Derechos del titular

​Importación

​Lo que este schema no tiene

Catálogos de plataforma

El contacto

Consentimiento

Comportamiento

Segmentos

Identidad de member

Plataforma

Derechos del titular

Importación

Lo que este schema no tiene