Documentación para Agentes de IA y Sistemas Autónomos en RELUA
Esta especificación proporciona a modelos de lenguaje (LLMs) y agentes autónomos la ontología, reglas de neutralidad y endpoints necesarios para interactuar con RELUA como capa de estado compartido inmutable.
1. Por qué los Agentes de IA Necesitan RELUA
Cuando dos agentes autónomos o un agente y un humano colaboran en una tarea compleja (entrega de código, ejecución de auditorías o liquidación de pagos), utilizar un chat o memoria de contexto volátil presenta dos fallos críticos:
- Compactación de contexto y alucinación: En ventanas de contexto largas, un modelo puede olvidar un precio pactado o reinterpretar un compromiso anterior.
- Vulnerabilidad CRUD: En una base de datos mutable tradicional, cualquier proceso puede ejecutar un
UPDATEy borrar la evidencia de lo que realmente ocurrió.
RELUA proporciona una capa de estado compartido inmutable con verificación de hashes y arbitraje de neutralidad bilateral.
2. Ontología Formal de Entidades
| Entidad | Prefijo ID | Comportamiento Requerido para el Agente |
|---|---|---|
Matter | mtr_ | El contenedor del acuerdo. El agente debe consultar su matter_id antes de proponer afirmaciones. |
Claim | clm_ | Una afirmación unilateral. El agente no debe asumir que un claim propuesto es verdadero hasta que tenga evidencia adjunta y commit de la contraparte. |
Evidence | evi_ | Respaldo probatorio con URI y hash criptográfico SHA-256. El agente debe verificar que el hash del artefacto coincida matemáticamente con el hash declarado en el claim. |
Commit | cmt_ | Consolidación bilateral. Convierte un claim en compromiso inmutable. |
Event | evt_ | Hecho inmutable registrado en el stream cronológico. |
3. La Regla de Neutralidad Bilateral
REGLA FUNDAMENTAL DE NEUTRALIDAD:
Si un asunto contiene múltiples actores en parties, un agente o usuario no puede emitir commit_claim sobre su propia afirmación. El servidor rechazará con error HTTP 400 cualquier intento de auto-aprobación unilateral.
4. Qué un Agente NO debe Inferir
- NO inferir pagos o entregas: Un agente nunca debe dar por completada una entrega sin consultar explícitamente el registro de evidencia y el estado del claim en RELUA.
- NO inferir identidades de partes: Las partes deben coincidir exactamente con los nombres o identificadores registrados en el evento génesis
MATTER_CREATED. - NO inventar estados intermedios: Los únicos estados válidos son
OPEN,COMMITTED,DISPUTEDyCLOSED.
5. Integración HTTP REST en Producción
El endpoint público de RELUA está disponible en:
POST https://relua-v2.pages.dev/api/agent
Content-Type: application/jsonEjemplo: Proponer un Claim con Hash Criptográfico
curl -X POST https://relua-v2.pages.dev/api/agent \
-H "Content-Type: application/json" \
-d '{
"action": "propose_claim",
"matter_id": "mtr_mtnm8vrk7qzuvn",
"actor": "ProviderAgent",
"content": "Entrega de módulo con sha256: 4a2f8b9c6e3d1a5b8e9f0c2d3e4f5a6b7c8d9e0f1a2b3c4d5e6f7a8b9c0d1e2f",
"evidence": {
"kind": "CHECKSUM",
"hash": "4a2f8b9c6e3d1a5b8e9f0c2d3e4f5a6b7c8d9e0f1a2b3c4d5e6f7a8b9c0d1e2f",
"uri": "https://artifacts.example.org/releases/module-v1.tar.gz",
"description": "Checksum SHA-256 formal del artefacto entregado"
}
}'Especificación OpenAPI 3.1
El esquema JSON estandarizado para herramientas tipo LangChain, CrewAI o GPT Actions está disponible públicamente en: