Categoría: SoA portable Estado: Propio sano Síntesis de: Claude M1 + Codex M1
M1 es el núcleo semántico de V3. Decide qué debe ocurrir contablemente a partir de hechos observados, contexto histórico y política de cliente — sin asumir cómo se materializará esa decisión en Holded u otro ERP.
Su output es un Internal Plan: intención contable explicada, validada y con confianza calibrada. Debe responder:
M1 es el activo a largo plazo del producto. Sobrevive a cualquier cambio de ERP. Si una decisión requiere entender el negocio del cliente, el proveedor, la sustancia económica del documento, el histórico de aprobaciones o el criterio contable, pertenece a M1.
El input principal es un Fact Bundle con cinco secciones, cada una con propietario, frescura, procedencia y autoridad explícitas.
extracted — datos del documentoProveedor, NIF, dirección, país, fechas (emisión/operación/vencimiento), importes, impuestos, retenciones, moneda, líneas textuales, conceptos detectados, evidencias OCR, clasificación documental, confianza de extracción.
Estos hechos no son automáticamente verdad. Un dato extraído puede estar mal, incompleto o contradicho por el ERP.
memory — contexto históricoCriterios previos por cliente, decisiones anteriores aprobadas, reglas semánticas activas, patrones por proveedor, excepciones conocidas, instrucciones internas, memoria sectorial.
La memoria debe estar versionada y atribuida. No todo recuerdo tiene el mismo peso.
erp_snapshot — estado del SoR ajenoExistencia del proveedor/contacto, cuentas disponibles, documentos similares, asientos relacionados, tags/proyectos/cost centers existentes, periodo contable, estado de conciliación, posibles duplicados.
M1 usa el snapshot para contexto y constraints, no para copiar una contabilidad paralela.
human_context — señales humanasAprobación anterior, edición anterior, comentario de contable, instrucción del cliente, revisión de ops, motivo de rechazo.
El origen humano no implica autoridad absoluta. Un comentario ambiguo puede necesitar interpretación y validación.
runtime — datos de ejecuciónEquipo, periodo, fecha de procesamiento, feature flags, entorno, umbrales de automatización, política de cliente, nivel de madurez.
M1 combina determinismo y LLMs en una estructura clara.
Antes de razonar, M1 normaliza el Fact Bundle:
No fusiona todos los hechos en un único objeto plano. Preserva owner.
Revisa el documento y los hechos extraídos. Su tarea es mejorar comprensión, no decidir contabilidad final.
Produce: resumen económico, conceptos relevantes, dudas de extracción, señales de rareza, posibles errores OCR, datos que requieren confirmación.
Propone la decisión semántica. Ve contexto de cliente, histórico, memoria y resultado del intérprete factual.
Produce: cuenta o familia de cuenta, tratamiento fiscal, imputación, política aplicada, confianza, razones, condiciones de automatización.
Intenta romper la decisión. Busca contradicción con hechos, overfitting al proveedor, uso indebido de memoria, confianza injustificada, riesgo fiscal, señal de duplicado, caso que debería ir a humano.
El crítico no sustituye validaciones determinísticas. Las complementa.
Corre antes y después de los LLMs:
Cuando falla una validación determinística fuerte, M1 no debe "arreglar" con LLM. Debe bloquear o pedir revisión.
Tipo de documento/evento, tratamiento contable, tratamiento fiscal, cuenta propuesta o rango aceptable, contrapartidas esperadas, dimensión analítica, devengo, elegibilidad para automatización.
Hechos clave, precedentes usados, instrucciones aplicadas, conflictos resueltos, alternativas consideradas, incertidumbres.
No es cadena de pensamiento libre. Es explicación auditada y legible para producto, ops y contabilidad.
Coherencia de importes, moneda, fechas, impuestos, duplicados, compatibilidad con política, consistencia con histórico, motivos de bloqueo.
M1 recomienda routing, pero no ejecuta:
M1 puede imponer restricciones que I1 debe respetar:
La frontera M1/I1 es el Internal Plan. Casos concretos:
| M1 puede decir | M1 NO puede decir |
|---|---|
| "registrar factura de proveedor como gasto 623 con IVA soportado deducible" | "llamar a /api/invoicing/v1/documents" |
| "requiere proyecto X si existe en ERP" | "crear contacto Holded con campo customId" |
| "no automatizar si el proveedor no coincide con NIF" | "usar tag Holded INTELIA_AUTO" |
| "debe conservar fecha de operación" | "aplicar workaround de factura rectificativa en dos pasos" |
| "confianza 0.92 por patrón aprobado" | "insertar este JSON" |
Si I1 necesita cambiar cuenta, impuesto o criterio contable para poder ejecutar en Holded, debe devolver conflicto a M1/S1, no corregir silenciosamente.
T3 puede evitar una llamada LLM si existe una regla semántica activa con scope suficiente. La regla pertenece al nivel M1.
M1 debe exponer a T3:
T3 no debe crear reglas semánticas a partir de outputs aislados. Necesita estabilidad, aprobación y ausencia de correcciones.
M1 debe proveer explicaciones útiles, no prompts internos.
La UX necesita:
M1 debe aceptar correcciones estructuradas desde S1 y convertirlas en re-planificación o señal de aprendizaje.
M1 puede ser re-ejecutado después de una corrección humana o señal T4, pero esa re-ejecución debe quedar versionada. No se sobrescribe el plan original; se produce un nuevo plan o una revisión del plan.
| Riesgo | Mitigación |
|---|---|
| M1 absorbe detalles de Holded | Linter conceptual de contratos; revisión de PRs con golden rules; tests que prohíban campos de ejecución en Internal Plan; ownership claro del vocabulario |
| Los tres LLMs se vuelven caros y lentos | T3 semántico antes de LLM; rutas rápidas determinísticas; ejecución parcial de roles según riesgo; batching |
| El crítico LLM crea falsa seguridad | Métricas por tipo de fallo; evals adversariales; validadores determinísticos independientes; comparación contra ediciones reales capturadas por T4 |
| La memoria contamina decisiones | Memoria con autoridad, fecha, fuente, tasa de corrección y capacidad de invalidación. Reglas activas pueden entrar en cuarentena |
| El Internal Plan se vuelve demasiado grande | Contrato pequeño, anexos de evidencia, versiones explícitas y separación entre decisión, explicación y raw facts |
| M1 bloquea demasiado | Medir falsos bloqueos; madurez por isla; umbrales ajustables por cliente; shadow mode para subir confianza sin riesgo |
decision_guards.py regresa al patrón actual (mezcla decisión + lectura SoR) |
Guards consumen facts normalizados. Lecturas SoR viven en facts/erp_snapshot/. Lint custom |
Patología 1: M1 intenta ser el sistema contable completo. Si se le permite acumular snapshots, líneas, resultados y ajustes hasta parecer un libro mayor interno, se rompe la tesis SoA/SoR. M1 debe decidir, no persistir verdad contable.
Patología 2: usar LLMs para compensar falta de datos. Si faltan NIF, fecha, impuesto o cuenta necesaria, el sistema debe declarar incertidumbre. La inferencia puede proponer, pero no fabricar autoridad.
Patología 3: confundir aprobación con verdad universal. Una aprobación de un contable para un cliente, periodo y proveedor no implica regla global. T3 debe preservar scope estrecho.
Patología 4: explicabilidad como texto decorativo. Las explicaciones deben ser accionables: qué evidencia importó, qué regla aplicó, qué cambiaría la decisión.
Patología 5: bootstrap cruzado introduce sesgo masivo. Cliente nuevo en sector X arranca con reglas heredadas. Si esas reglas son sesgadas, el cliente recibe muchas correcciones. T3 marca reglas bootstrapped como bootstrap_origin=X; si correction_rate>30% en primeros 30 docs, invalida en bloque.
| Métrica | Target |
|---|---|
% docs servidos por regla vs LLM |
Crece con el tiempo. >50% a los 6 meses por team |
motor_latency_p95 |
<2s (sub-fases deterministas) + <8s (con LLMs paralelos) |
decision_audit_completeness |
100%. Cada decisión tiene rule_versions + input_hash |
validation_failed_rate |
<1% |
criterion_drift_alerts_per_month_per_client |
<2 |
falsos_bloqueos_rate |
<5% (planes bloqueados que el contable habría aprobado) |
Síntesis. Detalle granular en versiones originales de Claude y Codex.