← servicialo.com
Extensiones

Extensiones del protocolo

El núcleo del protocolo es pequeño: objetos, dimensiones y ciclo de vida. Las capacidades adicionales se definen como extensiones con madurez explícita — una extensión en borrador o experimental nunca se presenta como capacidad estable.

Niveles de madurez
borrador
Propuesta de diseño. Puede cambiar o retirarse. No es requisito de conformance.
experimental
Implementada al menos parcialmente; interfaz inestable.
candidata
Interfaz estable; espera adopción de más de una implementación.
estable
Interfaz congelada; romperla exige versión mayor del protocolo.
obsoleta
Programada para remoción; no adoptar.
El registro canónico vive en protocol/manifest.yaml (PROTOCOL.md §15.6) y esta página se genera desde él.

Evidence Profiles

candidata

Qué constituye evidencia válida de una entrega, por vertical.

Qué define
  • —Envelope común de evidencia (tipo, actor, método, sensibilidad)
  • —Perfiles por vertical: salud, hogar, legal, educación, consultoría
  • —Niveles de certeza acumulativos (L1–L4) de una Prueba de Servicio
Estado real
Schemas publicados y usados por la implementación de referencia. Los niveles de certeza son parte del borrador Proof of Service.
Especificación → schema/evidence/base.schema.json
Evidence Profiles — Evidencia por vertical

Qué constituye prueba

Cada política define qué evidencia se necesita para acreditar una Prueba de Servicio. Los perfiles por vertical son ejemplos configurables — no requisitos universales del protocolo. Resolver disputas sin intervención humana es un caso de uso — no el fin.

🏥
Salud
Ejemplo de política: 4 evidencias posibles
→
Posibles evidencias según el tipo de servicio, el acuerdo, la política aplicable y la regulación correspondiente.
Registro de entrada
auto
Marca temporal al llegar y, cuando corresponda, ubicación
Registro de salida
auto
Marca temporal al salir y, cuando corresponda, ubicación
Ficha clínica firmada
manual
Documentación o atestación asociada a la entrega, cuando la política aplicable lo requiera
Adherencia al plan
manual
Lista de verificación del plan de tratamiento ejecutado
Regla de acreditación ilustrativa
Si las evidencias que esta política exige — registros de entrada/salida y ficha firmada — están presentes y son válidas, la entrega se acredita bajo esta política, con su nivel de certeza. Si falta ficha o firma, escalar.
Esto no determina por sí solo la calidad del servicio ni la verdad absoluta de cada afirmación.
🏠
Hogar
Ejemplo de política: 4 evidencias posibles
→
⚖️
Legal
Ejemplo de política: 3 evidencias posibles
→
📚
Educación
Ejemplo de política: 3 evidencias posibles
→
¿Por qué separar por vertical?
Un kinesiólogo y un electricista entregan servicios radicalmente distintos. Pedirle a ambos la misma evidencia no funciona. Cada perfil puede definir políticas configurables según el tipo de servicio, el acuerdo, la sensibilidad de los datos y la regulación aplicable. La verificación comprueba de forma reproducible si la evidencia satisface esos requisitos explícitos; no convierte una señal aislada en verdad objetiva ni reemplaza el juicio sobre la calidad.
Gradiente de certeza (Proof of Service)
borrador
L1Afirmado
L2Atestación bilateral
L3Respaldo operacional
L4Conciliación financiera
El nivel describe la evidencia disponible; la acreditación es una dimensión aparte, definida por política — una entrega puede acreditarse en cualquier nivel, con o sin pago. Ver Prueba de Servicio.

Settlement

experimental

Distribución de pagos entre profesional, organización e infraestructura.

Qué define
  • —Track de estado financiero independiente del ciclo de entrega
  • —Distribución a múltiples destinatarios (porcentaje | monto fijo | mixto)
  • —Momentos de liquidación: por sesión | mensual | al cierre
Estado real
El track billing.* y las tools payments.* están implementados; la distribución multi-destinatario está en diseño.
Especificación → PROTOCOL.md#128-payment-model

Disputes

borrador

Resolución formal de desacuerdos sobre una entrega.

Qué define
  • —Flujo estructurado: apertura → revisión de evidencia → resolución
  • —Congelamiento automático del cobro durante la disputa
  • —Contrato pre-acordado como criterio de resolución
Estado real
En diseño. Objetivo: automatizar la resolución de casos cuya evidencia satisface reglas previamente acordadas. El arbitraje por pares es una línea de investigación (ver /vision).
Sin documento de especificación todavía (en diseño)
Flujo objetivo (diseño)
Paso 1 · cliente | proveedor | agente
Apertura de disputa
Cualquier parte puede abrir una disputa dentro del plazo definido. Se congela el cobro automáticamente.
Paso 2 · sistema | admin
Revisión de evidencia
Se solicita evidencia adicional de ambas partes. Se compara contra lo acordado en el contrato.
Paso 3 · admin | arbitraje
Resolución
Si proveedor gana: Cobrado → Verificado. Si cliente gana: Cancelado con balance restaurado.
Objetivo de diseño: automatizar la resolución de los casos cuya evidencia satisface reglas previamente acordadas. El arbitraje por pares del mismo vertical es investigación — ver /vision.
Campos del contrato pre-acordado (ilustrativos)
evidencia_requerida
Qué evidencia debe registrarse para acreditar la entrega bajo el contrato
registro_entrada + registro_salida + ficha_clinica_firmada
plazo_disputa
Ventana de tiempo para abrir una disputa después de la entrega
48 horas
política_cancelación
Reglas de penalización por cancelación según tiempo restante
p. ej.: 0% si >24h, 50% si 2-24h, 100% si <2h — política ilustrativa; cada implementación define la suya
política_inasistencia
Qué ocurre si una parte no se presenta
p. ej.: cliente ausente → se cobra según política; proveedor ausente → reasignación + penalidad
arbitraje
Configuración del arbitraje si aplica (extensión Disputas, en diseño)
p. ej.: 1 árbitro si monto < $50, 3 si >= $50
monto_máximo_disputa
Monto máximo que puede disputarse sin escalamiento externo
p. ej.: $500 USD equivalente
Campos ilustrativos — cada implementación define sus políticas; el protocolo define la estructura.

Delegated Agency

experimental

Delegación explícita, acotada y revocable de un humano a un agente IA.

Qué define
  • —ServiceMandate: principal, agente, alcances, vigencia, revocación
  • —Scopes por recurso y acción (schedule:write, payment:read, …)
  • —Registro de auditoría de acciones de agentes
Estado real
Especificada e implementada como capa de servicio; los scopes son advisory en la implementación de referencia (no se validan aún en el boundary MCP).
Mandate scopes are advisory in the reference implementation — not enforced at the MCP tool boundary.
Especificación → spec/delegated-agency-model.md

Network Intelligence

experimental

Benchmarks operacionales agregados y anónimos entre nodos.

Qué define
  • —Eventos operacionales bucketeados (sin datos individuales)
  • —k-anonimato ≥ 5 organizaciones por segmento
  • —Modelo contribuir-para-acceder
Estado real
Lado de lectura implementado (market.list_segments, market.get_benchmark); el modelo de acumulación de contribución está en progreso. Opcional: el protocolo funciona sin la red.
Especificación → PROTOCOL.md#14-network-intelligence
La telemetría agregada en vivo se publica en /network. La red es opcional: una implementación es conforme sin contribuir ni leer datos de la red.

State Dimensions

borrador

Máquinas de estado ortogonales: entrega, evidencia, aceptación y liquidación.

Qué define
  • —Cinco enums por dimensión (fulfillment, evidence, acceptance, financial, order)
  • —Regla de no-orden-total entre dimensiones
  • —Mapeo desde los enums wire actuales (aditivo, sin breaking changes)
Estado real
Borrador. Formaliza la semántica que el Core ya enuncia en PROTOCOL.md §6.0.
Especificación → public/spec/extensions/state-dimensions.md

Proof of Service

borrador

El expediente verificable que vincula lo acordado, lo entregado, la evidencia y la liquidación.

Qué define
  • —Composición del expediente a partir de objetos existentes del Core
  • —Tres dimensiones independientes: nivel de certeza (L1–L4), estado del expediente (acreditación por política) y estado de liquidación
  • —Regla de presentación: la prueba nunca se muestra sin su nivel de certeza y su estado de expediente
Estado real
Borrador. No existe objeto wire todavía — el documento especifica el compuesto objetivo, derivable de los objetos actuales.
Especificación → public/spec/extensions/proof-of-service.md
B · Estado del expediente — acreditación según política
draftBorrador
El expediente se está componiendo: afirmaciones y evidencia en recolección.
supportedRespaldado
La evidencia registrada respalda la entrega; aún no se evalúa contra una política.
accreditedAcreditado
La evidencia satisface la política de acreditación aplicable. Puede ocurrir en L1, L2, L3 o L4 — con o sin pago.
disputedDisputado
Una parte disputa la entrega o su evidencia.
revokedRevocado
La acreditación fue retirada tras nueva evidencia o resolución.
La acreditación depende de una política (accreditation_policy: evidencia y atestaciones requeridas, nivel mínimo de certeza, excepciones). Una Prueba de Servicio puede quedar acreditada en L1, L2, L3 o L4 — el pago no es prerrequisito de la acreditación. El nivel de certeza (dimensión A) se describe arriba, en el gradiente de certeza.
C · Estado de liquidación — los movimientos financieros
not_requiredpendinginvoicedpartially_paidpaidrefundedcharged_backwritten_off
La liquidación corre en su propio ciclo — puede ocurrir antes, después o nunca respecto de la entrega. Un pago conciliado no prueba por sí solo la calidad ni el alcance entregado, y una devolución no des-hace la entrega. Los estados son los de la dimensión financial de la extensión state-dimensions.
Regla de presentación
La Prueba de Servicio nunca se muestra desnuda: cualquier componente que la represente muestra a la vez su nivel de certeza (L1–L4) y su estado de expediente. Presentar la liquidación como si fuera la certeza sugiere que más pago equivale a más verdad.

Webhooks

experimental

Notificaciones push de eventos del registry y de benchmarks.

Qué define
  • —Suscripciones con verificación HMAC-SHA256
  • —Reintentos con backoff y desactivación automática
  • —Eventos: registry y snapshot semanal de benchmarks
Estado real
v0.2 — eventos del registry estables; superficie en expansión.
Especificación → WEBHOOKS.md
Operaciones especificadas pero no implementadas en el servidor de referencia (service_orders.*, mandates.*): se listan como specified_unimplemented_tools en el manifest y CI falla si una de ellas aparece en código sin promoverse al registro de tools.