ANEXO 37

Recalibración FARO

Este anexo corresponde a la Fase 10 — Aprendizaje y mejora continua, etapa “Recalibración”. Es la capa donde FARO Connect toma los aprendizajes reales del sistema y los convierte en ajustes controlados sobre reglas, umbrales, pesos, recomendaciones, simulaciones, alertas, FARO Score, workflows y criterios de confianza.

El Anexo 36 responde:

¿Qué aprendió FARO?

El Anexo 37 responde:

¿Qué debe cambiar FARO a partir de ese aprendizaje?

Y acá hay que ser muy prudente: recalibrar no es tocar botones porque sí. Es ajustar el sistema con evidencia, trazabilidad y gobierno. Si no, FARO pasa de “inteligente” a “caprichoso con base de datos”.

1. Objetivo del anexo

El objetivo del Anexo 37 — Recalibración FARO es definir cómo FARO modifica sus parámetros y reglas de forma controlada después de medir resultados reales.

Debe responder:

Qué se puede recalibrar.
Cuándo se recalibra.
Quién aprueba la recalibración.
Qué evidencia la justifica.
Qué versión queda activa.
Qué impacto tuvo el cambio.
Cómo se revierte si sale mal.
Cómo se audita.

Ejemplo:

Aprendizaje:
La auditoría de descuentos mejora margen, pero no caja si no se combina con cobranza.

Recalibración:
Cuando FARO detecte crecimiento no rentable, ya no debe recomendar solo auditoría comercial. Debe recomendar paquete combinado:
1. auditar descuentos,
2. priorizar cobranza,
3. revisar comisión,
4. medir impacto a 30 días.

2. Tesis del Anexo 37

La tesis es:

FARO Connect debe mejorar sus reglas, pesos, umbrales y recomendaciones con base en resultados reales, pero nunca de forma descontrolada.

Un sistema débil hace esto:

Detecta.
Recomienda.
Mide.
Pero no cambia.

Un sistema peligroso hace esto:

Detecta.
Mide.
Cambia reglas automáticamente sin control.

FARO debe hacer esto:

Detecta.
Mide.
Aprende.
Propone recalibración.
Valida impacto.
Versiona cambio.
Aprueba si corresponde.
Aplica.
Monitorea.
Permite rollback.

Esa es la diferencia entre una IA improvisada y un sistema serio de dirección.

3. Qué es recalibración FARO

La recalibración FARO es el proceso mediante el cual el sistema ajusta sus criterios internos a partir de evidencia real.

Puede ajustar:

umbrales,
pesos,
reglas,
prioridades,
alertas,
tensiones,
recomendaciones,
acciones sugeridas,
simulaciones,
confianza,
FARO Score,
workflow,
SLA,
requisitos de evidencia,
reportes,
modelos predictivos,
pesos por industria,
pesos por empresa.

Ejemplo JSON:

{
  "recalibration_id": "RECAL_001",
  "target_type": "recommendation_rule",
  "target_code": "REC_COMMERCIAL_DISCOUNT_AUDIT",
  "reason": "La acción fue efectiva para margen pero insuficiente para caja.",
  "current_logic": "Recomendar auditoría de descuentos.",
  "proposed_logic": "Recomendar auditoría de descuentos + plan de cobranza cuando cobranza supere umbral.",
  "evidence": {
    "runs": 18,
    "effectiveness_margin": 0.78,
    "effectiveness_cash": 0.34
  },
  "requires_approval": true,
  "approval_role": "FARO Admin / Dirección"
}

4. Diferencia entre aprendizaje, recalibración y optimización

Secuencia:

Resultado real
→ Aprendizaje
→ Recalibración
→ Nueva decisión futura
→ Medición
→ Nueva mejora

5. Qué puede recalibrar FARO

5.1 Umbrales

Ejemplos:

descuento alto > 8%
stock crítico < 7 días de cobertura
mora crítica > 45 días
calidad de datos mínima > 0.80
acción vencida P1 > 24 horas

5.2 Pesos

Ejemplos:

peso de caja en FARO Score,
peso de margen en construcción,
peso de SLA en logística,
peso de RevPAR en hotelería,
peso de calidad de datos en diagnósticos sensibles.

5.3 Reglas

Ejemplo:

Antes:
Si margen baja, disparar alerta comercial.

Después:
Si margen baja + descuento sube + cobranza empeora, disparar tensión de crecimiento no rentable.

5.4 Recomendaciones

Ejemplo:

Antes:
Auditar descuentos.

Después:
Auditar descuentos + revisar cobranza + simular comisión.

5.5 Simulaciones

Ejemplo:

Ajustar factor de liquidez en canjes.
Ajustar elasticidad de precio.
Ajustar caída esperada de ventas.
Ajustar plazo real de recupero.

5.6 Workflow

Ejemplo:

Reducir SLA de aceptación en acciones P1.
Escalar antes aprobaciones críticas.
Agregar backup si responsable no acepta.

5.7 Evidencia

Ejemplo:

Exigir margen por operación en auditoría comercial.
Exigir valuación legal en canjes.
Exigir KPI recalculado en cierre de calidad de datos.

6. Qué NO debe recalibrarse automáticamente

Algunas cosas no deberían modificarse solas.

Regla:

FARO puede sugerir recalibrar. La Dirección o el administrador FARO aprueban cambios sensibles.

7. Niveles de recalibración

Para MVP:

Nivel 1 y 2.

Para versión Enterprise:

Nivel 2 y 3.

Para Neural avanzado:

Nivel 3 y 4, con auditoría fuerte.

Nivel 5 recién cuando el sistema tenga historial serio. La soberbia tecnológica suele salir cara.

8. Criterios para recalibrar

FARO no debe recalibrar por un solo caso aislado, salvo eventos críticos.

Debe evaluar:

cantidad de casos,
consistencia del patrón,
impacto económico,
impacto en Score,
confianza del aprendizaje,
calidad de datos,
riesgo de cambiar,
reversibilidad del cambio,
sensibilidad de la decisión.

Fórmula:

Fuerza de recalibración =
evidencia histórica × 25%
+ impacto económico × 20%
+ recurrencia × 20%
+ confianza del aprendizaje × 15%
+ bajo riesgo del cambio × 10%
+ facilidad de reversión × 10%

Código:

def fuerza_recalibracion(
    evidencia_historica,
    impacto_economico,
    recurrencia,
    confianza_aprendizaje,
    bajo_riesgo,
    facilidad_reversion
):
    return round(
        evidencia_historica * 0.25 +
        impacto_economico * 0.20 +
        recurrencia * 0.20 +
        confianza_aprendizaje * 0.15 +
        bajo_riesgo * 0.10 +
        facilidad_reversion * 0.10,
        2
    )

Lectura:

9. Recalibración de umbrales

Los umbrales definen cuándo se activa una alerta, tensión o acción.

Ejemplo:

Umbral actual:
descuento alto > 8%

Aprendizaje:
en esta industria, descuentos de 8% son normales en ciertos productos, pero peligrosos en otros.

Recalibración:
descuento alto por familia:
cemento > 4%
grifería > 12%
sanitarios > 10%
hierro > 5%

Código:

def recalibrar_umbral(actual_threshold, observed_false_positive_rate, observed_false_negative_rate):
    nuevo = actual_threshold

    if observed_false_positive_rate > 0.40:
        nuevo += 0.01

    if observed_false_negative_rate > 0.25:
        nuevo -= 0.01

    return round(max(0, nuevo), 4)

Regla:

Los umbrales deberían ser por industria, familia, empresa y contexto. No todo negocio soporta el mismo número.

10. Recalibración de alertas

FARO debe ajustar alertas ruidosas o débiles.

Caso 1 — Alerta ruidosa

Alerta:
descuento levemente alto.

Resultado:
100 alertas, solo 8 acciones útiles.

Recalibración:
subir umbral o convertir en observación.

Caso 2 — Alerta insuficiente

Alerta:
stock crítico.

Resultado:
se detectó tarde.

Recalibración:
anticipar alerta usando días de cobertura + plazo proveedor.

Código:

def recalibrar_alerta(alert_utility, false_positive_rate, false_negative_rate):
    if false_positive_rate > 0.40 and alert_utility < 0.30:
        return "reduce_sensitivity"

    if false_negative_rate > 0.25:
        return "increase_sensitivity"

    if alert_utility > 0.70:
        return "keep_or_raise_priority"

    return "monitor"

11. Recalibración de tensiones

Las tensiones deben recalibrarse cuando el patrón real muestra nuevas relaciones.

Ejemplo:

Tensión original:
ventas suben + margen baja = crecimiento no rentable.

Aprendizaje:
en esta empresa, el problema aparece realmente cuando además sube cobranza y comisión.

Recalibración:
activar tensión fuerte solo si:
ventas suben,
margen baja,
descuento sube,
cobranza empeora,
comisión sube.

Código:

def recalibrar_tension_crecimiento_no_rentable(ctx):
    condiciones = {
        "ventas_suben": ctx["sales_var"] > 0.10,
        "margen_baja": ctx["margin_var"] < -0.03,
        "descuento_sube": ctx["discount_var"] > 0.02,
        "cobranza_empeora": ctx["collection_days_var"] > 5,
        "comision_sube": ctx["commission_var"] > 0.05
    }

    score_condiciones = sum(condiciones.values())

    if score_condiciones >= 4:
        return "tension_fuerte"

    if score_condiciones == 3:
        return "tension_media"

    return "observacion"

12. Recalibración de diagnósticos

FARO debe ajustar diagnósticos que se confirman o se equivocan.

Ejemplo:

Diagnóstico:
margen deteriorado por descuentos.

Resultado:
la causa real fue aumento de costo proveedor.

Recalibración:
antes de atribuir causa a descuentos, cruzar variación de costo.

Código:

def recalibrar_diagnostico_margen(ctx):
    causas = []

    if ctx["discount_var"] > 0.02:
        causas.append("descuentos")

    if ctx["cost_var"] > 0.03:
        causas.append("costos")

    if ctx["mix_margin_var"] < -0.03:
        causas.append("mix_productos")

    return {
        "diagnosis": "margen_deteriorado",
        "probable_causes": causas,
        "requires_multicausal_reading": len(causas) > 1
    }

Regla:

Un diagnóstico que siempre culpa a una sola causa es cómodo, pero normalmente falso.

13. Recalibración de prioridades

FARO debe ajustar si priorizó mal.

Ejemplo:

FARO priorizó stock inmovilizado.
Pero la caja cayó bajo mínimo.
Aprendizaje:
cuando caja está bajo mínimo, prioridad financiera debe dominar.

Código:

def recalibrar_prioridad(evento, contexto):
    prioridad = evento["priority_score"]

    if contexto.get("cash_below_minimum"):
        if evento["area"] == "finance":
            prioridad += 20
        elif evento["economic_impact"] < 50:
            prioridad -= 10

    return max(0, min(100, prioridad))

14. Recalibración de recomendaciones

Las recomendaciones deben ajustarse según efectividad.

Ejemplo:

Recomendación actual:
auditar descuentos.

Aprendizaje:
efectiva para margen, insuficiente para caja.

Recalibración:
si cobranza está deteriorada, recomendar paquete combinado.

Código:

def recalibrar_recomendacion_crecimiento(ctx):
    recomendaciones = []

    if ctx["discount_rate"] > 0.08:
        recomendaciones.append("auditar_descuentos")

    if ctx["collection_days"] > ctx["collection_target"]:
        recomendaciones.append("plan_cobranza")

    if ctx["commission_margin_misaligned"]:
        recomendaciones.append("simular_comision_por_margen_y_cobro")

    if len(recomendaciones) >= 2:
        return {
            "recommendation_type": "paquete_integrado",
            "recommendations": recomendaciones
        }

    return {
        "recommendation_type": "accion_simple",
        "recommendations": recomendaciones
    }

15. Recalibración de acciones

FARO debe ajustar su biblioteca de acciones según resultado.

Ejemplo:

Acción:
Auditar descuentos.

Problema:
se cierra el informe, pero no cambia política.

Recalibración:
agregar acción obligatoria posterior:
definir política de autorización de descuentos.

Código:

def recalibrar_accion_por_efectividad(action_code, effectiveness_score):
    if effectiveness_score >= 0.80:
        return "increase_priority_when_applicable"

    if effectiveness_score >= 0.50:
        return "combine_with_supporting_actions"

    return "lower_priority_or_require_validation"

16. Recalibración de Action Guides

Los Action Guides deben mejorar cuando la ejecución muestra faltantes.

Ejemplo:

Guía:
Auditoría de descuentos.

Evidencia rechazada frecuentemente:
no incluye margen por operación.

Recalibración:
agregar paso obligatorio:
calcular margen por operación y adjuntar base.

Código:

def recalibrar_action_guide(guide, rejection_reasons):
    steps_to_add = []

    if "missing_margin_by_operation" in rejection_reasons:
        steps_to_add.append("calcular_margen_por_operacion")

    if "missing_customer_segmentation" in rejection_reasons:
        steps_to_add.append("segmentar_por_cliente")

    guide["steps"] += steps_to_add

    return guide

17. Recalibración de simulaciones

Las simulaciones deben ajustarse contra resultados reales.

Ejemplo descuento

Simulación:
ventas caerían 5%.

Resultado real:
ventas cayeron 12%.

Recalibración:
aumentar elasticidad estimada para ese segmento.

Ejemplo canje

Simulación:
plazo de realización 180 días.

Resultado:
270 días.

Recalibración:
aumentar plazo financiero y reducir factor de liquidez.

Código:

def recalibrar_supuestos_simulacion(simulated, actual, current_assumption):
    error_rate = (actual - simulated) / simulated if simulated else 0

    new_assumption = current_assumption * (1 + error_rate * 0.5)

    return round(new_assumption, 4)

Versión prudente:

No ajustar 100% al último error.
Ajustar parcialmente y seguir midiendo.

18. Recalibración de FARO Score

El Score debe recalibrarse si los pesos no reflejan impacto real.

Ejemplo:

FARO Score penaliza stock crítico -3.
Pero cada quiebre genera pérdida comercial fuerte.

Recalibración:
aumentar peso/penalización de stock crítico en productos tractores.

Código:

def recalibrar_peso_score(current_weight, observed_impact, expected_impact):
    if expected_impact == 0:
        return current_weight

    ratio = observed_impact / expected_impact

    if ratio > 1.25:
        return round(current_weight * 1.10, 4)

    if ratio < 0.75:
        return round(current_weight * 0.90, 4)

    return current_weight

Regla:

Cambios de pesos del Score deben versionarse y aprobarse. El Score no puede cambiar de lógica sin dejar rastro.

19. Recalibración de confianza

FARO debe ajustar confianza según aciertos históricos.

Ejemplo:

Diagnóstico margen deteriorado por descuentos:
80% confirmado.

Confianza futura:
sube.

Diagnóstico cliente riesgoso:
40% confirmado.

Confianza futura:
baja o requiere más datos.

Código:

def recalibrar_confianza(confianza_actual, tasa_acierto):
    if tasa_acierto >= 0.80:
        return min(1, confianza_actual + 0.05)

    if tasa_acierto <= 0.50:
        return max(0, confianza_actual - 0.10)

    return confianza_actual

20. Recalibración de calidad de datos

FARO debe subir exigencias cuando detecta que datos débiles provocan errores.

Ejemplo:

Problema:
diagnósticos de margen fallan cuando costos tienen completitud menor a 85%.

Recalibración:
bloquear diagnóstico fuerte de margen si completitud de costos < 85%.

Código:

def recalibrar_umbral_calidad_datos(metric, false_diagnosis_rate):
    base = {
        "cost_completeness": 0.80,
        "stock_reliability": 0.80,
        "customer_uniqueness": 0.85
    }

    threshold = base.get(metric, 0.80)

    if false_diagnosis_rate > 0.25:
        threshold += 0.05

    return min(0.95, threshold)

21. Recalibración de workflow y SLA

FARO debe ajustar tiempos si el workflow se traba.

Ejemplo:

Acciones P1:
se aceptan tarde.

Recalibración:
reducir tiempo de aceptación y escalar antes.

Código:

def recalibrar_sla(priority, current_sla, overdue_rate):
    new_sla = current_sla.copy()

    if overdue_rate > 0.40 and priority in ["P1", "P2"]:
        new_sla["accept_hours"] = max(1, int(current_sla["accept_hours"] * 0.75))
        new_sla["first_progress_hours"] = max(2, int(current_sla["first_progress_hours"] * 0.80))

    return new_sla

Pero cuidado:

Si el problema es falta de capacidad, acortar SLA solo fabrica más vencimientos. FARO debe distinguir demora por disciplina vs demora por sobrecarga.

22. Recalibración de escalamiento

Ejemplo:

Problema:
las acciones P2 vencidas recién se escalan a las 72 hs, pero generan daño antes.

Recalibración:
escalar P2 críticas a las 24 hs.

Código:

def recalibrar_escalamiento(priority, impact_level):
    if priority == "P2" and impact_level == "high":
        return {
            "first_escalation_after_hours": 24,
            "second_escalation_after_hours": 48
        }

    if priority == "P1":
        return {
            "first_escalation_after_hours": 0,
            "second_escalation_after_hours": 24
        }

    return {
        "first_escalation_after_hours": 72
    }

23. Recalibración de evidencia

FARO debe cambiar requisitos si detecta cierres débiles.

Ejemplo:

Acción:
plan de cobranza.

Problema:
se carga listado, pero no resultado de gestión.

Recalibración:
exigir evidencia de contacto, promesa de pago y cobro efectivo.

Código:

def recalibrar_evidencia(action_code, ineffective_closures_rate):
    requisitos_extra = []

    if action_code == "ACT_FINANCE_COLLECTION_PRIORITY" and ineffective_closures_rate > 0.30:
        requisitos_extra += [
            "resultado_contacto_cliente",
            "promesa_pago",
            "cobro_real_o_motivo_no_cobro"
        ]

    return requisitos_extra

24. Recalibración de reportes ejecutivos

FARO debe ajustar reportes según uso y decisiones.

Ejemplo:

Reporte semanal:
Dirección nunca abre anexo de calidad de datos.
Pero toma decisiones afectadas por baja confianza.

Recalibración:
subir advertencia de calidad de datos a portada cuando afecte decisiones sensibles.

Código:

def recalibrar_reporte(usage_stats, decision_risk):
    cambios = []

    if decision_risk.get("low_data_quality_affects_decision"):
        cambios.append("mostrar_calidad_datos_en_portada")

    if usage_stats.get("section_open_rate", {}).get("actions", 0) < 0.20:
        cambios.append("resumir_acciones_en_top_5_prioridades")

    return cambios

25. Recalibración por industria

Cada industria debe tener pesos y umbrales propios.

Construcción / insumos

Recalibraciones típicas:

mayor peso a caja/cobranza,
mayor peso a stock crítico,
descuentos por familia de producto,
canjes con liquidez conservadora,
referidos con límite sobre margen,
comisiones cruzadas con margen y cobro.

Retail

mayor peso a rotación,
merma,
promoción incremental,
stock lento,
ticket promedio,
quiebre producto estrella.

Logística

mayor peso a SLA,
costo por kilómetro,
combustible,
mantenimiento preventivo,
utilización de flota.

Hotelería

mayor peso a RevPAR,
ADR,
ocupación,
canales,
reclamos,
mantenimiento.

Salud

mayor peso a ocupación,
tiempos de espera,
costo por prestación,
insumos críticos,
uso de profesionales.

26. Recalibración por empresa

FARO debe ajustar sin perder estándares.

Ejemplo:

Empresa A:
usa stock como cobertura inflacionaria.

Recalibración:
no penalizar stock alto si está justificado por estrategia aprobada, pero sí medir rotación, caja atrapada y riesgo de obsolescencia.

Ejemplo 2:

Empresa B:
vende mucho a cuenta corriente.

Recalibración:
subir peso de cobranza y mora en Score financiero.

Código:

def recalibrar_por_empresa(company_profile, base_weights):
    weights = base_weights.copy()

    if company_profile.get("high_credit_sales"):
        weights["caja_finanzas"] += 0.05
        weights["clientes_mercado"] += 0.03
        weights["resultado_economico"] -= 0.03
        weights["personas_incentivos"] -= 0.05

    if company_profile.get("inflation_stock_strategy"):
        weights["operacion_stock"] += 0.03
        weights["caja_finanzas"] += 0.02

    return weights

27. Recalibración por madurez

No todas las empresas pueden recibir el mismo nivel de exigencia.

Ejemplo:

Una empresa sin datos confiables no debe recibir 80 tensiones sofisticadas.
Primero hay que recalibrar el sistema a modo diagnóstico básico.

28. Gobierno de recalibración

Toda recalibración debe tener gobierno.

Debe incluir:

solicitante,
motivo,
evidencia,
impacto esperado,
riesgo,
aprobador,
versión anterior,
versión nueva,
fecha de aplicación,
período de prueba,
rollback posible.

Estados:

proposed
under_review
approved
rejected
applied
monitoring
rolled_back
closed

29. Flujo de recalibración

Learning event
→ recalibration candidate
→ impact analysis
→ approval required?
→ approve / reject
→ version new rule
→ apply in sandbox / pilot
→ monitor result
→ promote to production
→ audit

Código conceptual:

def flujo_recalibracion(learning_event):
    candidate = {
        "source_learning_event": learning_event["learning_event_id"],
        "target_type": learning_event["recommended_adjustment"]["target_type"],
        "proposed_change": learning_event["recommended_adjustment"],
        "status": "proposed"
    }

    if learning_event.get("sensitive", False):
        candidate["requires_approval"] = True
        candidate["status"] = "under_review"
    else:
        candidate["requires_approval"] = False

    return candidate

30. Sandbox de recalibración

Antes de aplicar un cambio fuerte, FARO debe probarlo.

Ejemplo:

Nueva regla:
activar tensión crecimiento no rentable solo con 4 de 5 condiciones.

Sandbox:
correr nueva regla sobre los últimos 6 meses y comparar:
- alertas generadas,
- falsos positivos,
- falsos negativos,
- acciones útiles,
- impacto en Score.

Código:

def probar_regla_en_historico(regla, historico_eventos):
    resultados = []

    for evento in historico_eventos:
        resultado = regla(evento)
        resultados.append(resultado)

    return {
        "total_tested": len(historico_eventos),
        "triggered": sum(1 for r in resultados if r),
        "results": resultados
    }

Regla:

Primero backtesting. Después producción. No al revés.

31. Backtesting de reglas

El backtesting compara la regla nueva contra historial.

Debe medir:

cuántos casos detecta,
cuántos casos deja pasar,
cuántos falsos positivos reduce,
cuántos falsos negativos aparecen,
cómo habría cambiado el Score,
qué acciones habría creado.

Código:

def comparar_reglas(regla_actual, regla_nueva, historico):
    actual_hits = sum(1 for e in historico if regla_actual(e))
    nueva_hits = sum(1 for e in historico if regla_nueva(e))

    return {
        "actual_triggers": actual_hits,
        "new_triggers": nueva_hits,
        "delta_triggers": nueva_hits - actual_hits
    }

32. Rollback de recalibración

Toda recalibración debe poder revertirse.

Ejemplo:

Se subió sensibilidad de alerta de stock.
Resultado:
demasiadas alertas falsas.

Rollback:
volver a versión anterior de la regla.

Código:

def rollback_recalibracion(current_version, previous_version):
    return {
        "from_version": current_version,
        "to_version": previous_version,
        "status": "rolled_back",
        "rolled_back_at": "now()"
    }

Regla:

Si no podés volver atrás, no estás recalibrando; estás apostando.

33. Versionado de reglas

Cada cambio debe crear una versión nueva.

Ejemplo:

{
  "rule_code": "RULE_GROWTH_NOT_PROFITABLE",
  "version": "1.2",
  "previous_version": "1.1",
  "change_reason": "Reducir falsos positivos en campañas aprobadas.",
  "approved_by": "FARO Admin",
  "active": true
}

Convención:

1.0 regla inicial
1.1 ajuste menor
2.0 cambio fuerte de lógica

34. Auditoría de recalibración

Debe responder:

qué cambió,
por qué cambió,
quién lo aprobó,
qué evidencia lo justificó,
qué versión reemplazó,
cuándo entró en vigencia,
qué impacto tuvo,
si se revirtió.

Ejemplo:

{
  "audit_event": "recalibration_applied",
  "target": "discount_alert_threshold",
  "old_value": 0.08,
  "new_value": 0.10,
  "reason": "False positive rate > 40%",
  "approved_by": "FARO Admin",
  "effective_date": "2026-06-01"
}

35. Recalibración automática controlada

Solo debería permitirse para ajustes menores.

Ejemplos aceptables:

bajar prioridad de alerta ruidosa menor,
ajustar ranking de recomendaciones no sensibles,
sugerir mejores evidencias,
ordenar reportes según uso,
subir confianza de acción efectiva recurrente.

No aceptable automáticamente:

cambiar comisión,
bloquear cliente,
aprobar canje,
cambiar Score central,
modificar política de crédito,
subir precios,
recomendar despidos,
alterar reglas legales.

36. Tabla SQL de candidatos de recalibración

CREATE TABLE recalibration_candidates (
    recalibration_id TEXT PRIMARY KEY,
    company_id TEXT,
    industry_id TEXT,
    source_learning_event_id TEXT,
    target_type TEXT NOT NULL,
    target_code TEXT NOT NULL,
    current_config JSONB,
    proposed_config JSONB,
    reason TEXT,
    evidence_summary JSONB,
    recalibration_strength NUMERIC,
    risk_level TEXT,
    requires_approval BOOLEAN DEFAULT true,
    status TEXT DEFAULT 'proposed',
    created_at TIMESTAMP DEFAULT now(),
    updated_at TIMESTAMP DEFAULT now()
);

37. Tabla SQL de aprobaciones de recalibración

CREATE TABLE recalibration_approvals (
    approval_id TEXT PRIMARY KEY,
    recalibration_id TEXT NOT NULL,
    approver_user_id TEXT,
    approver_role TEXT,
    approval_status TEXT NOT NULL,
    approval_comment TEXT,
    approved_at TIMESTAMP
);

Valores:

approved
rejected
needs_more_data
pilot_required
deferred

38. Tabla SQL de versiones de configuración

CREATE TABLE configuration_versions (
    config_version_id TEXT PRIMARY KEY,
    target_type TEXT NOT NULL,
    target_code TEXT NOT NULL,
    version TEXT NOT NULL,
    previous_version TEXT,
    config_payload JSONB NOT NULL,
    change_reason TEXT,
    approved_by TEXT,
    active BOOLEAN DEFAULT false,
    effective_from TIMESTAMP,
    effective_to TIMESTAMP,
    created_at TIMESTAMP DEFAULT now()
);

39. Tabla SQL de backtesting

CREATE TABLE recalibration_backtests (
    backtest_id TEXT PRIMARY KEY,
    recalibration_id TEXT NOT NULL,
    company_id TEXT,
    test_period_start DATE,
    test_period_end DATE,
    old_rule_result JSONB,
    new_rule_result JSONB,
    delta_summary JSONB,
    false_positive_delta NUMERIC,
    false_negative_delta NUMERIC,
    score_impact_simulated NUMERIC,
    recommendation TEXT,
    created_at TIMESTAMP DEFAULT now()
);

40. Tabla SQL de cambios aplicados

CREATE TABLE recalibration_events (
    recalibration_event_id TEXT PRIMARY KEY,
    recalibration_id TEXT NOT NULL,
    company_id TEXT,
    target_type TEXT NOT NULL,
    target_code TEXT NOT NULL,
    old_version TEXT,
    new_version TEXT,
    applied_by TEXT,
    applied_at TIMESTAMP DEFAULT now(),
    rollback_available BOOLEAN DEFAULT true,
    monitoring_until TIMESTAMP,
    status TEXT DEFAULT 'applied'
);

41. Tabla SQL de monitoreo post-recalibración

CREATE TABLE recalibration_monitoring (
    monitoring_id TEXT PRIMARY KEY,
    recalibration_event_id TEXT NOT NULL,
    metric_code TEXT NOT NULL,
    value_before NUMERIC,
    value_after NUMERIC,
    delta_value NUMERIC,
    expected_direction TEXT,
    result_status TEXT,
    measured_at TIMESTAMP DEFAULT now()
);

Estados:

improved
neutral
worse
inconclusive
needs_rollback

42. Motor de recalibración FARO

Flujo general:

learning event
→ detectar candidato
→ calcular fuerza de recalibración
→ evaluar riesgo
→ definir aprobación requerida
→ ejecutar backtesting
→ aprobar / rechazar
→ versionar configuración
→ aplicar
→ monitorear
→ mantener o rollback

Código conceptual:

def motor_recalibracion(learning_event):
    strength = fuerza_recalibracion(
        evidencia_historica=learning_event["evidence_strength"],
        impacto_economico=learning_event["economic_impact"],
        recurrencia=learning_event["recurrence"],
        confianza_aprendizaje=learning_event["confidence"],
        bajo_riesgo=learning_event["low_risk"],
        facilidad_reversion=learning_event["reversibility"]
    )

    if strength < 0.50:
        return {
            "status": "observe",
            "reason": "Fuerza insuficiente para recalibrar"
        }

    return {
        "status": "candidate",
        "recalibration_strength": strength,
        "requires_approval": learning_event.get("sensitive", True)
    }

43. Motor de aprobación

def evaluar_aprobacion_recalibracion(candidate):
    if candidate["risk_level"] == "high":
        return "requires_direction_approval"

    if candidate["target_type"] in [
        "score_weights",
        "credit_policy",
        "commission_policy",
        "pricing_rule",
        "hr_sensitive_rule"
    ]:
        return "requires_direction_approval"

    if candidate["recalibration_strength"] >= 0.85 and candidate["risk_level"] == "low":
        return "can_auto_apply_controlled"

    return "requires_faro_admin_approval"

44. Motor de monitoreo post-recalibración

def monitorear_recalibracion(metric_before, metric_after, expected_direction):
    delta = metric_after - metric_before

    if expected_direction == "increase":
        status = "improved" if delta > 0 else "worse" if delta < 0 else "neutral"

    elif expected_direction == "decrease":
        status = "improved" if delta < 0 else "worse" if delta > 0 else "neutral"

    else:
        status = "inconclusive"

    return {
        "delta": delta,
        "status": status,
        "requires_rollback": status == "worse"
    }

45. Ejemplo completo: recalibración de descuentos

Aprendizaje

La alerta de descuento >8% generó demasiados falsos positivos en productos de alta elasticidad.

Evidencia

120 alertas.
Solo 22 accionables.
Falsos positivos: 48%.

Recalibración propuesta

No usar umbral único.
Definir umbral por familia de producto.

Nueva regla

cemento > 4%
hierro > 5%
sanitarios > 10%
grifería > 12%
pisos/revestimientos > 15%

Aprobación

Requiere aprobación Comercial + Dirección.

Monitoreo

Medir durante 30 días:
falsos positivos,
margen,
ventas,
acciones útiles.

46. Ejemplo completo: recalibración de canjes

Aprendizaje

Las simulaciones de canjes fueron optimistas.
El valor recuperado real fue 22% menor al simulado.
El plazo real fue 50% mayor.

Recalibración

Reducir factor de liquidez.
Aumentar costo financiero.
Exigir aprobación de Directorio desde menor umbral.

Código:

def recalibrar_canje(factor_liquidez_actual, plazo_actual, error_valor, error_plazo):
    nuevo_factor = factor_liquidez_actual * (1 - abs(error_valor) * 0.5)
    nuevo_plazo = plazo_actual * (1 + abs(error_plazo) * 0.5)

    return {
        "liquidity_factor": round(nuevo_factor, 2),
        "realization_period_days": round(nuevo_plazo)
    }

47. Ejemplo completo: recalibración de stock crítico

Aprendizaje

La alerta de stock se activó tarde porque solo miraba stock mínimo.

Recalibración

Cambiar regla:
stock crítico no es solo stock < mínimo.
También es días de cobertura < plazo proveedor.

Regla nueva:

def stock_critico_recalibrado(stock_actual, venta_diaria, plazo_proveedor, producto_critico):
    if not producto_critico:
        return False

    if venta_diaria == 0:
        return False

    dias_cobertura = stock_actual / venta_diaria

    return dias_cobertura < plazo_proveedor

48. Ejemplo completo: recalibración de workflow

Aprendizaje

Las acciones financieras P1 no se vencen por falta de ejecución.
Se vencen esperando aprobación de Dirección.

Recalibración

Crear SLA para aprobaciones P1:
Dirección debe responder en 4 horas.
Si no responde, escalar a Directorio / Gerencia General.

Nueva política:

{
  "approval_sla": {
    "P1": 4,
    "P2": 24,
    "P3": 72
  },
  "escalation": {
    "P1": "Gerencia General / Directorio",
    "P2": "Dirección"
  }
}

49. Ejemplo completo: recalibración de FARO Score

Aprendizaje

Las acciones cerradas con evidencia, pero sin impacto, estaban sumando demasiado al Score.

Recalibración

Reducir bonificación por cierre operativo.
Aumentar bonificación por impacto medido.

Antes:

acción cerrada con evidencia: +3
acción efectiva: +2 adicional

Después:

acción cerrada con evidencia: +1
acción efectiva medida: +4

Lectura:

FARO Score empieza a premiar resultado, no solo cumplimiento.

Eso es sano. Porque cerrar tareas sin cambiar la realidad es burocracia eficiente, no dirección.

50. Recalibración explicada para socio técnico

La explicación técnica es:

La recalibración FARO no es IA cambiando reglas libremente.

Es un circuito gobernado:

1. Se mide resultado real.
2. Se genera learning event.
3. Se propone candidato de recalibración.
4. Se calcula fuerza de recalibración.
5. Se evalúa riesgo.
6. Se ejecuta backtesting.
7. Se versiona la nueva configuración.
8. Se aprueba si corresponde.
9. Se aplica en entorno controlado.
10. Se monitorea impacto.
11. Se mantiene o se revierte.

Esto es defendible técnicamente. Y comercialmente también: muestra que FARO aprende sin volverse una ruleta.

51. Herramientas posibles

Para MVP alcanza:

PostgreSQL + tablas de configuración versionada + motor de reglas + aprobación manual.

No hace falta arrancar con MLflow y 14 microservicios. Primero que la lógica no haga agua; después se la viste de gala.

52. Uso de IA en recalibración

La IA puede ayudar a:

explicar por qué se propone una recalibración,
resumir evidencia,
detectar patrones,
redactar propuesta de cambio,
comparar versión anterior vs nueva,
preparar informe para aprobación.

Pero no debe:

cambiar reglas sensibles sola,
modificar pesos del Score sin aprobación,
inventar evidencia,
eliminar alertas críticas,
recalibrar con datos insuficientes,
confundir correlación con causalidad.

Prompt interno:

Actúa como analista ejecutivo FARO.

Con base únicamente en el payload estructurado recibido, redacta una propuesta de recalibración clara y defendible.

No inventes datos.
No afirmes causalidad absoluta si no está demostrada.
Incluye:
1. aprendizaje que originó la recalibración,
2. regla o parámetro actual,
3. cambio propuesto,
4. evidencia,
5. impacto esperado,
6. riesgo,
7. si requiere aprobación,
8. plan de monitoreo,
9. posibilidad de rollback.

Payload:
{recalibration_payload}

53. Testing de recalibración

Test fuerza suficiente

def test_fuerza_recalibracion_alta():
    score = fuerza_recalibracion(
        evidencia_historica=0.90,
        impacto_economico=0.80,
        recurrencia=0.85,
        confianza_aprendizaje=0.90,
        bajo_riesgo=0.80,
        facilidad_reversion=0.90
    )

    assert score >= 0.85

Test alerta ruidosa reduce sensibilidad

def test_alerta_ruidosa_reduce_sensitivity():
    ajuste = recalibrar_alerta(
        alert_utility=0.20,
        false_positive_rate=0.50,
        false_negative_rate=0.05
    )

    assert ajuste == "reduce_sensitivity"

Test falso negativo aumenta sensibilidad

def test_alerta_con_falso_negativo_aumenta_sensibilidad():
    ajuste = recalibrar_alerta(
        alert_utility=0.60,
        false_positive_rate=0.10,
        false_negative_rate=0.35
    )

    assert ajuste == "increase_sensitivity"

Test rollback

def test_rollback_recalibracion():
    resultado = rollback_recalibracion(
        current_version="1.2",
        previous_version="1.1"
    )

    assert resultado["status"] == "rolled_back"
    assert resultado["to_version"] == "1.1"

54. Errores comunes en recalibración

55. Riesgos si no existe esta capa

56. Output final del Anexo 37

Al finalizar este anexo, FARO debe tener definido:

1. Modelo de recalibración FARO.
2. Qué elementos se pueden recalibrar.
3. Qué elementos requieren aprobación.
4. Niveles de recalibración.
5. Criterios para recalibrar.
6. Fórmula de fuerza de recalibración.
7. Recalibración de umbrales.
8. Recalibración de alertas.
9. Recalibración de tensiones.
10. Recalibración de diagnósticos.
11. Recalibración de prioridades.
12. Recalibración de recomendaciones.
13. Recalibración de acciones.
14. Recalibración de Action Guides.
15. Recalibración de simulaciones.
16. Recalibración de FARO Score.
17. Recalibración de confianza.
18. Recalibración de calidad de datos.
19. Recalibración de workflow y SLA.
20. Recalibración de escalamiento.
21. Recalibración de evidencia.
22. Recalibración de reportes.
23. Recalibración por industria.
24. Recalibración por empresa.
25. Recalibración por madurez.
26. Gobierno de recalibración.
27. Backtesting.
28. Sandbox.
29. Versionado.
30. Rollback.
31. Auditoría.
32. Tablas SQL de recalibración.
33. Motor de recalibración.
34. Motor de aprobación.
35. Motor de monitoreo.
36. Testing de recalibración.
37. Uso controlado de IA explicativa.

57. Conexión con otros anexos

La Recalibración FARO transforma aprendizajes reales en ajustes controlados sobre reglas, umbrales, pesos, recomendaciones, simulaciones, workflow, evidencia y FARO Score. Cada cambio debe tener evidencia, versión, aprobación cuando corresponda, backtesting, monitoreo y posibilidad de rollback.