Eventos · Atrium

MÓDULO DE EVENTOS

ESPECIFICACIÓN TÉCNICA · GESTIÓN DE EVENTOS Y ACREDITACIÓN DE ASISTENCIA

Versión 2.03 · Proyecto Renacer Lacustre · Portal Red-Lago · Documento de Arquitectura de Sistemas · Listo para implementación

بِسْمِ اللَّهِ الرَّحْمَٰنِ الرَّحِيمِ

En el nombre de Dios, el Clemente, el Misericordioso.

« El instrumento sirve; el espíritu dirige »

Documento hermano: léase junto a «Sistema de Mérito y Gobernanza», que define el cálculo de puntos aquí referido.

Qué añade la 2.01 (6 sep 2026). Nada del cuerpo original cambia. Se incorporan tres puntos de dirección que faltaban: §12 — los dos modelos que se evaluarán para decidir quién genera los eventos; §13 — el canal por el que la ciudadanía propone encuentros que no convoca la Fundación; y en §4, la obligación del moderador de aportar las dos imágenes del evento antes de publicarlo.

Qué añade la 2.02 (8 sep 2026). Tampoco cambia nada del cuerpo. Se incorpora la §14, con las decisiones del fundador sobre datos, consentimiento y aforo: quién ve la lista de asistentes, por qué la geolocalización no se guarda, cómo se resuelve un carnet leído dos veces sin conexión, en qué condiciones entran los menores, cómo se pide el consentimiento de imagen, y cómo funciona la lista de espera. Se escriben aquí porque sin ellas el modelo de datos no se puede escribir sin inventar respuestas. En la §13 queda además la dirección del canal de propuestas. Tres puntos menores quedan como criterio por defecto, revisable, y están señalados como tales; abierto de verdad queda uno solo: los menores de 7 años para abajo.

Qué añade la 2.03 (15 sep 2026). Por primera vez cambia el cuerpo original, y a propósito: la §2 gana dos campos, la justificación —por qué hace falta el encuentro y qué lo motiva— y los objetivos —qué se quiere conseguir—. Decisión del fundador. Un evento decía cuándo, dónde y para cuánta gente, pero no para qué; y la §13 promete que una propuesta aceptada se convierte en evento sin volver a escribirla, promesa que no se cumplía si la propuesta traía su porqué y el evento no tenía dónde guardarlo. Entran también en la §4 —con la regla de que, como las dos imágenes, se pueden guardar en borrador pero no publicar sin ellos, regla confirmada por el fundador— y en la lista de la §13. Los dos campos ya existen en la base de datos (15 sep 2026).

1. Introducción y propósito

El Módulo de Eventos es la infraestructura que gestiona la interacción física y virtual entre la Fundación y sus colaboradores: la convocatoria, el acceso, el registro de asistencia y el reconocimiento del aporte de cada participante. Vincula el prestigio del usuario —su rango— con beneficios tangibles de acceso, y convierte cada acto del mundo real en un dato verificable, sin papeleo.

Relación con el Sistema de Mérito. Este módulo es una de las fuentes de acciones que alimentan el motor de mérito —en concreto, el principal punto de entrada del Carril 2 (acciones atestiguadas)—. El cálculo de los puntos no se define aquí, sino en el documento hermano; este módulo solo los origina y los otorga. Ambos hacen sinergia, pero cada uno se sostiene por sí mismo: el Módulo de Eventos puede existir sin el de Mérito, y viceversa.

2. Anatomía del evento (metadatos)

Cada evento creado contiene el siguiente esquema de datos, obligatorio para su indexación en la web y la app:

Identidad: ID único de evento (UUID), título y temática (Ciencia y Tecnología, Educación y Cultura, Legal y Fiscal, Economía Circular, Salud y Bienestar, Acción Social o Polivalente).
Justificación y objetivos: por qué hace falta el encuentro y qué lo motiva, y qué se quiere conseguir con él. Son dos textos separados, porque el porqué y el para qué se leen y se evalúan por separado. (Desde la 2.03.)
Cronología: fecha, hora de apertura de puertas y hora de inicio.
Geolocalización: localidad (nombre del sitio), dirección física y coordenadas GPS, para el Radar de la app.
Autoría: ponentes, responsables de Nodo y organizadores.
Modalidad de entrada: libre (requiere registro previo, sin coste) o de pago (solo para galas de recaudación; sin criptomonedas).

3. Estructura del módulo

Toda la operación de un evento vive en una sola ficha, dentro del Módulo de Eventos. Al crear un evento se abre su ficha, organizada en dos pestañas hermanas:

Módulo Eventos → Crear evento → [ Configuración · Gestión del Evento ]

La Configuración define el evento; la Gestión del Evento administra la asistencia y otorga el mérito. La presencia y los puntos viven siempre dentro del evento que les dio origen, nunca sueltos. El recorrido del moderador es uno solo y natural: crea el evento, lo configura, le sube flyer y documentos; el día del acto pasa lista con la app; y vuelve a la Gestión del Evento para revisar, ajustar y otorgar.

4. Configuración del evento

Primera pestaña de la ficha. Reúne la definición del evento y sus acciones de mantenimiento:

Datos: los campos de los metadatos (sección 2): título, tipo, justificación y objetivos, cronología, lugar y cupo.
Cargar flyer: imagen de convocatoria para la web y la app. Es la que se ve en la tarjeta de la cartelera y como cartel de la ficha.
Cargar el sello: la pieza conmemorativa que recibirá quien asista (§9). Una misma imagen puede servir para el flyer y para el sello, y de hecho es lo preferible: así el recuerdo y la convocatoria hablan el mismo idioma.
Cargar documentos: agenda, materiales y soportes asociados al evento.

Obligación de quien convoca. Presentar un evento como es debido incluye aportar las dos imágenes. No es un adorno: el flyer es lo que hace que alguien se detenga a leer la convocatoria, y el sello es lo que le quedará de haber ido. Un evento sin ellas se puede guardar, pero no publicar.

Y lo mismo vale para la justificación y los objetivos (2.03). Quien se acerca a una convocatoria tiene derecho a saber para qué es antes de decidir si va. Un borrador puede guardarse sin ellos; una convocatoria no se publica sin ellos.

Modificar: edición de cualquier dato del evento mientras esté abierto.
Eliminar: baja del evento, con confirmación.
Plantilla de criterios: al elegir el tipo de evento, el sistema carga automáticamente la plantilla de puntuación que le corresponde (sección 7), que regirá el cálculo en la Gestión del Evento.

5. Gestión del Evento — Panel del Moderador

Segunda pestaña de la ficha, y corazón operativo del módulo. Aquí el moderador del Nodo registra la asistencia y otorga el mérito de su evento. El sistema hace el trabajo pesado; el moderador evalúa y firma.

5.1 Lista de participantes

La lista vive dentro del portal, atada al evento —no en un archivo suelto, que sería manipulable—. El Excel queda como comodidad en los dos extremos: se puede importar un Excel para precargar invitados de golpe, y exportar la lista final firmada para los registros del Nodo. La fuente de verdad es siempre el portal.

5.2 Check-in por QR

QR dinámico y firmado: el código del carnet rota cada pocos segundos y va firmado criptográficamente; es imposible de copiar y reutilizar (una captura de pantalla no sirve).
Sentido del escaneo: el moderador escanea el carnet de cada asistente desde su app; él confirma la presencia real.
Respuesta visual: al escanear, la app responde al instante — verde/dorado: acceso pleno (rango alto) · azul: validado · rojo: inválido o ya utilizado.
Prevención de doble uso: un mismo carnet no puede validarse dos veces en el mismo evento.

5.3 Presencia y graduación de rol

El QR marca la presencia —estuvo: sí/no— de forma automática. Pero no todos los asistentes aportan igual, así que el panel permite al moderador graduar el rol de cada quien —presencia, rol activo o liderazgo—, dentro del rango pautado por la plantilla. Así el sistema premia el impacto real, no solo el haber estado.

5.4 Cálculo y otorgamiento en lote

Al cerrar el evento, el panel toma los criterios de la plantilla del tipo de acto, calcula los puntos sugeridos para cada asistente confirmado —según las siete variables del Sistema de Mérito— y los presenta en una lista lista para firmar. El moderador revisa, ajusta al alza a quien lideró si procede, y otorga en lote con un clic. Los puntos se asientan intransmisibles, con nombre, fecha, evento y la firma del moderador.

5.5 Modo sin conexión (offline-first)

Las actividades de campo ocurren en el manglar y en la orilla, donde no hay señal. La app del moderador puede escanear y registrar sin conexión, guardar en el teléfono y sincronizar cuando vuelva la cobertura. Sin esto, el carril moriría justo en el caso más importante.

5.6 Cierre anti-fraude

Geocerca opcional —el check-in solo cuenta dentro del radio del evento—; el otorgamiento siempre pasa por el moderador, humano responsable con nombre; y todo queda señalable por la comunidad. Confianza por defecto, auditoría por excepción.

6. Las dos mitades sincronizadas

El panel vive en dos lugares que se hablan entre sí, cada uno donde tiene sentido:

App móvil del moderador — la captura. Lector de QR y «pasar lista» en vivo, en el terreno, aunque sea sin señal.
Portal web — la administración. Crear el evento, definir criterios, ver la lista, cerrar y otorgar. Ubicación exacta: Módulo Eventos → Crear evento → Gestión del Evento, dentro del Área de Trabajo del Nodo, vinculada al carnet de cada participante.

La app captura; el portal administra; ambos se sincronizan.

7. Plantillas de criterios por tipo de acto

El mismo mecanismo, vestido según el caso. Al crear el evento, el tipo elegido carga su plantilla, que orienta qué variables del motor de mérito pesan más:

Tipo de acto	Qué pondera
Exposición / charla	Asistencia + rol de ponente (tracción social, intelecto)
Actividad de campo	Asistencia + responsables de tareas (esfuerzo físico, tiempo, compromiso)
Prototipado tecnológico	Asistencia + roles de desarrollo (intelecto, solución de problemas complejos)
Iniciativa legal / fiscal	Asistencia + redactores y responsables (compromiso, intelecto)

Uno solo aprende a usar el panel, y le sirve para todos los tipos de acto.

8. Beneficios por rango

El mérito abre puertas en los eventos. El sistema aplica automáticamente una matriz de beneficios según el rango del usuario, con lenguaje digno y sin distinciones de ostentación:

Rango	Beneficio en eventos	Tipo de acceso
Alevín / Camarón	Tarifa base, cuando el acto tenga coste	General
Manatí	Reducción parcial + material digital	General + material
Delfín	Reducción mayor	Lugar preferente
Manglar	Acceso sin coste	Pleno + espacios de trabajo técnico
Relámpago	Invitación de honor	Invitado especial / ponente

9. Sello conmemorativo de asistencia

Al finalizar el evento, cada participante recibe un sello conmemorativo —un coleccionable de participación que se suma a su perfil como memoria histórica de su recorrido junto al lago—. Es un reconocimiento de honor, nunca de voto: primo hermano del NFT de Mecenas, aumenta el valor simbólico del perfil sin tocar jamás la gobernanza.

10. Ruta de publicación

El ciclo de vida de un evento, de su creación a su cierre:

Creación. El responsable del Nodo carga el evento en la Configuración.
Aprobación de la DAO. Si el evento requiere fondos de la Fundación, la DAO aprueba el presupuesto antes de publicarlo.
Publicación. Sincronización en el módulo Eventos de la web y aviso push por la app (Radar), que muestra los eventos cercanos.
Registro / reserva. Apertura del registro de asistentes —y de la venta solo si es una gala de pago—.
Ejecución. Registro de asistencia por check-in QR y otorgamiento de puntos (sección 5).
Cierre. Publicación de fotos y vídeos en el Acta Diurna, y emisión del sello conmemorativo.

11. Lo que el módulo NO utiliza

Para fidelidad al principio de abstracción del proyecto, este módulo se construye sin la maquinaria innecesaria de versiones anteriores:

No acuña los tickets como NFT en una cadena de bloques, ni usa la red Arbitrum ni verificación on-chain para el acceso.
No requiere billetera de criptomonedas ni comisiones de red para asistir a un acto.
No usa criptomonedas como medio de pago; el cobro, reservado a galas, emplea medios tradicionales.

En su lugar: el QR es un código firmado por el propio portal y validado contra su servidor —más rápido, gratuito y a prueba de copias—. La tecnología se mantiene invisible al servicio de las personas y del lago.

12. Quién genera los eventos: dos modelos por evaluar

Este módulo describe cómo se gestiona un evento, pero no decide quién tiene la potestad de convocarlo. Esa es una cuestión de gobernanza, y quedan sobre la mesa dos modelos, que se evaluarán antes de fijar uno:

a · Dinámica descentralizada. Grupos seleccionados y elegidos por concurso o por mérito, que presentan una propuesta de evento interesante y prometedora para la tracción de interés hacia el proyecto. Cada convocatoria nace de quien la propone y la sostiene.

b · Dinámica centralizada. Una delegación permanente, cuyos miembros son elegidos por votación, encargada de la gestión de los eventos —desde la parte digital hasta la gerencia y la logística en físico, y todo lo que ello conlleva—. Ante esa delegación presentan su propuesta quienes deseen convocar un encuentro.

Lo que no cambia en ninguno de los dos. El mérito lo otorga siempre el moderador del Nodo, con su nombre y su firma (§5.4); nadie se acredita a sí mismo; y la aprobación del presupuesto, cuando haya fondos de la Fundación de por medio, sigue siendo de la DAO (§10.2). Lo que se está decidiendo aquí es quién convoca, no quién puntúa ni quién aprueba el gasto.

DÓNDE SE DECIDE ESTO, Y DÓNDE NO. Elegir entre los dos modelos es una decisión de gobernanza, y por tanto se vota en la DAO, igual que se aprueba allí el presupuesto de cada evento. Este módulo no aloja esa votación ni la refleja como una opción a elegir aquí dentro: se limita a saber cuál de los dos modelos está vigente y a comportarse en consecuencia.

Es la misma regla que ya rige para el resto del módulo, y conviene dejarla escrita para que no se erosione con el tiempo: el panel del moderador no tiene botón de votar. Si una decisión requiere el juicio de la comunidad, esa decisión vive en la DAO y aquí solo se ve su resultado. Mezclar las dos cosas haría que la gobernanza se decidiera en la sala equivocada, y con el tiempo nadie sabría dónde se decide qué.

13. Canal de propuestas de la ciudadanía

Sea cual sea el modelo que se adopte, hace falta una puerta de entrada para quien tiene una idea y no pertenece a ningún grupo convocante. No todos los encuentros nacerán de la Fundación, y sería un error que los que nacen fuera no tuvieran por dónde entrar.

Por eso el módulo habilita un canal de propuestas de evento, abierto a los miembros del movimiento:

Quien propone describe el encuentro con los mismos campos de la §2 —qué, por qué y para qué, cuándo, dónde, de qué naturaleza y para cuánta gente—, de modo que una propuesta aceptada se convierte en evento sin volver a escribirla.
La propuesta llega al grupo o delegación que corresponda según el modelo vigente, y no se publica sola: es una solicitud, no una convocatoria.
Quien propone recibe respuesta, y si su propuesta prospera, queda registrado como su autor.

Mientras el formulario no esté montado dentro del Portal, la puerta de entrada es una dirección de correo: eventos-redlago@proton.me. Una propuesta que llegue por ahí se atiende igual que una presentada por el formulario, y debe traer los campos de la §2 —título y temática, justificación y objetivos, fecha y horas, localidad con dirección, quién organiza y qué modalidad de entrada—, de modo que una propuesta aceptada pueda convertirse en evento sin volver a escribirla.

Cuando el formulario exista, esa dirección seguirá siendo válida: no se sustituye una puerta por otra, se suman. Hay quien no tendrá cuenta en el Portal el día que se le ocurra la idea, y esa idea no debe perderse por no tener dónde entrar.

14. Decisiones sobre datos, consentimiento y aforo

De dónde salen. Los seis puntos de esta sección son decisiones del fundador (8 sep 2026). Se escriben aquí porque el modelo de datos del módulo —las tablas que guardarán los eventos, las inscripciones y las presencias— no se puede escribir sin ellas sin inventar respuestas, y una respuesta inventada en el esquema es una respuesta que después cuesta sangre cambiar.

14.1 Quién ve la lista de asistentes

La lista de quien asiste a un encuentro no es pública, ni la ven los demás asistentes. La ve el equipo responsable del evento y sus delegados —organización, logística y gerencia—, porque es su responsabilidad: sin la lista no se pasa lista, no se prevé el agua ni el transporte, y no se cierra el acta. En los papeles del Portal ese equipo es el moderador del evento, y por encima la administración.

Es coherente con la §5.1: la lista vive atada al evento, dentro del portal, y el Excel es solo una comodidad en los dos extremos.

Decidido (8 sep 2026): la lista la ven SOLO los moderadores asignados a ese evento, no cualquier moderador del Portal. Tener rango de moderador no da derecho a ver quién fue a un acto que uno no organiza; el derecho nace de la responsabilidad sobre ese encuentro concreto, y se acaba con ella.

De aquí sale una pieza obligatoria del esquema: cada evento tiene su equipo, con nombre y apellido de quién lo compone. Sin esa tabla, la única forma de decidir quién ve la lista sería el rango global, que es justo lo que se descarta.

14.2 La geolocalización confirma, y no se guarda

La geocerca de la §5.6 sirve para una sola cosa: confirmar que la persona estaba allí. Lo que queda escrito es un sí o un no. La posición en sí no se almacena — ni en el momento del escaneo, ni después, ni «por si acaso».

Por qué. El peligro de los datos de ubicación no está en un punto suelto, sino en el rastro. Guardar dónde estuvo cada persona, acto tras acto, permite reconstruir por triangulación el mapa histórico de su vida: dónde vive, con quién anda, a qué hora sale. Un módulo de eventos no necesita eso para nada, y un movimiento ciudadano en el Zulia menos todavía. Lo que no se guarda no se puede filtrar, ni perder, ni usar contra nadie.

La geocerca sigue siendo opcional, como dice la §5.6: hay actos donde no hace falta.

14.3 El carnet leído dos veces sin conexión

En línea el caso no existe: la §5.2 ya impide validar dos veces el mismo carnet en el mismo evento, y el segundo intento responde en rojo. Sin conexión sí ocurre, porque un teléfono no sabe lo que hizo el otro; y al sincronizar llegan dos lecturas de la misma persona.

Regla: las dos lecturas se funden en una sola presencia. Manda la última —es la que refleja el estado final—, pero conserva los metadatos de la primera: la hora de llegada y qué moderador la registró.

Sí es posible, y no complica el esquema: basta con que la presencia sea única por (persona, evento) y guarde dos marcas en vez de una —la primera lectura y la última—. La presencia no se duplica, y la hora de llegada sigue siendo la de verdad y no la del segundo escaneo.

Criterio por defecto (revisable): la doble lectura se absorbe en silencio para quien escanea —la app responde lo mismo que la primera vez, sin alarma— y queda visible en el rastro de auditoría. Es la aplicación directa del principio de la §5.6: confianza por defecto, auditoría por excepción. Un moderador pasando lista bajo el sol no necesita una alerta por algo que casi siempre será un dedo que pulsó dos veces.

14.4 Menores de edad

Los menores no tienen cuenta en el Portal —así está escrito en los papeles legales—, de modo que un menor nunca se inscribe solo: entra dentro de la inscripción del adulto que lo trae.

Se admiten menores de 7 a 17 años acompañados de sus padres, y únicamente en actos cívicos y sociales que no comporten peligro para ellos: jornadas de limpieza voluntaria, colecta de semillas, charlas, desfiles y encuentros de ese orden.

Quien trae a un menor firma un descargo que hace dos cosas a la vez: exime de responsabilidad al proyecto, y carga sobre el adulto la responsabilidad completa del cuidado y el bienestar del menor.

De aquí sale una consecuencia directa para el módulo: cada evento lleva una marca de si admite menores o no, y la pone quien convoca. Un acto que no la tenga, no los admite.

Decidido (8 sep 2026): el descargo se firma DOS VECES — en el Portal y en papel. En el Portal al inscribir al menor, y queda registrado con fecha y con la versión exacta del texto que se firmó, igual que los papeles legales. Y en papel el día del acto, como respaldo físico, que el moderador marca como recibido.

Se hacen las dos cosas a propósito. La firma digital deja rastro de qué se firmó y cuándo —el papel solo, no—; y el papel cubre el caso de quien inscribe a un menor sin haber leído nada y se presenta en la orilla. Es más trabajo para quien organiza, y se asume: cuando hay un niño de por medio, la comodidad del organizador no es el criterio.

El texto del descargo debe verlo el abogado junto con los papeles v2.1.

Queda por decidir: qué pasa con los menores de 7 años para abajo. La decisión de arriba cubre de 7 a 17; por debajo de esa edad no hay regla escrita, y no me la invento.

14.5 Consentimiento de imagen

Al inscribirse en un evento, la persona responde un formulario breve de preguntas de sí o no. Una de ellas es el consentimiento para que el proyecto use su imagen con fines ilustrativos, informativos y de difusión.

El consentimiento es por evento, no de una vez para siempre: se puede decir que sí a un encuentro y que no al siguiente, y el Portal debe respetar cada respuesta por separado.

A quien haya dicho que no, se le desdibuja el rostro en las fotos que se publiquen, a petición suya.

Criterio por defecto (revisable): desdibuja quien publicó la foto —el equipo del evento—, y en la foto de grupo donde una sola persona dijo que no, se la desdibuja a ella. Si desdibujarla no es posible sin estropear la imagen, la foto no se publica. La regla se escribe ahora, antes de que ocurra el caso, porque después siempre hay prisa y siempre gana la foto bonita.

Falta ponerle un plazo. Se pondrá cuando haya alguien encargado de sostenerlo: un plazo sin responsable es una promesa vacía.

14.6 Aforo y lista de espera

Cada evento tiene su aforo, que es uno de los metadatos de la §2. Cuando se llena, quien llega después entra en lista de espera.

Decidido (10 sep 2026): el aforo cuenta a los niños también. Un adulto que trae dos menores ocupa tres plazas, no una. El aforo mide espacio físico y seguridad —cuánta gente cabe en la orilla, cuánta agua hay que llevar, a cuántos hay que poder sacar de allí si pasa algo—, y un niño ocupa sitio igual que un adulto. Contar solo adultos daría un número que no se corresponde con la gente que de verdad está en el acto, y ese es justo el número que importa cuando hay que contarlos.

Un evento lleno sigue admitiendo inscripciones: van a la cola. Un evento lleno que rechazara a todo el mundo no tendría lista de espera, y aquí la tiene.

Si se libera un cupo —una cancelación, una baja—, se ofrece por orden de llegada: el primero que esperó es el primero que entra. Sin sorteo, sin criterio, sin favor: la cola es la cola.

Criterio por defecto (revisable): quien recibe un cupo liberado tiene 48 horas para confirmarlo, y nunca más allá del comienzo del acto. Pasado el plazo, el cupo baja al siguiente de la cola. Sin ese reloj, un cupo se queda congelado en manos de alguien que ya no piensa ir, y el que sí iría se queda fuera.

En la naturaleza del problema se encuentra la solución.

Fundación Renacer Lacustre · Lago de Maracaibo, Zulia, Venezuela

Volver a la sala de Eventos