{
  "markdown": "<div align=\"center\">\n\n# Servicialo\n\n**La capa de orquestación para la economía de servicios en la era de agentes AI**\n\nUn protocolo abierto para coordinación de agenda, identidad, verificación<br>\nde entrega y liquidación financiera de servicios profesionales.\n\n`Protocolo abierto` `Legible por máquinas` `Agent-native` `Apache-2.0`\n\n[Sitio web](https://servicialo.com) ・ [Especificación](./PROTOCOL.md) ・ [Gobernanza](./GOVERNANCE.md) ・ [MCP Server](./packages/mcp-server) ・ [npm](https://www.npmjs.com/package/@servicialo/mcp-server)\n\n**Nuevo en Servicialo? Empieza aqui → [`SPEC.md`](./SPEC.md)**\n\n**Spec completa (crawler-friendly): https://servicialo.com/spec**\n\n**[Read in English](./README.en.md)**\n\n\n</div>\n\n---\n\n## Protocol Specification\n\nFor a formal description of the architecture, message flows, and data model:\n\n- [Whitepaper v0.9](https://servicialo.com/whitepaper) — formal protocol specification\n- [Protocol repository](https://github.com/servicialo/protocol) — schemas, RFCs, and reference materials\n- [PROTOCOL.md](./PROTOCOL.md) — full specification in this repo\n\n---\n\n## Protocol Units\n\nEl protocolo distingue primitivas de evento (SC, CAC) de modelos \nde billing (SC, CAC, RAC). Ver [GLOSSARY.md](./GLOSSARY.md) para \ndefiniciones completas.\n\n---\n\n## ¿Por dónde empiezo?\n\n**Tengo un negocio de servicios** y quiero que agentes AI descubran y agenden mis servicios\n→ Necesitas una plataforma compatible con el protocolo, no este repositorio. [Coordinalo](https://coordinalo.com) es la implementación de referencia. A medida que el protocolo madure, esperamos que surjan muchas más plataformas compatibles.\n\n**Soy un desarrollador** que quiere construir una plataforma compatible con el protocolo\n→ Sigue leyendo. Empieza por [`IMPLEMENTING.md`](./IMPLEMENTING.md).\n\n---\n\n## El problema\n\nSin un protocolo estándar, cada plataforma de servicios habla su propio idioma. Un agente AI que quiere agendar una cita médica, verificar una reparación a domicilio o cobrar una consulta legal necesita una integración distinta para cada una. Los datos quedan en silos, la interoperabilidad requiere integraciones custom, y la inteligencia colectiva sobre entrega de servicios nunca se forma.\n\n**Servicialo es el protocolo común.** Define el esquema mínimo viable para que cualquier agente AI coordine cualquier servicio profesional en cualquier plataforma compatible — sin integración adicional.\n\n---\n\n## Primitivas del protocolo\n\nServicialo define cuatro primitivas de coordinación. Juntas cubren la cadena de valor completa de la entrega de servicios profesionales:\n\n| Primitiva | Qué resuelve | Superficie del protocolo |\n|-----------|-------------|--------------------------|\n| **Coordinación de agenda** | Intersección de disponibilidad multi-parte (proveedor, cliente, recurso) con manejo de excepciones | Ciclo de vida 6+3, 6 flujos de excepción, scheduler de 3 variables |\n| **Verificación de identidad** | Credenciales del proveedor, puntaje de confianza, separación cliente-pagador | Credenciales del proveedor, trust_score, separación payer_id |\n| **Liquidación financiera** | Facturación, cobranza, liquidación y revenue sharing con resolución de disputas | Dimensión de cobro, ledger de Orden de Servicio, payment_schedule |\n| **Señales de demanda** | Telemetría operacional anónima y agregada entre nodos de la red | Extensión de Telemetría (modelo contribuir-para-acceder) |\n\nCada primitiva se especifica de forma independiente. Las implementaciones adoptan lo que necesitan.\n\n---\n\n## Qué es un servicio\n\n> *Un servicio es una promesa de transformación entregada en un momento y lugar específico.*\n\nA diferencia de un producto, un servicio no se puede almacenar, revender ni devolver. Se consume en el momento en que se entrega. Eso lo hace fundamentalmente diferente — y es por eso que necesita su propio protocolo.\n\nUn servicio nace de tres fuentes:\n\n| Origen | Pregunta clave | Ejemplo |\n|--------|---------------|---------|\n| **Desde un activo** | *Qué tienes que otros necesitan?* | Un departamento vacío → hospedaje temporal |\n| **Desde una ventaja** | *Qué sabes que otros no?* | Certificación en kinesiología → rehabilitación deportiva |\n| **Desde tu tiempo** | *Qué puedes hacer que otros no quieren o no pueden?* | Horas disponibles → limpieza profesional |\n\n---\n\n## Las 8 dimensiones\n\nTodo servicio profesional — desde una sesión de kinesiología hasta una auditoría tributaria — se modela con las mismas 8 dimensiones:\n\n| | Dimensión | Qué captura | Ejemplo |\n|:---:|-----------|-------------|---------|\n| **1** | **Qué** | La actividad o resultado que se entrega | Sesión de kinesiología, reparación eléctrica |\n| **2** | **Quién entrega** | El proveedor del servicio, con credenciales | Kinesiólogo certificado, electricista SEC |\n| **3** | **Quién recibe** | El cliente — con pagador separado explícitamente | Paciente (paga FONASA), empleado (paga empresa) |\n| **4** | **Cuándo** | Ventana temporal acordada | 2026-02-10 de 10:00 a 10:45 |\n| **5** | **Dónde** | Ubicación física o virtual, con `resource_id` opcional que referencia un Recurso físico (3.5b: sala, box, sillón, equipamiento) | Sala 3 de clínica, domicilio, videollamada |\n| **6** | **Ciclo** | Posición actual en las dimensiones de estado (entrega, evidencia, aceptación, liquidación) | Completado · evidencia registrada · cobro pendiente |\n| **7** | **Evidencia** | Cómo se respalda que el servicio ocurrió | GPS + duración + firma del cliente |\n| **8** | **Cobro** | Liquidación financiera, independiente del ciclo | $35.000 CLP · cobrado · paquete prepago |\n\n> **El pagador no siempre es el cliente.** En salud paga la aseguradora. En corporativo paga la empresa. En educación paga el apoderado. El protocolo separa explícitamente al cliente del pagador — porque en la vida real casi nunca son la misma persona.\n\n---\n\n## El ciclo de vida: 6 estados core + 3 financieros opcionales\n\nEl protocolo define estados independientes para observar el ciclo completo de una coordinación. Los 9 hitos siguientes son el **camino feliz** — la ruta operativa más común, no una secuencia única obligatoria. Los 6 primeros son requeridos; los 3 financieros son una extensión opcional. Entrega, evidencia, aceptación y liquidación evolucionan de manera independiente ([PROTOCOL.md §6.0](./PROTOCOL.md)):\n\n```\nSolicitado → Agendado → Confirmado → En Curso → Completado → Documentado → (opcional) Facturado → Cobrado → Verificado\n```\n\n| # | Estado | Qué ocurre |\n|:-:|--------|-----------|\n| 1 | **Solicitado** | El cliente o su agente define qué necesita, cuándo y dónde |\n| 2 | **Agendado** | Se asigna hora, proveedor y ubicación. Se bloquea el horario |\n| 3 | **Confirmado** | Ambas partes reconocen el compromiso |\n| 4 | **En Curso** | Registro de entrada detectado. El servicio está siendo entregado |\n| 5 | **Completado** | El proveedor marca la entrega como completa |\n| 6 | **Documentado** | Registro formal generado: ficha clínica, reporte, minuta |\n| 7 | **Facturado** | Documento tributario emitido |\n| 8 | **Cobrado** | Pago recibido y confirmado |\n| 9 | **Verificado** | El cliente confirma — cierre del ciclo |\n\n> **Verificado es el cierre.** El cliente no puede verificar hasta tener el cuadro completo: la evidencia documentada, la factura emitida y el cobro aplicado. Verificación prematura obliga al cliente a confirmar algo que aún no tiene registro formal.\n\n---\n\n## Las excepciones son la regla\n\nLas excepciones no son casos excepcionales. Ocurren en el **15–30% de las citas**. Un servicio bien diseñado define qué pasa cuando las cosas no salen según el plan:\n\n| Excepción | Transición | Qué pasa |\n|-----------|-----------|----------|\n| **Inasistencia del cliente** | Confirmado → Cancelado | Se aplica penalidad, se libera tiempo del proveedor |\n| **Inasistencia del proveedor** | Confirmado → Reasignando → Agendado | Se busca reemplazo automáticamente |\n| **Cancelación** | Cualquier pre-entrega → Cancelado | Se aplica la política de cancelación acordada |\n| **Disputa de calidad** | Completado → Disputado | Se congela el cobro, se solicita evidencia |\n| **Reagendamiento** | Agendado/Confirmado → Reagendando → Agendado | Se mantiene el proveedor si es posible. Incluye conflictos de recurso (doble reserva, recurso no disponible) |\n| **Entrega parcial** | En Curso → Parcial | Se documenta lo entregado, se ajusta la factura |\n\n---\n\n## Servicio y Orden de Servicio\n\nEl protocolo se construye sobre dos objetos y su relación:\n\n```\nOrganización\n└── Orden de Servicio            ← acuerdo comercial (opcional)\n    ├── alcance                   qué servicios, cuántos, de qué tipo\n    ├── precio                    cómo se calcula el valor\n    ├── esquema de pagos          cuándo se mueve el dinero\n    └── Servicios                 ← unidades atómicas de entrega\n        └── 8 dimensiones cada uno\n```\n\n> **La Service Delivery** es la instancia atómica ejecutada — lo que realmente ocurrió. En el wire format actual se representa con el objeto **Service** (nombre conservado por compatibilidad). **La Orden de Servicio** es el acuerdo comercial que agrupa entregas bajo un alcance, un precio y un esquema de pagos. \"Servicio\" a secas es el término general del dominio, no un cuarto objeto.\n\nCuando un Servicio pertenece a una Orden, su dimensión de cobro es **informativa** — registra el valor económico, pero no genera factura. La facturación es responsabilidad exclusiva de la Orden.\n\nLa misma estructura funciona para cualquier vertical:\n\n| Vertical | Ejemplo | Alcance | Pagos |\n|----------|---------|---------|-------|\n| **Salud** | Plan de kinesiología | 12 sesiones | Por sesión |\n| **Consultoría** | Contrato por horas | 40 horas de asesoría legal | Mensual según consumo |\n| **Proyectos** | Auditoría previa en 3 fases | Hitos definidos | Por hito aprobado |\n\n---\n\n## Evidencia por vertical\n\nCada vertical define, por política, qué evidencia acredita una entrega. Los perfiles siguientes son ejemplos configurables — no requisitos universales del protocolo: cada acuerdo puede exigir evidencias distintas, y la privacidad, la proporcionalidad y la regulación acotan qué corresponde recopilar. La acreditación resultante vale bajo la política aplicada y con su nivel de certeza; no determina por sí sola la calidad del servicio ni la verdad absoluta de cada afirmación. Sin ambigüedad — requisitos explícitos, previamente acordados, para producir una Prueba de Servicio acreditable:\n\n<details>\n<summary><b>Salud</b> — 4 tipos de evidencia</summary>\n\n| Evidencia | Descripción | Captura |\n|-----------|-------------|:-------:|\n| Registro de entrada | Marca temporal al llegar y, cuando corresponda, ubicación | auto |\n| Registro de salida | Marca temporal al salir y, cuando corresponda, ubicación | auto |\n| Ficha clínica firmada | Documentación o atestación asociada a la entrega, cuando la política aplicable lo requiera | manual |\n| Adherencia al plan | Lista de verificación del plan de tratamiento ejecutado | manual |\n\n**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.\n\n</details>\n\n<details>\n<summary><b>Hogar</b> — 4 tipos de evidencia</summary>\n\n| Evidencia | Descripción | Captura |\n|-----------|-------------|:-------:|\n| Foto antes | Foto del estado inicial con marca temporal y GPS | manual |\n| Foto después | Foto del resultado final con marca temporal y GPS | manual |\n| Lista de verificación | Tareas acordadas marcadas como completadas | manual |\n| Firma del cliente | Firma digital del cliente confirmando recepción | manual |\n\n**Regla de acreditación ilustrativa:** Si fotos antes/después existen con metadatos válidos y lista completa → la entrega se acredita bajo esta política, con su nivel de certeza. Si falta firma del cliente → escalar.\n\n</details>\n\n<details>\n<summary><b>Legal</b> — 3 tipos de evidencia</summary>\n\n| Evidencia | Descripción | Captura |\n|-----------|-------------|:-------:|\n| Minuta de reunión | Registro de lo discutido y acordado | manual |\n| Entrega de documentos | Confirmación de entrega de documentos generados | manual |\n| Registro de horas | Horas facturables con descripción de actividades | manual |\n\n**Regla de acreditación ilustrativa:** Si minuta existe y horas registradas dentro del rango acordado → la entrega se acredita bajo esta política, con su nivel de certeza. Si horas exceden lo acordado sin justificación → escalar.\n\n</details>\n\n<details>\n<summary><b>Educación</b> — 3 tipos de evidencia</summary>\n\n| Evidencia | Descripción | Captura |\n|-----------|-------------|:-------:|\n| Registro de asistencia | Confirmación de presencia del alumno y profesor | auto |\n| Entrega de material | Material o tareas entregadas al alumno | manual |\n| Evaluación | Evaluación o retroalimentación de la sesión | manual |\n\n**Regla de acreditación ilustrativa:** Si asistencia registrada y material entregado → la entrega se acredita bajo esta política, con su nivel de certeza. Si falta evaluación y contrato la requiere → escalar.\n\n</details>\n\n---\n\n## Resolución de disputas — extensión en diseño\n\nEl módulo de disputas (`Servicialo/Disputas`) está **en diseño** — el flujo siguiente describe el diseño objetivo, no una capacidad operativa:\n\n**1. Apertura** — Cualquier parte abre disputa dentro del plazo definido. Se congela el cobro automáticamente.\n\n**2. Revisión de evidencia** — Se solicita evidencia adicional de ambas partes. El sistema compara evidencia registrada contra el contrato.\n\n**3. Resolución** — Si proveedor gana: Cobrado → Verificado. Si cliente gana: Cancelado con balance restaurado.\n\n> **Objetivo de diseño:** automatizar la resolución de los casos cuya evidencia satisface reglas previamente acordadas en el contrato. Los casos que la evidencia no resuelve escalarían a revisión humana; el arbitraje por pares del mismo vertical es una línea de investigación, no un mecanismo desplegado.\n\n---\n\n## Servidor MCP\n\nServicialo expone sus herramientas como un servidor MCP, permitiendo que agentes AI descubran y coordinen servicios profesionales de forma nativa.\n\n### Inicio rápido\n\nEl package `@servicialo/mcp-server` es un thin-client que conecta a la API HTTP de una plataforma Servicialo-compatible. Por defecto apunta a [Coordinalo](https://coordinalo.com) (`servicialo.com`). Si estás construyendo tu propio backend, apunta al tuyo con `SERVICIALO_BASE_URL`. Si eres una organización usuaria (clínica, consultora, etc.), las credenciales las obtienes desde tu plataforma — no necesitas instalar este package directamente.\n\n```bash\nnpx -y @servicialo/mcp-server\n```\n\nCon eso, tu agente ya puede buscar organizaciones, consultar disponibilidad y listar servicios — sin credenciales.\n\n### Modo autenticado\n\nPara el ciclo completo — agendar, verificar entrega, cobrar:\n\n```json\n{\n  \"mcpServers\": {\n    \"servicialo\": {\n      \"command\": \"npx\",\n      \"args\": [\"-y\", \"@servicialo/mcp-server\"],\n      \"env\": {\n        \"SERVICIALO_API_KEY\": \"tu_api_key\",\n        \"SERVICIALO_ORG_ID\": \"tu_org_id\"\n      }\n    }\n  }\n}\n```\n\nLas credenciales las obtiene cada organización desde la plataforma Servicialo-compatible que utilice.\n\n### Las fases del agente — 40 herramientas\n\nUn agente bien diseñado sigue este orden:\n\n| # | Fase | Qué resuelve | Herramientas |\n|:-:|------|-------------|--------------|\n| 0 | **Resolver** | Dónde está el endpoint | `resolve.lookup` · `resolve.search` · `trust.get_score` |\n| 1 | **Descubrir** | Qué hay disponible | `registry.search` · `registry.get_organization` · `registry.manifest` · `scheduling.check_availability` · `services.list` · `a2a.get_agent_card` |\n| 2 | **Entender** | Dimensiones y reglas del servicio | `service.get` · `contract.get` |\n| 3 | **Comprometer** | Identidad del cliente y reserva | `clients.get_or_create` · `scheduling.book` · `scheduling.confirm` |\n| 4 | **Gestionar** | Estado y transiciones | `lifecycle.get_state` · `lifecycle.transition` · `scheduling.reschedule` · `scheduling.cancel` |\n| 5 | **Verificar** | Evidencia de que ocurrió | `delivery.checkin` · `delivery.checkout` · `delivery.record_evidence` |\n| 6 | **Cerrar** | Documentación y cobro | `documentation.create` · `payments.create_sale` · `payments.record_payment` · `payments.get_status` |\n| — | **Recursos** | Espacios físicos y equipamiento | `resource.list` · `resource.get` · `resource.create` · `resource.update` · `resource.delete` · `resource.get_availability` |\n| — | **Resolver admin** | Portabilidad y telemetría | `resolve.register` · `resolve.update_endpoint` · `telemetry.heartbeat` |\n| — | **Inteligencia de red** | Benchmarks de mercado anonimizados | `market.list_segments` · `market.get_benchmark` |\n| — | **Discovery (cold start)** | Taxonomía sin conocimiento previo — qué verticals, regiones y eventos existen | `registry.list_verticals` · `registry.list_regions` · `registry.list_event_types` |\n\n*El servidor envía telemetría anónima al arrancar para estadísticas del protocolo. Se puede desactivar con `SERVICIALO_TELEMETRY=false`. Adicionalmente, los servidores autenticados emiten telemetría operacional bucketeada para alimentar los benchmarks de red — opt-out con `SERVICIALO_OPERATIONAL_TELEMETRY=false`. Ver [`docs/telemetry-operational.md`](./docs/telemetry-operational.md).*\n\nEl protocolo garantiza que cualquier agente pueda completar el ciclo completo con cualquier implementación compatible.\n\n### Ejemplos completos\n\n**[Sesión de kinesiología](./examples/kinesiology-session.md)** — Vertical salud. Registro de entrada con GPS, ficha clínica firmada, pago por transferencia.\n\n**[Reparación eléctrica](./examples/home-repair.md)** — Vertical hogar. Visita a domicilio, fotos antes/después, lista de verificación, firma del cliente, pago en efectivo.\n\n### A2A Ready\n\nServicialo soporta [A2A (Agent-to-Agent)](https://a2a-protocol.org/) como extensión opcional, permitiendo que agentes externos (Salesforce Agentforce, Google ADK, etc.) descubran y reserven servicios sin pasar por MCP.\n\nGuía completa: [`docs/a2a-interoperability.md`](./docs/a2a-interoperability.md)\n\n### Inteligencia de red — benchmarks de mercado\n\nCada nodo que ejecuta el MCP server autenticado emite eventos operacionales anonimizados (`booking_created`, `service_completed`, `dispute_opened`, `payment_settled`) con valores **bucketeados** (precios en bandas, duraciones en rangos, regiones a nivel país, fingerprint en lugar de slug). El registry agrega esos eventos y publica distribuciones por (vertical × región × evento) bajo dos reglas estrictas:\n\n- **k-anonimato ≥ 5** — una segmento se publica sólo si ≥ 5 organizaciones distintas contribuyeron data.\n- **Contribuir-para-acceder** — nodos que no aportan telemetría ven datos con 90 días de delay; nodos activos contribuyentes ven en tiempo real. Sin tier de pago.\n\nDos formas de consumir:\n\n- **Pull** — `GET /api/benchmarks` y `GET /api/benchmarks/segments`, o las tools MCP `market.get_benchmark` / `market.list_segments`.\n- **Push** — suscribirse al evento `benchmark.weekly_snapshot` vía [Webhooks API](./WEBHOOKS.md). El registry dispara un snapshot cada lunes 00:00 UTC con HMAC-signed payload.\n\nDetalles: [`docs/benchmarks.md`](./docs/benchmarks.md) · [`docs/telemetry-operational.md`](./docs/telemetry-operational.md) · [`GOVERNANCE.md`](./GOVERNANCE.md#contribute-to-access-policy-v01) · [`WEBHOOKS.md`](./WEBHOOKS.md)\n\n---\n\n## Los 7 principios\n\n| # | Principio | |\n|:-:|-----------|---|\n| 1 | **Todo servicio tiene un ciclo** | No importa si es un masaje o una auditoría. El protocolo define estados independientes para observar el ciclo completo: entrega, evidencia, aceptación y liquidación. |\n| 2 | **La entrega debe ser verificable** | Sin evidencia suficiente, una entrega no puede considerarse acreditada con el nivel de certeza requerido. El protocolo define qué constituye evidencia válida para que humanos y agentes AI puedan confiar en ella. |\n| 3 | **El pagador no siempre es el cliente** | En salud paga la aseguradora. En corporativo paga la empresa. En educación paga el apoderado. El protocolo separa explícitamente al cliente del pagador. |\n| 4 | **Las excepciones son la regla** | Inasistencias, cancelaciones, reagendamientos, disputas. Un servicio bien diseñado define qué pasa cuando las cosas no salen según el plan. |\n| 5 | **Un servicio es un producto legible por máquinas** | Tiene nombre, precio, duración, requisitos y resultado esperado. Definido así, cualquier agente AI puede descubrirlo, coordinarlo y cerrarlo con la misma confianza que un humano. |\n| 6 | **El acuerdo es separado de la entrega** | La Orden de Servicio define lo acordado. El servicio atómico define lo entregado. Son dos objetos distintos con dos ciclos de vida distintos. |\n| 7 | **La inteligencia colectiva es un bien común del protocolo** | Cada nodo que implementa el protocolo contribuye datos operacionales. La inteligencia agregada mejora a todos los nodos — como Waze, donde cada conductor contribuye y todos navegan mejor. Ninguna implementación es dueña de los datos de la red. |\n\n---\n\n## Arquitectura por capas\n\nAdopta solo lo que necesitas. Core cubre el ciclo completo de entrega. Las extensiones agregan capacidades para operaciones especializadas.\n\n### Servicialo Core — `estable`\n\nTodo lo necesario para modelar un servicio profesional de principio a fin.\n\nPara cualquier plataforma donde dos partes toman un compromiso de entrega y necesitan una cuenta verificable de lo que ocurrió — desde una sociedad de psicólogos hasta una empresa de limpieza con múltiples cuentas, equipos y personal.\n\nIncluye: 8 dimensiones · ciclo de vida 6+3 (6 estados core + 3 financieros opcionales) · 6 flujos de excepción · 7 principios fundamentales · gestión de recursos · órdenes de servicio · prueba de entrega · protocolo MCP (40 herramientas) · resolver de descubrimiento (análogo a DNS, sobre HTTP) · interoperabilidad A2A · inteligencia de red (benchmarks bucketeados con k-anonimato ≥5 y contribuir-para-acceder) · webhooks para distribución push · descubrimiento de taxonomía sin conocimiento previo (cold-start)\n\n### Servicialo/Finanzas — `en diseño`\n\nDistribución de pagos entre profesional, organización e infraestructura — con reglas claras de liquidación.\n\nPara plataformas que intermedian pagos entre clientes y profesionales, o que cobran comisiones.\n\n### Servicialo/Disputas — `en diseño`\n\nResolución formal de disputas. Objetivo de diseño: automatizar los casos cuya evidencia satisface reglas previamente acordadas; el arbitraje por pares del mismo vertical es una línea de investigación.\n\nPara plataformas con volumen suficiente o donde el monto por servicio hace que las disputas sean económicamente relevantes.\n\n---\n\n## Schema\n\nJSON Schemas para validación automática: [`schema/service.schema.json`](./schema/service.schema.json) y [`schema/service-order.schema.json`](./schema/service-order.schema.json)\n\n```yaml\n# ─────────────────────────────────────────────\n# SERVICIALO v0.9\n# Dos entidades: Orden + Servicios atómicos\n# ─────────────────────────────────────────────\n\norden_de_servicio:\n  id: texto                      # Identificador único\n  alcance: texto                 # Qué se acuerda entregar\n  precio: número                 # Precio total acordado\n  esquema_pagos: texto           # prepago | por_sesión | mensual\n  currency: texto                # ISO 4217\n\n  servicios[]:                   # Cada servicio atómico — 8 dimensiones\n\n    servicio:\n      id: texto\n      orden_de_servicio_id: texto  # Referencia a la Orden padre\n      tipo: texto                # Categoría del servicio\n      vertical: texto            # salud | legal | hogar | educación | ...\n      nombre: texto              # Nombre legible\n      duración_minutos: entero\n      visibilidad: texto         # public | unlisted | private\n\n      proveedor:\n        id: texto\n        credenciales: texto[]    # Certificaciones requeridas\n        puntaje_confianza: número  # 0-100 calculado por historial\n        organización_id: texto\n\n      cliente:\n        id: texto\n        pagador_id: texto        # Puede diferir del cliente\n\n      agenda:\n        solicitado_en: fecha_hora\n        agendado_para: fecha_hora\n        duración_esperada: minutos\n\n      ubicación:\n        tipo: presencial | virtual | domicilio\n        dirección: texto\n        recurso_id: texto        # Opcional — referencia a recurso físico\n\n      ciclo_de_vida:\n        estado_actual: enum      # 6 core + 3 financieros opcionales + excepciones\n        transiciones: transición[]\n        excepciones: excepción[]\n\n      prueba_de_entrega:\n        entrada: fecha_hora\n        salida: fecha_hora\n        duración_real: minutos\n        evidencia: evidencia[]   # GPS, firma, fotos, documentos\n\n      cobro:\n        orden_de_servicio_id: texto  # Referencia a la Orden padre\n        monto:\n          valor: número\n          moneda: texto          # ISO 4217\n        pagador: referencia\n        estado: pendiente | cobrado | facturado | pagado | disputado\n        cobrado_en: fecha_hora\n        documento_tributario: referencia  # Boleta/factura si se emitió\n\n      mandato:                   # Delegación explícita a agente IA\n        mandato_id: texto        # UUID único\n        principal_id: texto      # Humano u organización\n        agente_id: texto         # Agente que recibe la delegación\n        alcances: texto[]        # resource:action (e.g. schedule:write)\n        estado: activo | expirado | revocado | suspendido\n\n# Ledger: proyección calculada desde entregas + términos comerciales +\n# eventos de liquidación — nunca un saldo editable a mano\n```\n\n---\n\n## Implementaciones\n\nCualquier plataforma puede implementar Servicialo. Para ser listada debe modelar las 8 dimensiones, implementar los 6 estados core (los 3 financieros son opcionales), manejar al menos 3 de los 6 flujos de excepción, adherir a los 7 principios fundamentales y exponer al menos un binding máquina a máquina que implemente los perfiles Core (HTTP, MCP, A2A u otro equivalente — una implementación puramente HTTP es conforme sin MCP; MCP es la vía recomendada para agentes). La verificación es manual hoy (PR + revisión del equipo); la suite automatizada de certificación es parte del roadmap.\n\n| Plataforma | Vertical | Cobertura | Estado |\n|------------|----------|-----------|:------:|\n| [**Coordinalo**](https://coordinalo.com) | Healthcare | 8/8 dimensiones · ciclo 6+3 completo · 6/6 excepciones · 7/7 principios | Live |\n\n> Coordinalo es la implementación de referencia — no el protocolo. El segundo nodo es una oportunidad abierta — ver [`IMPLEMENTORS.md`](./IMPLEMENTORS.md).\n\n### Para implementadores\n\nGuía paso a paso para construir una plataforma compatible desde cero — 8 pasos, el primero toma 20 minutos.\nEmpezar aquí: [`IMPLEMENTING.md`](./IMPLEMENTING.md) ([English](./IMPLEMENTING.en.md))\n\nReferencias adicionales:\n- [`schema/evidence/`](./schema/evidence/) — Schemas de evidencia por vertical (salud, hogar, legal, educación, consultoría)\n- [`ERRORS.md`](./ERRORS.md) — Códigos de error del protocolo\n- [`WEBHOOKS.md`](./WEBHOOKS.md) — Notificaciones asíncronas de cambios de estado (v0.2 — eventos del registry estables)\n\n---\n\n## Qué hay en este repositorio\n\n```\nservicialo/\n├── app/                  # servicialo.com — sitio del protocolo (Next.js)\n├── components/           # Componentes del sitio\n├── examples/             # Conversaciones agente-servidor\n├── lib/                  # Datos del protocolo\n├── packages/\n│   └── mcp-server/       # @servicialo/mcp-server — servidor MCP (npm)\n├── schema/               # JSON Schemas para validación\n│   ├── evidence/         # Schemas de evidencia por vertical\n│   │   ├── base.schema.json       # Envelope compartido\n│   │   ├── health.schema.json     # Salud\n│   │   ├── home.schema.json       # Hogar\n│   │   ├── legal.schema.json      # Legal\n│   │   ├── education.schema.json  # Educación\n│   │   └── consulting.schema.json # Consultoría\n│   ├── service.schema.json\n│   ├── service-order.schema.json\n│   └── ...\n├── protocol/\n│   └── manifest.yaml     # Fuente única de verdad: versión, tools, estados, extensiones\n├── SPEC.md               # Quick spec — referencia autocontenida para evaluadores\n├── PROTOCOL.md           # Especificación completa\n├── ERRORS.md             # Códigos de error del protocolo\n├── WEBHOOKS.md           # Especificación de webhooks (v0.2)\n├── IMPLEMENTORS.md       # Guía para construir una implementación\n├── GOVERNANCE.md         # Gobernanza de red y política de datos\n└── README.md\n```\n\n|  | Versión | Estado |\n|---|---------|--------|\n| Protocol | 0.10 | Draft |\n| @servicialo/mcp-server | 0.9.13 | [npm](https://www.npmjs.com/package/@servicialo/mcp-server) |\n\n---\n\n## Ecosystem\n\n- [Telemetría de red](https://servicialo.com/network) — instalaciones del MCP server reportadas por telemetría (no equivale a implementaciones adoptadas)\n- [Implementadores](https://servicialo.com/implementors) — implementaciones verificadas del protocolo\n- Using Servicialo? [Open an issue](https://github.com/servicialo/mcp-server/issues/new) to get listed\n\n---\n\n## Licencia\n\nApache-2.0 — Servicialo es un protocolo abierto. Cualquiera puede implementarlo.\n",
  "bytes": 29207,
  "sha": "9f6fef45dc931c550f91a141ffca969fc8fa6c90317ec62b49e368b187560a38",
  "repo_slug": "servicialo/servicialo",
  "fonte": "repo",
  "truncated": false,
  "api": "https://agentalog.com/api/listings/mcp_com_servicialo_mcp_server_7813e0c2/readme"
}