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.

O Twin é uma plataforma de gémeos digitais baseada em eventos. Mantém o registo operacional na tua infraestrutura para que possas reproduzir o histórico e responder a perguntas após uma alteração. É open source sob Apache-2.0 e é publicado na nona ronda do programa de lançamento da fundação Dweve, com a documentação em docs.dweve.com no mesmo dia.

O Twin é um gémeo digital para as coisas em que as pessoas confiam: cada alteração recebe uma linha e as linhas antigas permanecem.

Self-hosted em infraestrutura controlada pelo operador

Um gémeo digital orientado a eventos em que o registo é a fonte de verdade e cada estado atual é derivado do histórico.

Twin é código aberto sob a licença Apache-2.0. Será publicado na nona ronda do programa de lançamento da fundação; quando isso acontecer, execute-o na infraestrutura que controla e pergunte diretamente ao passado.

Mantenha o registo desde o primeiro evento

Registos operacionais estruturados para sistemas responsáveis.

Modelos de simulação que se ligam ao estado operacional.

Uma superfície de políticas para operações reais.

Uma consulta temporal ou de relacionamento não substitui o histórico de eventos por uma resposta conveniente. O Twin deriva a vista pedida desse histórico e mantém explícito o caminho através de projeções, relacionamentos e tempo.

Essa separação é importante quando uma projeção é reconstruída ou um evento tardio chega. A mesma pergunta pode ser executada novamente contra o histórico corrigido, enquanto a resposta anterior permanece ligada ao que era conhecido quando foi produzida.

A vista pode mudar quando o histórico muda, sem se tornar o próprio registo.

Uma resposta rápida continua a ser uma leitura do histórico, nunca um substituto dele.

A mesma pessoa pode ter permissão para ver um ativo durante o turno e ser recusada depois de o turno terminar. A atribuição, a localização e o estado do ativo podem importar juntamente com o papel, pelo que uma lista estática de permissões não consegue descrever todas as decisões legítimas.

O Twin avalia essas condições contra o estado operacional registado e mantém a decisão com as suas entradas. Um revisor pode ver quem pediu, o que lhe foi atribuído, quais condições se aplicaram e por que razão o acesso foi permitido ou recusado naquele momento.

A permissão é um evento avaliado, não uma chave que dura para sempre.

Uma auditoria posterior usa as condições registadas com a decisão original.

O Twin mantém o seu modelo de eventos e relacionamentos separado de qualquer norma setorial. Os adaptadores podem ler e escrever os modelos já em uso, enquanto o núcleo mantém uma conta consistente de tempo, proveniência e mudança.

Nem todos os conceitos têm um equivalente exato. A transição inclui, portanto, um relatório de perdas que identifica o que foi representado, o que foi transformado e o que não pôde ser transportado.

A interoperabilidade continua auditável porque a evidência da tradução acompanha a entrega.

O adaptador torna a diferença explícita em vez de a esconder atrás de uma exportação bem-sucedida.

Um ativo, modelo clínico ou de processo permanece propriedade do seu domínio. O Twin aceita-o através de um adaptador e adiciona histórico operacional sem exigir que a organização substitua primeiro todos os modelos existentes.

Quando a informação regressa, o recetor obtém o mapeamento e os seus limites. Um revisor pode ver o que entrou no Twin, o que mudou de forma e o que foi omitido antes de aprovar a entrega.

O domínio mantém o seu modelo enquanto a entrega ganha um registo auditável.

A adoção começa pelos modelos que já suportam o trabalho.

dois permitidos, três recusados com motivos

mesma identidade, decisão nova, ilustrativo

Atribuído ao contrato de manutenção da bomba-4471 num único local

Dentro do contrato, dentro do turno e no local aprovado: o histórico da bomba abre.

Uma segunda visita nas mesmas condições: a decisão é tomada novamente e a resposta é a mesma, porque todas as condições continuam válidas.

A mesma identidade fora do turno escalado: recusado. Nada foi revogado e ninguém teve de se lembrar de nada; a condição de tempo falhou, e a recusa indica a próxima janela válida.

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

a pedir o histórico da bomba de outro local

O histórico da bomba do local vizinho está fora do contrato atribuído: recusado, com o limite indicado em vez de um resultado vazio silencioso.

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

O pedido chega de uma localização não aprovada: recusado, e a origem é registada para que a equipa de segurança possa correlacioná-la com o histórico do ativo a que se acede.

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

cada recusa indica a condição que falhou

O acesso depende do pedido e também da pessoa. O Twin avalia a função, a atribuição, o tempo e a localização em conjunto e regista o motivo quando um pedido é recusado. A mesma pessoa pode receber respostas diferentes à medida que o turno, o local ou o ativo muda, sem uma alteração permanente de função. A decisão permanece associada ao sujeito, ao recurso e à condição falhada para revisão posterior. Uma passagem concedida é limitada pela relação e pela janela temporal que a justificaram, em vez de se tornar uma função ampla que sobrevive à tarefa original. Uma recusa é uma evidência útil porque nomeia a condição que um operador pode corrigir ou contestar. Nenhuma função permanente tem de mudar para que a resposta mude.

Mantenha o registo. Derive o estado. Pergunte ao passado diretamente.

A identidade e a função são apenas parte da questão. O Twin também pode avaliar condições de atribuição, tempo, localização, dispositivo e política quando uma pessoa pede uma página ou um histórico de ativos. Cada uma dessas condições é verificada no momento do pedido.

A mesma pessoa pode ser permitida no turno e recusada mais tarde sem que qualquer função permanente mude. A decisão regista o sujeito, o recurso, o tempo e a regra falhada, para que um pedido negado não se torne um beco sem saída inexplicado. Um revisor posterior pode, portanto, ver o turno que fez a diferença.

O registo mantém a alteração, o seu contexto e a decisão que se seguiu.

montado depois, a partir de quem e do que resta

o que fez o ativo em março e o que se sabia então

o mesmo intervalo, comando ligado ao resultado

nada precisa de ser reconstruído primeiro

Quando alguém pergunta em julho por que uma decisão de março foi tomada, a resposta tem de ser o registo de março, não uma reconstrução a partir das exportações de hoje. O Twin preserva o conjunto de evidências relevante juntamente com a decisão. A pergunta pode selecionar o que era conhecido então, qual regra se aplicava então e qual correção chegou mais tarde. Isso impede que uma revisão justa transforme o conhecimento de hoje na certeza de ontem. A resposta apresenta os eventos de origem e a linhagem ao lado da conclusão, para que outro revisor possa repetir a pergunta em vez de confiar na primeira explicação. Uma correção posterior permanece visível sem tirar a decisão de março do contexto.

Uma pergunta de auditoria pode pedir o estado de março, a informação conhecida num determinado dia ou a regra então em vigor. O Twin reconstrói a leitura adequada a partir dos eventos retidos, em vez de pedir às pessoas que a reconstruam a partir de exportações.

A resposta mantém a sua forma temporal, os eventos de origem e a linhagem visíveis ao lado da conclusão. Um revisor pode repetir a pergunta e compreender por que uma correção posterior pertence a uma resposta e não a outra.

A resposta pode ser examinada mais tarde

O Gémeo mantém o evento, o seu contexto e a decisão que suportou num único registo operacional.

Mantenha o registo. Derive o estado. Pergunte diretamente ao passado.

O registo de eventos mantém o facto e o momento em que ocorreu.

Uma vista derivada pode permanecer rápida enquanto cada resposta histórica continua rastreável.

Um evento armazenado pode responder a uma pergunta que ninguém sabia fazer no dia em que foi escrito. A resposta mostra ainda o que aconteceu, o que era conhecido na altura e quem ou qual regra moldou o resultado.

A mesma memória operacional suporta uma revisão, uma decisão de acesso, uma verificação de linhagem e um cenário. Esses usos partilham o registo; não o reescrevem para cada público.