Ingesta
Los 18 CSVs se cargan correctamente a la tabla raw_* con conteos verificables (260 productos, 4.820 ventas, 2.140 movimientos de stock).
No es una demo “linda”: es una demostración de que FARO Connect corre de punta a punta. docker-compose up → PostgreSQL + Redis + migraciones + seeds + 18 CSVs + pipeline + 30 tensiones + Score 66 + reporte semanal + IA controlada, todo validado contra expected JSONs.
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.
La demo no es una pasada rápida de pantallas. Cada capacidad se demuestra contra datos cargados, reglas evaluadas y outputs validados.
Los 18 CSVs se cargan correctamente a la tabla raw_* con conteos verificables (260 productos, 4.820 ventas, 2.140 movimientos de stock).
Los datos pasan de raw a staging y luego al modelo FARO canónico, con dedupe key y constraints únicos por empresa.
Se calculan indicadores ejecutivos (margen, descuento, DSO, cobertura stock) y se versionan por período en kpi_snapshots.
El motor evaluador evalúa las 30 tensiones MVP; 18 quedan activas; 10 críticas o altas visibles en la bandeja.
Se crean y se recomiendan acciones desde tensiones canónicas: 42 acciones, 6 críticas, 5 vencidas, 3 bloqueadas, 3 escaladas.
Las acciones cambian de estado según evidencias y vencimientos. new → in_progress → waiting_evidence → in_review → closed / expired / escalated.
Los cierres requieren respaldo documental. EVD-007 submitted, EVD-012 missing, EVD-006 rejected: la demo muestra los tres estados juntos.
Todo deja historia auditada en timeline_events con tipo, actor, payload y request_id. Más de 80 eventos en el período demo.
Se notifican eventos críticos con dedupe_key para evitar ruido: TNS-001 crítica, acción vencida, evidencia rechazada, escalamiento L3.
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).
Se genera el reporte semanal ejecutivo con Score, tensiones, acciones, evidencias, escalamientos, decisiones requeridas y foco próxima semana.
La IA explica sin inventar usando slots controlados con audit_trail (D5). Si el proveedor no responde, usa fallback determinístico.
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.
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.
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.
Cuatro servicios, healthchecks explícitos, volúmenes persistentes, puertos no conflictivos. Levanta limpio en cualquier máquina con Docker.
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.
Variables mínimas para correr la demo y los comandos que el operador ejecuta. Todo demás se infiere.
# --- 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
Aplica migraciones y carga seeds base + Empresa Demo. Equivale a pnpm db:migrate:demo && pnpm db:seed:base && pnpm db:seed:demo.
Levanta todo: docker-compose up -d → seeds → load-csv → pipeline → Score → reporte → demo-check. Termina con URL final.
Borra volumen Postgres, limpia Redis y reconstruye desde cero. Útil entre demos para garantizar estado limpio.
Corre qa/demo-check.ts comparando outputs reales (KPIs, tensiones, Score, reporte) contra data/expected/*.json. Devuelve PASS o FAIL.
Solo ejecuta el pipeline (sin levantar contenedores). Útil para re-correr con cambios en reglas o KPIs sin recargar CSVs.
Regenera el reporte semanal ejecutivo. Soporta flag --week=22 para apuntar a períodos específicos del dataset 6 meses.
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
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.
| Entidad | UUID | Uso |
|---|---|---|
| Empresa Demo Cuyo S.A. | 10000000-0000-0000-0000-000000000001 | company_id canónico del tenant demo |
| Sucursal Mendoza Centro | 11000000-0000-0000-0000-000000000001 | Casa central, mayor volumen |
| Sucursal Mendoza Norte | 11000000-0000-0000-0000-000000000002 | Depósito + sucursal comercial |
| Sucursal San Juan | 11000000-0000-0000-0000-000000000003 | Expansión reciente, ventas en crecimiento |
| Director | 12000000-0000-0000-0000-000000000001 | Ver Score, reporte, decisiones |
| Gerente General | 12000000-0000-0000-0000-000000000002 | Operar dashboard, aprobar acciones |
| Responsable Comercial | 12000000-0000-0000-0000-000000000003 | Ejecutar acciones comerciales |
| Responsable Finanzas | 12000000-0000-0000-0000-000000000004 | Gestionar cobranza |
| Responsable Stock | 12000000-0000-0000-0000-000000000005 | Stock crítico y reposición |
| Aprobador Dirección | 12000000-0000-0000-0000-000000000006 | Aprobar evidencia crítica |
Director general. Ve Score, reporte semanal, decisiones requeridas. Usuario del botón “ver mi semana FARO”.
Gerencia general. Opera dashboard ejecutivo, aprueba acciones y evidencia, escala lo que el director debe ver.
Política de descuentos, plan de márgenes, asignaciones por vendedor. Día a día en ACT-COM-*.
Cobranza, mora crítica, límite de crédito. Owner de ACT-FIN-* y evidencia financiera.
Cobertura, reposición y stock crítico en Mendoza Norte. Owner de ACT-STK-*.
Aprueba evidencia crítica antes de cierre. Sin este rol, ACT-COM-001 no cierra ni recupera Score.
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.
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.
Estructura tenant: empresa → sucursales → áreas funcionales. Base para RLS.
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
Catálogo de productos con cost_price, list_price, stock mín/máx y marca de criticidad para reglas de cobertura.
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
Cartera de clientes con segmento, límite de crédito, plazo de pago y nivel de riesgo. Base para TNS-005 / TNS-016.
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
Empleados con rol, área, sucursal y esquema de comisión. Base para TNS-003 (vendedor erosiona margen).
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
Proveedores con condición de pago, lead time y nivel de criticidad. Base para TNS-023 (proveedor crítico con demora).
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
Cabecera de ventas con cliente, vendedor, bruto, descuento, neto, costo y margen. Núcleo para TNS-001 / TNS-002 / TNS-015.
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
Líneas de venta detalladas. Necesario para abrir margen por familia (TNS-014).
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
Movimientos de stock: ventas, compras, ajustes, transferencias. Base para TNS-006 y rotación.
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
Snapshot diario de inventario con días de cobertura. Disparador de TNS-006 cuando cobertura cae bajo umbral.
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
Cuentas por cobrar con días vencidos y estado. Base para TNS-004 y TNS-005.
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
Cobranza realizada con método de pago y estado. Para calcular DSO y close rate por cliente.
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
Compras a proveedores con fecha de pedido, recepción y costo. Base para TNS-008 (reposición reactiva).
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
Líneas de compra detalladas con costo unitario. Base para variación de costo (TNS-022).
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
Acciones recomendadas canónicas (ACT-COM-001, ACT-FIN-001, etc.) con responsable, aprobador, prioridad y criterio de cierre.
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
Evidencias canónicas (EVD-007, EVD-012, etc.) con trust level y estado. Mezcla intencional de submitted / approved / rejected / missing.
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
Eventos de cambio de estado: action_assigned, action_expired, evidence_submitted, action_escalated. Alimenta timeline.
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}"Inputs precalculados para KPIs por período y dimensión. Permite validar reglas sin tener que correr todo el pipeline.
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
Snapshots semanales de Score con componentes y confianza. Permite reproducir el delta 74 → 66 y la trayectoria 6 meses.
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
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-001 | Crecimiento no rentable | Comercial | High | Ventas +18% + margen 28%→21% + descuento 6%→12% | DEMO |
TNS-002 | Descuento fuera de política | Comercial | High | Descuento promedio supera umbral autorizado en BR-MDZ-NORTE | DEMO |
TNS-003 | Vendedor erosiona margen | Comercial | High | EMP-001 vende alto volumen con margen 14% vs target 28% | DEMO |
TNS-004 | Venta sin conversión a caja | Finanzas | High | DSO 32 → 43 días + mora subiendo | DEMO |
TNS-005 | Mora crítica por cliente | Finanzas | High | CLI-004 con 47 días vencidos y monto 1.2M abierto | DEMO |
TNS-006 | Stock crítico alta rotación | Stock | High | PROD-001 (cemento) con cobertura 8 días vs mín 14 | DEMO |
TNS-007 | Stock inmovilizado | Stock | Medium | PROD-003 (porcelanato) sin venta 60 días, valor 2.2M | DEMO |
TNS-008 | Reposición reactiva | Compras | High | PUR-000122 emitida 5 días después del quiebre | — |
TNS-009 | Acciones vencidas | Dirección | Medium | 5 acciones con due_date superado (incluye ACT-FIN-001) | DEMO |
TNS-010 | Acciones sin evidencia | Dirección | High | 11 acciones avanzadas sin evidencia válida cargada | DEMO |
TNS-011 | Ventas concentradas en pocos clientes | Comercial | High | Top 5 clientes concentran 62% del facturado | — |
TNS-012 | Ticket promedio cae con ventas estables | Comercial | Medium | Ticket promedio -14% mientras volumen se sostiene | — |
TNS-013 | Caída de ventas en sucursal relevante | Comercial | High | BR-SJ con -22% vs trimestre anterior | — |
TNS-014 | Margen bajo por familia de producto | Comercial | High | Familia Revestimientos con margen 18% vs target 32% | — |
TNS-015 | Venta crece por descuento, no por demanda sana | Comercial | High | Crecimiento +18% explicado 70% por aumento de descuento | — |
TNS-016 | Cliente supera límite de crédito | Finanzas | Critical | CLI-003 con exposición 48M vs límite 45M | — |
TNS-017 | Cobranza concentrada en pocos responsables | Finanzas | Medium | EMP-002 gestiona 78% de la cobranza vencida | — |
TNS-018 | Facturación alta con cobranza parcial | Finanzas | High | Facturación mensual 84M cobrado solo 58M | — |
TNS-019 | Caja proyectada insuficiente | Finanzas | Critical | Caja proyectada D+30 -6.5M vs compromisos | — |
TNS-020 | Mora creciente sin gestión registrada | Finanzas | High | +18% en mora pero 0 acciones de cobranza con evidencia | — |
TNS-021 | Quiebre de stock con ventas perdidas | Stock | High | 3 quiebres PROD-001 con demanda no atendida estimada 1.8M | — |
TNS-022 | Compra con costo creciente y margen sin ajustar | Compras | High | Costo PROD-001 sube 3.2% sin ajuste en lista de precios | — |
TNS-023 | Proveedor crítico con demora recurrente | Compras | High | SUP-002 con 3 demoras >7 días en último trimestre | — |
TNS-024 | Stock alto con deuda a proveedores | Finanzas/Stock | High | Stock 42M + deuda proveedores 38M (ratio 1.10) | — |
TNS-025 | Reposición sin rotación suficiente | Compras | Medium | PUR-000122 repone PROD-003 que tiene 60 días sin venta | — |
TNS-026 | Dirección sin visibilidad semanal | Dirección | High | Reporte semanal no se genera 2 semanas seguidas (simulado) | DEMO |
TNS-027 | Fuente crítica atrasada | Datos | High | kpi_inputs sin update por 48hs (BR-SJ) | DEMO |
TNS-028 | Baja confianza de dato en KPI crítico | Datos | High | KPI-FIN-001 con confidence 65% por campos faltantes | DEMO |
TNS-029 | Responsable no asignado en acción crítica | Dirección | Critical | 1 acción crítica TNS-019 sin owner_email asignado | DEMO |
TNS-030 | Tensión crítica reincidente | Dirección | Critical | TNS-001 se repite 3 períodos consecutivos → escalada L3 | DEMO |
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).
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.
| Acción | Tensión | Responsable | Estado | Vencimiento | Evidencia | Score recovery |
|---|---|---|---|---|---|---|
ACT-COM-001 | TNS-001 | Comercial (Diego Funes) | in_review | 2026-06-06 | EVD-007 submitted · EVD-012 missing | +8 |
ACT-COM-002 | TNS-002 | Comercial (Diego Funes) | in_progress | 2026-06-10 | EVD-011 approved | +4 |
ACT-FIN-001 | TNS-004 | Finanzas (Soledad Ortiz) | expired | 2026-05-29 | EVD-006 rejected | +6 |
ACT-STK-001 | TNS-006 | Stock (Pablo Sosa) | blocked | 2026-06-03 | EVD-008 missing | +5 |
ACT-COM-003 | TNS-002 | Comercial (Diego Funes) | new | 2026-06-12 | EVD-007 referenced | +3 |
ACT-COM-004 | TNS-003 | Comercial / RRHH | in_analysis | 2026-06-15 | missing | +3 |
ACT-FIN-002 | TNS-005 | Finanzas (Soledad Ortiz) | waiting_evidence | 2026-06-08 | EVD-011 pendiente segunda firma | +4 |
ACT-DIR-001 | TNS-030 | Gerencia → Dirección | escalated | 2026-06-02 | EVD-012 missing (L3) | +5 |
ACT-DQ-001 | TNS-027 | Data owner | closed | 2026-05-28 | EVD-004 approved | +2 |
ACT-OPS-001 | TNS-009 | Gerencia General | in_progress | 2026-06-09 | EVD-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.
| Evidencia | Acción | Estado | Trust | Lectura ejecutiva |
|---|---|---|---|---|
EVD-007 | ACT-COM-001 | submitted | critical | Política de descuentos cargada, falta validación de Dirección |
EVD-012 | ACT-COM-001 | missing | critical | Aprobación de Dirección faltante → bloquea cierre y recovery |
EVD-006 | ACT-FIN-001 | rejected | high | Comprobante bancario insuficiente → cobranza no acreditada |
EVD-008 | ACT-STK-001 | missing | high | Falta orden de compra emitida con confirmación del proveedor |
EVD-003 | ACT-DIR-001 | submitted | critical | Caso escalado L3, aprobación de Director pendiente |
EVD-011 | ACT-COM-002 | approved | medium | Comunicación interna validada por gerencia |
EVD-004 | ACT-DQ-001 | approved | high | Reproceso de datos confirmado, KPI vuelve a verde |
EVD-010 | ACT-OPS-001 | submitted | medium | Reporte 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.
{
"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
}
]
}
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).
{
"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"
]
}
{
"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.
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.
ACT-FIN-001 (cobranza prioritaria).EVD-012 (Dirección), EVD-008 (orden de compra).ACT-DIR-001 por reincidencia TNS-001.{
"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"
}
{
"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.
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.
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();
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();
#!/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."
Cada storyboard tiene minuto-a-minuto explicitado. La frase clave de cada bloque es la que el operador debe poder decir mirando la pantalla.
Audiencia: empresario / director ocupado. Objetivo: mostrar valor rápido sin entrar en ingeniería profunda. Lectura ejecutiva, lenguaje claro, una frase ancla por bloque.
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.”Audiencia: socio comercial, gerente general de empresa cliente, posible piloto. Profundiza en bandeja, workflow, evidencia y reporte. Bloques explícitos para no improvisar.
make demo-check en pantalla, mostrar PASS. “Esto todavía no es producto terminado. Pero ya demuestra la cadena técnica y ejecutiva principal.”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.
company_id + RLS.docker-compose up -d, healthchecks, conexión a Postgres (54329), Redis (63799), mailhog (8025).data/csv/, mostrar conteos y formato. Abrir contrato-datos-mvp.html para ver el contrato canónico que cumplen los CSVs.scripts/run-pipeline.sh en vivo. Mostrar 14 pasos, logs, conteos esperados vs reales. Cruzar con pipeline-interactivo.html.audit_trail del slot resuelto, validar guardrails.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.”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.
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).
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é.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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á.
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.
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.
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.
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.
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.
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.
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.
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.
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”.
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.
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.
confidence ≥ 80 en métricas críticas.dedupe_key; visibles en mailhog (http://localhost:8025).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.db/seeds/ de 000_ a 009_.data/csv/.data/expected/.data/files/evidencia/.postman/.qa/smoke-demo.spec.ts) presente.storyboard/.demo-check valida shape y conteos antes del pipeline.ANALYZE automático.run-pipeline.sh y demo-check en vivo; abrir Postgres con psql si pide.make demo-reset && make demo al menos 1 hora antes para garantizar estado limpio.make demo-check imprime PASS.http://localhost:3000/faro/demo y validar que Score muestra 66.http://localhost:8025 y validar que hay notificaciones generadas.index.html) abierta en pestaña alternativa para cross-refs.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
La demo ejecutable no vive sola. Consume catálogos canónicos, valida contratos, alimenta motor y reporte, y deriva en deploy productivo.
30 tensiones canónicas TNS-001..TNS-030. Los nombres de tensiones del demo se reconcilian con este catálogo (CAT-001 manda).
Contrato canónico de los CSVs de ingesta. Los 18 CSVs del demo siguen este contrato (columnas, tipos, claves).
Pipeline interactivo 25 etapas. El demo corre las etapas operativas (ingesta → reporte) sobre los datos sintéticos.
Fórmula del FARO Score con 5 componentes. El demo produce el Score 66 con drivers explícitos y recovery +8.
Máquina de estados y escalamiento L1/L2/L3. El demo muestra 3 escalamientos abiertos con su trazabilidad.
Backlog priorizado del MVP. La demo es el primer entregable visible; el resto del backlog vive ahí.
Plantillas oficiales (Excel + CSV) compatibles con el contrato de datos. Útiles para reproducir el dataset en otro entorno.
Ambientes, deploy, versionado y release MVP. El siguiente entregable después del demo local. En construcción.
Estrategia de testing, calidad y CI/CD del MVP. El demo incluye smoke pero la estrategia completa vive ahí. En construcción.
Pasá al hub para ver el resto del pack o reproducí el paquete con docker-compose up. FARO deja de ser concepto: pasa a ser sistema que corre, calcula, audita y reporta.