Protocolo abierto para serviciosv0.10 — Borrador

Una semántica común para acordar, entregar y compensar servicios

Servicialo conecta lo ofrecido, lo acordado, lo entregado, la evidencia de la entrega y su liquidación, para que plataformas, sistemas y agentes operen servicios con un lenguaje compartido.

1 implementación en producción · 114 instalaciones técnicas detectadas en 20 países
Especificación abierta (Apache-2.0)Independiente del transporte — HTTP · MCP · A2A
§ 01El problema

Cada sistema representa los servicios a su manera

Un servicio real vive fragmentado entre la agenda, los mensajes, el cobro, los formularios y los sistemas internos de cada parte.

El problema no es agendar. Es que cada sistema representa de forma distinta qué se acordó, quién debía participar, qué ocurrió, qué evidencia existe y cómo se compensa.

Sin una semántica compartida, cada integración — entre plataformas o con agentes — vuelve a definir esas respuestas desde cero, y las definiciones no coinciden entre sistemas.

MCP y A2A definen cómo se conectan los agentes. Servicialo define qué significa un servicio: qué se acordó, qué se entregó, qué lo respalda y cómo se liquida.

§ 02Qué estandariza

Cinco elementos, un lenguaje común

El protocolo define objetos y eventos legibles por máquinas para cada etapa de un servicio — y la relación entre ellas.

  1. 01
    Oferta
    Service Offer

    Lo que una organización publica: servicios, condiciones y disponibilidad.

  2. 02
    Acuerdo
    Service Order

    Lo pactado entre las partes: alcance, precio, políticas y quién paga.

  3. 03
    Entrega
    Service Delivery

    Cada instancia ejecutada del servicio, con su propio estado.

  4. 04
    Evidencia
    Evidence Events

    Los registros que respaldan lo ocurrido: confirmaciones, firmas, marcas de tiempo.

  5. 05
    Liquidación
    Settlement Events

    Los movimientos financieros vinculados: factura, pago, devolución.

Cada elemento conserva su propio ciclo de vida: el protocolo no impone un orden total entre entrega, evidencia y liquidación. Un prepago, una facturación mensual o un servicio sin costo no rompen el modelo.

Prueba de Servicio
borrador

Una Prueba de Servicio es el expediente que vincula estos elementos para una entrega concreta: afirmaciones, eventos, evidencia, atestaciones y niveles de certeza. No declara la verdad del mundo ni reemplaza el juicio sobre la calidad. Hoy el expediente es derivable de los objetos actuales del protocolo; su formalización como objeto propio es una extensión en borrador.

Servicialo no impone una plataforma, un medio de pago, un modelo de negocio, un agente ni una interfaz. Define la semántica; cada implementación decide el resto.

Objetos, esquemas y máquinas de estado en la especificación
§ 03Un ejemplo

Una sesión de kinesiología, de punta a punta

El mismo recorrido aplica a cualquier servicio profesional programado.

  1. 01Oferta

    Un centro publica “Sesión de kinesiología — 45 minutos”. Una persona, o su agente, descubre el servicio y consulta disponibilidad.

  2. 02Acuerdo

    Se agenda una hora. Quedan registrados el precio, la política de cancelación y quién paga — que no siempre es quien recibe.

  3. 03Entrega

    El profesional ejecuta la sesión. La entrega queda registrada con su propio estado, independiente del pago.

  4. 04Evidencia

    Según la política acordada, los sistemas registran confirmaciones, marcas de tiempo, documentación o atestaciones: evidencia asociada a esa entrega, no una declaración suelta.

  5. 05Liquidación

    El cobro queda vinculado a la entrega. Puede ocurrir antes (prepago), después (facturación mensual) o no existir (servicio sin costo).

La misma estructura cubre una orden de 12 sesiones, un contrato por horas o un proyecto por hitos — estados y ciclo de vida en la especificación.

§ 04Estado actual

Qué existe hoy

Distinguimos explícitamente lo disponible de lo experimental, lo que está en diseño y lo aspiracional. Las hipótesis no se presentan como resultados.

Disponible hoy
Experimental · candidata
  • Binding A2A
    descubrimiento e intents de booking
  • Evidence Profiles
    Qué constituye evidencia válida de una entrega, por vertical.
  • Settlement
    Distribución de pagos entre profesional, organización e infraestructura.
  • Delegated Agency
    Delegación explícita, acotada y revocable de un humano a un agente IA.
  • Network Intelligence
    Benchmarks operacionales agregados y anónimos entre nodos.
  • Webhooks
    Notificaciones push de eventos del registry y de benchmarks.
En diseño
  • Disputes
    Resolución formal de desacuerdos sobre una entrega.
  • State Dimensions
    Máquinas de estado ortogonales: entrega, evidencia, aceptación y liquidación.
  • Proof of Service
    El expediente verificable que vincula lo acordado, lo entregado, la evidencia y la liquidación.
La madurez de cada extensión vive en protocol/manifest.yaml y se valida en CI — ver extensiones y su madurez →
§ 05Implementaciones y red

Una implementación de referencia, una red opt-in

El protocolo no depende de una plataforma, de la red ni de una autoridad central.

Referencia
Coordinalo es la implementación de referencia — no el protocolo ni la única forma de implementarlo. Opera en producción (vertical salud) desde 2026.
Implementaciones independientes
Cualquier plataforma puede implementar Servicialo desde la especificación. La conformidad se revisa manualmente hoy; la suite automatizada es objetivo del roadmap, no una capacidad actual.
La red es opt-in
El registro en el resolver y la telemetría son opcionales. Una implementación es conforme sin registrarse ni compartir datos.
Cómo leer las cifras
La telemetría distingue cuatro cosas distintas: instalaciones técnicas detectadas (hosts únicos, anónimos), nodos recientemente activos, implementaciones verificadas y organizaciones operando en producción. Instalar el servidor no es operar servicios: hoy hay una implementación en producción y ninguna implementación independiente verificada todavía. Las instalaciones indican interés técnico, no adopción operacional.
§ 06Siguiente paso

Tres caminos de entrada

Servicialo es mantenido por su autor, con especificación abierta (Apache-2.0). El código, el proceso de cambios y la gobernanza están documentados en GitHub y GOVERNANCE.md.