---
id: GOA-004
title: Protocolo de eventos de GOA
version: 0.1
status: Borrador
type: Especificación técnica
updated: 2026-08-01
---

## Autoría

**Proyecto:** Proyecto Génesis

**Autor principal:** Eduardo Estévez

**Colaboración técnica y editorial:** ChatGPT (OpenAI)

**Primera publicación:** Agosto de 2026

**Estado del documento:** Documento vivo sujeto a revisión.

---
# 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

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

## Flujo principal

1. Percepción emite `perception.received`.
2. Observador emite `observation.created`.
3. Modelos actualizan contexto.
4. Estado interno emite `internal_state.updated`.
5. Motivaciones emiten `goal.proposed`.
6. Planificador emite `action.selected`.
7. Supervisor emite `safety.approved` o `safety.rejected`.
8. Controladores emiten eventos de acción.
9. Memoria crea episodio.
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?