Hacia dónde apunta el protocolo
Este documento describe posibilidades futuras, líneas de investigación y visión de largo plazo. Nada de esta página es parte normativa del protocolo — lo especificado vive en /spec y lo implementado en /extensions.
Por qué coordinar servicios merece un protocolo
Los servicios son la mitad de la economía que no tiene semántica compartida. Los productos tienen códigos de barra, tracking y prueba de entrega; los servicios se confirman por WhatsApp, se registran en cuadernos y se liquidan contra declaraciones. El costo alto es sistémico: errores, rechazos, duplicidades, sobrecodificación y prestaciones difíciles de verificar. Quien paga absorbe la pérdida; el prestador legítimo cobra tarde, atrapado en la misma fila de sospecha. El enemigo es la ausencia de evidencia estructurada — no una de las partes.
Si compromiso, entrega, evidencia y liquidación comparten una semántica común, cada capa que hoy es fricción — reembolsos, auditoría, reputación, acceso a crédito — puede construirse encima como infraestructura, no como excepción. Esa es la apuesta de largo plazo de Servicialo.
El valor no espera al pagador
No esperamos a que el pagador adopte el protocolo. Cada parte captura valor por su cuenta, en este orden.
Datos de servicio como pasaporte financiero
La reputación es contexto, no un puntaje
Una prueba acredita una gestión. Muchas pruebas verificables forman un historial. Ese historial aporta contexto para decidir qué esperar ahora. Los tres son cosas distintas, y la cadena completa — prueba, historial, reputación, decisión — está definida en el modelo de la portada. Lo que sigue es su consecuencia de largo plazo, no una capacidad.
El mismo historial verificable puede sostener decisiones distintas. Quien financia mira cumplimiento y disputas. Quien opera un servicio mira consistencia y experiencia. Un agente mira cuánta confianza necesita para actuar sin revisión humana. Los tres pueden leer el mismo historial y decidir distinto sin que ninguno se equivoque, porque un score es una interpretación, no un hecho. Por eso el protocolo no define un puntaje universal: no posee la reputación, y sólo puede hacer portables y verificables los hechos que la sustentan. La interpretación queda en la política de cada tercero.
Lo que existe hoy es mucho menos que eso: el resolver registra un puntaje de confianza básico (actividad, verificación) que es una señal operacional de la red, no reputación de servicio. La reputación portable entre plataformas requiere múltiples implementaciones independientes y mecanismos de atestación que todavía no existen — y de derivarse, se derivaría de entregas reales verificadas a través del protocolo, no de governance tokens, votos delegados ni métricas de participación.
Disputas resueltas por evidencia, no por discrecionalidad
La extensión de Disputas (en diseño, ver /extensions) define el flujo estructurado: apertura, congelamiento del cobro, revisión de evidencia contra el contrato, resolución. Objetivo de diseño: automatizar la resolución de los casos cuya evidencia satisface reglas previamente acordadas.
La línea de investigación va más allá: árbitros pares del mismo vertical profesional que evalúan los casos que la evidencia no resuelve, con ventanas de votación acotadas e incentivos de participación. No hay especificación ni implementación de arbitraje por pares hoy, y no publicamos porcentajes de resolución automática porque no existe una muestra verificable.
La red que aprende de cada nodo
Cada nodo que implementa el protocolo genera datos operacionales: patrones de agenda, tasas de inasistencia, distribuciones de precios, señales de demanda. Agregados con k-anonimato, esos datos podrían convertirse en inteligencia colectiva — como Waze, donde cada conductor contribuye y todos navegan mejor, sin que ningún actor sea dueño de la red.
Lo que existe hoy es la base: telemetría operacional bucketeada, benchmarks con k-anonimato ≥ 5 y el modelo contribuir-para-acceder (extensión Network Intelligence, experimental — ver /extensions). La inteligencia colectiva con efectos de red reales requiere decenas de nodos independientes; hoy existe una implementación en producción.