Propósito: Define los tipos canónicos de eventos del sistema según la taxonomía del Event Protocol v1.0. Esta base de datos NO registra eventos ocurridos (eso es responsabilidad de Supabase), solo define su semántica, clasificación y propiedades observables.

Campo Tipo en Notion Configuración estricta
EVENT_TYPE Title Identificador del tipo canónico de evento (formato: EVT-CATEGORÍA-NOMBRE, ejemplo: EVT-EA-CONF-VERDAD, EVT-EO-TAREA-COMPLETADA). Este identificador es estable y se usa en toda la documentación del sistema.
Nombre_Evento Text Nombre canónico legible del tipo de evento (ejemplo: "Conflicto de Verdad Notion-Supabase", "Tarea Completada Exitosamente").
Tipo_Evento Select Taxonomía del Event Protocol v1.0: EO (Operativo - hecho esperado) · ED (Desviación - rompe expectativas) · EE (Error - fallo técnico) · EA (Alucinación - contradice verdad documentada) · ECV (Conflicto de Verdad - discrepancia Notion-Supabase).
Descripción_Canónica Text Descripción factual y precisa de qué representa este tipo de evento. Define qué características debe tener un hecho observable para clasificarse bajo este tipo, sin especificar qué hacer al respecto.
Módulo_Origen_Típico Multi-select Módulos del sistema que típicamente pueden generar este tipo de evento (ejemplo: M3, M14, M16, M22). Este campo es descriptivo, no restrictivo: otros módulos pueden generar el evento si las condiciones se cumplen.
Impacto_Gobernanza Select Impacto normativo del evento según el Event Protocol v1.0: Continúa (el sistema puede continuar operando) · Escala (requiere notificación a gobernanza pero no detiene) · Detiene (debe detener la ejecución inmediatamente). Este campo clasifica el impacto normativo, no ejecuta comportamiento.
Fuente_Documental Relation Relación a BD Referencias Normativas. Apunta a la sección del Event Protocol v1.0 que define formalmente este tipo de evento.
ADR_Relacionado Relation (multi) Relación a BD ADRs. Señala decisiones arquitectónicas que justifican o modifican el tratamiento de este tipo de evento.
Referencia_Protocolo URL Enlace directo al Event Protocol v1.0 en GitHub, idealmente a la sección específica que define este evento.
Estructura_Obligatoria Text Lista de campos que debe contener un evento real de este tipo cuando ocurre (ejemplo: "event_id, timestamp, módulo_origen, descripción_factual, impacto_potencial, estado_resultante, acción_tomada, referencia_normativa"). Permite validar que eventos registrados en Supabase cumplen con el protocolo.
Owner_Normativo Person Responsable de la definición semántica de este tipo de evento. Autoridad para clarificar dudas de clasificación o proponer refinamientos taxonómicos.
Fecha_Definición Date Fecha en que se definió oficialmente este tipo de evento en el protocolo. Permite trazabilidad histórica de la evolución de la taxonomía.
Estado Select Activo · Deprecado. Un tipo de evento deprecado ya no debe usarse para clasificar nuevos eventos, pero eventos históricos clasificados así siguen siendo válidos.
Contexto_Adicional Text Campo opcional exclusivamente para ejemplos concretos de cuándo aplicar esta clasificación, aclaraciones sobre casos límite, o notas sobre la evolución histórica de la definición. No puede modificar la semántica del evento ni introducir reglas de comportamiento.

Aclaración arquitectónica crítica: Esta tabla define la taxonomía de eventos (los tipos posibles), no registra eventos individuales ocurridos. Cuando el sistema detecta un hecho observable, lo clasifica usando esta taxonomía y lo registra en Supabase como evento individual. Esta base de datos es normativa (define qué tipos existen), Supabase es factual (registra qué ocurrió). La separación previene que la definición de tipos se contamine con la operativa de registro.

Decisión arquitectónica fundamental sobre causalidad: Esta base de datos NO contiene un campo SOP_Aplicables ni ninguna relación que señale qué hacer cuando este evento ocurre. Esta omisión es deliberada y obligatoria. Los eventos son hechos observables que se clasifican y registran. Los SOPs son contratos que declaran bajo qué condiciones son invocables. La decisión de qué SOP invocar ante un evento es responsabilidad de motores de decisión (M14) o tablas de decisión explícitas, nunca del propio evento. Esta separación garantiza que los hechos no gobiernan el sistema y que toda decisión es auditable y explícita.