01 · Resumen ejecutivo

FARO ve foto sin timeline; ve película con timeline

FARO-UI-005 construye la vista visual y auditable de todo lo que ocurre alrededor de una tensión, una acción o una evidencia: detección, asignación, cambio de estado, evidencia cargada, aprobación, rechazo, bloqueo, escalamiento, cierre, impacto Score y reporte. Una sola pregunta de dirección: ¿qué pasó realmente?

Una empresa no se controla mirando solo el resultado final. Se controla viendo la secuencia de decisiones, acciones, evidencias, bloqueos y cierres. El estado actual no alcanza: "Acción cerrada" no responde quién la cerró, cuándo, con qué evidencia, quién la aprobó, qué se rechazó antes ni qué impacto tuvo. El timeline responde todo eso desde una sola fuente.

FARO soporta 3 niveles de timeline sobre la misma tabla canónica:

  • Timeline de acción — qué pasó con ACT-COM-001 específicamente, desde creación hasta cierre con evidencia aprobada.
  • Timeline de tensión — qué pasó desde que se detectó TNS-001: acciones generadas, responsables, vencimientos, cierre.
  • Timeline ejecutivo (empresa / período) — qué pasó en la semana 22 en Empresa Demo Cuyo S.A.: 6 tensiones detectadas, 14 acciones creadas, 8 iniciadas, Score 74 → 66.

Detrás de los 3 niveles vive una sola tabla: faro.execution_events con 40 event_types canónicos agrupados en 4 categorías ejecutivas (tensión 8 · acción 15 · evidencia 8 · score 5) más 4 transversales de comentario/sistema/asignación/vencimiento. Esto aplica la Decisión D3 del fundamento: un único log de ejecución, no 5 tablas dispersas (action_events, evidence_events, score_events, etc.).

El timeline visual no reemplaza el audit_log técnico de gobierno (FARO-GOV-001). Lo traduce a gestión. El audit_log demuestra cambios sensibles a un auditor; el timeline ejecutivo explica a un gerente qué decisión se tomó cuándo y con qué respaldo. Misma materia prima, dos audiencias distintas.

Este documento es P1 crítico para trazabilidad, confianza y reporte ejecutivo. Define DDL, función helper, vista unificada, contrato API, componentes UI, mockup visual, reglas visuales por familia, performance, RLS, tests mínimos, integración con FARO Score y conexión con reporte semanal. Si una acción se cierra sin dejar evento, FARO miente; el timeline existe para que no pueda mentir.

02 · Tesis y diferencia con auditoría legal (GOV-001)

Auditoría visual ejecutiva vs auditoría legal técnica

El timeline no es un historial decorativo: es una herramienta de control. Pero no es la única auditoría del sistema. Coexiste explícitamente con FARO-GOV-001 (audit_log legal). Mismo evento, dos lentes distintos.

Regla dura. El timeline visual es la cara visible de la ejecución; el audit_log es la trazabilidad legal de cada cambio sensible. Confundirlos lleva a dos errores típicos: (1) un timeline lleno de eventos técnicos que nadie entiende, o (2) un audit_log demasiado curado que ya no sirve a un auditor. FARO los mantiene separados a propósito.

FARO-UI-005 · Esta pieza

Timeline visual ejecutivo

  • Objetivo Entender la ejecución del negocio.
  • Usuario Gerencia general, dueño, responsables operativos.
  • Muestra Eventos relevantes ejecutivos con título claro.
  • Formato Narrativo visual cronológico, badges, iconos.
  • Nivel Ejecutivo-operativo, explicativo.
  • Tabla faro.execution_events + v_execution_timeline.
  • Retención Vida útil del proyecto + archivado funcional.
  • MVP Completo: 3 niveles, 40 event_types, filtros, Score impact.

Qué resuelve el timeline visual

Problema operativoSolución del timeline
No saber quién hizo quéMuestra actor por evento (usuario / sistema / IA / integración)
Cierres dudososMuestra evidencia cargada y su validación
Rechazos invisiblesRegistra rechazo con motivo y aprobador
Bloqueos eternosMuestra cuándo se bloqueó y por qué
Escalamientos informalesRegistra motivo y destino del escalamiento
Cambios de responsable confusosDeja trazabilidad de from/to por responsable
Score inexplicableConecta eventos con recuperación o penalización
Reportes sin respaldoPermite auditar cada afirmación del reporte semanal
Discusiones internasCambia opinión por evidencia con fecha y actor

Principio ejecutivo

El timeline debe permitir ver, sin esfuerzo, los nueve elementos esenciales de una decisión operativa: hecho · actor · momento · estado anterior · estado nuevo · evidencia · impacto · riesgo · comentario. Si un evento no aporta control, no entra al catálogo. Si aporta control, queda. Sin ese filtro, el timeline se vuelve carnaval y nadie lo mira.

03 · 3 niveles de timeline

Acción · Tensión · Empresa-semanal

FARO no impone un solo timeline. Soporta tres niveles según la pregunta ejecutiva. Los tres consumen la misma tabla execution_events filtrada por entidad o por período.

Nivel 1 · Operativo

Timeline de acción

"¿Qué pasó con ACT-COM-001 específicamente?"

Vista del responsable y del aprobador. Cronología completa de la acción individual, desde creación hasta cierre con evidencia aprobada. Es la vista por defecto en la pantalla de detalle de acción (UI-003).

ACT-COM-001 → creada (sistema) → iniciada (Juan Pérez) → evidencia cargada (Juan Pérez) → enviada a revisión → evidencia aprobada (Ana Gerente) → cerrada
Nivel 2 · Diagnóstico

Timeline de tensión

"¿Qué pasó desde que detectamos TNS-001?"

Vista del gerente general. Cronología completa desde la detección de la tensión hasta su cierre, incluyendo todas las acciones derivadas y sus desenlaces. Es la vista que abre la bandeja al hacer drill-in sobre una tensión.

TNS-001 → detectada → 3 acciones creadas → responsables asignados → ACT-COM-002 vencida → ACT-COM-001 cerrada → tensión en verificación → tensión cerrada
Nivel 3 · Ejecutivo

Timeline empresa-semanal

"¿Qué pasó esta semana en Empresa Demo Cuyo?"

Vista de dirección y reporte semanal. Agregado de toda la actividad ejecutiva del período. Es la fuente directa del reporte ejecutivo semanal y del cálculo de Score consolidado.

Semana 22 → 6 tensiones detectadas → 14 acciones creadas → 8 iniciadas → 5 evidencias cargadas → 3 acciones vencidas → 2 escaladas → Score 74 → 66

Una tabla, tres vistas. Los tres timelines leen desde la misma vista faro.v_execution_timeline. La diferencia es el filtro: por action_id, por tension_id, o por rango de occurred_at + company_id. Esto evita el clásico bug de "el timeline de acción dice una cosa y el reporte ejecutivo dice otra": son la misma fuente, leída con criterios distintos.

04 · 40 eventos canónicos

4 categorías · 40 event_types · 13 familias funcionales

El catálogo de eventos del MVP está cerrado: 40 event_types agrupados en 4 categorías ejecutivas. Si un módulo quiere registrar un evento que no está acá, no entra hasta que se agregue al catálogo. Esto evita que el timeline crezca por improvisación.

4.1 · Tensión 8

Eventos de tensión

Ciclo de vida completo de una tensión, desde detección por el motor hasta cierre o reapertura. Familia funcional: detection, assignment, escalation, workflow.

tension_detectedTensión detectada por motor
tension_updatedTensión actualizada
tension_assignedResponsable asignado
tension_status_changedCambio de estado de tensión
tension_escalatedTensión escalada a nivel superior
tension_closedTensión cerrada
tension_reopenedTensión reabierta
tension_rejectedTensión rechazada justificadamente
4.2 · Acción 15

Eventos de acción

Workflow operativo de cada acción: creación, asignación, ejecución, bloqueo, escalamiento, extensión, revisión y cierre. Familia funcional: workflow, assignment, blockage, escalation, deadline, comment.

action_createdAcción creada
action_startedAcción iniciada
status_changedCambio de estado
responsible_changedCambio de responsable
due_date_changedCambio de vencimiento
action_blockedAcción bloqueada
action_unblockedAcción desbloqueada
action_escalatedAcción escalada
extension_requestedExtensión solicitada
extension_approvedExtensión aprobada
extension_rejectedExtensión rechazada
submitted_to_reviewAcción enviada a revisión
action_closedAcción cerrada
action_cancelledAcción cancelada
comment_addedComentario agregado
4.3 · Evidencia 8

Eventos de evidencia

Ciclo de validación de evidencia: carga, corrección, envío, aprobación, rechazo, pedido de más información, archivado. Familia funcional: evidence, approval, rejection, system.

evidence_uploadedEvidencia cargada
evidence_updatedEvidencia corregida
evidence_submittedEvidencia enviada a revisión
evidence_approvedEvidencia aprobada
evidence_rejectedEvidencia rechazada
evidence_needs_more_infoRequiere más información
evidence_archivedEvidencia archivada
evidence_downloadedEvidencia descargada (futuro)
4.4 · Score 5

Eventos de Score

Cambios en FARO Score por penalización, recuperación habilitada, recuperación efectiva, bloqueo de recuperación o recálculo. Familia funcional: score. Toda variación de Score deja evento.

score_penalizedScore penalizado por tensión detectada
score_recovery_enabledRecuperación habilitada por evidencia aprobada
score_recoveredScore recuperado por cierre con evidencia
score_blockedRecuperación bloqueada por falta de evidencia
score_recalculatedScore recalculado por motor

Suma 8 + 15 + 8 + 5 = 36 eventos por categoría ejecutiva. Los 4 restantes para llegar a 40 son transversales (no pertenecen a un único entity_type): un system de mantenimiento, un report de reporte generado, un integration_synced de integración externa y un comment_added de comentario libre. Total catálogo MVP: 40 event_types canónicos.

05 · Tabla execution_events

faro.execution_events · una tabla, 40 event_types, sin duplicación

Aplicación directa de la Decisión D3 del fundamento SQL: timeline visual unificado sobre una única tabla canónica execution_events, no cinco tablas dispersas (action_events, evidence_events, score_events, etc.). Esta pieza confirma la decisión D3 y la materializa con DDL, función helper, vista y seed.

Por qué una sola tabla. Un evento real (ej: "evidencia aprobada cerró acción y recuperó Score") toca tensión, acción, evidencia y score simultáneamente. Cinco tablas separadas obligan a hacer cinco INSERTs sincronizados, leer cinco fuentes para el timeline y arreglar inconsistencias cuando una falla. Una sola tabla con FK opcionales a cada entidad resuelve el problema en su raíz: insertás una vez, leés una vez, no hay drift entre fuentes.

5.1 · Campos canónicos de execution_events

Campo Tipo Descripción Ejemplo
execution_event_iduuid · pkIdentificador del evento. PK9000...0001
company_iduuid · not nullEmpresa propietaria. Base de RLS. IDX1000...0001
entity_typeenumEntidad principal: tension, action, evidence, score, report, system.action
entity_iduuid · nullID de la entidad principal del evento.2300...0001
tension_iduuid · nullFK opcional a faro.tensions. FK2200...0001
action_iduuid · nullFK opcional a faro.actions. FK2300...0001
evidence_iduuid · nullFK opcional a faro.evidence. FK2400...0001
report_iduuid · nullFK opcional a reporte ejecutivo.null
score_snapshot_iduuid · nullFK opcional a snapshot de Score.null
event_typetext · not nullUno de los 40 event_types canónicos del catálogo.evidence_approved
event_familyenumFamilia funcional para filtros: detection, workflow, evidence, approval, rejection, escalation, blockage, assignment, deadline, score, report, system, comment.approval
actor_typeenumOrigen del evento: user, system, integration, ai.user
actor_user_iduuid · nullUsuario actor (null si actor_type != user).1200...0002
from_statustext · nullEstado previo al evento.submitted
to_statustext · nullEstado posterior al evento.approved
titletext · not nullTítulo ejecutivo estandarizado del evento.Evidencia aprobada
descriptiontext · nullDescripción narrativa breve.Se aprobó EVD-007.
severityenum · nulllow, medium, high, critical.critical
priorityenum · nulllow, medium, high, critical.critical
impact_scorenumeric(9,4)Impacto numérico sobre FARO Score.-8.5000
confidence_deltanumeric(9,4)Variación de confianza del dato.1.5000
source_moduletext · nullMódulo originador del evento.evidence_review
source_referencetext · nullReferencia técnica (ej: ID de regla).RULE-TNS-001
payloadjsonbPayload técnico libre (colapsado en UI). GIN IDX{...}
occurred_attimestamptzMomento real del evento. IDX2026-05-30 09:03
created_attimestamptzMomento de inserción del registro.2026-05-30 09:03

5.2 · DDL · V044__create_execution_events.sql

▸ V044__create_execution_events.sql · PostgreSQL 15+
-- FARO-UI-005 · V044__create_execution_events.sql
-- Tabla canónica única del timeline ejecutivo. Aplica D3.

CREATE TABLE IF NOT EXISTS faro.execution_events (
  execution_event_id uuid PRIMARY KEY DEFAULT gen_random_uuid(),
  company_id        uuid NOT NULL,

  entity_type       text NOT NULL CHECK (
    entity_type IN ('tension','action','evidence','score','report','system')
  ),
  entity_id         uuid NULL,

  tension_id        uuid NULL,
  action_id         uuid NULL,
  evidence_id       uuid NULL,
  report_id         uuid NULL,
  score_snapshot_id uuid NULL,

  event_type   text NOT NULL,
  event_family text NOT NULL CHECK (
    event_family IN (
      'detection','workflow','evidence','approval','rejection',
      'escalation','blockage','assignment','deadline',
      'score','report','system','comment'
    )
  ),

  actor_type    text NOT NULL DEFAULT 'user' CHECK (
    actor_type IN ('user','system','integration','ai')
  ),
  actor_user_id uuid NULL,

  from_status text NULL,
  to_status   text NULL,

  title       text NOT NULL,
  description text NULL,

  severity text NULL CHECK (severity IS NULL OR severity IN ('low','medium','high','critical')),
  priority text NULL CHECK (priority IS NULL OR priority IN ('low','medium','high','critical')),

  impact_score     numeric(9,4) NULL,
  confidence_delta numeric(9,4) NULL,

  source_module    text NULL,
  source_reference text NULL,

  payload jsonb NOT NULL DEFAULT '{}'::jsonb,

  occurred_at timestamptz NOT NULL DEFAULT now(),
  created_at  timestamptz NOT NULL DEFAULT now()
);

-- Índices ejecutivos por entidad y tiempo
CREATE INDEX IF NOT EXISTS idx_execution_events_company_time
  ON faro.execution_events(company_id, occurred_at DESC);

CREATE INDEX IF NOT EXISTS idx_execution_events_tension
  ON faro.execution_events(company_id, tension_id, occurred_at DESC);

CREATE INDEX IF NOT EXISTS idx_execution_events_action
  ON faro.execution_events(company_id, action_id, occurred_at DESC);

CREATE INDEX IF NOT EXISTS idx_execution_events_evidence
  ON faro.execution_events(company_id, evidence_id, occurred_at DESC);

CREATE INDEX IF NOT EXISTS idx_execution_events_family
  ON faro.execution_events(company_id, event_family, occurred_at DESC);

CREATE INDEX IF NOT EXISTS idx_execution_events_type
  ON faro.execution_events(company_id, event_type, occurred_at DESC);

CREATE INDEX IF NOT EXISTS idx_execution_events_actor
  ON faro.execution_events(company_id, actor_user_id, occurred_at DESC);

CREATE INDEX IF NOT EXISTS idx_execution_events_payload
  ON faro.execution_events USING gin(payload);

COMMENT ON TABLE faro.execution_events IS
  'Timeline canónico de ejecución FARO. Registra eventos de tensiones, acciones, evidencias, score, reportes y sistema.';

5.3 · Función helper · log_execution_event

Ver función SQL completa · V045__create_log_execution_event_function.sql
▸ V045__create_log_execution_event_function.sql
CREATE OR REPLACE FUNCTION faro.log_execution_event(
  p_company_id       uuid,
  p_entity_type      text,
  p_entity_id        uuid,
  p_event_type       text,
  p_event_family     text,
  p_title            text,
  p_description      text DEFAULT NULL,
  p_actor_user_id    uuid DEFAULT NULL,
  p_actor_type       text DEFAULT 'user',
  p_tension_id       uuid DEFAULT NULL,
  p_action_id        uuid DEFAULT NULL,
  p_evidence_id      uuid DEFAULT NULL,
  p_from_status      text DEFAULT NULL,
  p_to_status        text DEFAULT NULL,
  p_severity         text DEFAULT NULL,
  p_priority         text DEFAULT NULL,
  p_impact_score     numeric DEFAULT NULL,
  p_confidence_delta numeric DEFAULT NULL,
  p_source_module    text DEFAULT NULL,
  p_source_reference text DEFAULT NULL,
  p_payload          jsonb DEFAULT '{}'::jsonb
)
RETURNS uuid AS $$
DECLARE
  v_event_id uuid;
BEGIN
  INSERT INTO faro.execution_events (
    company_id, entity_type, entity_id, event_type, event_family,
    title, description, actor_user_id, actor_type,
    tension_id, action_id, evidence_id,
    from_status, to_status, severity, priority,
    impact_score, confidence_delta,
    source_module, source_reference, payload
  )
  VALUES (
    p_company_id, p_entity_type, p_entity_id, p_event_type, p_event_family,
    p_title, p_description, p_actor_user_id, p_actor_type,
    p_tension_id, p_action_id, p_evidence_id,
    p_from_status, p_to_status, p_severity, p_priority,
    p_impact_score, p_confidence_delta,
    p_source_module, p_source_reference, COALESCE(p_payload, '{}'::jsonb)
  )
  RETURNING execution_event_id INTO v_event_id;

  RETURN v_event_id;
END;
$$ LANGUAGE plpgsql;

5.4 · Vista unificada · v_execution_timeline

Ver vista SQL · V046__create_v_execution_timeline.sql
▸ V046__create_v_execution_timeline.sql
CREATE OR REPLACE VIEW faro.v_execution_timeline AS
SELECT
  ee.company_id,
  ee.execution_event_id,
  ee.entity_type,
  ee.entity_id,

  ee.tension_id,
  t.tension_code,
  t.title AS tension_title,
  t.severity AS tension_severity,

  ee.action_id,
  a.action_code,
  a.title AS action_title,
  a.priority AS action_priority,
  a.status AS action_status,

  ee.evidence_id,
  e.evidence_code,
  e.title AS evidence_title,
  e.status AS evidence_status,

  ee.report_id,
  ee.score_snapshot_id,

  ee.event_type,
  ee.event_family,
  ee.actor_type,
  ee.actor_user_id,
  u.full_name AS actor_name,
  u.email     AS actor_email,

  ee.from_status, ee.to_status,
  ee.title, ee.description,
  ee.severity, ee.priority,
  ee.impact_score, ee.confidence_delta,
  ee.source_module, ee.source_reference,
  ee.payload,
  ee.occurred_at, ee.created_at

FROM faro.execution_events ee
LEFT JOIN faro.tensions t  ON t.tension_id = ee.tension_id  AND t.company_id = ee.company_id
LEFT JOIN faro.actions  a  ON a.action_id  = ee.action_id   AND a.company_id = ee.company_id
LEFT JOIN faro.evidence e  ON e.evidence_id= ee.evidence_id AND e.company_id = ee.company_id
LEFT JOIN faro.users    u  ON u.user_id    = ee.actor_user_id;

5.5 · Seed demo · Empresa Demo Cuyo S.A.

Ver seed SQL ejemplo · V047__seed_demo_execution_events.sql
▸ V047__seed_demo_execution_events.sql · Empresa Demo Cuyo S.A.
BEGIN;

-- 1) Tensión detectada por motor evaluador
SELECT faro.log_execution_event(
  '10000000-0000-0000-0000-000000000001', -- company_id
  'tension',
  '22000000-0000-0000-0000-000000000001', -- entity_id
  'tension_detected',
  'detection',
  'Tensión detectada',
  'FARO detectó crecimiento no rentable: ventas suben, margen cae y descuentos aumentan.',
  NULL, 'system',
  '22000000-0000-0000-0000-000000000001', NULL, NULL,
  NULL, 'new',
  'critical', 'critical',
  -8.5000, NULL,
  'evaluation_engine', 'RULE-TNS-001',
  '{"rule_code":"RULE-TNS-001","tension_code":"TNS-001"}'::jsonb
);

-- 2) Acción creada como recomendación
SELECT faro.log_execution_event(
  '10000000-0000-0000-0000-000000000001',
  'action',
  '23000000-0000-0000-0000-000000000001',
  'action_created', 'workflow',
  'Acción creada',
  'FARO creó la acción ACT-COM-001 como recomendación para TNS-001.',
  NULL, 'system',
  '22000000-0000-0000-0000-000000000001',
  '23000000-0000-0000-0000-000000000001',
  NULL,
  NULL, 'new',
  'critical', 'critical',
  NULL, NULL,
  'evaluation_engine', 'ACT-COM-001',
  '{"action_code":"ACT-COM-001","recommended_by":"TNS-001"}'::jsonb
);

-- 3) Acción iniciada por usuario
SELECT faro.log_execution_event(
  '10000000-0000-0000-0000-000000000001',
  'action',
  '23000000-0000-0000-0000-000000000001',
  'action_started', 'workflow',
  'Acción iniciada',
  'El responsable inició la revisión de la política de descuentos.',
  '12000000-0000-0000-0000-000000000002', 'user',
  '22000000-0000-0000-0000-000000000001',
  '23000000-0000-0000-0000-000000000001',
  NULL,
  'new', 'in_progress',
  'critical', 'critical',
  NULL, NULL,
  'action_workflow', NULL,
  '{}'::jsonb
);

-- 4) Evidencia cargada
SELECT faro.log_execution_event(
  '10000000-0000-0000-0000-000000000001',
  'evidence',
  '24000000-0000-0000-0000-000000000001',
  'evidence_uploaded', 'evidence',
  'Evidencia cargada',
  'Se cargó evidencia EVD-007 · Cambio de política comercial.',
  '12000000-0000-0000-0000-000000000002', 'user',
  '22000000-0000-0000-0000-000000000001',
  '23000000-0000-0000-0000-000000000001',
  '24000000-0000-0000-0000-000000000001',
  NULL, 'submitted',
  'critical', 'critical',
  NULL, 1.5000,
  'evidence_upload', 'EVD-007',
  '{"evidence_code":"EVD-007","trust_level":"critical"}'::jsonb
);

COMMIT;
06 · Componentes UI

Timeline vertical · filtros · sticky header de día

El timeline se materializa en un set acotado de componentes React/TS. Una sola pieza canónica ExecutionTimeline que se monta en UI-001 (bandeja), UI-003 (workflow acción) y en el reporte ejecutivo semanal. No se duplican implementaciones: una fuente, un componente, una verdad.

Comp 01

ExecutionTimeline

Componente raíz. Recibe ExecutionTimelineResponse y orquesta header, filtros, lista y empty state. Punto único de montaje en cualquier pantalla.

Comp 02

ExecutionTimelineHeader

Header con título, sub y 4 métricas ejecutivas: total eventos, evidencias, score events, bloqueos. Es el resumen del summary del API.

Comp 03

ExecutionTimelineFilters

9 chips de familia (Detección, Workflow, Evidencia, Aprobación, Rechazo, Escalamiento, Bloqueo, Score, Comentarios). Multi-select, no exclusivo.

Comp 04

ExecutionTimelineItem

Item visual con icono por familia + línea vertical + tarjeta con badges, título, descripción, fecha, actor, meta (estado, score) y refs (TNS, ACT, EVD).

Comp 05

ExecutionEventIcon + Badge

Iconos y badges por event_family con paleta sobria: detección coral, workflow azul, evidencia cyan, aprobación teal, rechazo coral, escalamiento ámbar.

Comp 06

Sticky header de día

Cabecera flotante por día (ej. Hoy, Ayer, 30 may 2026) que se queda fija al hacer scroll por listas largas. Agrupación natural del ojo.

Comp 07

ExecutionTimelineEmpty

3 empty states honestos: sin eventos, sin eventos con filtro activo y timeline incompleto (datos previos a la activación de auditoría visual).

Comp 08

Payload colapsado

El payload jsonb queda en <details> colapsable para que el usuario ejecutivo no vea ruido técnico salvo que lo pida explícitamente.

Reglas visuales por familia

Paleta acotada, no carnaval. El usuario tiene que entender, no celebrar cumpleaños. Detección en coral; workflow en azul sobrio; evidencia en cyan; aprobación en teal; rechazo/bloqueo en coral; escalamiento/vencimiento en ámbar; score en teal con énfasis; sistema/comentario en gris cálido. Nada de gradientes psicodélicos.

FamiliaColor recomendadoUso típicoToken CSS
DetecciónCoral suaveTensiones nuevas detectadas por motor--coral / --coral-soft
WorkflowAzul sobrioCambios de estado, creación, asignación--faro-blue / --blue-soft
EvidenciaCyan claroCarga, corrección y archivado de evidencia--cyan / --cyan-soft
AprobaciónTeal sobrioEvidencias aprobadas, extensiones aprobadas--teal / --teal-soft
RechazoCoral fuerteEvidencias rechazadas, extensiones rechazadas--coral / --coral-soft
BloqueoCoral/ámbarAcciones bloqueadas, recuperación de Score bloqueada--coral / --amber
EscalamientoÁmbarAcciones/tensiones escaladas a nivel superior--amber / --amber-soft
VencimientoÁmbarCambios y vencimientos de due_date--amber / --amber-soft
ScoreTeal con énfasisPenalizaciones y recuperaciones de FARO Score--teal / --faro-navy
AsignaciónAzul sobrioAsignación de responsable o aprobador--faro-blue / --blue-soft
ComentarioArenaComentarios manuales en acción o tensión--faro-arena-50 / --gray-text
SistemaGris cálidoEventos de mantenimiento, recálculos automáticos--faro-arena-50 / --gray-text
07 · Filtros, búsqueda y exportabilidad

Por tipo, por actor, por fecha · export preparado

El timeline puede crecer mucho. Sin controles, se vuelve inservible a las pocas semanas. El MVP entrega filtros por familia, actor y rango de fecha, búsqueda libre por título/descripción y exportabilidad preparada (estructura lista; implementación de export en fase posterior).

Familia ·
Todas Detección Workflow Evidencia Aprobación Rechazo Escalamiento Bloqueo Score Comentarios
Actor ·
Todos Usuario Sistema FARO Integración FARO IA
Período ·
Hoy Esta semana Este mes Últimos 90 días Rango personalizado

Contrato API mínimo

MétodoEndpointUsoFiltros soportados
GET/api/v1/actions/:id/timelineTimeline de acciónevent_family
GET/api/v1/tensions/:id/timelineTimeline de tensiónevent_family
GET/api/v1/evidence/:id/timelineTimeline de evidenciaevent_family
GET/api/v1/execution/timelineTimeline ejecutivo / períodoperiod_start, period_end, event_family, actor_type
POST/api/v1/execution/eventsCrear comentario / evento manualBody con title, description, refs
GET/api/v1/execution/events/:idDetalle de evento individual

Performance y paginación

Riesgo claro. Un timeline ejecutivo puede crecer a miles de filas por mes. Mitigaciones MVP: LIMIT 200 por defecto, paginación cursor por occurred_at, índices por (company_id, entity, occurred_at) y filtros obligatorios por familia o período. Archivado funcional posterior. Sin estos controles, el endpoint colapsa al primer reporte semanal real.

Ver query con paginación cursor
▸ Paginación por occurred_at
SELECT *
FROM faro.v_execution_timeline
WHERE company_id = $1
  AND action_id  = $2
  AND ($3::timestamptz IS NULL OR occurred_at < $3)
ORDER BY occurred_at DESC
LIMIT 50;

Exportabilidad futura (preparado, no MVP)

El MVP no entrega export PDF/CSV/XLSX implementado, pero la estructura está preparada: execution_events es exportable directo, v_execution_timeline es la fuente para todos los formatos. Roadmap: PDF firmado de timeline por acción (cierre de auditoría), CSV de timeline ejecutivo semanal (input para reporte). No se construye en MVP para no inflar alcance; se construye cuando un piloto lo pida en producción.

08 · Auditoría visual básica + Score impact

Score events visibles · explicación trazable

El timeline debe explicar por qué el Score sube o baja. Sin eventos de Score, una caída de 8 puntos queda inexplicada y el ejecutivo desconfía del número. Con eventos, cada variación tiene fecha, motivo, acción asociada y aprobador.

Eventos que explican variación de Score

  • score_penalized — "FARO penalizó 8.5 puntos al detectarse TNS-001 (Crecimiento no rentable)."
  • score_recovery_enabled — "Evidencia aprobada habilita recuperación de hasta 5 puntos al cerrar la acción."
  • score_recovered — "Acción ACT-COM-001 cerrada con evidencia aprobada · Score recuperó 5 puntos."
  • score_blocked — "Recuperación bloqueada: cierre sin evidencia aprobada · 0 puntos recuperados."
  • score_recalculated — "Motor recalculó Score por nueva snapshot semanal: 66 → 71."

Ejemplo concreto · Empresa Demo Cuyo

Semana 22 en Empresa Demo Cuyo S.A.: el Score pasa de 74 a 66. Sin timeline, ese -8 es solo un número. Con timeline, la línea explicativa es trazable:

  1. Lunes 09:03 — motor detecta TNS-001 (Crecimiento no rentable) → score_penalized -8.5
  2. Lunes 11:20 — FARO crea ACT-COM-001 como recomendación → no impacta Score todavía
  3. Martes 10:15 — Juan Pérez inicia ACT-COM-001 → no impacta Score
  4. Jueves 14:40 — Juan Pérez carga EVD-007 → score_recovery_enabled +5 (potencial)
  5. Viernes 09:25 — Ana Gerente aprueba EVD-007 → evidence_approved
  6. Viernes 09:26 — cierre de ACT-COM-001 → score_recovered +5
  7. Viernes 17:00 — motor recalcula Score → score_recalculated 66 → 71

El Score consolidado del cierre semanal es 71, no 66. Sin timeline, el reporte habría dicho "Score 66" y nadie habría podido auditar la recuperación. Con timeline, la recuperación es defendible ante el director general.

Query de eventos críticos semanales

▸ SQL · eventos críticos para reporte semanal
SELECT
  occurred_at, event_type, title, description,
  severity, priority, impact_score
FROM faro.execution_events
WHERE company_id = $1
  AND occurred_at >= $2
  AND occurred_at < $3
  AND (
    severity = 'critical'
    OR priority = 'critical'
    OR event_family IN ('rejection','blockage','escalation')
  )
ORDER BY occurred_at DESC;

Reporte semanal alimentado por timeline

El reporte ejecutivo semanal no se redacta a mano; se compone desde el timeline. Frase real del reporte de Empresa Demo Cuyo, semana 22:

"Durante la semana se detectaron 6 tensiones, se crearon 14 acciones, se cerraron 5 acciones con evidencia aprobada, 3 acciones quedaron vencidas, 2 fueron escaladas y FARO Score pasó de 74 a 71 (recuperación parcial sobre -8 iniciales)."

Cada uno de esos números sale de un COUNT sobre execution_events filtrado por familia y período. Cero relato manual. Cero invento posible.

09 · Mockup visual estático

3 niveles · acción · tensión · empresa-semanal

Render estático de los 3 niveles con eventos reales del seed demo. Empresa Demo Cuyo S.A. · TNS-001 (Crecimiento no rentable) · ACT-COM-001 (Revisar política de descuentos) · EVD-007 (Cambio de política).

FARO · Timeline de ejecución NIVEL 1 · ACCIÓN

ACT-COM-001 · Revisar política de descuentos

Trazabilidad operativa de una acción específica. Empresa Demo Cuyo S.A. · TNS-001 derivado.

Eventos
7
Evidencias
2
Score events
2
Bloqueos
No
Lunes 25 may · 2026
W
Workflow Critical
25 may · 09:03

Acción creada

FARO creó la acción ACT-COM-001 como recomendación automática para TNS-001 (Crecimiento no rentable).

Estado: — → new
TNS-001ACT-COM-001

Sistema FARO · evaluation_engine

W
Workflow Critical
25 may · 14:22

Acción iniciada

Juan Pérez inició la revisión de la política de descuentos para clientes mayoristas.

Estado: new → in_progress
ACT-COM-001

Juan Pérez · responsable comercial

Jueves 28 may · 2026
E
Evidencia Critical
28 may · 14:40

Evidencia cargada · EVD-007

Se cargó evidencia "Cambio de política comercial" con detalle del nuevo tope de descuento y aprobación interna previa.

Estado: — → submitted Confianza: +1.5
ACT-COM-001EVD-007

Juan Pérez · responsable comercial

Workflow High
28 may · 14:42

Acción enviada a revisión

La acción pasa a estado de revisión esperando aprobación de la evidencia cargada.

Estado: in_progress → in_review
ACT-COM-001EVD-007

Juan Pérez · responsable comercial

Viernes 29 may · 2026
A
Aprobación Critical
29 may · 09:25

Evidencia aprobada · EVD-007

Ana Gerente aprobó EVD-007. La evidencia es suficiente para cerrar la acción y habilitar recuperación de Score.

Estado: submitted → approved Confianza: +1.5
ACT-COM-001EVD-007

Ana Gerente · aprobadora · general_manager

Workflow Critical
29 may · 09:26

Acción cerrada

ACT-COM-001 quedó cerrada con evidencia aprobada. Política comercial actualizada en sistema.

Estado: in_review → closed
ACT-COM-001EVD-007

Sistema FARO · action_workflow

S
Score High
29 may · 09:26

Score recuperado · +5 puntos

El cierre con evidencia aprobada recuperó 5 puntos sobre la dimensión commercial_health.

Score impact: +5.0 Dimensión: commercial_health
TNS-001ACT-COM-001

Sistema FARO · score_engine

FARO · Timeline de tensión NIVEL 2 · TENSIÓN

TNS-001 · Crecimiento no rentable

Cronología desde detección hasta verificación. Empresa Demo Cuyo S.A. · 3 acciones derivadas.

Eventos
5
Acciones
3
Score impact
-8.5
Escalamientos
0
Lunes 25 may · 2026
D
Detección Critical
25 may · 09:03

Tensión detectada

FARO detectó crecimiento no rentable: ventas +12% trimestral, margen -3 puntos, descuento medio +4 puntos.

Score: -8.5 Regla: RULE-TNS-001
TNS-001

Sistema FARO · evaluation_engine

+3
Workflow
25 may · 09:04

3 acciones creadas como recomendación

FARO creó automáticamente ACT-COM-001 (Revisar política descuentos), ACT-COM-002 (Auditar vendedores fuera de target) y ACT-COM-003 (Recalibrar comisiones por margen).

TNS-001ACT-COM-001ACT-COM-002ACT-COM-003

Sistema FARO · evaluation_engine

P
Asignación
25 may · 11:20

Responsables asignados

Ana Gerente asignó las 3 acciones a Juan Pérez (comercial) con aprobación final en gerencia general.

TNS-001

Ana Gerente · general_manager

Viernes 29 may · 2026
Workflow
29 may · 09:26

ACT-COM-001 cerrada con evidencia aprobada

Primera de las 3 acciones cerrada con EVD-007 aprobada por Ana Gerente. Política comercial actualizada en sistema.

TNS-001ACT-COM-001EVD-007

Sistema FARO · action_workflow

Workflow
29 may · 17:10

Tensión en verificación

Con 1 de 3 acciones cerradas y 2 en progreso, TNS-001 pasa a estado de verificación. Cierre formal queda condicionado al cierre de las 2 acciones restantes.

Estado: open → verifying
TNS-001

Sistema FARO · tension_workflow

FARO · Timeline ejecutivo NIVEL 3 · EMPRESA

Empresa Demo Cuyo S.A. · Semana 22 · 2026

Resumen ejecutivo agregado · entrada directa al reporte semanal.

Tensiones
6
Acciones creadas
14
Cerradas
5
Score
74 → 71
Resumen agregado · semana 22 (25-31 may)
6
Detección
25-31 may

6 tensiones detectadas por el motor

TNS-001 (crecimiento no rentable), TNS-004 (venta sin conversión a caja), TNS-006 (stock crítico alta rotación), TNS-009 (acciones vencidas), TNS-019 (caja proyectada insuficiente · crítica), TNS-026 (sin visibilidad semanal).

TNS-001TNS-004TNS-006TNS-009TNS-019TNS-026

Sistema FARO · evaluation_engine

14
Workflow
25-31 may

14 acciones creadas como recomendación

Promedio 2.3 acciones por tensión. 8 iniciadas dentro del SLA, 6 todavía en estado new al cierre semanal.

Sistema FARO · evaluation_engine

5
Evidencia
25-31 may

5 evidencias cargadas · 4 aprobadas

EVD-002, EVD-005, EVD-007, EVD-010, EVD-011. Una evidencia (EVD-011) requirió más información antes de aprobación.

Usuarios responsables · 3 personas distintas

↑2
Escalamiento High
29-30 may

2 acciones escaladas a gerencia general

ACT-FIN-001 (gestión de mora crítica) y ACT-STK-002 (reposición producto crítico) fueron escaladas por incumplimiento de SLA al responsable comercial.

Sistema FARO · escalation_engine

✓5
Workflow
28-31 may

5 acciones cerradas con evidencia aprobada

ACT-COM-001, ACT-STK-001, ACT-FIN-003, ACT-COM-004 y ACT-DAT-001. Tres acciones quedaron vencidas sin cierre y se incluyen en la bandeja de la semana 23.

Responsables operativos · 4 personas distintas

S
Score
31 may · 17:00

FARO Score · 74 → 71

Caída neta de 3 puntos. Penalización bruta -11.5 (6 tensiones detectadas) compensada con recuperación de +8.5 (5 acciones cerradas con evidencia aprobada).

Penalización: -11.5 Recuperación: +8.5 Neto: -3

Sistema FARO · score_engine

IA puede generar narrative del timeline (D5 con guardrails AI-001). Los textos descriptivos del timeline pueden ser asistidos por IA (resumen de la semana, frase ejecutiva del Score, descripción de la tensión), pero solo dentro de los guardrails AI-001 / FARO-GOV-001: prohibido inventar números, prohibido crear códigos TNS/ACT/EVD que no existan en catálogo, prohibido modificar from/to_status, prohibido alterar impact_score. La IA escribe la prosa; los hechos los pone el sistema.

10 · Integración con GOV-001 audit_log

Timeline = cara visual · audit_log = trazabilidad legal

El timeline visual y el audit_log técnico son complementarios, no excluyentes. Ambos se alimentan de las mismas operaciones, pero responden a preguntas distintas y los usan audiencias distintas.

Diagrama lógico

▸ Flujo conceptual de un evento
[ Acción operativa real: aprobar evidencia EVD-007 ]
            |
            v
+--------------------------------+
| Endpoint API                   |
| POST /evidence/:id/approve     |
+--------------------------------+
            |
   +--------+---------+
   v                  v
+-------------+    +------------------+
| log_audit() |    | log_execution_   |
| (GOV-001)   |    |   event()        |
| audit_log   |    | (UI-005)         |
| técnico     |    | execution_events |
| inmutable   |    | visual ejecutivo |
+-------------+    +------------------+
   |                  |
   v                  v
[auditor legal]    [gerencia + reporte
                    ejecutivo + UI]

Reglas de integración

  1. Todo evento que modifique estado debe registrar ambos. Por contrato del endpoint: si la operación toca una entidad sensible (acción, evidencia, tensión, score, permisos), se llama tanto log_audit() como log_execution_event().
  2. El timeline visual nunca lee del audit_log. Lee de v_execution_timeline. El audit_log es solo lectura de auditor.
  3. El audit_log nunca aparece en pantalla ejecutiva. Vive en una pantalla aparte (FARO-GOV-001 · módulo Auditoría) restringida por rol.
  4. Las dos tablas tienen company_id y son RLS-aware. Cero filtración cross-tenant en ninguna de las dos.
  5. El audit_log es inmutable por contrato. El timeline puede archivarse funcionalmente (no se borra: cambia status a archived a nivel agregado), pero el audit_log es INSERT-only por triggers de seguridad.

Comparación operativa

AspectoUI-005 timelineGOV-001 audit_log
Tablafaro.execution_eventsfaro.audit_log
MutabilidadSoft (archivado funcional)Hard (INSERT-only)
CoberturaEventos ejecutivos relevantesTodo cambio sensible (DML, login, permisos)
Visible en UISí · pantalla ejecutivaSolo módulo de auditoría restringido
LenguajeEjecutivo / narrativoTécnico / forense
AudienciaGerencia, responsables, dueñoAdmin de seguridad, auditor externo
RetenciónVida útil + archivo agregadoInmutable, retención por contrato
PerformanceLIMIT 200 + paginación cursorAppend-only, índices por occurred_at

Roles que ven cada uno (RLS)

RolTimeline visual (UI-005)Audit_log (GOV-001)
ResponsableSus accionesNo
AprobadorAcciones que apruebaNo
Gerente de áreaSu área completaNo
Director / DueñoTimeline completo de la empresaLectura restringida
Data OwnerEvidencia y datos asignadosNo
Auditor interno / externoLectura completaLectura completa
Admin de seguridadLectura completaLectura completa
Integración técnicaSolo eventos autorizadosNo
11 · Cross-references

Dónde se consume el timeline en el resto del pack

El timeline ejecutivo es transversal: lo consume la bandeja de tensiones, la pantalla de workflow de acción, el módulo de seguridad RLS y el catálogo de acciones. Estos son los puntos de cruce.

12 · Próximos pasos

Qué falta para cerrar el loop de auditoría visual

Esta pieza confirma la decisión D3 y define el contrato. Estos son los siguientes documentos y patches que cierran el ciclo de trazabilidad ejecutiva.

  1. FARO-WF-001 · Workflow y Escalamiento Operativo. Definir reglas formales de escalamiento (cuándo, a quién, por qué canal, con qué SLA, qué pasa si no responde, cómo impacta en Score, cómo se registra en timeline). Ya tenemos acción, evidencia y timeline; falta gobernar el escalamiento.
  2. FARO-GOV-001 · Auditoría legal técnica. Construir faro.audit_log como tabla INSERT-only complementaria al timeline visual. Triggers de seguridad, retención por contrato y pantalla de auditoría restringida por rol.
  3. FARO-UI-003 · Patch detalle de acción. Reemplazar el timeline ad-hoc por el componente canónico ExecutionTimeline consumiendo v_execution_timeline. No duplicar dos timelines en producto.
  4. FARO-ENG-003.1 · Patch motor evaluador. Al detectar tensión, registrar simultáneamente tension_detected y score_penalized en el mismo BEGIN/COMMIT. Atómico por contrato.
  5. FARO-UI-004 · Patch evidencia. En upload/approve/reject/needs_more_info, agregar log_execution_event() al endpoint. Cero evidencia sin evento visible.
  6. FARO-TPL-002 · Reporte semanal ejecutivo. Reescribir el reporte semanal para que se componga 100% desde COUNT y agregados sobre execution_events. Cero relato manual; cero invento posible.
  7. FARO-LEARN · Recalibración futura. Usar el timeline acumulado para alimentar el módulo de aprendizaje: qué tensiones cierran rápido, qué evidencias se rechazan más, qué responsables tienen mejor ratio de cierre. Insumo crudo para mejora del motor.