> ## Documentation Index > Fetch the complete documentation index at: https://internal.softcrum.com/llms.txt > Use this file to discover all available pages before exploring further. # Customer Core — modelo de datos > Las 25 tablas del schema core, cada una con su forma, su objetivo y el feature spec que la crea. Es el schema del que dependen los otros tres módulos de producto. Schema `core`. **No depende de ningún módulo y todos dependen de él** ([ADR-009](/adr/adr-009-customer-core-shared-context)). Es el único schema al que `loyalty`, `messaging` y `crm` pueden apuntar con una FK. La columna **Forma** es la de [ADR-024](/adr/adr-024-table-naming-and-base-structure): **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](/adr/adr-012-segment-dsl)) | 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](/adr/adr-014-billable-metric)) | 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.