GOA-004 — Protocolo de eventos de GOA

Objetivo

Definir cómo se comunican los órganos de GOA sin acoplarse directamente entre sí.

Principio central

Los órganos no deben llamarse arbitrariamente entre ellos; deben intercambiar eventos estructurados.

Esto permite:

• sustituir componentes;
• registrar trazabilidad;
• reproducir incidentes;
• simular órganos;
• probar diferentes modelos;
• aislar fallos.

Estructura mínima de un evento

{
  "event_id": "evt_...",
  "event_type": "observation.created",
  "timestamp": "2026-08-01T23:00:00-05:00",
  "source": "observer",
  "target": ["world_model", "memory"],
  "priority": 50,
  "confidence": 0.86,
  "correlation_id": "corr_...",
  "privacy_level": "household",
  "payload": {}
}

Campos obligatorios

• event_id
• event_type
• timestamp
• source
• priority
• payload

Campos recomendados

• target
• confidence
• correlation_id
• causation_id
• privacy_level
• expires_at
• schema_version

Familias de eventos

Percepción

• perception.received
• perception.failed
• sensor.status_changed

Observación

• observation.created
• observation.updated
• observation.invalidated

Inferencia

• inference.proposed
• inference.strengthened
• inference.refuted

Estado interno

• internal_state.updated
• need.threshold_reached
• rest.requested

Motivación

• goal.proposed
• goal.updated
• goal.expired

Planificación

• action.proposed
• action.selected
• action.deferred
• action.rejected

Seguridad

• safety.approved
• safety.limited
• safety.rejected
• safety.emergency_stop

Acción

• action.started
• action.completed
• action.failed

Memoria

• episode.created
• memory.consolidated
• memory.archived
• memory.corrected

Narrativa

• narrative.fragment_created
• narrative.fragment_revised
• identity.change_proposed

Sociedad

• relationship.updated
• permission.requested
• permission.granted
• permission.denied

Prioridad

Escala inicial de 0 a 100.

• 90–100: emergencia y seguridad;
• 70–89: integridad física y errores críticos;
• 50–69: interacción activa;
• 30–49: aprendizaje y memoria;
• 10–29: reflexión y mantenimiento;
• 0–9: tareas diferibles.

Reglas

1. 1. Seguridad puede interrumpir cualquier flujo.
2. 2. Todo evento debe ser idempotente o detectable como duplicado.
3. 3. Los eventos sensibles deben indicar privacidad.
4. 4. Las inferencias deben incluir confianza.
5. 5. Las acciones deben enlazar con su decisión y resultado.
6. 6. Los órganos no deben modificar silenciosamente datos ajenos.
7. 7. Todo cambio de identidad requiere trazabilidad.
8. 8. Los eventos pueden expirar si pierden relevancia.

Flujo principal

1. 1. Percepción emite perception.received.
2. 2. Observador emite observation.created.
3. 3. Modelos actualizan contexto.
4. 4. Estado interno emite internal_state.updated.
5. 5. Motivaciones emiten goal.proposed.
6. 6. Planificador emite action.selected.
7. 7. Supervisor emite safety.approved o safety.rejected.
8. 8. Controladores emiten eventos de acción.
9. 9. Memoria crea episodio.
10. 10. Narrador crea o revisa un fragmento autobiográfico.

Transporte inicial

Para el simulador se recomienda un bus de eventos en memoria.

Después puede evolucionar a:

• colas persistentes;
• procesos separados;
• comunicación local entre Raspberry Pi y ESP32;
• registro auditable.

Preguntas abiertas

• ¿Qué eventos deben persistirse?
• ¿Cómo se evita una tormenta de eventos?
• ¿Cuándo usar comandos y cuándo eventos?
• ¿Cómo se sincronizan dos organismos?
• ¿Qué eventos pueden viajar fuera de la red local?