T3 — Calcification Engine

Categoría: SoA con escritura a SoR pequeño propio (rule stores de M1 y de I1) Estado: Propio sano — el componente nuevo más diferencial de V3. Síntesis de: Claude T3 + Codex T3

1. Responsabilidad

T3 convierte decisiones repetidas, aprobadas y estables en reglas ejecutables sin LLM. Su propósito es reducir coste, latencia y variabilidad sin sacrificar control contable.

T3 es el corazón del valor a largo plazo del 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. Toda regla pasa por gate humano (Intelia ops). No hay auto-promoción.
No invalida reglas viejas sin shadow. Cualquier cambio pasa por período de shadow.
No mezcla niveles. Reglas semánticas viven en M1.RuleStore; reglas de integración viven en I1.PlanStore. T3 propone a la capa correspondiente.
No corrige planes. Solo gestiona reglas que sustituyen decisiones futuras.
No ejecuta en Holded. Solo gestiona conocimiento.
No calcifica sin reverse-sync vivo. Si T4 está caído, T3 pausa. "No editó" no es válido si no estás observando.

3. Tipos de calcificación

3.1 Calcificación semántica (M1)

(motor_input_signature) → Internal Plan

Cuando los LLMs de M1 toman la misma decisión repetidamente para inputs similares, T3 propone una regla que sustituye la llamada al LLM.

Ejemplo: "Para proveedor Glovo (NIF B12345678) + concepto con comida, el LLM Account devuelve 62980000 las últimas 8 ejecuciones, todas aprobadas. → Propuesta de regla account_rule_R-2341 en M1.RuleStore."

3.2 Calcificación de integración (I1)

(intent_signature, erp_context_signature) → ExecutionPlan

Cuando el Plan Generator de I1 genera el mismo ExecutionPlan para inputs equivalentes, T3 propone una regla que sustituye la llamada al agente.

Ejemplo: "Para Internal Plan con vat_application_mechanism: REVERSE_CHARGE + holded_subdomain: tipo_pyme, el agente genera el mismo ExecutionPlan las últimas 12 ejecuciones, todas validadas. → Propuesta de regla i1_plan_rule_R-981 en I1.PlanStore."

3.3 Frontera entre niveles

Una regla nunca cruza niveles. Si se descubre que una decisión "semántica" depende del estado del ERP, eso es señal de mezcla: la decisión debería estar en I1, no en M1. T3 rechaza propuestas mezcladas.

4. Lifecycle de una regla

Cinco estados explícitos:

candidate → shadow → active → quarantined → retired

Estado	Descripción
candidate	Patrón observado por T3, aún no fiable. No se aplica nunca. Acumula evidencia.
shadow	Aprobada por Intelia ops. Se aplica en sombra: cada doc nuevo del patrón se procesa POR AMBOS paths (agente + regla), comparator estructural valida match.
active	Pasó shadow. Aplica en producción. Cada aplicación incrementa contadores.
quarantined	Dejó de ser fiable (correction_rate alto, T4 detecta drift). No aplica. Pendiente de revisión.
retired	Inválida o sustituida. NO se borra — queda en historial para auditoría.

5. Sistema de evidencia

Tipos de evidencia (positiva)

Tipo	Cómo se captura	Peso
EXPLICIT_APPROVAL	Contable aprueba en dashboard Intelia	1.0
HOLDED_INACTION	Auto-contabilizado, contable no editó en 14 días	0.7
HOLDED_POSITIVE_COMMENT	Contable comentó "OK" / similar (LLM-extracted)	0.5
REVALIDATION_PASS	T4 detecta que tras edición, contable volvió al criterio Intelia	1.2
BULK_APPROVE_IN_DASHBOARD	Aprobó dentro de bulk action	0.5 (peso reducido)

Tipos de evidencia (negativa)

Tipo	Peso negativo
HUMAN_EDITED_PLAN_IN_DASHBOARD	Contable cambió el plan antes de aprobar
HOLDED_EDITED_BY_HUMAN	T4 detecta cambio post-ejecución
HOLDED_NEGATIVE_COMMENT	Comment del contable indica desacuerdo (LLM-extracted)
FINAL_VALIDATION_FAILED	Plan ejecutado pero readback no coincide

Acumulación

Score por (rule_signature, evidence_window):

score = Σ(positive * peso) − Σ(negative * peso)

Score ≥ 5 sin negativa → propuesta a Intelia ops (lifecycle candidate → shadow).
Score ≤ −2 → invalidar regla activa (lifecycle active → quarantined).

Ventana temporal: últimas 60 evidencias o 90 días, lo primero que llegue.

6. Arquitectura operativa

T3 tiene tres planos:

6.1 Lookup (sincrónico, barato)

Cuando M1 o I1 va a tomar una decisión, consulta T3 por reglas activas. Si hay match, devuelve la regla; sino, sigue al LLM.

Esto es síncrono y rápido. No bloquea pipeline.

6.2 Evidence collector (asíncrono)

Workflow Temporal continuous que escucha eventos del bus de signals (TX):

Aprobaciones y ediciones en dashboard (S1).
Inacciones y ediciones en Holded (T4).
Final Validation pass/fail (I1).

Acumula evidencia por rule_signature.

6.3 Promotion engine (Temporal workflows durables)

Proposer: cuando score ≥ 5 → genera regla candidate → notifica a Intelia ops.
Shadow tester: cada doc nuevo que matchea regla candidate ejecuta ambos paths. Comparator estructural compara. Tras N=15 ejecuciones con ≥95% match → promueve a active.
Invalidator: detecta scores negativos o signals de invalidación → mueve regla a quarantined.

7. Bootstrap cruzado

Diferenciación competitiva del producto.

Flujo

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

Por archetype, no por cliente individual

T3 mantiene archetypes (cluster de clientes similares por features del CompiledGuide + sector + tamaño). Las reglas se almacenan en el archetype, no en el cliente. Bootstrap cruzado = "este cliente nuevo entra al archetype hostelería-mediano-iva-general → recibe sus reglas".

8. Invalidación

Trigger	Acción
`T4: GUIDE_VERSION_CHANGED`	Reglas con `dependent_guide_versions` afectadas pasan a re-shadow
`T4: CRITERION_CHANGED` desde contable	Reglas usadas para ese cliente pasan a dashboard ops review
`Edición del contable >3 veces en 30 días`	Regla pasa a `quarantined`. Notificación a ops
`Manual invalidation` desde dashboard ops	Inmediata. Audit obligatorio
`Cambio sistémico` (chart_of_accounts, periodos)	Invalidación masiva en bloque

Las reglas quarantined no se borran. Quedan con histórico para auditoría y posible reactivación.

9. Fronteras

Con M1

T3 puede evitar una llamada LLM si existe una regla semántica activa. M1 expone:

representación canónica de decisión;
evidencias usadas;
features de matching;
resultado de validación;
feedback de aprobación/edición.

Con I1

T3 gestiona lifecycle de reglas de traducción. I1 posee el contenido y las features de matching.

Con T4

T4 alimenta T3 con la mayoría de evidencias post-ejecución. Sin T4 vivo, T3 pausa (las evidencias "no editó" son mentirosas).

Con S1

S1 es el gate humano de T3: dashboard donde Intelia ops aprueba/rechaza propuestas. Y donde el contable da evidence explícita (EXPLICIT_APPROVAL).

10. Riesgos arquitectónicos y mitigaciones

Riesgo	Mitigación
Calcificación prematura (auto-promote sin garantías)	Gate humano obligatorio + shadow mode
Calcificación de errores sistemáticos del agente	Shadow + comparator estructural detecta divergencia
Sesgo del contable (aprueba sin verificar) infla evidencia positiva	Peso de `EXPLICIT_APPROVAL` se ajusta por `correction_rate_historico` del contable
Reglas demasiado específicas (cubren 1 doc)	`intent_signature` con bucket explícito de magnitudes. Signatures con cobertura 1 no se proponen
Reglas demasiado amplias (cubren >40% de docs)	Métricas obligatorias: `coverage_per_rule`. Alarma si >40%. Revisión humana de signature
Bootstrap cruzado introduce sesgo masivo	Reglas bootstrapped tienen período shadow obligatorio (primeros 10 docs por patrón pasan por dashboard)
Loop de feedback se atasca (contable no revisa)	Si 30 días sin evidencia, regla candidate se archiva — no se promueve por silencio
Reglas obsoletas tras cambio fiscal o de chart	Invalidación cross sistema. Detector cruzado con calendario fiscal
Intelia ops dashboard se convierte en cuello de botella	Auto-aprobación condicional para propuestas de muy alta confianza (N>10, score>15, cero negativas). Con audit posterior, no gate síncrono

11. Lo que puede salir mal

Patología 1: T3 como tabla de reglas con counter >= N. Calcifica errores. T3 debe ser sistema de governance de conocimiento operativo, no optimización técnica.

Patología 2: T3 paraliza con miedo. Políticas muy estrictas (N=20, cero negativa, shadow 30 días) → reglas nunca se promueven. Cliente mes 12 sigue llamando al agente al 80%. Vigilancia: proposals_promoted_per_month. Si <5/mes a los 6 meses, relajar.

Patología 3: T3 sesga hacia clientes "modelo". Archetypes construidos con datos de primeros clientes (early adopters, urbanos) → cliente nuevo "rural" recibe mal bootstrap. Vigilancia: bootstrap_success_rate por cliente. Si <60% en mes 1, revisar archetype.

Patología 4: reglas se desactualizan silenciosamente cuando cambia fiscalidad. Cambio de IVA → reglas con tax_keys viejos siguen activas. Mitigación: T3 cruzado con calendario fiscal. Cambios fiscales conocidos disparan re-shadow masivo del subset afectado.

Patología 5: calcificación correlación falsa. Un proveedor parece estable hasta que cambia el concepto. Mitigación: scopes estrechos, período shadow, invalidación por T4, explicación de matching y umbrales conservadores al principio.

12. Métricas operacionales

Métrica	Target
`t3_rules_proposed_per_month_per_archetype`	5-20
`t3_proposal_to_promotion_rate`	60-80%
`t3_shadow_pass_rate`	>90%
`t3_invalidation_rate_per_month`	<10% del rule store
`t3_bootstrap_acceptance_rate`	>70% de reglas bootstrapped sobreviven primer mes
`t3_intelia_ops_review_latency`	<48h
`% docs servidos por regla vs LLM`	Crece monotónico por cliente

13. Open questions

¿Calcificación a nivel team o a nivel tax_entity? Multi-tax-entity per team afecta.
Schema del intent_signature y erp_context_signature. Lo más sensible del sistema.
¿Shadow mode pasa por todos los docs o por sampling?
Comparator estructural del shadow: nivel de tolerancia. ¿Match exacto vs match funcional?
Cómo se interpretan los comentarios del contable en Holded — LLM con structured output, threshold de confidence.
Persistencia de evidencia. ¿Tabla crece forever? Política de retention.
Política de auto-invalidación. ¿Una edición invalida regla para solo ese cliente o para el archetype?

Síntesis. Detalle granular en versiones originales.