1. Responsabilidad

T4 observa Holded después de que Intelia escribe o propone, y convierte lo que pasó allí en señales estructuradas para aprendizaje, auditoría y control.

Sin T4, Intelia vuelve a depender de dashboards propios para saber si acertó. Con T4, Holded se convierte en interfaz de trabajo de alta confianza y fuente de feedback.

T4 es el sustrato del aprendizaje: sin él, T3 calcifica sobre evidencia mentirosa.

2. NO es su responsabilidad

• No decide automáticamente. Propaga señal estructurada; otros componentes deciden qué hacer.
• No escribe a Holded. Solo lee. T4 es read-only sobre el SoR ajeno.
• No procesa en runtime de la decisión de Intelia. Trabaja asíncrono.
• No interpreta semantics libremente. Cuando lee un comment, el LLM extrae intent estructurado (positive | negative | neutral | criterion_change); no toma decisión propia.
• No cambia cuentas en M1 ni reglas en Plan Store. Solo emite signals; los componentes propietarios deciden.

3. Qué monitoriza

Para cada documento que Intelia ha ejecutado (registrado en executed_plan_history con plan_id y external_id en Holded), T4 vigila:

T4 NO monitoriza cambios hechos por Intelia misma (filtrados por timestamp + actor, o hash del estado pre/post-ejecución).

4. Tipos de señal

5. Mecanismo de polling

Holded no tiene webhooks fiables. T4 funciona por polling.

HoldedDocumentMonitor {
    document_id: str (external),
    intelia_plan_id: UUID,
    monitored_fields: ["account_lines", "approved", "tax_keys", ...],
    last_hash: str,
    last_polled_at: datetime,
    poll_tier: "hot" | "warm" | "cold",
    edits_detected: list[EditSignal]
}

6. Matching y trazabilidad

La trazabilidad insertada por I1 es requisito. T4 debe preferir matching explícito:

1. Por tag estructural (intelia-plan-id-<uuid>) — match perfecto.
2. Por comment con plan_id — match fuerte.
3. Por external_id + hash de estado pre-ejecución — match débil pero útil.
4. Por correlación temporal — solo como fallback.

Si T4 no puede atribuir un cambio a un plan Intelia con confidence alto, emite signal UNATTRIBUTED_CHANGE que no entra al loop de aprendizaje (queda solo para audit).

7. Procesamiento de comments

Los comments libres del contable son la señal más rica pero la más ruidosa.

8. Ciclo de respuesta opcional al contable

Cuando T4 detecta una edición ambigua, puede dejar un comment al contable en Holded preguntando la razón:

[Intelia] Detectamos que cambiaste 62980000 → 62890000.

¿Razón del cambio?
- #criterio_cambiado (actualizamos la regla)
- #extraccion_incorrecta (OCR leyó mal)
- #bug_intelia (el agente se equivocó)
- O ignora si fue excepción puntual.

Política: solo se hace si la edición es de alta importance (cuenta cambiada vs comment añadido). Si se hace para todo, satura al contable.

9. Cambios sistémicos

Algunos cambios afectan a múltiples documentos:

• Chart of accounts (cliente renombra cuenta o crea cuenta nueva).
• Period locks (cliente cerró trimestre).
• Tax entity config (activó SII, cambió régimen).

T4 monitoriza estos cambios "sistémicos":

SystemicChangeSignal {
    signal_type: "CHART_OF_ACCOUNTS_CHANGED" | "PERIOD_LOCKED" | ...,
    team_id: UUID,
    detected_at: datetime,
    delta: { ... },
    affected_intelia_plans: [list of plan_ids dependientes],
    audience: ["m1_motor", "t3_calcification", "i1_facts_snapshot"]
}

Disparan invalidación masiva en T3 (reglas afectadas → re-shadow) y refresh de facts/erp_snapshot/ en M1.

10. Outputs — el Delta Event

T4 emite señales tipadas:

DeltaEvent {
    signal_type: enum,
    intelia_plan_id: UUID,
    holded_external_id: str,
    detected_at: datetime,
    delta: {
        field: str,
        old_value: any,
        new_value: any,
    },
    actor: "human" | "intelia" | "system" | "unknown",
    confidence_interpretation: float,
    audience: ["t3_calcification", "m1_motor", "intelia_ops"],
    actionable: bool,
    severity: ERROR | WARNING | INFO,
    recommendation: "ignorar" | "revisar" | "invalidar" | "recalibrar" | "promover"
}

Consumidores:

11. Riesgos arquitectónicos y mitigaciones

12. Lo que puede salir mal

Patología 1: T4 satura Holded API. Polling agresivo + clientes grandes → 1000+ calls/min → bloqueo. Mitigación: cadencia adaptativa + monitor holded_calls_per_minute.

Patología 2: false positives en interpretación de comments. LLM clasifica comment ambiguo como "positive" cuando era negativo. T3 calcifica un patrón que el contable rechaza. Mitigación: confidence threshold + modo "siempre Intelia ops revisa comments" para clientes con contables muy verbose.

Patología 3: latencia entre cambio y propagación. Contable edita 9am; polling 9:15am; T3 procesa hora siguiente. Aceptable trade-off por coste.

Patología 4: el contable edita en Holded y en dashboard al mismo tiempo. Las dos rutas generan evidence de tipos distintos. Mitigación: tracking unificado de "edition events" sin importar canal.

Patología 5: T4 se convierte en sincronizador. Si T4 intenta replicar todo el estado de Holded, reintroducimos el SoR paralelo. Vigilancia: T4 solo observa objetos vinculados a planes Intelia (vía tag o external_id en executed_plan_history), no exploración completa.

13. Métricas operacionales

14. Open questions

• Cadencia óptima de polling caliente — 15 min razonable, medir coste real.
• ¿Comments del contable se procesan inmediatamente o en batch? Trade-off latencia vs coste.
• Política de retención de signals históricos. Propuesta: 12 meses caliente, archivar.
• ¿T4 puede inferir CRITERION_CHANGED por patrón de cambios sin comment del contable? Probablemente sí con threshold.
• Reverse-sync de comentarios sistémicos (a nivel cliente, no documento específico). ¿Cómo se captura?
• Cómo se filtran los cambios hechos por Intelia vs por el contable cuando Holded no atribuye autoría clara.
• ¿Qué objetos Holded deben entrar en observación inicial y cuáles quedan fuera? Definir whitelist conservadora.

Nota especial sobre prioridad

T4 es el componente que merece la segunda iteración de diseño más profunda. Codex lo señaló explícitamente:

"Sin un T4 muy bien diseñado, la promesa de Holded como interfaz madura queda demasiado apoyada en confianza conceptual."

Antes de implementar V3, hacer un brainstorm específico de T4 con ejemplos concretos de deltas Holded, taxonomía de señales, ventanas de observación, severidades e invalidación de reglas T3.

Síntesis. Detalle granular en versiones originales.