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 implementa con disciplina del modelo híbrido. Síntesis de: Claude S1 + Codex S1

1. Responsabilidad

S1 define dónde trabaja el humano y cómo interviene en el pipeline. En V3 no hay una única interfaz. Hay una UX híbrida con dos superficies:

Pending Plans (Intelia Dashboard) para baja confianza, onboarding, excepciones, edición asistida, aprobación explícita y explicación.
Holded como interfaz para alta confianza y trabajo diario de contables maduros, con trazabilidad hacia Intelia mediante comment, tag estructural y enlace al plan.

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

2. NO es su responsabilidad

No decide contabilidad automáticamente. Presenta, captura y enruta. Si un humano cambia una cuenta, esa corrección debe volver a M1 como señal semántica, no quedarse como mutación local de UI.
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.
No es otra herramienta contable completa. No debe competir con Holded. Es bandeja de decisión, explicación y excepción.

3. Pending Plans (Dashboard Intelia)

Cola de planes que requieren intervención antes de escribir o consolidar.

Layout conceptual

Vista por documento:

Izquierda: documento original (PDF, factura, contexto).
Centro: Internal Plan (decisión semántica de M1) + ExecutionPlan (traducción de I1) — capas separadas, navegables.
Derecha: panel de acción + razonamiento del agente + signals + provider history.

Acciones del contable

Acción	Qué hace	Evidence emitida a T3
Aprobar	Plan se ejecuta tal cual. Documento se contabiliza en Holded	`EXPLICIT_APPROVAL` (peso 1.0)
Editar plan semántico	Cambia cuenta, imputación, deducibilidad → vuelve a M1 como señal	`HUMAN_EDITED_SEMANTIC` con delta (peso negativo para regla M1)
Editar plan de integración	Cambia traducción Holded (ej. tipo de tag, comentario) → afecta solo I1	`HUMAN_EDITED_TRANSLATION` (peso negativo para regla I1)
Rechazar y re-decidir	Plan se descarta, M1+I1 reprocesa desde cero	`PLAN_REJECTED` (peso negativo grande)
Comentar	Deja comment libre → LLM extrae intent	Signal procesado vía T4-extractor
Bulk approve	N planes a la vez con mismo `intent_signature`	Cada uno con peso reducido 0.5

Filtros y ordenación

Por team / tax_entity.
Por proveedor.
Por antigüedad.
Por confianza del plan (e.g. solo <0.6 para atención prioritaria).
Por origen (regla calcificada vs agente vs bootstrap).

Vista doble: semántica vs operativa

Permite que el contable decida en qué nivel actúa:

Modo simple: ve solo "cuenta + imputación + deducibilidad" → edita semánticamente.
Modo avanzado: ve el ExecutionPlan completo (operaciones Holded ordenadas, tags, comments) → puede editar la traducción.

Si el contable cambia un campo semántico (cuenta, deducibilidad), se propaga a M1 y se re-genera el ExecutionPlan. Si cambia un campo operativo (e.g. orden de operaciones), solo afecta a I1.

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.

Comment con link y razonamiento

[Intelia] Plan ID: abc-123-...
Cuenta: 629800 (Gastos generales)
Razón: Histórico de Glovo · regla calcificada R-1234
Ver detalle: https://intelia.app/plans/abc-123

Tags aplicados: [duda-cuenta] (provider nuevo en último mes)

(Si hay cambios o dudas, edita en Holded y nosotros lo procesamos.
 También puedes comentar #criterio_cambiado, #extraccion_incorrecta, #bug_intelia.)

Comment dedupado por hash. Si el plan no cambia, no se reposta.

Tags semánticos derivados de signals

Adicionalmente al intelia-plan-id-*:

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

T4 los lee desde el otro lado para refinar interpretación.

5. Routing por madurez — matriz, no estado global

La madurez no es un booleano de cliente. Debe evaluarse por isla:

Por tipo de documento (factura recurrente vs gasto raro).
Por proveedor (Glovo conocido vs proveedor nuevo).
Por importe (umbrales que mueven a revisión).
Por periodo (final de trimestre con mayor cuidado).
Por regla aplicada (calcificada estable vs candidate).
Por edición reciente (si el contable editó este patrón hace 7 días, baja confianza).

confianza por (cliente, isla) >= umbral → auto-Holded
confianza por (cliente, isla) < umbral → dashboard Intelia

Umbrales per-cliente y per-archetype, ajustables por Intelia ops. Cliente nuevo: arranca con umbral 0.95 (casi todo a dashboard). Mes 6: umbral 0.80 (más auto). El sistema aprende qué umbrales son seguros via T3.

6. Onboarding del cliente

Día 0

Modo guiado:

TODO va por dashboard.
Umbral = 1.0 (nada auto).
Contable revisa cada plan, aprueba o edita.
T3 recoge evidencia abundante.

Mes 1-3

Confianza por archetype + por proveedor se construye. Reglas bootstrapped se validan. Umbral baja gradualmente.

Mes 3+

Para cada (proveedor, patrón) con >10 aprobaciones consistentes, umbral local = 0.85. Documentos similares pasan a auto-Holded.

Mes 6: 70% auto, 30% dashboard. Mes 12: 85-95% auto.

7. Boundaries

Con M1

S1 muestra la decisión semántica sin permitir mutaciones invisibles. Si el usuario cambia cuenta, impuesto, proyecto semántico o fecha de devengo:

Debe registrarse como señal semántica.
Debe versionarse.
Debe propagarse a M1 (que puede re-evaluar) y a T3 (evidencia negativa para regla aplicada).

Con I1

Si el usuario cambia algo operativo (orden de operaciones, tag específico, traducción Holded):

Se queda en el ExecutionPlan editado.
Genera señal negativa para regla de traducción en I1.
NO propaga a M1.

Con T3

S1 es el gate humano de T3:

Aprobaciones explícitas → evidencia positiva fuerte.
Ediciones → evidencia negativa.
Bulk approve → peso reducido.

Con T4

S1 actúa antes de escribir; T4 actúa después. Ambos producen Learning Signals. La diferencia: S1 captura intención humana explícita; T4 captura intención humana implícita (lo que hizo en Holded).

8. Riesgos y mitigaciones

Riesgo	Mitigación
Contable nunca abre dashboard → planes acumulan	Notificaciones email/Slack si pendientes >20. Si >50, escala a Intelia ops
Doble trabajo (revisar en Intelia + revisar en Holded)	UX clara: "tu trabajo principal sigue siendo Holded. Aquí solo cuando Intelia tiene dudas"
Contable hace bulk approve sin mirar → calcificación sesgada	Bulk approve con peso 0.5 (vs 1.0 individual). Detect pattern recurrente
Edición silenciosa en UI no propaga a M1	Política dura: cualquier cambio semántico en dashboard genera señal a M1; el plan se re-genera o versiona
Comments ambiguos del contable en Holded	T4 los procesa con LLM; confidence threshold; low_confidence_comments queda para review humano
Umbral de confianza muy bajo → ejecuciones auto erróneas	Métrica `correction_rate` por umbral. Si sube post-cambio, retroceder umbral

9. Lo que puede salir mal

Patología 1: el contable nunca usa el dashboard. Asume que Intelia "ya lo hace bien" y nunca revisa. Cola crece. Mitigación: SLA por defecto + notificación a ops si pendiente >7 días. Si cliente realmente no quiere revisar, subir umbral artificial (todo va auto con peor calcificación pero no bloqueado).

Patología 2: dashboard se convierte en otra herramienta contable completa. No debe competir con Holded. Si el contable termina haciendo TODO en Intelia (incluso para clientes maduros), algo está mal en routing. Mitigación: medir % del tiempo del contable en Intelia vs Holded. Si >40% para clientes maduros, revisar umbrales.

Patología 3: bulk approve se vuelve hábito. Contable abre dashboard, hace "select all" + approve cada día sin mirar. Evidence se infla artificialmente. Mitigación: detect-pattern. Si bulk approve >5 días seguidos, dashboard exige "abrir y revisar individualmente al menos 3" antes del próximo bulk.

Patología 4: la UX queda partida. Algunas acciones se revisan en Intelia, otras en Holded sin trazabilidad clara. Contable pierde confianza. Mitigación: cada objeto escrito en Holded debe tener enlace/tag a Intelia. Dashboard debe mostrar "qué pasó después" en Holded para cada plan.

Patología 5: edición en dashboard sin propagación. Contable cambia cuenta en Pending Plans, el plan se ejecuta con la cuenta nueva, pero M1 no se entera. Próxima factura del mismo proveedor → mismo error. Mitigación: política dura — cualquier edición semántica dispara señal a M1 + recálculo del provider history.

10. Métricas operacionales

Métrica	Target
`s1_auto_ratio_per_team`	0% mes 0 → 70% mes 6 → 90% mes 12
`s1_dashboard_review_latency_p95`	<24h por contable
`s1_planes_pendientes_cola_max_per_team`	<20. Si sube, cliente desatendiendo
`s1_bulk_approve_ratio`	<30%. Si alto, calcificación pierde calidad
`s1_explicit_approval_rate`	>70% de pendientes aprobados sin editar
`s1_edit_rate`	<20%. Si alto, agente da planes mediocres
`s1_rejection_rate`	<5%. Si alto, agente da planes inválidos

11. Open questions

¿Qué campos son editables en Pending Plans sin abrir modo avanzado?
¿Permitimos editar el Internal Plan (M1) o solo el ExecutionPlan (I1) por defecto?
¿Vista móvil del dashboard? Probablemente fase 2.
Notificaciones: ¿email/Slack/in-Holded-comment? Triple, según importancia.
Multi-contable per team: ¿quién ve qué? ¿Cualquiera puede aprobar?
¿Modo "experto" para contables que quieran control granular del ExecutionPlan?
¿Dashboard tiene "modo auditoría" para revisar lo ya hecho?

Síntesis. Detalle granular en versiones originales.