01 · Resumen ejecutivo

Paquete demo ejecutable, no maqueta animada

FARO-DEMO-001 es un paquete Docker Compose que levanta FARO Connect con datos sintéticos realistas y demuestra la cadena completa dato → tensión → acción → evidencia → Score → reporte → decisión. La empresa simulada es Empresa Demo Cuyo S.A., comercializadora de insumos para la construcción con 3 sucursales en Mendoza y San Juan, 6 meses de datos cargados.

La diferencia entre un mockup y una demo ejecutable no es estilo: es categoría de credibilidad. Un mockup convence al que ya cree; una demo ejecutable convence al CTO que pregunta “¿y esto realmente corre?”. El paquete responde levantando PostgreSQL + Redis, corriendo migraciones, cargando seeds, ingestando 18 CSVs sintéticos, ejecutando el pipeline (RAW → staging → normalización → KPIs → reglas → tensiones → acciones → evidencia → workflow → timeline → Score → reporte → IA controlada) y validando contra expected JSONs.

El caso central que vive la Empresa Demo es el clásico crecimiento no rentable: ventas suben 18%, margen bruto cae del 28% al 21%, descuentos pasan del 6% al 12%, cobranza se estira de 32 a 43 días, stock crítico aparece en productos de alta rotación, hay acciones vencidas, falta evidencia para cerrar. FARO Score 74 → 66 en el snapshot inicial, con recuperación potencial a 74 (+8) por cierre de acciones críticas con evidencia aprobada (D7).

El paquete es reproducible, trazable y verificable. Reproducible porque corre en cualquier máquina con Docker. Trazable porque cada número del Score tiene drivers explícitos y cada acción tiene timeline. Verificable porque el script demo-check.sh compara outputs reales contra expected JSONs y devuelve PASS o FAIL. Si cada demo dependiera de tocar datos a mano, acomodar pantallas y rezar, no sería una demo técnica: sería teatro de riesgo.

El alcance es MVP. No incluye: datos reales de clientes, integraciones reales con ERP, WhatsApp productivo, proveedor de IA obligatorio (alcanza el fallback), multiindustria completa, benchmark externo, carga masiva enterprise. Incluye: docker-compose, PostgreSQL, Redis, migraciones, seeds base + Empresa Demo, 18 CSVs con 6 meses de datos, expected JSONs, scripts demo-up/demo-reset/demo-check, 30 tensiones MVP evaluadas, acciones con workflow real, evidencias mixtas, timeline, alertas, snapshot de Score, reporte semanal ejecutivo, 4 storyboards (10 min, 20 min, 45 min técnica, WhatsApp), FAQs CTO e inversor.

Tesis ejecutiva. El documento explica. El mockup seduce. El dataset prueba. La demo ejecutable convence. Para un socio técnico, CTO o inversor, la diferencia entre “lo pensamos” y “corre de punta a punta” cambia la conversación. FARO deja de depender de “imaginate cómo funcionaría” y pasa a mostrar una cadena viva contra resultados esperados.

02 · 12 capacidades demo

Qué debe probar la demo, capacidad por capacidad

La demo no es una pasada rápida de pantallas. Cada capacidad se demuestra contra datos cargados, reglas evaluadas y outputs validados.

Capacidad 01

Ingesta

Los 18 CSVs se cargan correctamente a la tabla raw_* con conteos verificables (260 productos, 4.820 ventas, 2.140 movimientos de stock).

Capacidad 02

Normalización

Los datos pasan de raw a staging y luego al modelo FARO canónico, con dedupe key y constraints únicos por empresa.

Capacidad 03

KPIs

Se calculan indicadores ejecutivos (margen, descuento, DSO, cobertura stock) y se versionan por período en kpi_snapshots.

Capacidad 04

Tensiones

El motor evaluador evalúa las 30 tensiones MVP; 18 quedan activas; 10 críticas o altas visibles en la bandeja.

Capacidad 05

Acciones

Se crean y se recomiendan acciones desde tensiones canónicas: 42 acciones, 6 críticas, 5 vencidas, 3 bloqueadas, 3 escaladas.

Capacidad 06

Workflow

Las acciones cambian de estado según evidencias y vencimientos. newin_progresswaiting_evidencein_reviewclosed / expired / escalated.

Capacidad 07

Evidencia

Los cierres requieren respaldo documental. EVD-007 submitted, EVD-012 missing, EVD-006 rejected: la demo muestra los tres estados juntos.

Capacidad 08

Timeline

Todo deja historia auditada en timeline_events con tipo, actor, payload y request_id. Más de 80 eventos en el período demo.

Capacidad 09

Alertas

Se notifican eventos críticos con dedupe_key para evitar ruido: TNS-001 crítica, acción vencida, evidencia rechazada, escalamiento L3.

Capacidad 10

Score

Se calcula FARO Score 66 (previo 74, delta -8) con confianza ≥ 80 y drivers explicitados. Recuperación potencial +8 si cierran acciones críticas (D7).

Capacidad 11

Reporte

Se genera el reporte semanal ejecutivo con Score, tensiones, acciones, evidencias, escalamientos, decisiones requeridas y foco próxima semana.

Capacidad 12

IA controlada

La IA explica sin inventar usando slots controlados con audit_trail (D5). Si el proveedor no responde, usa fallback determinístico.

Perfil de Empresa Demo Cuyo S.A.

Industria
Construcción
Comercio retail B2B-B2C de insumos
Sucursales
3
Mendoza Centro, Mendoza Norte, San Juan
Depósitos
2
Mendoza y San Juan
Áreas
7
Comercial, Finanzas, Compras, Stock, RRHH, Operaciones, Dirección
Empleados
42
Dotación distribuida en 3 sucursales
Clientes
180
Constructoras, desarrolladoras y particulares
Productos
260
Cemento, hierro, revestimientos, etc.
Proveedores
35
Cuyo y nacional
Período
6 meses
Noviembre 2025 a mayo 2026
Moneda
ARS
Importes en pesos argentinos
Frecuencia
Diaria
También semanal y mensual según KPI
Caso central
Crecimiento no rentable
TNS-001 crítica + cadena asociada

Historia ejecutiva

La Empresa Demo atraviesa una situación clásica de empresa en crecimiento: las ventas suben (+18%), pero el margen bruto cae (28% → 21%), los descuentos aumentan (6% → 12%), la cobranza se estira (32 → 43 días), aparece stock crítico en productos clave, las compras no reponen a tiempo, algunos vendedores venden mucho pero con baja rentabilidad, hay acciones vencidas y falta evidencia para cerrar. El Score cae. FARO detecta la tensión principal (TNS-001 Crecimiento no rentable), recomienda acciones, asigna responsables, exige evidencia, escala el caso L3 y reporta semanalmente al director.

Resultados esperados

Score inicial
66
−8 vs período anterior (74)
Status: warning. Confianza ≥ 80. Drivers negativos: TNS-001, TNS-004, TNS-006, acciones vencidas, evidencia faltante.
Score recuperable (D7)
74
+8 si cierran acciones críticas
Status: attention. Recuperación posible solo con evidencia aprobada en ACT-COM-001, ACT-FIN-001 y ACT-STK-001.

El delta de recuperación es potencial techo, no automático. El Score no recupera por promesa; recupera por evidencia aprobada. Tensiones detectables esperadas: 30 evaluadas, mínimo 18 activas, 10 críticas o altas en la bandeja, 5 con acciones vencidas, 5 con evidencia pendiente, 3 escaladas.

03 · Estructura del paquete

Carpetas, scripts, seeds, CSVs, expected, files, storyboard, qa

El paquete sigue un layout estándar pensado para reproducibilidad y para que un CTO pueda navegarlo en 5 minutos sin documentación adicional.

faro-demo/
  README.md                          # Levantar en 60 segundos
  docker-compose.yml                 # PostgreSQL + Redis + app + mailhog
  .env.demo.example                  # Variables de ambiente demo
  Dockerfile                         # Imagen Node.js + pnpm

  scripts/
    demo-up.sh                       # Levanta toda la cadena
    demo-reset.sh                    # Borra y reconstruye
    demo-check.sh                    # Valida outputs vs expected JSONs
    seed-demo.sh                     # Carga seeds base + Empresa Demo
    run-pipeline.sh                  # Ejecuta el pipeline FARO
    generate-report.sh               # Genera reporte semanal
    load-csv.ts                      # Carga 18 CSVs a RAW

  db/
    migrations/                      # V001..V040 (esquema FARO)
    seeds/
      000_seed_base_catalogs.sql    # Roles, permisos, categorías
      001_seed_demo_company.sql     # Empresa Demo Cuyo S.A.
      002_seed_demo_users_roles.sql # 6 usuarios + 1 viewer
      003_seed_demo_master_data.sql # Productos, clientes, empleados
      004_seed_demo_transactions.sql# Ventas, stock, cobranza, compras
      005_seed_demo_tensions_actions.sql # Tensiones y acciones demo
      006_seed_demo_evidence.sql    # Evidencias en estados mixtos
      007_seed_demo_timeline.sql    # 80+ eventos históricos
      008_seed_demo_score.sql       # Snapshot Score 74 y 66
      009_seed_demo_reports.sql     # Reporte semanal generado

  data/
    csv/                             # 18 CSVs sintéticos 6 meses
      001_companies_branches_areas.csv
      002_products.csv
      003_customers.csv
      004_employees.csv
      005_suppliers.csv
      006_sales.csv
      007_sales_items.csv
      008_stock_movements.csv
      009_inventory_snapshot.csv
      010_accounts_receivable.csv
      011_collections.csv
      012_purchases.csv
      013_purchase_items.csv
      014_actions.csv
      015_evidence.csv
      016_workflow_events.csv
      017_kpi_inputs.csv
      018_score_snapshots.csv

    expected/                        # JSONs para validar outputs
      kpi_expected.json
      tensions_expected.json
      actions_expected.json
      evidence_expected.json
      workflow_expected.json
      score_expected.json
      notifications_expected.json
      report_expected.json
      ai_expected.json
      qa_expected.json

    files/evidencia/                # Adjuntos de evidencia demo
      politica-descuentos-v1.pdf
      aprobacion-direccion-descuentos.pdf
      comprobante-cobranza-cliente-001.pdf
      orden-compra-stock-critico.pdf
      captura-tablero-stock.png

  storyboard/                       # 4 guiones de demo + FAQs
    demo_10_min.md
    demo_20_min.md
    demo_45_min_tecnica.md
    demo_script_whatsapp.md
    demo_faq_cto.md
    demo_faq_inversor.md

  postman/
    FARO_Demo_MVP.postman_collection.json
    FARO_Demo_MVP.postman_environment.json

  qa/
    demo-check.ts                    # Validador outputs vs expected
    smoke-demo.spec.ts               # Playwright smoke E2E
    expected-validator.ts
    score-validator.ts
    tension-validator.ts
    report-validator.ts

Por qué este layout. Cada carpeta es responsabilidad única: scripts/ levanta, db/ migra y siembra, data/csv/ ingesta, data/expected/ valida, data/files/ adjunta evidencia, storyboard/ guía la demo, qa/ verifica. Si algo falla, el CTO sabe dónde mirar sin tener que leer documentación previa. La lógica del pipeline vive en la app FARO; el paquete demo es la cáscara que lo hace ejecutable.

04 · docker-compose.yml

PostgreSQL + Redis + app + mailhog

Cuatro servicios, healthchecks explícitos, volúmenes persistentes, puertos no conflictivos. Levanta limpio en cualquier máquina con Docker.

▸ docker-compose.yml · v3.9
version: "3.9"

services:
  postgres:
    image: postgres:16
    container_name: faro_demo_postgres
    restart: unless-stopped
    environment:
      POSTGRES_USER: faro
      POSTGRES_PASSWORD: faro
      POSTGRES_DB: faro_demo
    ports:
      - "54329:5432"
    volumes:
      - faro_demo_pgdata:/var/lib/postgresql/data
      - ./db/init:/docker-entrypoint-initdb.d
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U faro -d faro_demo"]
      interval: 10s
      timeout: 5s
      retries: 5

  redis:
    image: redis:7
    container_name: faro_demo_redis
    restart: unless-stopped
    ports:
      - "63799:6379"
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 10s
      timeout: 5s
      retries: 5

  mailhog:
    image: mailhog/mailhog:latest
    container_name: faro_demo_mailhog
    restart: unless-stopped
    ports:
      - "8025:8025"   # UI web para inspeccionar emails de notificación
      - "1025:1025"   # SMTP capturado por FARO demo

  faro-app:
    build:
      context: .
      dockerfile: Dockerfile
    container_name: faro_demo_app
    restart: unless-stopped
    depends_on:
      postgres:
        condition: service_healthy
      redis:
        condition: service_healthy
      mailhog:
        condition: service_started
    environment:
      NODE_ENV: demo
      DATABASE_URL: postgresql://faro:faro@postgres:5432/faro_demo
      REDIS_URL: redis://redis:6379
      FARO_DEMO_MODE: "true"
      FARO_AI_MODE: "fallback"
      SMTP_HOST: mailhog
      SMTP_PORT: "1025"
      APP_URL: http://localhost:3000
    ports:
      - "3000:3000"

volumes:
  faro_demo_pgdata:

Decisiones de diseño. Puertos no estándar (54329, 63799) para no chocar con instalaciones locales. mailhog en lugar de SMTP real para capturar y visualizar notificaciones sin enviar emails reales. FARO_AI_MODE=fallback garantiza que la demo corre sin necesitar API keys de proveedor externo. El volumen faro_demo_pgdata persiste datos entre reinicios; demo-reset.sh lo borra cuando hace falta limpieza completa.

05 · Variables y comandos clave

.env.demo y los 6 comandos que importan

Variables mínimas para correr la demo y los comandos que el operador ejecuta. Todo demás se infiere.

.env.demo.example

▸ .env.demo.example
# --- App ---
NODE_ENV=demo
APP_ENV=demo
APP_URL=http://localhost:3000

# --- Base de datos ---
DATABASE_URL=postgresql://faro:faro@localhost:54329/faro_demo
REDIS_URL=redis://localhost:63799

# --- Modo demo ---
FARO_DEMO_MODE=true
FARO_AI_MODE=fallback
FARO_DEFAULT_COMPANY_ID=10000000-0000-0000-0000-000000000001
FARO_TEST_NOW=2026-05-31T18:00:00-03:00

# --- Providers fake (no requieren credenciales) ---
EMAIL_PROVIDER=fake
STORAGE_PROVIDER=fake
AI_PROVIDER=fallback

# --- SMTP capturado por mailhog ---
SMTP_HOST=localhost
SMTP_PORT=1025

Comandos clave

CMD 01

make seed

Aplica migraciones y carga seeds base + Empresa Demo. Equivale a pnpm db:migrate:demo && pnpm db:seed:base && pnpm db:seed:demo.

CMD 02

make demo

Levanta todo: docker-compose up -d → seeds → load-csv → pipeline → Score → reporte → demo-check. Termina con URL final.

CMD 03

make demo-reset

Borra volumen Postgres, limpia Redis y reconstruye desde cero. Útil entre demos para garantizar estado limpio.

CMD 04

make demo-check

Corre qa/demo-check.ts comparando outputs reales (KPIs, tensiones, Score, reporte) contra data/expected/*.json. Devuelve PASS o FAIL.

CMD 05

make demo-pipeline

Solo ejecuta el pipeline (sin levantar contenedores). Útil para re-correr con cambios en reglas o KPIs sin recargar CSVs.

CMD 06

make demo-report

Regenera el reporte semanal ejecutivo. Soporta flag --week=22 para apuntar a períodos específicos del dataset 6 meses.

Output esperado de make demo

▸ consola · salida exitosa esperada
FARO Demo MVP

[OK] PostgreSQL healthy
[OK] Redis healthy
[OK] Mailhog ready
[OK] Migrations applied (V001..V040)
[OK] Base catalogs seeded
[OK] Empresa Demo Cuyo S.A. loaded (3 sucursales, 7 usuarios)
[OK] CSV dataset loaded (18 archivos, 4.820 ventas, 2.140 movimientos)
[OK] KPIs calculated
[OK] 30 MVP tensions evaluated (18 active, 10 critical/high)
[OK] Actions created (42 total, 6 critical, 5 expired)
[OK] Workflow initialized (estados mixtos)
[OK] Evidence seeded (8 submitted, 1 rejected, 11 missing)
[OK] FARO Score calculated: 66 (delta -8 vs 74)
[OK] Weekly report generated
[OK] AI fallback explanation generated
[OK] Demo check: PASS

Open:
http://localhost:3000/faro/demo
http://localhost:8025/         # Mailhog: ver notificaciones
06 · IDs determinísticos y usuarios demo

UUIDs fijos + 6 usuarios canónicos + 1 viewer

Para que la demo sea reproducible y los tests sean estables, todos los IDs principales son fijos. Los usuarios siguen nombres argentinos realistas del rubro construcción Cuyo.

IDs determinísticos

EntidadUUIDUso
Empresa Demo Cuyo S.A.10000000-0000-0000-0000-000000000001company_id canónico del tenant demo
Sucursal Mendoza Centro11000000-0000-0000-0000-000000000001Casa central, mayor volumen
Sucursal Mendoza Norte11000000-0000-0000-0000-000000000002Depósito + sucursal comercial
Sucursal San Juan11000000-0000-0000-0000-000000000003Expansión reciente, ventas en crecimiento
Director12000000-0000-0000-0000-000000000001Ver Score, reporte, decisiones
Gerente General12000000-0000-0000-0000-000000000002Operar dashboard, aprobar acciones
Responsable Comercial12000000-0000-0000-0000-000000000003Ejecutar acciones comerciales
Responsable Finanzas12000000-0000-0000-0000-000000000004Gestionar cobranza
Responsable Stock12000000-0000-0000-0000-000000000005Stock crítico y reposición
Aprobador Dirección12000000-0000-0000-0000-000000000006Aprobar evidencia crítica

6 usuarios canónicos + 1 viewer

Director
Mario García

Director general. Ve Score, reporte semanal, decisiones requeridas. Usuario del botón “ver mi semana FARO”.

Gerente General
Lucía Romero

Gerencia general. Opera dashboard ejecutivo, aprueba acciones y evidencia, escala lo que el director debe ver.

Responsable Comercial
Diego Funes

Política de descuentos, plan de márgenes, asignaciones por vendedor. Día a día en ACT-COM-*.

Responsable Finanzas
Soledad Ortiz

Cobranza, mora crítica, límite de crédito. Owner de ACT-FIN-* y evidencia financiera.

Responsable Stock
Pablo Sosa

Cobertura, reposición y stock crítico en Mendoza Norte. Owner de ACT-STK-*.

Aprobador Dirección
Andrea Vidal

Aprueba evidencia crítica antes de cierre. Sin este rol, ACT-COM-001 no cierra ni recupera Score.

Viewer (solo lectura)
Sandra López

Rol auditor / consultora externa. Útil para probar RLS y permisos restringidos en la demo.

Password demo. Todos los usuarios demo comparten password demo123456. Solo válido en ambiente demo con FARO_DEMO_MODE=true. Nunca producción: el seed verifica el flag y se niega a correr si detecta producción. Emails terminan en .test (TLD reservado) para garantizar que ningún envío accidental escape al mundo real.

07 · 18 CSVs oficiales

Dataset 6 meses · columnas + ejemplos in extenso

Cada CSV está especificado con sus columnas y muestras realistas del rubro construcción Cuyo. La ingesta los carga a raw_*; el pipeline los normaliza al modelo FARO canónico.

001_companies_branches_areas.csv4 filas

Estructura tenant: empresa → sucursales → áreas funcionales. Base para RLS.

▸ columnas + 4 ejemplos
company_code,company_name,branch_code,branch_name,area_code,area_name,is_active
EMP-DEMO,Empresa Demo Cuyo S.A.,BR-MDZ-CENTRO,Mendoza Centro,COM,Comercial,true
EMP-DEMO,Empresa Demo Cuyo S.A.,BR-MDZ-CENTRO,Mendoza Centro,FIN,Finanzas,true
EMP-DEMO,Empresa Demo Cuyo S.A.,BR-MDZ-NORTE,Mendoza Norte,STK,Stock,true
EMP-DEMO,Empresa Demo Cuyo S.A.,BR-SJ,Sucursal San Juan,COM,Comercial,true
002_products.csv260 filas

Catálogo de productos con cost_price, list_price, stock mín/máx y marca de criticidad para reglas de cobertura.

▸ columnas + 5 ejemplos
product_code,sku,name,category,subcategory,unit,cost_price,list_price,current_stock,min_stock,max_stock,is_critical,margin_target_pct
PROD-001,CEM-50KG,Cemento bolsa 50kg,Cemento,Bolsas,unidad,6200,8900,180,300,900,true,28
PROD-002,HIE-08,Hierro nervado 8mm,Hierro,Barras,unidad,3400,4850,950,700,1800,true,30
PROD-003,REV-PORC-60,Porcelanato 60x60,Revestimientos,Pisos,m2,9800,14500,220,180,600,false,32
PROD-004,CAL-25KG,Cal hidráulica 25kg,Áridos,Bolsas,unidad,2900,4100,440,300,1200,false,28
PROD-005,LAD-CER-18,Ladrillo cerámico 18x18x33,Mampostería,Ladrillos,unidad,310,470,12800,8000,30000,true,33
003_customers.csv180 filas

Cartera de clientes con segmento, límite de crédito, plazo de pago y nivel de riesgo. Base para TNS-005 / TNS-016.

▸ columnas + 4 ejemplos
customer_code,name,customer_type,segment,credit_limit,payment_terms_days,risk_level,branch_code,is_active
CLI-001,Constructora Los Andes,empresa,constructoras,25000000,30,medium,BR-MDZ-CENTRO,true
CLI-002,Obra Particular Godoy Cruz,persona,particular,1500000,0,low,BR-MDZ-CENTRO,true
CLI-003,Desarrolladora Norte SRL,empresa,desarrolladoras,45000000,45,high,BR-MDZ-NORTE,true
CLI-004,Cooperativa Viña Real,empresa,cooperativas,8000000,30,medium,BR-SJ,true
004_employees.csv42 filas

Empleados con rol, área, sucursal y esquema de comisión. Base para TNS-003 (vendedor erosiona margen).

▸ columnas + 4 ejemplos
employee_code,user_email,full_name,role_code,area_code,branch_code,commission_scheme,is_active
EMP-001,comercial@empresa-demo.test,Diego Funes,responsible_owner,COM,BR-MDZ-CENTRO,ventas_margen,true
EMP-002,finanzas@empresa-demo.test,Soledad Ortiz,responsible_owner,FIN,BR-MDZ-CENTRO,no_aplica,true
EMP-003,stock@empresa-demo.test,Pablo Sosa,responsible_owner,STK,BR-MDZ-NORTE,no_aplica,true
EMP-004,vendedor1@empresa-demo.test,Marcos Pereira,seller,COM,BR-MDZ-CENTRO,ventas_brutas,true
005_suppliers.csv35 filas

Proveedores con condición de pago, lead time y nivel de criticidad. Base para TNS-023 (proveedor crítico con demora).

▸ columnas + 3 ejemplos
supplier_code,name,category,payment_terms_days,lead_time_days,criticality,is_active
SUP-001,Cementos Andinos S.A.,cemento,30,5,critical,true
SUP-002,Aceros Cuyanos,hierro,45,10,critical,true
SUP-003,Revestimientos del Sur,revestimientos,60,20,medium,true
006_sales.csv4.820 filas

Cabecera de ventas con cliente, vendedor, bruto, descuento, neto, costo y margen. Núcleo para TNS-001 / TNS-002 / TNS-015.

▸ columnas + 3 ejemplos
sale_id,sale_date,branch_code,customer_code,seller_code,document_type,invoice_number,gross_amount,discount_amount,net_amount,cost_amount,margin_amount,payment_condition,status
SALE-000001,2026-01-03,BR-MDZ-CENTRO,CLI-001,EMP-001,factura,F-0001-000001,1250000,75000,1175000,835000,340000,credit,confirmed
SALE-000002,2026-05-18,BR-MDZ-NORTE,CLI-003,EMP-001,factura,F-0001-004201,3850000,462000,3388000,2680000,708000,credit,confirmed
SALE-000003,2026-05-22,BR-SJ,CLI-004,EMP-004,factura,F-0001-004388,890000,53400,836600,612000,224600,cash,confirmed
007_sales_items.csv13.450 filas

Líneas de venta detalladas. Necesario para abrir margen por familia (TNS-014).

▸ columnas + 3 ejemplos
sale_item_id,sale_id,product_code,quantity,unit_price,discount_pct,gross_amount,net_amount,cost_amount,margin_amount
SI-000001,SALE-000001,PROD-001,100,8900,6,890000,836600,620000,216600
SI-000002,SALE-000002,PROD-002,350,4850,12,1697500,1493800,1190000,303800
SI-000003,SALE-000003,PROD-004,200,4100,6,820000,770800,580000,190800
008_stock_movements.csv2.140 filas

Movimientos de stock: ventas, compras, ajustes, transferencias. Base para TNS-006 y rotación.

▸ columnas + 3 ejemplos
movement_id,movement_date,branch_code,product_code,movement_type,quantity,unit_cost,reference_type,reference_id
STM-000001,2026-05-18,BR-MDZ-CENTRO,PROD-001,sale,-100,6200,sale,SALE-000001
STM-000002,2026-05-20,BR-MDZ-CENTRO,PROD-001,purchase,300,6400,purchase,PUR-000120
STM-000003,2026-05-21,BR-MDZ-NORTE,PROD-002,transfer,-50,3400,transfer,TRF-000045
009_inventory_snapshot.csv780 filas

Snapshot diario de inventario con días de cobertura. Disparador de TNS-006 cuando cobertura cae bajo umbral.

▸ columnas + 3 ejemplos
snapshot_date,branch_code,product_code,current_stock,min_stock,max_stock,stock_value,days_coverage,is_critical
2026-05-31,BR-MDZ-CENTRO,PROD-001,180,300,900,1116000,8,true
2026-05-31,BR-MDZ-NORTE,PROD-002,950,700,1800,3230000,22,false
2026-05-31,BR-SJ,PROD-004,220,300,1200,638000,11,true
010_accounts_receivable.csv620 filas

Cuentas por cobrar con días vencidos y estado. Base para TNS-004 y TNS-005.

▸ columnas + 3 ejemplos
ar_id,customer_code,invoice_number,issue_date,due_date,original_amount,open_amount,days_overdue,risk_level,status
AR-000001,CLI-003,F-0001-004201,2026-05-18,2026-06-17,3388000,3388000,0,high,open
AR-000002,CLI-001,F-0001-003120,2026-04-10,2026-05-10,2500000,1800000,21,medium,overdue
AR-000003,CLI-004,F-0001-002550,2026-03-15,2026-04-14,1750000,1200000,47,high,overdue
011_collections.csv480 filas

Cobranza realizada con método de pago y estado. Para calcular DSO y close rate por cliente.

▸ columnas + 3 ejemplos
collection_id,collection_date,customer_code,invoice_number,amount,payment_method,status
COL-000001,2026-05-25,CLI-001,F-0001-003120,700000,transfer,confirmed
COL-000002,2026-05-28,CLI-004,F-0001-002550,550000,check,confirmed
COL-000003,2026-05-29,CLI-002,F-0001-004500,180000,cash,confirmed
012_purchases.csv410 filas

Compras a proveedores con fecha de pedido, recepción y costo. Base para TNS-008 (reposición reactiva).

▸ columnas + 3 ejemplos
purchase_id,order_date,received_date,supplier_code,total_amount,payment_terms_days,status
PUR-000120,2026-05-15,2026-05-20,SUP-001,1920000,30,received
PUR-000121,2026-05-18,2026-05-28,SUP-002,3400000,45,received
PUR-000122,2026-05-25,2026-06-04,SUP-003,2200000,60,pending
013_purchase_items.csv1.220 filas

Líneas de compra detalladas con costo unitario. Base para variación de costo (TNS-022).

▸ columnas + 3 ejemplos
purchase_item_id,purchase_id,product_code,quantity,unit_cost,total_cost
PI-000001,PUR-000120,PROD-001,300,6400,1920000
PI-000002,PUR-000121,PROD-002,1000,3400,3400000
PI-000003,PUR-000122,PROD-003,150,9800,1470000
014_actions.csv42 filas

Acciones recomendadas canónicas (ACT-COM-001, ACT-FIN-001, etc.) con responsable, aprobador, prioridad y criterio de cierre.

▸ columnas + 3 ejemplos
action_code,tension_code,title,responsible_email,approver_email,priority,status,due_date,closure_criteria,expected_score_recovery_max
ACT-COM-001,TNS-001,Revisar política de descuentos,comercial@empresa-demo.test,aprobador@empresa-demo.test,critical,in_review,2026-06-06,Política aprobada y comunicada,8
ACT-FIN-001,TNS-004,Activar plan de cobranza prioritaria,finanzas@empresa-demo.test,gg@empresa-demo.test,critical,expired,2026-05-29,Plan ejecutado con comprobantes,6
ACT-STK-001,TNS-006,Reponer stock crítico Mendoza Norte,stock@empresa-demo.test,gg@empresa-demo.test,critical,blocked,2026-06-03,Orden de compra emitida y confirmada,5
015_evidence.csv20 filas

Evidencias canónicas (EVD-007, EVD-012, etc.) con trust level y estado. Mezcla intencional de submitted / approved / rejected / missing.

▸ columnas + 3 ejemplos
evidence_code,action_code,title,evidence_type,trust_level,status,file_path,submitted_by_email,reviewed_by_email,review_comment
EVD-007,ACT-COM-001,Política de descuentos revisada,policy_document,critical,submitted,data/files/evidencia/politica-descuentos-v1.pdf,comercial@empresa-demo.test,,
EVD-012,ACT-COM-001,Validación de Dirección,direction_validation,critical,missing,,,
EVD-006,ACT-FIN-001,Comprobante cobranza cliente,external_receipt,high,rejected,data/files/evidencia/comprobante-cobranza-cliente-001.pdf,finanzas@empresa-demo.test,gg@empresa-demo.test,Falta comprobante bancario definitivo
016_workflow_events.csv85 filas

Eventos de cambio de estado: action_assigned, action_expired, evidence_submitted, action_escalated. Alimenta timeline.

▸ columnas + 3 ejemplos
event_id,event_date,action_code,event_type,actor_email,from_state,to_state,payload_json
WFE-000001,2026-05-22,ACT-COM-001,action_assigned,gg@empresa-demo.test,new,in_progress,"{""due_date"":""2026-06-06""}"
WFE-000002,2026-05-25,ACT-COM-001,evidence_submitted,comercial@empresa-demo.test,in_progress,in_review,"{""evidence_code"":""EVD-007""}"
WFE-000003,2026-05-30,ACT-FIN-001,action_expired,system,in_progress,expired,"{""days_overdue"":1}"
017_kpi_inputs.csv320 filas

Inputs precalculados para KPIs por período y dimensión. Permite validar reglas sin tener que correr todo el pipeline.

▸ columnas + 3 ejemplos
kpi_code,period_start,period_end,branch_code,dimension,value,confidence
KPI-SAL-001,2026-05-25,2026-05-31,BR-MDZ-CENTRO,total_sales,18450000,95
KPI-SAL-002,2026-05-25,2026-05-31,BR-MDZ-CENTRO,gross_margin_pct,21.3,92
KPI-FIN-001,2026-05-25,2026-05-31,BR-MDZ-CENTRO,dso_days,43,90
018_score_snapshots.csv26 filas

Snapshots semanales de Score con componentes y confianza. Permite reproducir el delta 74 → 66 y la trayectoria 6 meses.

▸ columnas + 3 ejemplos
snapshot_date,period_start,period_end,score_current,score_previous,score_delta,status,confidence,kpi_health,tension_health,execution_health,evidence_health,governance_health
2026-05-31,2026-05-25,2026-05-31,66,74,-8,warning,82,20,14,12,10,10
2026-05-24,2026-05-18,2026-05-24,74,76,-2,attention,84,22,17,14,11,10
2026-05-17,2026-05-11,2026-05-17,76,78,-2,attention,85,23,18,15,10,10
08 · 30 tensiones esperadas

TNS-001..TNS-030 mapeadas a casos del dataset demo

El motor evaluador evalúa las 30 tensiones canónicas del catalogo. La columna “Señal demo” muestra qué combinación de datos en la Empresa Demo dispara la regla. Los nombres son los del catálogo canónico (CAT-001 manda, D4).

Reconciliación DEMO-001 → CAT-001. El spec original FARO-DEMO-001 listaba nombres de tensión diferentes a los del catálogo canónico. Se aplicaron los nombres oficiales del catálogo (TNS-002 “Descuento fuera de política”, TNS-003 “Vendedor erosiona margen”, TNS-005 “Mora crítica por cliente”, TNS-007 “Stock inmovilizado”, TNS-008 “Reposición reactiva”, TNS-009 “Acciones vencidas”, TNS-010 “Acciones sin evidencia”, etc.). Severidades y dimensiones de Score también se alinean con CAT-001 (TNS-001 es high, no critical).

Código Nombre canónico (CAT-001) Área Severidad Señal en Empresa Demo Demo
TNS-001Crecimiento no rentableComercialHighVentas +18% + margen 28%→21% + descuento 6%→12%DEMO
TNS-002Descuento fuera de políticaComercialHighDescuento promedio supera umbral autorizado en BR-MDZ-NORTEDEMO
TNS-003Vendedor erosiona margenComercialHighEMP-001 vende alto volumen con margen 14% vs target 28%DEMO
TNS-004Venta sin conversión a cajaFinanzasHighDSO 32 → 43 días + mora subiendoDEMO
TNS-005Mora crítica por clienteFinanzasHighCLI-004 con 47 días vencidos y monto 1.2M abiertoDEMO
TNS-006Stock crítico alta rotaciónStockHighPROD-001 (cemento) con cobertura 8 días vs mín 14DEMO
TNS-007Stock inmovilizadoStockMediumPROD-003 (porcelanato) sin venta 60 días, valor 2.2MDEMO
TNS-008Reposición reactivaComprasHighPUR-000122 emitida 5 días después del quiebre
TNS-009Acciones vencidasDirecciónMedium5 acciones con due_date superado (incluye ACT-FIN-001)DEMO
TNS-010Acciones sin evidenciaDirecciónHigh11 acciones avanzadas sin evidencia válida cargadaDEMO
TNS-011Ventas concentradas en pocos clientesComercialHighTop 5 clientes concentran 62% del facturado
TNS-012Ticket promedio cae con ventas establesComercialMediumTicket promedio -14% mientras volumen se sostiene
TNS-013Caída de ventas en sucursal relevanteComercialHighBR-SJ con -22% vs trimestre anterior
TNS-014Margen bajo por familia de productoComercialHighFamilia Revestimientos con margen 18% vs target 32%
TNS-015Venta crece por descuento, no por demanda sanaComercialHighCrecimiento +18% explicado 70% por aumento de descuento
TNS-016Cliente supera límite de créditoFinanzasCriticalCLI-003 con exposición 48M vs límite 45M
TNS-017Cobranza concentrada en pocos responsablesFinanzasMediumEMP-002 gestiona 78% de la cobranza vencida
TNS-018Facturación alta con cobranza parcialFinanzasHighFacturación mensual 84M cobrado solo 58M
TNS-019Caja proyectada insuficienteFinanzasCriticalCaja proyectada D+30 -6.5M vs compromisos
TNS-020Mora creciente sin gestión registradaFinanzasHigh+18% en mora pero 0 acciones de cobranza con evidencia
TNS-021Quiebre de stock con ventas perdidasStockHigh3 quiebres PROD-001 con demanda no atendida estimada 1.8M
TNS-022Compra con costo creciente y margen sin ajustarComprasHighCosto PROD-001 sube 3.2% sin ajuste en lista de precios
TNS-023Proveedor crítico con demora recurrenteComprasHighSUP-002 con 3 demoras >7 días en último trimestre
TNS-024Stock alto con deuda a proveedoresFinanzas/StockHighStock 42M + deuda proveedores 38M (ratio 1.10)
TNS-025Reposición sin rotación suficienteComprasMediumPUR-000122 repone PROD-003 que tiene 60 días sin venta
TNS-026Dirección sin visibilidad semanalDirecciónHighReporte semanal no se genera 2 semanas seguidas (simulado)DEMO
TNS-027Fuente crítica atrasadaDatosHighkpi_inputs sin update por 48hs (BR-SJ)DEMO
TNS-028Baja confianza de dato en KPI críticoDatosHighKPI-FIN-001 con confidence 65% por campos faltantesDEMO
TNS-029Responsable no asignado en acción críticaDirecciónCritical1 acción crítica TNS-019 sin owner_email asignadoDEMO
TNS-030Tensión crítica reincidenteDirecciónCriticalTNS-001 se repite 3 períodos consecutivos → escalada L3DEMO

Distribución esperada. 30 tensiones evaluadas; mínimo 18 activas; 10 críticas o altas en la bandeja; 14 con demo_relevance = true visibles en pantallas demo (las marcadas DEMO). Top priority: TNS-001 Crecimiento no rentable con priority_score ≥ 90 y severidad efectiva critical por umbral compuesto (margen + descuento).

09 · Acciones y evidencias esperadas

Códigos canónicos ACT-* y EVD-* con estados mixtos

Las acciones siguen el catálogo canónico de acciones (FARO-SQL-005). Las evidencias también. La demo no muestra todo verde: muestra acciones vencidas, evidencia rechazada y escalamientos reales para evitar el efecto PowerPoint.

Acciones esperadas

AcciónTensiónResponsableEstadoVencimientoEvidenciaScore recovery
ACT-COM-001TNS-001Comercial (Diego Funes)in_review2026-06-06EVD-007 submitted · EVD-012 missing+8
ACT-COM-002TNS-002Comercial (Diego Funes)in_progress2026-06-10EVD-011 approved+4
ACT-FIN-001TNS-004Finanzas (Soledad Ortiz)expired2026-05-29EVD-006 rejected+6
ACT-STK-001TNS-006Stock (Pablo Sosa)blocked2026-06-03EVD-008 missing+5
ACT-COM-003TNS-002Comercial (Diego Funes)new2026-06-12EVD-007 referenced+3
ACT-COM-004TNS-003Comercial / RRHHin_analysis2026-06-15missing+3
ACT-FIN-002TNS-005Finanzas (Soledad Ortiz)waiting_evidence2026-06-08EVD-011 pendiente segunda firma+4
ACT-DIR-001TNS-030Gerencia → Direcciónescalated2026-06-02EVD-012 missing (L3)+5
ACT-DQ-001TNS-027Data ownerclosed2026-05-28EVD-004 approved+2
ACT-OPS-001TNS-009Gerencia Generalin_progress2026-06-09EVD-010 referenced+3

Total acciones demo: 42 (10 mostradas arriba como muestra). 6 críticas, 5 vencidas, 3 bloqueadas, 3 escaladas, 8 cerradas con evidencia, 11 con evidencia faltante. Cada action_code resuelve contra el catálogo canónico de acciones.

Evidencias esperadas

EvidenciaAcciónEstadoTrustLectura ejecutiva
EVD-007ACT-COM-001submittedcriticalPolítica de descuentos cargada, falta validación de Dirección
EVD-012ACT-COM-001missingcriticalAprobación de Dirección faltante → bloquea cierre y recovery
EVD-006ACT-FIN-001rejectedhighComprobante bancario insuficiente → cobranza no acreditada
EVD-008ACT-STK-001missinghighFalta orden de compra emitida con confirmación del proveedor
EVD-003ACT-DIR-001submittedcriticalCaso escalado L3, aprobación de Director pendiente
EVD-011ACT-COM-002approvedmediumComunicación interna validada por gerencia
EVD-004ACT-DQ-001approvedhighReproceso de datos confirmado, KPI vuelve a verde
EVD-010ACT-OPS-001submittedmediumReporte de avance cargado, falta foto de cierre

Total evidencias requeridas en el período demo: 20. Submitted: 8 · Approved: 5 · Rejected: 1 · Missing: 8. El balance es intencional: una demo con todo verde no vende FARO porque no existe ninguna empresa real con todo verde.

expected/actions_expected.json

▸ data/expected/actions_expected.json
{
  "actions_total_min": 30,
  "actions_critical_min": 6,
  "actions_expired_min": 3,
  "actions_blocked_min": 2,
  "actions_in_review_min": 2,
  "actions_with_missing_evidence_min": 8,
  "required_actions": [
    {
      "action_code": "ACT-COM-001",
      "tension_code": "TNS-001",
      "status": "in_review",
      "expected_score_recovery_max": 8
    },
    {
      "action_code": "ACT-FIN-001",
      "tension_code": "TNS-004",
      "status": "expired",
      "expected_score_recovery_max": 6
    },
    {
      "action_code": "ACT-STK-001",
      "tension_code": "TNS-006",
      "status": "blocked",
      "expected_score_recovery_max": 5
    }
  ]
}
10 · Workflow y Score

Estados mixtos + Score 74 → 66 con recuperación potencial +8

El workflow muestra distribución realista de estados. El Score cae 8 puntos y puede recuperar otros 8 si se cierran las acciones críticas con evidencia aprobada (D7).

Distribución de estados workflow esperada

5
new
4
in_analysis
8
in_progress
6
waiting_evidence
3
in_review
3
blocked
5
expired
8
closed
3
escalated

expected/workflow_expected.json

▸ data/expected/workflow_expected.json
{
  "expired_actions_min": 3,
  "blocked_actions_min": 2,
  "open_escalations_min": 2,
  "timeline_events_min": 80,
  "required_events": [
    "tension_detected",
    "action_created",
    "action_assigned",
    "action_expired",
    "evidence_submitted",
    "evidence_rejected",
    "action_escalated",
    "score_recalculated",
    "weekly_report_generated"
  ]
}

Score esperado · componentes y drivers

▸ data/expected/score_expected.json
{
  "period_start": "2026-05-25",
  "period_end": "2026-05-31",
  "score": {
    "current": 66,
    "previous": 74,
    "delta": -8,
    "status": "warning",
    "confidence_min": 80,
    "confidence_status": "good"
  },
  "components": {
    "kpi_health":        { "expected": 20, "tolerance": 3 },
    "tension_health":    { "expected": 14, "tolerance": 3 },
    "execution_health":  { "expected": 12, "tolerance": 3 },
    "evidence_health":   { "expected": 10, "tolerance": 3 },
    "governance_health": { "expected": 10, "tolerance": 2 }
  },
  "required_negative_drivers": [
    "TNS-001", "TNS-004", "TNS-006",
    "ACTION_EXPIRED", "EVIDENCE_MISSING"
  ],
  "required_recovery_opportunities": [
    "ACT-COM-001", "ACT-FIN-001", "ACT-STK-001"
  ],
  "recovery_after_actions": {
    "score_current_after_actions": 74,
    "score_delta_after_actions": 8,
    "score_status_after_actions": "attention",
    "recovery_explanation": "La recuperación se produce por cierre de acciones críticas con evidencia aprobada."
  }
}

Recuperación potencial es techo, no automática (D7). El recovery +8 requiere las tres condiciones simultáneamente: ACT-COM-001 con EVD-007 + EVD-012 aprobadas, ACT-FIN-001 re-abierta con EVD-006 reemplazada por evidencia válida, ACT-STK-001 desbloqueada con EVD-008 cargada y revisada. Si una sola falla, el techo baja proporcionalmente. El Score no recupera por promesa.

11 · Reporte semanal e IA controlada

Reporte ejecutivo + explicación IA con slots y audit_trail (D5)

El reporte semanal es el output visible para el Director. La IA explica sin inventar usando slots controlados; si el proveedor no responde, el fallback determinístico produce el mismo formato.

Preview del reporte semanal

Empresa Demo Cuyo S.A.
Semana 22 · Mayo 2026 · reporte generado 2026-05-31 18:00 ART
FARO Score
66 (delta −8 vs semana 21). Status: warning. Confianza: 82%.
Tensiones críticas
TNS-001 (Crecimiento no rentable), TNS-004 (Venta sin conversión a caja), TNS-006 (Stock crítico alta rotación).
Acciones vencidas
5 acciones con due_date superado. Crítica: ACT-FIN-001 (cobranza prioritaria).
Evidencias pendientes
11 evidencias faltantes. Bloqueantes: EVD-012 (Dirección), EVD-008 (orden de compra).
Escalamientos abiertos
3 escalamientos. Uno L3 abierto: ACT-DIR-001 por reincidencia TNS-001.
Decisiones requeridas
Aprobar política de descuentos revisada (Dirección). Confirmar plan de cobranza prioritaria (Gerencia General).
Recomendaciones
Cerrar ACT-COM-001, ACT-FIN-001 y ACT-STK-001 con evidencia válida para recuperar Score a 74.
Foco próxima semana
Margen comercial · cobranza CLI-003/CLI-004 · reposición cemento BR-MDZ-NORTE.

expected/report_expected.json

▸ data/expected/report_expected.json
{
  "report_type": "weekly_executive",
  "must_include": [
    "Empresa Demo Cuyo S.A.",
    "FARO Score",
    "66",
    "-8",
    "Crecimiento no rentable",
    "acciones vencidas",
    "evidencia",
    "escalamientos",
    "decisiones requeridas"
  ],
  "required_sections": [
    "Resumen ejecutivo",
    "FARO Score",
    "Tensiones principales",
    "Acciones críticas",
    "Evidencias",
    "Escalamientos",
    "Decisiones requeridas",
    "Foco próxima semana"
  ],
  "status_expected": "generated"
}

expected/ai_expected.json · slots controlados con audit_trail (D5)

▸ data/expected/ai_expected.json
{
  "mode": "fallback_or_provider",
  "score_explanation": {
    "must_include_refs":      ["SCORE", "TNS-001"],
    "must_not_include_refs":  ["TNS-999"],
    "must_include_numbers":   [66, -8],
    "must_not_invent_actions": true,
    "must_have_missing_information_array": true
  },
  "slots": {
    "score_current":      { "source": "faro.score_snapshots", "value": 66 },
    "score_previous":     { "source": "faro.score_snapshots", "value": 74 },
    "top_tension":         { "source": "faro.tensions",        "value": "TNS-001" },
    "top_action":          { "source": "faro.actions",         "value": "ACT-COM-001" },
    "missing_evidence":    { "source": "faro.evidence",        "value": ["EVD-012", "EVD-008"] }
  },
  "audit_trail": {
    "prompt_template_id": "PROMPT-WEEKLY-EXEC-v1",
    "slots_resolved_at":  "2026-05-31T17:55:00-03:00",
    "provider_used":      "fallback",
    "validation_passed":  true
  },
  "guardrails": {
    "invalid_source_ref_rejected": true,
    "prompt_injection_detected":   true,
    "fallback_available":          true
  }
}

Por qué slots con audit_trail (D5). La IA no puede inventar números, códigos ni acciones. Cada slot se resuelve contra una fuente explícita de la base FARO antes de armar el prompt; el modelo solo redacta sobre slots resueltos. El audit_trail deja registro de qué template, qué valores, qué proveedor y si pasó las validaciones (refs válidos, números esperados, ausencia de acciones inventadas). Si la validación falla, se activa el fallback determinístico que produce el mismo formato sin LLM.

12 · Seeds SQL + run-pipeline.sh

Inserts canónicos + orquestador del pipeline

Seeds idempotentes con ON CONFLICT DO UPDATE. Pipeline en orden explícito: ingesta → staging → normalización → KPIs → reglas → tensiones → acciones → workflow → evidencia → Score → reporte → IA → demo-check.

001_seed_demo_company.sql

▸ db/seeds/001_seed_demo_company.sql
INSERT INTO faro.companies (
  company_id,
  company_code,
  name,
  industry_code,
  country,
  timezone,
  ai_enabled
)
VALUES (
  '10000000-0000-0000-0000-000000000001',
  'EMP-DEMO',
  'Empresa Demo Cuyo S.A.',
  'commerce_construction_supplies',
  'AR',
  'America/Argentina/Mendoza',
  true
)
ON CONFLICT (company_id)
DO UPDATE SET
  name = EXCLUDED.name,
  industry_code = EXCLUDED.industry_code,
  timezone = EXCLUDED.timezone,
  updated_at = now();

002a Sucursales

▸ db/seeds/001_seed_demo_company.sql (continuación)
INSERT INTO faro.branches (
  branch_id, company_id, branch_code, name, city, province, country, is_active
)
VALUES
( '11000000-0000-0000-0000-000000000001',
  '10000000-0000-0000-0000-000000000001',
  'BR-MDZ-CENTRO', 'Mendoza Centro', 'Mendoza', 'Mendoza', 'AR', true ),
( '11000000-0000-0000-0000-000000000002',
  '10000000-0000-0000-0000-000000000001',
  'BR-MDZ-NORTE', 'Mendoza Norte', 'Mendoza', 'Mendoza', 'AR', true ),
( '11000000-0000-0000-0000-000000000003',
  '10000000-0000-0000-0000-000000000001',
  'BR-SJ', 'Sucursal San Juan', 'San Juan', 'San Juan', 'AR', true )
ON CONFLICT (branch_id)
DO UPDATE SET
  name = EXCLUDED.name,
  updated_at = now();

scripts/run-pipeline.sh

▸ scripts/run-pipeline.sh · orquestador del pipeline FARO
#!/usr/bin/env bash
set -euo pipefail

echo "FARO Demo Pipeline · starting"

# 1. Ingesta CSV a RAW
echo "[1/14] Loading CSVs to RAW..."
pnpm demo:load-csv --dir data/csv

# 2. Validación RAW
echo "[2/14] Validating RAW..."
pnpm demo:validate-raw

# 3. Promoción a staging
echo "[3/14] Promoting RAW to staging..."
pnpm demo:promote-staging

# 4. Normalización
echo "[4/14] Normalizing staging..."
pnpm demo:normalize

# 5. Upsert master data
echo "[5/14] Upserting master data..."
pnpm demo:upsert-master

# 6. Insert facts
echo "[6/14] Inserting facts..."
pnpm demo:insert-facts

# 7. KPIs
echo "[7/14] Calculating KPIs..."
pnpm demo:kpis

# 8. Reglas y tensiones
echo "[8/14] Evaluating rules and detecting tensions..."
pnpm demo:rules

# 9. Acciones recomendadas
echo "[9/14] Creating recommended actions..."
pnpm demo:actions

# 10. Workflow checker
echo "[10/14] Running workflow checker..."
pnpm demo:workflow

# 11. Evidencias
echo "[11/14] Seeding demo evidence..."
pnpm demo:evidence

# 12. Notificaciones
echo "[12/14] Dispatching demo notifications..."
pnpm demo:notify

# 13. Score y reporte semanal
echo "[13/14] Calculating FARO Score and generating weekly report..."
pnpm demo:score
pnpm demo:report

# 14. IA fallback / provider
echo "[14/14] Generating AI explanation (slots + audit_trail)..."
pnpm demo:ai

echo ""
echo "FARO Demo Pipeline · PASS"
echo "Run scripts/demo-check.sh to validate outputs."
13 · 4 storyboards completos

10 min ejecutiva · 20 min comercial · 45 min técnica · WhatsApp

Cada storyboard tiene minuto-a-minuto explicitado. La frase clave de cada bloque es la que el operador debe poder decir mirando la pantalla.

Storyboard 1 · Demo ejecutiva 10 minutos

10 min

Audiencia: empresario / director ocupado. Objetivo: mostrar valor rápido sin entrar en ingeniería profunda. Lectura ejecutiva, lenguaje claro, una frase ancla por bloque.

  • 0–1Apertura. Mostrar la home con Score 66 y delta -8 ya visible. “Esto no es un dashboard. Es una capa de dirección que toma datos dispersos y los convierte en tensiones, acciones, responsables, evidencia, Score y reporte.”
  • 1–2Datos cargados. Mostrar contadores: ventas (4.820), stock (2.140 movimientos), cobranza (620 AR), compras (410). “Datos sintéticos, pero estructurados como una empresa real.”
  • 2–4Tensión principal. Click en TNS-001 (Crecimiento no rentable): Ventas +18%, Margen 28% → 21%, Descuentos 6% → 12%. “Un dashboard tradicional festeja ventas. FARO detecta que el crecimiento está destruyendo rentabilidad.”
  • 4–5Acción. Mostrar ACT-COM-001 con responsable (Diego Funes), vencimiento (2026-06-06), criterio de cierre, evidencia requerida (EVD-007 + EVD-012). “FARO no se queda en diagnóstico. Baja a acción con responsable y criterio de cierre.”
  • 5–6Evidencia. EVD-007 submitted, EVD-012 missing. “El Score no recupera por promesa. Recupera por evidencia aprobada.”
  • 6–7Score. Drawer con Score 66, delta -8, drivers negativos (TNS-001, TNS-004, TNS-006) y recovery potencial +8 a 74. “El Score explica qué deteriora y qué puede recuperar.”
  • 7–8Reporte semanal. Vista del reporte semana 22. “Dirección no necesita revisar 40 pantallas. Recibe lectura semanal accionable.”
  • 8–9IA controlada. Mostrar explicación IA con badge “slots+audit_trail”. “La IA no inventa ni decide. Explica lo que FARO ya calculó y validó.”
  • 9–10Cierre. Volver a la home. “Este paquete no es solo conceptual. Se levanta con Docker, corre seeds, calcula outputs y se valida contra expected JSONs.”

Storyboard 2 · Demo comercial 20 minutos

20 min

Audiencia: socio comercial, gerente general de empresa cliente, posible piloto. Profundiza en bandeja, workflow, evidencia y reporte. Bloques explícitos para no improvisar.

  • 0–2Tesis FARO. Capa de dirección, no dashboard. Pieza productiva, no presentación. Diferencia con Power BI / Looker / Tableau.
  • 2–4Dataset y carga. Mostrar 18 CSVs, 6 meses, Empresa Demo Cuyo S.A., 3 sucursales (Mendoza Centro, Mendoza Norte, San Juan). Aclarar que es sintético y está etiquetado como tal.
  • 4–7TNS-001 Crecimiento no rentable. Abrir la tensión, mostrar KPIs disparadores (KPI-SAL-001, KPI-SAL-002, KPI-SAL-003), regla evaluada, drivers, evolución histórica 6 meses.
  • 7–9Bandeja de tensiones. 18 activas, 10 críticas/altas, filtros por área (Comercial/Finanzas/Stock/Dirección) y por estado.
  • 9–11Acción + workflow. ACT-COM-001 in_review, ACT-FIN-001 expired, ACT-STK-001 blocked. Mostrar timeline con eventos.
  • 11–13Evidencia + cierre bloqueado. EVD-007 submitted, EVD-012 missing (crítica), EVD-006 rejected (por qué rechazada). Mostrar cómo se reabre.
  • 13–15Score + drivers. Score 66 con sus 5 componentes (kpi_health 20, tension_health 14, execution_health 12, evidence_health 10, governance_health 10). Confianza 82%.
  • 15–17Reporte semanal. Generación del reporte, secciones obligatorias, cómo se distribuye (email, Slack, WhatsApp futuro).
  • 17–18IA controlada. Slots, audit_trail, prohibición de inventar acciones, fallback determinístico. Mostrar caso real de prompt injection bloqueado.
  • 18–19Seguridad / RLS / roles. Login como viewer y mostrar que no ve datos de otra empresa. Mostrar audit timeline.
  • 19–20demo-check y cierre. Correr make demo-check en pantalla, mostrar PASS. “Esto todavía no es producto terminado. Pero ya demuestra la cadena técnica y ejecutiva principal.”

Storyboard 3 · Demo técnica 45 minutos

45 min

Audiencia: CTO, arquitecto, equipo técnico del posible cliente. Profundidad real en arquitectura, datos, pipeline, workflow, Score, QA y operación. Mensaje honesto: lo que está y lo que falta.

  • 0–5Arquitectura. Diagrama de capas: ingesta → raw → staging → normalizado → modelo canónico → motor de reglas → workflow → Score → UI → reportes → IA. Explicar separación por company_id + RLS.
  • 5–10Docker + DB. Levantar en pantalla: docker-compose up -d, healthchecks, conexión a Postgres (54329), Redis (63799), mailhog (8025).
  • 10–15Migraciones. Mostrar V001..V040, RLS policies por tabla, seeds base. Cruzar con modelo-sql.html y seguridad-rls-mvp.html.
  • 15–20Dataset. Recorrer los 18 CSVs en data/csv/, mostrar conteos y formato. Abrir contrato-datos-mvp.html para ver el contrato canónico que cumplen los CSVs.
  • 20–28Pipeline. Ejecutar scripts/run-pipeline.sh en vivo. Mostrar 14 pasos, logs, conteos esperados vs reales. Cruzar con pipeline-interactivo.html.
  • 28–33Workflow. Recorrer una acción end-to-end: ACT-COM-001 desde tension_detected → action_assigned → evidence_submitted → in_review → (pendiente Dirección). Cruzar con workflow-escalamiento-mvp.html.
  • 33–38Score. Abrir el cálculo: 5 componentes, pesos, drivers negativos y recovery opportunities. Cruzar con motor-score-mvp.html.
  • 38–42Reporte + IA. Generar reporte, mostrar cómo se arma cada sección. Abrir audit_trail del slot resuelto, validar guardrails.
  • 42–45QA/OPS y preguntas. Correr make demo-check, mostrar PASS. Mostrar qa-estrategia-mvp.html PENDIENTE, jobs idempotentes, DLQ. Cerrar con preguntas. “No estamos diciendo que todo el producto esté terminado. Estamos mostrando que la arquitectura principal es ejecutable, testeable y escalable.”

Storyboard 4 · Guion WhatsApp corto

~90 seg

Audiencia: socio técnico o referente al que se le manda un mensaje para abrir conversación. Lenguaje directo, sin tecnicismos vacíos, con el dato concreto del caso.

  • M·1Hook. “Armamos un paquete demo ejecutable de FARO Connect. No es solo presentación: levanta PostgreSQL + Redis, carga una Empresa Demo Cuyo S.A. con 6 meses de datos sintéticos, corre migraciones, seeds, KPIs, reglas, tensiones, acciones, evidencia, workflow, Score y reporte semanal.”
  • M·2Caso. “El caso principal muestra una empresa que vende +18%, pero baja margen de 28% a 21%, aumenta descuentos y empeora cobranza. FARO detecta crecimiento no rentable, genera acciones, exige evidencia, calcula Score 66 y muestra recuperación potencial a 74.”
  • M·3Cierre. “La idea es que un socio técnico pueda ver no solo el concepto, sino la cadena funcionando y validada contra resultados esperados. Si te interesa darle una vuelta, te paso link y credenciales (NDA).”

Validaciones anti-humo. Cualquier storyboard debe poder responder en pantalla: de dónde salió TNS-001 (KPIs + regla), por qué Score 66 (componentes + drivers), qué acción lo recupera (ACT-COM-001 + expected recovery), qué falta para cerrar (EVD-012), quién es responsable (usuario/rol), qué pasa si vence (escalamiento), dónde queda registrado (timeline/audit), cómo sé que no inventa (expected JSON + source refs), cómo sé que corre (make demo-check PASS).

14 · FAQs CTO + FAQs Inversor

Preguntas reales con respuestas que no esquivan

Las dos audiencias técnicas-comerciales más exigentes. Las respuestas son honestas: lo que está resuelto, lo que falta, lo que no se hace todavía y por qué.

FAQ CTO (12 preguntas)

¿Esto está hardcodeado?

No debe estarlo y no lo está. El demo usa seeds y expected outputs, pero el pipeline calcula KPIs, tensiones, acciones y Score desde datos cargados. Los expected JSONs sirven para validar el resultado, no para simularlo. Si borrás el output y volvés a correr el pipeline, los números se recalculan desde cero.

¿Qué pasa si cambio los datos?

Si cambia el dataset, deberían cambiar KPIs, tensiones, Score y reporte. El demo-check permite validar si el resultado sigue dentro de la tolerancia esperada o si la divergencia es legítima. Para probar: editá 006_sales.csv bajando descuentos al 4% y vas a ver que TNS-002 baja su severidad.

¿Cómo evitan duplicados?

Con dedupe_key en cada entidad relevante, constraints únicos a nivel SQL y jobs idempotentes. Tensiones: UNIQUE (company_id, rule_id, period_start, period_end). Acciones: UNIQUE (company_id, tension_id, action_definition_id). Reportes: UNIQUE (company_id, report_code, period_start). Notificaciones: dedupe_key calculado por evento + ventana de supresión.

¿Cómo evitan cruce de empresas?

company_id obligatorio en cada tabla de datos. RLS (Row-Level Security) de PostgreSQL aplicada por SET app.current_company_id en el session context de cada request. Tests cross-company en CI: cualquier query que devuelva filas de más de una empresa falla el build. Cruzar con seguridad-rls-mvp.html.

¿La IA decide?

No. La IA solo explica payloads estructurados. FARO calcula, gobierna y audita. La IA recibe slots ya resueltos (Score actual, top tension, top action, missing evidence) y produce texto. Los guardrails rechazan refs inventados (TNS-999), exigen números esperados y bloquean prompt injection. Si la validación falla, se activa el fallback determinístico.

¿Qué pasa si no tengo API key de proveedor IA?

La demo corre con FARO_AI_MODE=fallback. El fallback determinístico produce el mismo formato que el proveedor (mismos slots, misma estructura), solo que sin LLM detrás. Mensaje visible al usuario: “Explicación generada por FARO sin modelo de lenguaje”. No bloquea ninguna funcionalidad.

¿Cómo manejan migraciones y versionado de esquema?

Migraciones Flyway-style en db/migrations/, numeradas V001..V040, idempotentes, con downgrade documentado solo para migraciones reversibles. El pipeline CI valida que cada migración nueva no rompa los tests de las anteriores. Seeds versionados aparte (000_ base, 001_..009_ demo).

¿Cómo se observa la operación? Logs, métricas, errores

Logs estructurados JSON con request_id propagado, métricas Prometheus expuestas en /metrics, errores con Sentry-compatible payload, DLQ (Dead Letter Queue) para jobs que fallan tres veces. El paquete demo incluye mailhog para inspeccionar notificaciones; en producción se reemplaza por SMTP real o transactional API.

¿Por qué PostgreSQL y no [otra base]?

PostgreSQL 16 da: RLS nativo, JSONB con índices GIN, arrays con índices, materialized views, particionado, extensiones (pg_stat_statements, pgcrypto), replicación lógica. Cubre los 6 requisitos críticos de FARO en un solo motor maduro. No descartamos columnar para analítica a futuro, pero no es bloqueante para MVP.

¿Cómo escalan multiempresa y multiindustria?

Multiempresa por company_id + RLS (mismo tenant share, schema compartido, aislamiento por política). Multiindustria por playbooks (catalogo-tensiones-mvp con industry_scope array), reglas YAML por industria y KPIs filtrables. La empresa demo usa industry_code = commerce_construction_supplies. Cruzar con roadmap-multiindustria.html.

¿Cómo se prueba la cadena completa en CI?

El paquete incluye qa/smoke-demo.spec.ts (Playwright) que: levanta docker-compose, corre seeds + pipeline, navega a la UI, valida que aparezca TNS-001 y Score 66, exporta screenshots. CI corre esto en cada PR con dataset frozen. Cruzar con qa-estrategia-mvp.html PENDIENTE.

¿Cómo se pasa de este demo a producción?

FARO-DEPLOY-001 cubre el paso a staging y producción: ambientes separados, variables y secrets, migraciones automatizadas, build/deploy reproducible, rollback, releases versionados, monitoreo post-release, backups pre-release, smoke tests post-deploy. Cruzar con deploy-ambientes-mvp.html PENDIENTE.

FAQ Inversor (12 preguntas)

¿Esto ya es vendible?

Como producto final, no. Como MVP técnico-comercial demostrable, sí. Permite mostrar la cadena completa, validar interés con pilotos estratégicos y cobrar honorarios de implementación + suscripción acordada caso por caso. FARO se encuentra en etapa de construcción, validación y pilotos estratégicos.

¿Cuál es el avance real?

La lógica central está bajada a datos, reglas, workflow, Score, reporte y validación. Falta endurecer producto (UX final, edge cases), integraciones reales (ERPs comunes en Argentina), operación productiva (SRE, SLA, on-call) y go-to-market estructurado. La demo ejecutable es la prueba de que la base está.

¿Por qué esto no es otro dashboard?

Porque no se limita a mostrar métricas. Detecta tensiones canónicas, prioriza, asigna acciones con responsable y vencimiento, exige evidencia documental, mide ejecución y recalcula Score. Un dashboard te dice qué pasó; FARO te dice qué tensés que hacer, quién lo hace, cómo se cierra y cuánto mejora el Score si se cierra bien.

¿Cuál es el moat?

Tres capas: (1) los catálogos canónicos (KPIs, tensiones, acciones, evidencias) son IP construida desde experiencia ejecutiva real, no copiable rápido; (2) el motor evaluador convierte reglas YAML en outputs trazables auditados; (3) el método de aplicación (consultoría + producto) es lo que define el resultado, no el SaaS solo.

¿Quién es el cliente?

Empresas en crecimiento (typically 50–500 empleados, multi-sucursal o multi-empresa) que ya tienen ERP y datos, pero les falta una capa de dirección que les diga dónde mirar y qué hacer. Argentina primero (caja real, contexto inflacionario, multi-empresa familiar común). Industrias piloto: comercio retail, construcción, servicios profesionales, distribución, salud privada.

¿Por qué ahora?

Cruce de tres ventanas: (1) empresarios entendieron que dashboards no alcanzan; (2) IA controlada permite explicar a costo bajo lo que antes requería consultor presencial; (3) infraestructura cloud + open source madurada hace que un equipo chico pueda construir lo que antes pedía equipo enterprise. La pieza ejecutable demuestra el cruce.

¿Qué equipo hace falta para crecer?

Para los próximos 12 meses: 1 tech lead + 2 fullstack senior + 1 data engineer + 1 product designer + 1 head of consultoría + 2 consultores asociados. Plus comercial y operaciones. Plan detallado en el pack ejecutivo confidencial.

¿Qué gastan en infraestructura?

El stack actual (PostgreSQL + Redis + Node + Next + Vercel/AWS) escala lineal a usuarios y empresas activas. MVP de pilotos cabe en USD ~300–500/mes por tenant moderado. Multitenancy con RLS mantiene el footprint bajo. La elasticidad cloud cubre picos de procesamiento semanal/mensual.

¿Cómo se diferencia de Power BI / Tableau / Looker?

Esos son visualizadores de métricas. FARO es una capa operativa que detecta tensiones, genera acciones, exige evidencia y reporta a dirección con foco. No competimos en visualización; complementamos (FARO puede consumir desde data warehouses ya armados). Cruzar con diagnostico-empresarial.html.

¿Y vs un ERP que ya tiene workflow?

El ERP gestiona operación transaccional. FARO mira por arriba con foco en dirección. Sus workflows son operativos (orden de compra, cobro); los de FARO son ejecutivos (revisión de política, escalamiento L3, decisión requerida del director). Coexisten: el ERP alimenta a FARO con datos.

¿Cuáles son los riesgos principales?

Riesgo de adopción (las empresas ya cargadas de software no quieren más herramientas), de ejecución (equipo chico, mucho frente abierto), de timing (mercado argentino volátil), de validación (pilotos pueden tomar 6 meses en mostrar resultados verificables). Mitigación: foco en pilotos con director comprometido, método + producto como paquete, sin venta “solo SaaS”.

¿Qué buscás del inversor / socio?

Capital para 12–18 meses de runway productivo + acceso a redes de empresas medianas argentinas / Latam + apoyo en go-to-market y gobierno corporativo. No buscamos validación; ya validamos el problema operando empresas. Buscamos acelerador del segmento correcto. Detalles en conversación directa con Tomás Pombo.

15 · Criterios de aceptación + riesgos + checklist pre-demo

Qué debe pasar para que la demo se considere aprobada

Tres bloques: criterios funcionales (el sistema corre como debe), criterios técnicos (los archivos están donde deben), riesgos con mitigación, checklist pre-demo y comando de validación.

Criterios de aceptación funcional

  • Docker levanta PostgreSQL, Redis y mailhog con healthchecks verdes en < 60 segundos.
  • Migraciones aplican limpio (V001..V040 sin errores).
  • Seeds cargan Empresa Demo Cuyo S.A., 3 sucursales, 7 usuarios, catálogos base.
  • CSVs cargan los 18 archivos con conteos esperados (260 productos, 4.820 ventas, 2.140 movimientos).
  • Pipeline corre los 14 pasos completos sin intervención manual.
  • KPIs calculan con confidence ≥ 80 en métricas críticas.
  • 30 tensiones MVP se evalúan; al menos 18 quedan activas; al menos 10 críticas o altas.
  • TNS-001 se detecta con priority_score ≥ 90 y severidad efectiva critical.
  • Acciones se crean / cargan con estados mixtos (new, in_progress, in_review, blocked, expired, escalated, closed).
  • Evidencias se cargan en mezcla intencional (submitted, approved, rejected, missing).
  • Workflow genera distribución esperada (3 expired, 3 blocked, 3 escalated).
  • Timeline tiene ≥ 80 eventos con tipos requeridos.
  • Notificaciones se generan con dedupe_key; visibles en mailhog (http://localhost:8025).
  • Score calcula 66 ± tolerancia (target 66, tolerance ±3 por componente).
  • Reporte semanal se genera con todas las secciones obligatorias.
  • IA / fallback explica Score con slots resueltos, audit_trail completo, sin invenciones.
  • demo-check pasa con PASS final.
  • Storyboards 10 min / 20 min / 45 min / WhatsApp documentados.

Criterios de aceptación técnica

  • docker-compose.yml existe y levanta con docker-compose up -d.
  • scripts/demo-up.sh, demo-reset.sh, demo-check.sh existen y son ejecutables.
  • Seeds SQL versionados en db/seeds/ de 000_ a 009_.
  • 18 CSVs presentes en data/csv/.
  • 10 expected JSONs presentes en data/expected/.
  • 5 files demo presentes en data/files/evidencia/.
  • Postman collection presente en postman/.
  • QA smoke (qa/smoke-demo.spec.ts) presente.
  • README demo presente en la raíz.
  • 4 storyboards + 2 FAQs presentes en storyboard/.
  • UUIDs determinísticos para empresa, sucursales y usuarios.
  • Sin datos reales: ningún nombre, razón social, email ni teléfono real en el paquete.

Riesgos y mitigaciones

  • Dataset demasiado chico. Mitigación: 6 meses, 4.820 ventas, 2.140 movimientos, 620 AR. Suficiente para reglas estadísticas y vista de tendencias.
  • Dataset demasiado complejo. Mitigación: MVP focalizado en 30 tensiones; 14 con DEMO; no se cargan los 1.500 cruces extendidos.
  • Demo hardcodeada. Mitigación: expected JSONs solo validan, no alimentan. CI corre el pipeline desde CSVs en cada PR.
  • No corre en otra PC. Mitigación: Docker + README + healthchecks explícitos + puertos no estándar para evitar conflictos.
  • Score no coincide. Mitigación: tolerancia por componente explícita en expected JSON; drivers esperados validados aparte.
  • Falla IA. Mitigación: fallback determinístico obligatorio; demo no depende de proveedor externo.
  • CSVs inconsistentes. Mitigación: demo-check valida shape y conteos antes del pipeline.
  • Demo lenta. Mitigación: seeds optimizados, índices creados pre-carga, ANALYZE automático.
  • CTO la ve como maqueta. Mitigación: mostrar run-pipeline.sh y demo-check en vivo; abrir Postgres con psql si pide.
  • Inversor se pierde en técnica. Mitigación: usar storyboard 10 min primero; profundizar solo si lo pide.

Checklist pre-demo (10 min antes)

  • Correr make demo-reset && make demo al menos 1 hora antes para garantizar estado limpio.
  • Verificar que make demo-check imprime PASS.
  • Abrir http://localhost:3000/faro/demo y validar que Score muestra 66.
  • Abrir http://localhost:8025 y validar que hay notificaciones generadas.
  • Logout y login como Director para asegurar permisos del rol del storyboard.
  • Cerrar pestañas innecesarias y silenciar notificaciones del sistema.
  • Tener a mano el storyboard correspondiente impreso o en segunda pantalla.
  • Tener URL del hub (index.html) abierta en pestaña alternativa para cross-refs.
  • Comprobar audio y compartición de pantalla si la demo es remota.
  • Tener listo el plan B: si Docker falla en vivo, mostrar capturas + recorrido del paquete en filesystem.

demo-check · salida esperada

▸ ./scripts/demo-check.sh · salida exitosa
FARO Demo Check

[DB]
[OK] migrations applied (V001..V040)
[OK] demo company exists (Empresa Demo Cuyo S.A.)
[OK] users and roles exist (7 usuarios)
[OK] RLS test passed (viewer no ve otra empresa)

[Data]
[OK] products loaded: 260
[OK] customers loaded: 180
[OK] sales loaded: 4.820
[OK] stock movements loaded: 2.140
[OK] AR records loaded: 620
[OK] purchases loaded: 410

[Pipeline]
[OK] KPIs calculated (confidence avg 88%)
[OK] TNS-001 detected (priority_score 92)
[OK] TNS-004 detected
[OK] TNS-006 detected
[OK] 30 MVP tensions evaluated
[OK] 18 tensions active
[OK] 10 tensions critical/high

[Workflow]
[OK] actions created: 42
[OK] actions expired: 5
[OK] actions blocked: 3
[OK] escalations open: 3
[OK] evidence submitted: 8
[OK] evidence approved: 5
[OK] evidence missing: 11

[Score]
[OK] score current: 66
[OK] score previous: 74
[OK] delta: -8
[OK] confidence: 82 (≥ 80)
[OK] recovery potential: +8

[Reports]
[OK] weekly report generated
[OK] report contains FARO Score
[OK] report contains TNS-001
[OK] report contains decisiones requeridas

[AI]
[OK] fallback explanation generated
[OK] no invalid source refs
[OK] audit_trail complete

Result: PASS
16 · Cross-references

Dónde se cruza esta demo con el resto del pack

La demo ejecutable no vive sola. Consume catálogos canónicos, valida contratos, alimenta motor y reporte, y deriva en deploy productivo.