Status: Target conceptual · No implementación Fecha: 2026-05-22 Autor: Claude (versión paralela con Codex en ../v3-conceptual-codex/)
V3 se construye sobre tres categorías de componente. Toda pieza del sistema cae en una y sólo una:
| Categoría | Qué es | Quién lo controla |
|---|---|---|
| SoR (System of Record) | Persiste verdad canónica. Determinista. Lifecycle estable. Asientos, libro diario, saldos. | Externo (Holded / Sage / Odoo) o pequeño y aburrido propio (audit log de decisiones, plan store, dashboard state). |
| SoA (System of Action) | Decide y actúa sobre uno o varios SoR. Extracción, motor de decisión LLM, conciliación inteligente, calcificación, reverse-sync. | Intelia. |
| Conector | Traduce entre SoA y SoR. No tiene verdad propia ni decide qué hacer. Plan Generator, Executor, Final Validation. | Intelia, per-ERP. |
Frase operativa:
El Motor decide. El Conector traduce. El SoR persiste. T3 calcifica patrones por nivel. T4 propaga señal estructurada.
V3 honesta requiere disciplina explícita en cinco fronteras:
account_lines se elimina o se declara sombra explícita. La verdad contable canónica vive en el ERP, no en Intelia. Si se conserva una proyección en Intelia, se nombra last_synced_holded_cache con TTL, sin autoridad de escritura.facts/extracted/ (Intelia), facts/memory/ (Intelia), facts/erp_snapshot/ (sombra del SoR ajeno, con refreshed_at explícito).holded_integration/, no en un namespace top-level que insinúe agnosticismo.StandaloneIntent del Motor.(input_signature) → StandaloneIntent. Viven en el Motor.(StandaloneIntent + erp_context) → ExecutionPlan. Viven en el integrador.Estas reglas se evalúan en code review. Cualquier PR que las viole se rechaza por mezcla SoR/SoA.
┌──────────────────────────────────────────────┐
│ Documento entrante (Gmail · WhatsApp · upload)
└──────────────────────────────────────────────┘
│
▼
╔══════════════════════════════════════════════╗
║ M1 — MOTOR ║
║ SoA · portable entre ERPs ║
║ ║
║ Facts → Decisions (3 LLMs) → Internal Plan ║
║ → Contextual → Validation ║
║ ║
║ Output: StandaloneIntent + InternalAccPlan ║
╚══════════════════════════════════════════════╝
│
▼
╔════════════════════════════════════════════════════════╗
║ I1 — INTEGRADOR HOLDED ║
║ Conector + SoR pequeño propio · per-ERP ║
║ ║
║ ┌──────────────────┐ miss ┌──────────────────┐ ║
║ │ Plan Store │ ─────────▶│ Plan Generator │ ║
║ │ (reglas calcif.)│ │ (agente LLM) │ ║
║ │ │ ◀─────hit │ guides + tool │ ║
║ └──────────────────┘ └──────────────────┘ ║
║ ↓ ║
║ ExecutionPlan + score de confianza ║
║ ║
║ ┌──────────────────────────────────────────────────┐ ║
║ │ Executor determinista (Temporal) │ ║
║ └──────────────────────────────────────────────────┘ ║
║ ↓ ║
║ ┌──────────────────────────────────────────────────┐ ║
║ │ Final Validation (PlanState vs readback) │ ║
║ └──────────────────────────────────────────────────┘ ║
╚════════════════════════════════════════════════════════╝
│
┌───────────────┴────────────────┐
│ score de confianza │
└──────┬───────────────┬─────────┘
ALTA │ │ BAJA
▼ ▼
╔══════════════════════╗ ╔══════════════════════╗
║ S1 (Holded) ║ ║ S1 (Dashboard) ║
║ Auto-contabilizado ║ ║ "Planes pendientes" ║
║ + link al plan ║ ║ contable revisa, ║
║ + tag estructural ║ ║ edita o aprueba ║
╚══════════════════════╝ ╚══════════════════════╝
│ │
└───────┬───────┘
▼
╔════════════════════════════════════════════════════════╗
║ T4 — REVERSE SYNC ║
║ Conector · monitoriza Holded · propaga señal ║
║ ║
║ Poll de approved/edited/commented ║
║ ↓ ║
║ Señal structured ──▶ Plan Store (invalidar regla?) ║
║ ──▶ Motor (recalibrar memory?) ║
╚════════════════════════════════════════════════════════╝
│
▼
╔════════════════════════════════════════════════════════╗
║ T3 — CALCIFICATION ENGINE ║
║ SoA · observa · propone · promueve ║
║ ║
║ Recolecta evidencia (plan ejecutado + feedback) ║
║ ↓ ║
║ Detecta patrones (N repeticiones sin edición) ║
║ ↓ ║
║ Propone regla a Intelia ops (gate humano) ║
║ ↓ ║
║ Período shadow contra agente nuevo ║
║ ↓ ║
║ Promueve a Plan Store (tipo según nivel: M1 o I1) ║
╚════════════════════════════════════════════════════════╝Y dos transversales que envuelven todo:
workflow_id, observabilidad.| ID | Componente | Tipo | Responsabilidad en una frase | Doc |
|---|---|---|---|---|
| M1 | Motor | SoA portable | Decidir qué quiere contabilizarse, sin saber qué ERP recibe. | m1-motor.md |
| I1 | Integrador Holded | Conector + SoR pequeño propio | Traducir intent a operaciones Holded, ejecutarlas, validar resultado. | i1-integrator-holded.md |
| T3 | Calcification Engine | SoA + escritura a SoR pequeño | Observar patrones recurrentes en planes ejecutados y convertirlos en reglas. | t3-calcification.md |
| T4 | Reverse Sync | Conector + SoA pequeño | Capturar señal del SoR ajeno (ediciones del contable) y propagarla al SoA. | t4-reverse-sync.md |
| S1 | UX Híbrido | Surface | Dashboard Intelia para baja confianza + Holded como interfaz para alta confianza. | s1-ux-hybrid.md |
| TX | Signals + Temporal | Transversal | Plumería: durabilidad, observabilidad, projection de eventos. | tx-signals-temporal.md |
Notas de organización:
DocumentFacts.StandaloneIntent + InternalAccountingPlan + ContextualDecision + ValidationResult: PASSED.(intent_signature, erp_context_signature). Match → devuelve ExecutionPlan cached + confidence: 0.95.observed_state vía readback.PlanState declarado vs observed_state. PASSED.intelia-plan-<id>. Contable lo ve en su flujo habitual.PLAN_CONFIRMED_BY_INACTION.Tiempo total: 3-10s. Coste LLM: solo el de M1 (3 calls en Fase 2 si las decisiones no están calcificadas en M1).
1-2. Como en happy path. 3. I1.Plan Store: miss. Llama I1.Plan Generator (agente LLM con guías Holded + tool wrapper). 4. Plan Generator razona: lee estado Holded, consulta guías, produce ExecutionPlan + confidence: 0.55 + reasoning_trace. 5. Confianza por debajo de umbral → S1.Dashboard "Planes pendientes". Plan NO se ejecuta. 6. Contable abre el dashboard, ve el plan + factura + reasoning, aprueba sin tocar. 7. I1.Executor ejecuta el plan aprobado. Captura readback. Final Validation OK. 8. T3: registra evidencia de aprobación. Suma a contador del patrón. 9. Tras 5 aprobaciones del mismo patrón sin edición, T3 propone regla a Intelia ops. 10. Intelia ops aprueba. Regla entra en shadow mode 14 días: cada match nuevo se sirve por agente, se compara con la regla propuesta, y si match → contadores positivos. 11. Tras shadow OK, regla promueve a Plan Store. Próximo documento del patrón = caso happy path.
Tiempo total caso cold: 15-30s + tiempo de revisión del contable. Coste LLM: M1 + Plan Generator + interpretación de evidencia en T3.
1-7. Como happy path. 8. T4 detecta que el contable cambió la cuenta 629... por 623... en Holded a los 3 días. 9. T4 emite signal estructurado: EDITED_BY_HUMAN { plan_id, field: account_code, old: "629", new: "623" }. 10. T4 opcionalmente: añade comment en Holded [Intelia] ¿Razón del cambio? Responde con #criterio, #extraccion, #bug, o ignora. 11. Si el contable responde #criterio → signal CRITERION_CHANGED → Intelia ops revisa si toca recalibrar la regla en Plan Store o el LLM guide en M1. 12. Si no responde, el signal queda como evidencia de baja confianza del patrón. T3 marca la regla para re-shadow si N edits superan umbral.
| Fase | Volumen alta-confianza | UX dominante | Coste LLM por documento |
|---|---|---|---|
| Mes 0 (onboarding) | 0-20% | Dashboard Intelia (contable revisa todo) | Alto: M1 + Plan Generator en cada doc |
| Mes 1-3 | 30-50% | Mezcla: simple va por Holded, nuevo se revisa | Medio: Plan Generator en ~50% de docs |
| Mes 6 | 70-80% | Contable abre Intelia ocasionalmente | Bajo: Plan Generator en ~25% |
| Mes 12+ | 85-95% | Contable trabaja casi solo en Holded | Marginal: Plan Generator solo en casos edge |
Cliente nuevo en sector X no arranca desde cero. T3 mantiene un repositorio de calcificaciones por sector / arquetipo de empresa. Al onboardear, el sistema clona las reglas de "cliente mediano de hostelería" como starter pack. Esas reglas tienen marca de origen: bootstrap_from: {client_id: X, sector: hosteleria}.
Las reglas bootstrapped tienen menor confianza inicial (0.7 en lugar de 0.95). Los primeros 10 documentos de cada patrón pasan por dashboard antes de ascender a alta confianza por client específico. Es calcificación con prior + posterior bayesiano.
Esta es la ventaja diferencial del producto: cliente N+1 onboardea más rápido que cliente N. Producto compone economía de escala IA-first sin depender del prompt-en-runtime.
| Surface | Latencia | Control del contable | Señal para T3 |
|---|---|---|---|
| Holded auto (alta confianza) | Inmediato | Pasivo (reacciona si ve algo raro) | Inactividad N días o edición |
| Dashboard Intelia (baja confianza) | Espera al contable | Activo (aprueba o edita explícito) | Aprobación explícita |
Auto es mejor UX a largo plazo; dashboard es mejor señal de aprendizaje. El sistema vive en el continuo y se mueve hacia auto con la madurez del cliente. No hay versión "perfecta" — hay calibración constante del umbral de confianza.
El agente LLM como Plan Generator da cobertura del 100% de casos (incluyendo edge cases que un sistema rule-based no cubriría) al coste de:
T3 cierra este gap: calcificación convierte los patrones recurrentes en reglas deterministas, reduciendo la dependencia del agente con el tiempo. Pero el agente nunca desaparece: siempre hay casos edge.
Mitigación: tipar el ExecutionPlan como Pydantic schema estricto. Aunque el agente genere planes distintos, el shape del plan es comparable y verificable. Y al ser el ExecutionPlan declarativo (no imperative), dos planes funcionalmente equivalentes pero textualmente distintos pueden compararse.
Usar Holded como surface para alta confianza es la mejor UX para el contable (no aprende otra app), pero la señal "no editó en N días" es más débil que "aprobó explícitamente en dashboard". El sistema acepta esta pérdida de calidad de señal a cambio de UX.
Mitigación parcial: T4 lee comments del contable en Holded. Si el contable dejó un comment al lado del documento, eso es señal explícita. Pero la mayoría de contables no comentan, comportamiento default es silencio.
V3 no construye el esperanto universal (Fase 6 agnóstica del target documentado V2). Cada ERP es un integrador completo (I_<erp>/) con su Plan Generator + Plan Store + Executor + Final Validation. Cuando llegue Sage:
I2 — Integrador Sage desde cero como paquete paralelo a I1.Trade-off: más LOC por ERP que en una abstracción universal, pero cero abstracciones prematuras. La regla del 3 dicta: cuando llegue el tercer integrador, si patrones reales emergen, entonces se extrae lo común a posteriori.
Bootstrap cruzado (cliente N+1 arranca con reglas de N) acelera onboarding pero arrastra sesgos de los clientes existentes. Si todos los clientes en bootstrap_from: hosteleria son mediterráneos, un cliente nuevo en hostelería pero del País Vasco puede heredar criterios que no aplican.
Mitigación: las reglas bootstrapped tienen confianza reducida + período shadow obligatorio (primeros 10 docs por patrón pasan por dashboard). El cliente nuevo "validate" o "rechazar" cada regla heredada en sus primeras semanas.
Open questions que V3 conceptual reconoce y no resuelve:
Schema del intent_signature que usa Plan Store para lookup. ¿Hash determinista de qué subconjunto de StandaloneIntent? Si incluimos demasiado, los hits son escasos. Si incluimos poco, las reglas calcifican sobre patrones demasiado amplios y dan planes incorrectos.
Cadencia de polling para T4 Reverse Sync. Cada 15 min es estándar pero ¿es demasiado caro a escala? ¿Se puede dividir en polling rápido para documentos recientes + polling lento para histórico?
Política de invalidación cuando cambian guías Holded. Si las guías que el Plan Generator consume cambian, ¿qué reglas calcificadas se invalidan automáticamente? ¿Se versiona el guide y cada regla recuerda su guide_version?
Definición operativa de "alta confianza". ¿Score numérico simple? ¿Función de (confianza del Plan Generator + edad de la regla calcificada + N veces aprobada)? Tipos de input edge tendrán que tener thresholds distintos.
Concurrencia con el contable. Si el contable edita un documento Holded mientras Intelia está ejecutando un cambio sobre ese mismo documento, ¿qué pasa? T4 capturará el delta, pero podemos haber sobreescrito el cambio del contable. ¿Lock optimista? ¿Lease + retry?
Reverse-sync de comentarios libres del contable. Si el contable comenta "esto es un caso especial, no lo trates con regla general" — ¿cómo lo procesa T4? ¿LLM extrae intent? ¿Humano (Intelia ops) revisa cola de comments?
Métricas de salud del sistema. ¿Qué KPIs operacionales se necesitan? Propuesta: auto_rate (% docs alta confianza), latency_p95, cost_llm_per_doc, correction_rate (% editados post-ejecución), calcification_rate (% docs servidos por regla vs agente), bootstrap_recall (% reglas heredadas aceptadas).
Multi-tax-entity por team. Si un team tiene N tax entities con configuraciones fiscales distintas, ¿T3 calcifica por team o por tax_entity? Probablemente por tax_entity, pero el bootstrap cruzado puede beneficiarse de patrones a nivel team.
| Dimensión | V2 Target (documentado) | V3 (este doc) |
|---|---|---|
| Esperanto universal (Fase 6 + Fase 7) | Presente | Eliminado. Cada integrador es paquete completo. |
| Plan Generator | Determinista (hand-coded en holded_write_planner.py) |
Agente LLM con guías + tool wrapper. |
| Calcificación | confidence_calcified flag implícito |
T3 componente de primera clase con shadow + gate humano. |
| Reverse-sync | Ausente | T4 componente de primera clase. |
| Cliente nuevo | Recibe reglas hard-coded uniformes | Bootstrap cruzado desde clientes similares. |
| Frontera de aprobación | Implícita (campo approved de Holded) |
Híbrida: dashboard Intelia para baja confianza + Holded para alta. |
account_lines |
SoR Intelia paralelo al ledger Holded | Eliminado o sombra explícita. La verdad vive en el ERP. |
V3 no es una optimización de V2 Target — es una arquitectura distinta que asume distinto modelo mental: la IA no proyecta a un ERP abstracto; la IA opera directamente sobre el ERP concreto que existe, y el sistema aprende del feedback orgánico del contable. El "abstracto" emerge a posteriori vía calcificación cruzada cuando hay N ERPs reales.
| Empieza por... | Si tu objetivo es... |
|---|---|
m1-motor.md |
Entender qué decide Intelia y cómo se separa de la integración |
i1-integrator-holded.md |
Entender cómo se gestiona la cicatriz Holded sin contaminar el SoA |
t3-calcification.md |
Entender el loop de aprendizaje y por qué es componente de primera clase |
t4-reverse-sync.md |
Entender cómo el SoA aprende del criterio del contable |
s1-ux-hybrid.md |
Entender el bootstrap híbrido (dashboard → Holded auto) |
tx-signals-temporal.md |
Entender la plumería durable y observable |
Versión Claude. La versión paralela de Codex está en ../v3-conceptual-codex/. Síntesis final cuando ambas estén completas.