1. Responsabilidad

Convertir patrones de decisión recurrentes en reglas deterministas mediante observación + propuesta + gate humano + período shadow + promoción.

T3 es el corazón del valor a largo plazo de Intelia como producto IA-first. Sin T3, el sistema es un proxy LLM sobre Holded; con T3, el sistema se vuelve cada vez más eficiente y predecible con el uso.

2. NO es su responsabilidad

• No decide automáticamente. Las reglas propuestas SIEMPRE pasan por gate humano (Intelia ops). No hay auto-promoción.
• No invalida reglas viejas sin shadow. Cualquier cambio pasa por período de shadow primero.
• No mezcla niveles. Las reglas semánticas viven en M1.RuleStore; las reglas de integración viven en I1.PlanStore. T3 propone a la capa correspondiente.
• No calcifica sin reverse-sync vivo. Si T4 está caído, T3 pausa. La señal de "no editó" no es válida si no estás monitoreando.

3. El loop end-to-end

                  ┌────────────────────────────────────┐
                  │   T3 observa cada documento procesado  │
                  └────────────────────────────────────┘
                                 │
                                 ▼
              ┌──────────────────────────────────────┐
              │  Detector de evidencia                │
              │  - Plan ejecutado (executed_plan)     │
              │  - Confianza del Plan Generator       │
              │  - Aprobación del contable (signals): │
              │    · Dashboard: explicit approve      │
              │    · Holded: no edit en N días        │
              │    · Holded: comment positivo         │
              │  - Edición del contable (T4 signals)  │
              └──────────────────────────────────────┘
                                 │
                                 ▼
              ┌──────────────────────────────────────┐
              │  Agrupador por patrón                 │
              │  Clusters de evidencias por           │
              │  (intent_signature, erp_signature)    │
              └──────────────────────────────────────┘
                                 │
                                 ▼
              ┌──────────────────────────────────────┐
              │  Proposer                             │
              │  Cuando un cluster tiene N≥5 evidencias│
              │  positivas y 0 negativas, propone     │
              │  regla candidate                       │
              └──────────────────────────────────────┘
                                 │
                                 ▼
              ┌──────────────────────────────────────┐
              │  Gate humano (Intelia ops dashboard)  │
              │  - Revisión del patrón                │
              │  - Confirmación / rechazo / edición   │
              └──────────────────────────────────────┘
                                 │
                                 ▼
              ┌──────────────────────────────────────┐
              │  Shadow mode (14-30 días)             │
              │  Cada doc nuevo del patrón:           │
              │  - Agente genera plan                 │
              │  - Regla candidate genera plan        │
              │  - Comparator estructural             │
              │  - Si match en 95%+ → promote OK      │
              └──────────────────────────────────────┘
                                 │
                                 ▼
              ┌──────────────────────────────────────┐
              │  Promoción al rule store correspondien│
              │  - Semántica → M1.RuleStore           │
              │  - Integración → I1.PlanStore          │
              └──────────────────────────────────────┘

4. Tipos de calcificación

T3 calcifica en dos niveles:

5. Sistema de evidencia

score = Σ(evidencia_positiva * peso) - Σ(evidencia_negativa * peso)

6. Bootstrap cruzado

Es la diferenciación competitiva del producto. Lo explico en flow:

1. Cliente nuevo onboardea. Sector hosteleria, tamaño mediano.
2. T3 consulta su bootstrap_index: ¿hay clientes existentes con sector + tamaño similar?
3. Si sí, T3 selecciona top 3 clientes "modelo" del mismo arquetipo (criterios: tiempo de uso, calidad de feedback, baja correction_rate).
4. T3 clona las reglas calcificadas de los modelos al cliente nuevo, marcadas como bootstrap_origin: {client_id, sector, archetype}.
5. Las reglas bootstrapped tienen confidence: 0.7 (vs 0.95 de las nativas).
6. Sistema arranca: los primeros documentos del cliente nuevo matchean reglas bootstrapped → caen en BAJA confianza → dashboard Intelia para revisión humana del cliente.
7. Si el contable nuevo aprueba sin tocar → la regla bootstrapped sube su confianza para ESTE cliente, hacia 0.95.
8. Si el contable rechaza / edita → la regla bootstrapped se marca como no apta para este cliente. Cae confianza, eventualmente se inactiva.

Resultado: cliente N+1 onboardea con criterio "razonable de partida" en vez de cero. Coste LLM en mes 0 es bajo, no alto.

7. Shadow mode

Cuando una regla propuesta pasa el gate humano (Intelia ops aprueba), entra en shadow mode antes de promoverse:

• Cada documento que matchee la regla candidate se procesa por ambos paths:
  1. Agente LLM genera plan (path actual).
  2. Regla candidate genera plan (sombra).
• Un comparator estructural compara ambos planes (no diff textual; comparación por shape declarativo del ExecutionPlan).
• Si match en ≥95% en N=15 ejecuciones consecutivas → promote. Regla pasa a active.
• Si match en <95% → la regla candidate vuelve al gate humano con el delta del comparator.

Coste del shadow: doble llamada LLM en N=15 docs. Aceptable comparado con el ahorro futuro.

8. Invalidación de reglas

Las reglas inactivas NO se borran. Quedan con status: inactive para auditoría y posible reactivación.

9. Riesgos arquitectónicos y mitigaciones

10. Lo que puede salir mal

Patología 1: T3 paraliza la calcificación con miedo. Si las políticas de evidencia son muy estrictas (N=20 + cero negativa + shadow de 30 días), las reglas nunca se promueven. Cliente N+1 mes 12 sigue llamando al agente al 80%. Coste LLM constante. Vigilancia: tracking de proposals_promoted_per_month. Si <5/mes a los 6 meses, relajar políticas.

Patología 2: T3 sesga hacia los clientes "modelo" del bootstrap. Los archetype se construyen con datos de los primeros clientes. Si esos primeros clientes son sesgo (early adopters tech, urbanos), el bootstrap para futuros clientes "rurales" sale mal. Vigilancia: tracking de bootstrap_success_rate por cliente. Si <60% en mes 1, revisar la definición de archetype.

Patología 3: dashboard de Intelia ops para revisar propuestas se vuelve cuello de botella. Si T3 propone 10 reglas/día y Intelia ops solo revisa 1/día, las propuestas se acumulan. Calcificación se ralentiza. Mitigación: auto-aprobación condicional para propuestas de alta confianza (N>10, score>15, cero negativas, cliente con baja correction_rate). Auto-aprobadas con audit posterior, no gate síncrono.

Patología 4: reglas calcificadas se desactualizan silenciosamente cuando cambia la fiscalidad. Cambio de tipo de IVA en España (e.g. del 21% al 22%) y las reglas calcificadas con tax_keys viejos siguen activas. Mitigación: T3 cruzado con calendario fiscal. Cambios fiscales conocidos disparan re-shadow masivo del subset afectado. Pero el detector es manual hasta que se automatice.

11. Open questions

1. ¿Calcificación a nivel team o a nivel tax_entity? Multi-tax-entity per team: ¿reglas por tax_entity (más específicas) o por team (más bootstrap)?

2. Schema del intent_signature y del erp_context_signature. Es lo más sensible del sistema. Mal diseñado → reglas falsas. Bien diseñado → 80% hit rate.

3. ¿Shadow mode pasa por todos los docs o por sampling? Si pasa todos, coste alto. Si por sampling, evidencia más lenta.

4. Comparator estructural del shadow: nivel de tolerancia.

   • ¿Match exacto del ExecutionPlan? Demasiado estricto.
   • ¿Match funcional (mismo PlanState declarado, distinto orden de ops)? Mejor pero más complejo.

5. ¿Cómo se interpretan los comentarios del contable en Holded? LLM con prompt corto + structured output (positive | negative | neutral | criterion_change). Pero los comentarios son ambiguos en lenguaje natural.

6. Persistence de evidencia. ¿Tabla de evidencia crece para siempre? Política de retention. Propuesta: rotación trimestral, archivo Cold Storage.

7. Política de auto-invalidación. Si T4 declara EDITED_BY_HUMAN, ¿desconfianzar la regla afectada para SOLO ese cliente o para el archetype entero? Default: solo cliente. Pero si la edición se repite en N clientes del mismo archetype, escalar.

12. Métricas operacionales

Próximos docs

• t4-reverse-sync.md — el detector de evidencia más rico de T3
• s1-ux-hybrid.md — dónde el contable da evidencia explícita