s1-ux-hybrid

S1 — UX Híbrido (Dashboard Intelia + Holded como interfaz)

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


1. Responsabilidad

Ofrecer al contable dos caminos para revisar la decisión de Intelia según la confianza:

  • Alta confianza → documento auto-contabilizado en Holded; contable lo ve en su flujo habitual; link al plan + tag estructural permiten profundizar si quiere.
  • Baja confianza → documento aparece en Dashboard Intelia "Planes pendientes"; contable revisa, edita o aprueba antes de que se ejecute.

S1 es la fuente más fuerte de evidence para T3 (aprobación explícita > inacción).

2. NO es su responsabilidad

  • No decide la confianza. Eso lo decide el Plan Generator de I1.
  • No persiste verdad contable. El estado de aprobación de planes es SoR pequeño propio de Intelia; el ledger sigue en Holded.
  • No reemplaza Holded como herramienta del contable. Si todo va auto, el contable no necesita abrir Intelia.

3. El dashboard Intelia "Planes pendientes"

Vista principal del contable cuando un plan necesita revisión.

Layout

┌──────────────────────────────────────────────────────────────────────┐
│  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            │  │
│                                     └──────────────────────────────┘  │
│                                                                        │
└──────────────────────────────────────────────────────────────────────┘

Acciones

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

Filtros y ordenación

  • Por team / tax_entity.
  • Por proveedor.
  • Por antigüedad del documento.
  • Por confianza del plan (e.g. solo los <0.6 que merecen atención prioritaria).

Bulk approve

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.

4. Holded como interfaz para alta confianza

Cuando un plan se ejecuta automáticamente, Intelia escribe en Holded:

Tag estructural

intelia-plan-id-<uuid>

Tag fijo, único por documento, parseable. Permite:

  • Buscar documentos por su plan.
  • Filtrar "todos los procesados por Intelia con regla X" en Holded.
  • T4 lo usa como ancla de monitoring.

Tags semánticos de revisión

Adicionalmente al intelia-plan-id-*, el plan puede llevar tags semánticos derivados de los signals:

  • duda-cuenta (Slot 1 baja confianza)
  • duda-imputacion (Slot 2 baja confianza)
  • aviso-cuenta-generica (fallback de cuenta)
  • error-cuenta-invalida (LLM dio código que no existe)
  • etc.

Estos son los mismos del target documentado V2. T4 los lee desde el otro lado.

5. Transición entre surfaces

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.

Indicador en dashboard

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%."

6. Onboarding del cliente

Día 0

El cliente firma. Intelia inicia el proceso con un modo guiado:

  • Primer mes: TODO va por dashboard. Umbral = 1.0 (nada se auto-ejecuta).
  • Contable revisa cada plan. Aprueba o edita.
  • T3 recoge evidencia abundante.

Mes 1-3

Confianza por archetype + por proveedor se va construyendo. Reglas bootstrapped del archetype del cliente se validan. Umbral baja gradualmente.

Mes 3+

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.

7. Riesgos arquitectónicos y mitigaciones

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."

8. Lo que puede salir mal

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.

9. Open questions

  1. 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.

  2. ¿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".

  3. ¿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.

  4. 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.

  5. 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.

  6. 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?

10. Métricas operacionales

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

Próximos docs