Categoría: Surface (no es ni SoA ni SoR; es la cara visible al contable) Estado: Propio sano (cuando se implemente con disciplina del modelo híbrido) Tamaño esperado: ~3-4k LOC (frontend + backend del dashboard) + integración Holded como surface
Ofrecer al contable dos caminos para revisar la decisión de Intelia según la confianza:
S1 es la fuente más fuerte de evidence para T3 (aprobación explícita > inacción).
Vista principal del contable cuando un plan necesita revisión.
┌──────────────────────────────────────────────────────────────────────┐
│ Planes pendientes de revisión │
│ [12] ⏳ Esperando aprobación │
├──────────────────────────────────────────────────────────────────────┤
│ │
│ ┌─── DOCUMENTO ────────────────┐ ┌─── PLAN PROPUESTO ──────────┐ │
│ │ Factura Glovo #G-12345 │ │ Cuenta: 629800 (Gastos │ │
│ │ Fecha: 15 may 2026 │ │ generales) │ │
│ │ Importe: 245,80€ │ │ Imputación: CTR (100%) │ │
│ │ [ver PDF original] │ │ IVA: deducible 100% │ │
│ │ │ │ IRPF: no aplica │ │
│ │ Provider: Glovo S.A. │ │ │ │
│ │ Histórico: 12 facturas │ │ Operaciones Holded: │ │
│ │ prev. todas en 629800 │ │ 1. Ensure contact Glovo │ │
│ │ │ │ 2. Create purchase │ │
│ │ ⚠ Provider nuevo este │ │ 3. Add tags ["duda-cuenta"]│ │
│ │ mes — confianza 0.62 │ │ │ │
│ └───────────────────────────────┘ │ Razonamiento del agente: │ │
│ │ "Glovo aparece 12 veces en │ │
│ Acciones: │ tu historial, todas en │ │
│ [✓ Aprobar] [✎ Editar plan] │ 629800. Sin embargo, el │ │
│ [✗ Rechazar y re-decidir] │ importe esta vez es 4x │ │
│ [💬 Comentar] │ superior — recomiendo │ │
│ │ revisión humana." │ │
│ │ │ │
│ │ served_by: agent_v3.4 │ │
│ │ confidence: 0.62 │ │
│ └──────────────────────────────┘ │
│ │
└──────────────────────────────────────────────────────────────────────┘
| Acción | Qué hace | Evidence emitida a T3 |
|---|---|---|
| Aprobar | Se ejecuta el plan tal cual. Documento se contabiliza en Holded | EXPLICIT_APPROVAL (peso 1.0) |
| Editar plan | El contable modifica el plan (cambio de cuenta, imputación, etc.) y luego ejecuta | HUMAN_EDITED_PLAN_IN_DASHBOARD con delta (peso negativo) |
| Rechazar y re-decidir | El plan se descarta, M1 + I1 vuelven a procesarlo desde cero (puede ser útil si el contable cambió datos del documento) | PLAN_REJECTED (peso negativo grande) |
| Comentar | El contable deja un comment libre. Se procesa con LLM para extraer intent | Signal procesado vía T4-extractor |
Para clientes maduros con muchos docs de baja confianza similares, bulk approve permite aprobar N planes a la vez si todos tienen el mismo intent_signature (e.g. 20 facturas de Amazon con plans idénticos). Pero un solo click NO cuenta como N aprobaciones explícitas — T3 considera bulk approve como evidencia más débil (peso 0.5 por doc) porque el contable no las miró individualmente.
Cuando un plan se ejecuta automáticamente, Intelia escribe en Holded:
intelia-plan-id-<uuid>
Tag fijo, único por documento, parseable. Permite:
El cliente NO elige una surface. El sistema decide automáticamente por documento:
confianza del plan >= 0.85 (cliente maduro) → auto-Holded
confianza < 0.85 → dashboard Intelia
El umbral 0.85 es per-cliente y per-archetype. Cliente nuevo: arranca con umbral 0.95 (casi todo a dashboard). Mes 6: umbral 0.80 (más cosas a auto). El sistema aprende qué umbrales son seguros para cada cliente vía T3.
El contable ve en su dashboard Intelia:
"En último mes: 247 documentos procesados. 195 automáticos (79%). 52 revisados aquí (21%)."
Y un timeline: "Hace 3 meses, revisabas 65% de los documentos; ahora 21%."
El cliente firma. Intelia inicia el proceso con un modo guiado:
Confianza por archetype + por proveedor se va construyendo. Reglas bootstrapped del archetype del cliente se validan. Umbral baja gradualmente.
Para cada proveedor/patrón con >10 aprobaciones consistentes, umbral local es 0.85. Documentos similares pasan a auto-Holded.
Mes 6 esperado: 70% auto, 30% dashboard.
| Riesgo | Mitigación |
|---|---|
| Contable nunca abre dashboard → planes acumulan sin revisión | Notificaciones email/Slack si planes pendientes >20. Si llega a >50, escala a Intelia ops |
| Contable hace bulk approve sin mirar → calcificación con sesgo | Bulk approve marca planes con peso 0.5 en evidence (vs 1.0 de approval individual) |
| Contable edita planes pero no comenta razón → T3 no sabe por qué | Tras 3 ediciones sin comment, dashboard sugiere comentario inline: "Has editado 3 veces consecutivas. ¿Quieres dejar una nota?" |
| Comments del contable en Holded son ambiguos → T4 misinterpreta | Confidence threshold + low_confidence_comments para review humano |
| El umbral de confianza es muy bajo y se ejecutan auto cosas que no deberían | Métrica correction_rate por umbral. Si correction_rate sube post-cambio umbral, retroceder umbral |
| Surface duplicada (Holded + Intelia) confunde al contable | UX clara: "tu trabajo principal sigue siendo Holded. Aquí solo cuando Intelia tiene dudas." |
Patología 1: el contable nunca usa el dashboard. Asume que Intelia "ya lo hace bien" y nunca revisa los planes pendientes. La cola crece. Mitigación: SLA por defecto: si plan pendiente >7 días sin revisión, Intelia ops es notificada para empujar al cliente. Si el cliente realmente no quiere revisar, se puede subir umbral artificialmente y todo va auto (con peor calidad de calcificación pero al menos no se bloquean documentos).
Patología 2: el contable se acostumbra al dashboard y nunca migra a auto. Algunos contables preferirán "ver todo siempre" en lugar de confiar en auto. Eso es un cliente que paga por revisar; sub-optimal económicamente pero válido. Mitigación: respetar elección. Pero documentar el coste (más LLM por documento) y eventualmente reflejarlo en pricing.
Patología 3: Holded auto-contabiliza algo mal y el contable se entera tarde. Documento se ejecutó automáticamente con error sutil; el contable no lo vio hasta el cierre fiscal. Mitigación: T4 con polling caliente detecta cualquier edición; T3 con métricas de drift detecta patrones; reportes mensuales muestran al cliente "lo que Intelia ha hecho automático" para revisión.
Patología 4: bulk approve se vuelve hábito y la evidence se infla artificialmente. Contable abre dashboard, hace "select all" + approve todos los días sin mirar. T3 ve 50 aprovaciones/día como señal fortísima, cuando es ruido. Mitigación: detect-pattern de bulk approve recurrente. Si un contable hace bulk approve >5 días seguidos, dashboard exige "abrir y revisar individualmente al menos 3" antes del próximo bulk.
UX del editor de plans en dashboard. ¿El contable edita campos sueltos (cuenta, imputación) o ve el ExecutionPlan raw? Probablemente lo primero, con vista "advanced" para el segundo.
¿Permitimos que el contable edite el StandaloneIntent (lo que decidió M1) en lugar del ExecutionPlan (lo que I1 genera)? Filosóficamente, sí: si el contable cambia "deducible 100%" a "deducible 50%", debería propagarse al motor, no solo al plan Holded. Implementación: 2 vistas, "lo semántico" y "lo Holded".
¿Hay versión "modo experto" para contables que quieran control granular? Algunos van a querer ver el ExecutionPlan completo, otros solo el resumen humano. UX progresiva.
Móvil. ¿El dashboard Intelia tiene versión móvil? Contable revisando en metro. Vale la pena MVP web-first y móvil después.
Notificaciones en Holded vs notificaciones en Intelia. Si plan pendiente, ¿se notifica al contable en su Holded (vía comment o tag) o en Intelia dashboard? Probablemente ambos para alta importance.
Acceso múltiple contables al mismo team. Si team tiene 3 contables compartiendo dashboard, ¿quién ve qué? ¿Se reparten o cualquiera puede ver/aprobar?
| Métrica | Target |
|---|---|
s1_auto_ratio_per_team |
0% → 20% mes 1 → 70% mes 6 → 90% mes 12 |
s1_dashboard_review_latency_p95_per_team |
<24h (cliente revisa dentro de 24h promedio) |
s1_planes_pendientes_cola_max_per_team |
<20. Si sube, cliente desatendiendo |
s1_bulk_approve_ratio |
<30% de aprobaciones via bulk. Si alto, calcificación pierde calidad |
s1_explicit_approval_rate |
>70% de planes pendientes son aprobados sin editar |
s1_edit_rate |
<20%. Si alto, agente da planes mediocres |
s1_rejection_rate |
<5%. Si alto, agente da planes inválidos |
t3-calcification.md — principal consumidor de evidencet4-reverse-sync.md — captura signals desde Holded surface
Comment con link
Comment dedupado por hash (mismo decision_hash → no se reposta).