Servicialo define qué significa que un servicio fue prometido, entregado y probado, para que dos sistemas que no se conocen puedan estar de acuerdo sin depender de un intermediario que lo garantice.
Es una especificación, no una plataforma: define la semántica — oferta, acuerdo, entrega, evidencia y liquidación — y deja a cada implementación el resto.
Qué pasa si esto no se define
No es un problema de agendas. La evidencia de cumplimiento existe: lo que no existe es una forma acordada de decir qué se prometió, qué se entregó y qué lo prueba — y la ausencia tiene tres consecuencias concretas.
- 01La evidencia queda cautiva
Lo que prueba que una entrega ocurrió — la confirmación, la hora real, la firma, el documento — existe, pero vive dentro del software que corrió esa hora. No hay una forma acordada de sacarlo, así que el registro del profesional deja de ser suyo: es un subproducto del sistema que eligió para agendar. Y no queda cautiva sólo la prueba de esa entrega: queda cautivo el historial. Diez años de entregas acreditadas no se acumulan en un registro que viaje con quien las prestó — se acumulan fragmentados entre los sistemas que se fueron usando, y cada cambio de plataforma empieza el conteo de nuevo.
- 02Verificar es N×M
Cualquier tercero que necesite verificar una entrega — un pagador, una aseguradora, un auditor, un prestamista, un agente — tiene que integrarse una vez por cada sistema del que provenga la evidencia. En la práctica ese problema no se resuelve: se recorta. Se integra con los más grandes y el resto queda fuera de la verificación, no por incumplir sino por no ser integrable.
- 03La semántica se hereda
Si la semántica de servicio no existe cuando los agentes empiecen a coordinar a volumen, se hereda de la que sí existe: la de los bienes. Ahí el no-show, el reagendamiento y el pagador distinto del beneficiario son casos borde de un modelo pensado para paquetes que se despachan y llegan — no rasgos ordinarios de lo que se está modelando.
Por qué protocolo y no producto
La diferencia no es de tamaño ni de ambición: es que dos de los tres problemas anteriores no admiten solución de producto.
Un producto puede resolver el primer problema para sus propios usuarios: guardar bien la evidencia y devolvérsela a quien la generó. No puede resolver el segundo, porque el problema N×M es precisamente el de sistemas que no comparten dueño; un producto que lo resolviera para todos tendría que ser adoptado por todos, y sería entonces el intermediario del que la declaración de rol dice que no hay que depender.
Por eso lo que se publica es una especificación bajo Apache-2.0, no un servicio. Cualquier plataforma puede implementarla sin permiso, y una implementación es conforme sin registrarse en ninguna red ni compartir dato alguno. El costo de esa decisión es real: sin producto no hay distribución, y la adopción hay que ganarla documento por documento.
Por qué existe
Esta función va a ser definida por alguien. El volumen agéntico lo obliga: en cuanto un agente coordina servicios a escala necesita saber qué cuenta como entrega y qué cuenta como prueba, y si nadie lo escribió, lo escribe de facto el primero que llegue con tracción.
Quien define el objeto determina de quién es el registro. Si el objeto lo define el runtime de una plataforma, la evidencia es de la plataforma y el profesional la usa prestada. Si lo define una vertical, la evidencia existe pero no cruza: sirve dentro de salud, o dentro de educación, y se detiene en el borde. Si lo define una especificación neutral, la evidencia es del profesional y viaja con él.
Este no es un argumento de que Servicialo sea esa especificación. Es el argumento de por qué conviene que exista alguna, y por qué esta está escrita. Si otra la define mejor, el resultado buscado igual se cumple.
De ese argumento se sigue una consecuencia directa: la portabilidad del registro es un principio del protocolo — si la evidencia es del profesional, tiene que poder salir. Su especificación normativa está en desarrollo y todavía no forma parte del documento.
Nada de esto se inventa en un vacío. Hay modelado de dominio con años de producción encima — la Open Booking API de OpenActive en booking, FHIR en salud, GS1 EPCIS en eventos de bienes — y una línea de trabajo reciente sobre la capa agéntica: AP2 en autorización, y RAILS: Verification-Native Clearing For Agentic Commerce (de Valois-Franklin y Bogdan, Evolutionairy AI, junio 2026) en clearing y verificación de obligaciones.
Servicialo se posiciona como complementario, no como reemplazo. Esos trabajos modelan el mecanismo de verificación y clearing; Servicialo modela los objetos de dominio que ese mecanismo consume, para servicios prestados por humanos: qué se prometió, qué entrega concreta ocurrió, qué la respalda. No reclama prioridad sobre ninguno de ellos.
El mapeo concreto entre los objetos de Servicialo y cada uno de estos estándares — perfiles de interoperabilidad, correspondencia de campos — no está especificado hoy y no se presenta como si lo estuviera.
El argumento filosófico completo — por qué la soberanía del registro importa, y para quién — vive en el manifiesto de Grupo Digitalo. Esta página y la especificación son el cómo técnico: qué obliga el protocolo, y qué no.
Qué NO es
Un protocolo se define tanto por lo que deja fuera como por lo que modela. Cinco cosas que Servicialo no es, y con qué compone en su lugar.
- No es un marketplace
- No intermedia la relación comercial ni captura la demanda. Compone con los marketplaces, directorios y agentes que ya lo hacen: el resolver responde slug → endpoint y el registry publica qué ofrece una organización; el precio, la selección y la relación con el cliente quedan en el nodo.
- No es un riel de pago
- Modela estados de liquidación — factura, cargo, pago, devolución, conciliación — pero no mueve dinero. Compone con los rieles que ya existen: el evento de liquidación referencia el movimiento; el movimiento ocurre fuera del protocolo.
- No es un producto de agendamiento
- Define semántica de disponibilidad, compromiso y reagendamiento; no reemplaza el calendario, la interfaz de reserva ni el motor de agenda. Compone con los productos de agenda que ya operan: la agenda sigue donde está, el acuerdo se vuelve legible fuera de ella.
- No es un sistema de identidad
- No emite ni verifica identidad de personas ni de organizaciones. Compone con credenciales verificables y con los emisores que ya acreditan títulos, matrículas y habilitaciones: el protocolo transporta el atributo, su origen y quién lo verificó — no lo certifica.
- No es un transporte
- No define cómo se conectan dos sistemas. Compone con MCP y A2A, y con HTTP como binding normativo: el protocolo dice qué significa el mensaje; el transporte, cómo llega.
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.
Servicialo define semántica de servicio, no el stack de confianza completo
De la lista anterior se sigue algo que conviene decir directamente: Servicialo no necesita controlar el transporte, la identidad, la autorización ni el mecanismo criptográfico con que viaja la evidencia. Si emerge un estándar común para cualquiera de esas capas, Servicialo puede expresarse como un perfil de servicios sobre él — sin cambiar lo que modela.
- Identidad
- Otro estándar puede establecer quién actuó.
- Autorización
- Otro estándar puede establecer qué le estaba permitido hacer.
- Transporte y sobre de evidencia
- Otro estándar puede transportar y firmar la evidencia.
- Servicialo
- Define qué significaba la obligación de servicio, qué estado alcanzó, qué evidencia la respalda y cómo ese historial puede seguir siendo portable.
La autorización responde qué le estaba permitido hacer a alguien. Servicialo responde qué ocurrió efectivamente. Son preguntas distintas, y una capa adyacente que resuelva la primera no compite con la segunda: la habilita.
Ningún perfil de ese tipo está escrito hoy. La afirmación es sobre la forma del protocolo — la semántica está separada del sobre que la transporta —, no sobre un trabajo de interoperabilidad existente.
La declaración de no-alcance normativa vive en PROTOCOL.md §1.2. Lo que sí obliga el protocolo está en la especificación.
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.
- 01OfertaService Offer
Lo que una organización publica: servicios, condiciones y disponibilidad.
- 02AcuerdoService Order
Lo pactado entre las partes: alcance, precio, políticas y quién paga.
- 03EntregaService Delivery
Cada instancia ejecutada del servicio, con su propio estado.
- 04EvidenciaEvidence Events
Los registros que respaldan lo ocurrido: confirmaciones, firmas, marcas de tiempo.
- 05LiquidaciónSettlement 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.
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.
De la prueba a la reputación
El expediente de una entrega no es el final del recorrido. La razón por la que la portabilidad importa no se agota en probar una transacción: se agota recién cuando el historial que esa transacción integra puede viajar con quien lo generó. Cuatro tramos, cada uno con un significado distinto.
- PruebaProof
- Evidencia verificable de una obligación o gestión particular: qué se acordó, qué entrega ocurrió y qué la acredita bajo la política vigente entre las partes.
- Historial verificableVerified history
- La acumulación longitudinal de esas pruebas: qué ocurrió, cuántas veces, en qué contexto, con qué excepciones y con qué disputas.
- ReputaciónReputation
- El contexto que ese historial aporta para una decisión concreta. No es un atributo del profesional ni un número que el protocolo emita: es una lectura del historial, hecha por quien decide y bajo su política.
- DecisiónDecision
- La acción de un tercero que cambia porque confía en ese contexto. Ahí — y no antes — el historial portable tiene valor económico.
Servicialo no posee la reputación. Hace portables y verificables los hechos que la sustentan.
La reputación es contexto, no un score universal. Cada tercero interpreta el historial verificable bajo su propia política.
Los cuatro tramos son definiciones, no capacidades disponibles. Servicialo modela las primitivas necesarias para producir evidencia de servicio verificable; el historial portable y la reputación siguen siendo hipótesis por construir y validar entre nodos independientes. La Prueba de Servicio es una extensión en borrador y la portabilidad del historial no tiene todavía especificación normativa. Qué decisiones habilitaría se trata en visión.
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ónUna sesión de kinesiología, de punta a punta
El mismo recorrido aplica a cualquier servicio profesional programado.
- 01Oferta
Un centro publica “Sesión de kinesiología — 45 minutos”. Una persona, o su agente, descubre el servicio y consulta disponibilidad.
- 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.
- 03Entrega
El profesional ejecuta la sesión. La entrega queda registrada con su propio estado, independiente del pago.
- 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.
- 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.
Qué existe hoy, y qué no
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.
- Especificación y modelo principalPROTOCOL.md v0.10 (borrador) + JSON Schemas
- Servidor MCP (40 tools)@servicialo/mcp-server v0.9.14
- Perfil HTTP + OpenAPIbinding REST normativo
- Registry + resolver globaldescubrimiento y portabilidad
- Coordinalo (referencia, salud)en producción
- Binding A2Adescubrimiento e intents de booking
- Evidence ProfilesQué constituye evidencia válida de una entrega, por vertical.
- SettlementDistribución de pagos entre profesional, organización e infraestructura.
- Delegated AgencyDelegación explícita, acotada y revocable de un humano a un agente IA.
- Network IntelligenceBenchmarks operacionales agregados y anónimos entre nodos.
- WebhooksNotificaciones push de eventos del registry y de benchmarks.
- DisputesResolución formal de desacuerdos sobre una entrega.
- State DimensionsMáquinas de estado ortogonales: entrega, evidencia, aceptación y liquidación.
- Proof of ServiceEl expediente verificable que vincula lo acordado, lo entregado, la evidencia y la liquidación.
Quién lo implementa, y quién lo revisa
El protocolo no depende de una plataforma, de la red ni de una autoridad central. Tampoco tiene, todavía, quien lo contradiga desde afuera.
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.