Event-Sourced Digital Twin Platform | Dweve Twin

Twin is an event-sourced digital twin platform with three clocks on every event, branching scenarios and self-hosted operation. Publishing in round nine.

Twin es una plataforma de gemelos digitales basada en eventos. Mantiene el registro operativo en tu infraestructura para que puedas reproducir el historial y responder preguntas después de un cambio. Es de código abierto bajo Apache-2.0 y se publica en la novena ronda del programa de lanzamiento de la fundación de Dweve, con su documentación en docs.dweve.com el mismo día.

Twin es un gemelo digital para las cosas de las que la gente depende: cada cambio recibe una línea y las líneas antiguas permanecen.

Autohospedado en infraestructura controlada por el operador

Un gemelo digital basado en eventos donde el registro es el log y cada estado actual se deriva del historial.

Gemelo es código abierto bajo Apache-2.0. Se publica en la novena ronda del programa de lanzamiento de la fundación; una vez hecho, ejecútalo en infraestructura que controles y pregunta directamente al pasado.

Mantén el registro desde el primer evento

Registros operativos estructurados para sistemas responsables.

Modelos de simulación que se conectan al estado operativo.

Una superficie de políticas para operaciones reales.

Una consulta temporal o de relaciones no reemplaza el historial de eventos con una respuesta conveniente. Gemelo deriva la vista solicitada de ese historial y mantiene explícita la ruta a través de proyecciones, relaciones y tiempo.

Esa separación importa cuando se reconstruye una proyección o llega un evento tardío. La misma pregunta puede ejecutarse de nuevo contra el historial enmendado, mientras que la respuesta anterior permanece ligada a lo que se sabía cuando se produjo.

La vista puede cambiar cuando el historial cambia sin convertirse en el registro mismo.

Una respuesta rápida sigue siendo una lectura del historial, nunca un reemplazo de él.

A la misma persona se le puede permitir ver un activo mientras está de turno y negársele después de que termine el turno. La asignación, la ubicación y el estado del activo pueden importar junto con un rol, por lo que una lista de permisos estática no puede describir cada decisión legítima.

Gemelo evalúa esas condiciones contra el estado operativo registrado y mantiene la decisión con sus entradas. Un revisor puede ver quién preguntó, qué se le asignó, qué condiciones se aplicaron y por qué se permitió o denegó el acceso en ese momento.

El permiso es un evento evaluado, no una clave que dura para siempre.

Una auditoría posterior utiliza las condiciones registradas con la decisión original.

Gemelo mantiene su modelo de eventos y relaciones separado de cualquier estándar industrial individual. Los adaptadores pueden leer y escribir los modelos ya en uso, mientras que el núcleo conserva una cuenta consistente de tiempo, procedencia y cambio.

No todos los constructos tienen un equivalente exacto. Por lo tanto, la transferencia incluye un informe de pérdidas que identifica qué se representó, qué se transformó y qué no se pudo transferir.

La interoperabilidad sigue siendo revisable porque la evidencia de la traducción viaja con la entrega.

El adaptador hace explícita la diferencia en lugar de ocultarla tras una exportación exitosa.

Un modelo de activo, clínico o de proceso sigue siendo propiedad de su dominio. Twin lo acepta mediante un adaptador y añade historial operativo sin pedir a la organización que reemplace primero todos los modelos existentes.

Cuando la información sale de nuevo, el destinatario recibe el mapeo y sus límites. Un revisor puede ver qué entró en Twin, qué cambió de forma y qué se omitió antes de aprobar la entrega.

El dominio conserva su modelo mientras la entrega gana un registro revisable.

La adopción comienza desde los modelos que ya soportan el trabajo.

dos permitidos, tres rechazados con motivos

misma identidad, decisión renovada, ilustrativo

Asignado al contrato de mantenimiento de pump-4471 en un sitio

una identidad, evaluada en cada solicitud

desde la oficina del sitio, dentro del turno

Dentro del contrato, dentro del turno y en el sitio aprobado: se abre el historial de la bomba.

Una segunda visita en las mismas condiciones: la decisión se toma de nuevo y la respuesta es la misma, porque todas las condiciones siguen cumpliéndose.

La misma identidad fuera del turno programado: rechazado. No se revocó nada y nadie tuvo que recordar nada; la condición de tiempo falló, y el rechazo indica la siguiente ventana válida.

{ "outcome": "refused", "policy": "next valid window", "severity": "warning" }

solicitando el historial de la bomba de otro sitio

El historial de la bomba del sitio vecino queda fuera del contrato asignado: rechazado, con el límite indicado en lugar de un resultado vacío silencioso.

{ "outcome": "refused", "policy": "asset outside grant", "severity": "warning" }

La solicitud llega desde una ubicación no aprobada: rechazada, y el origen se registra para que el equipo de seguridad pueda correlacionarlo con el historial de activos al que se accedía.

{ "outcome": "refused", "policy": "request origin rejected", "severity": "warning" }

cada rechazo indica la condición que falló

El acceso depende de la solicitud y de la persona. Twin evalúa rol, asignación, tiempo y ubicación de forma conjunta, y registra el motivo cuando se rechaza una solicitud. La misma persona puede recibir respuestas distintas al cambiar el turno, el sitio o el activo, sin una mutación permanente del rol. La decisión queda vinculada al sujeto, al recurso y a la condición fallida para su revisión posterior. Un cruce concedido está limitado por la relación y la ventana de tiempo que lo justificaron, en lugar de convertirse en un rol amplio que sobreviva a la tarea original. Un rechazo es evidencia útil porque nombra la condición que un operador puede corregir o impugnar. No es necesario que cambie ningún rol permanente para que cambie la respuesta.

Conserva el registro. Deriva el estado. Pregunta al pasado directamente.

La identidad y el rol son solo parte de la cuestión. Twin también puede evaluar condiciones de asignación, tiempo, ubicación, dispositivo y política cuando una persona solicita una página o un historial de activos. Cada una de esas condiciones se comprueba en el momento de la solicitud.

A la misma persona se le puede permitir el acceso durante el turno y denegárselo más tarde sin que cambie ningún rol permanente. La decisión registra el sujeto, el recurso, el tiempo y la regla fallida, de modo que una solicitud denegada no se convierte en un callejón sin salida sin explicación. Un revisor posterior puede ver así el turno que marcó la diferencia.

El registro conserva el cambio, su contexto y la decisión que lo siguió.

historia escrita el mismo día, ilustrativa

ensamblado después, con quien y lo que quede

qué hizo el activo en marzo y qué se sabía entonces

el mismo intervalo, orden vinculada al resultado

una historia, varias lecturas temporales

Cuando alguien pregunta en julio por qué se tomó una decisión en marzo, la respuesta debe ser el registro de marzo, no una reconstrucción a partir de las exportaciones actuales. Twin conserva el conjunto de evidencia relevante junto con la decisión. La pregunta puede seleccionar lo que se sabía entonces, qué regla se aplicaba entonces y qué corrección llegó después. Eso evita que una revisión justa convierta el conocimiento de hoy en la certeza de ayer. La respuesta lleva sus eventos fuente y linaje junto a la conclusión, de modo que otro revisor pueda repetir la pregunta en lugar de confiar en la primera explicación. Una corrección posterior sigue siendo visible sin sacar la decisión de marzo de su contexto.

Una pregunta de auditoría puede solicitar el estado de marzo, la información conocida en un día concreto o la regla vigente entonces. Twin reconstruye la lectura adecuada a partir de los eventos retenidos en lugar de pedir a las personas que la reconstruyan a partir de exportaciones.

La respuesta mantiene su forma temporal, los eventos fuente y el linaje visibles junto a la conclusión. Un revisor puede repetir la pregunta y entender por qué una corrección posterior pertenece a una respuesta pero no a otra.

El gemelo conserva el evento, su contexto y la decisión que respaldó en un único registro operativo.

El registro de eventos conserva el hecho y el momento en que ocurrió.

Una vista derivada puede seguir siendo rápida mientras cada respuesta histórica siga siendo trazable.

Un evento almacenado puede responder a una pregunta que nadie sabía que debía hacer el día en que se escribió. La respuesta sigue mostrando qué ocurrió, qué se sabía en ese momento y quién o qué regla determinó el resultado.