Metaskills
BADANIA · DIGITAL TWIN · NOTATKA TECHNICZNA

Jak Digital Twin wpisuje się w Państwa stos technologiczny

Nota techniczna dla osób, które muszą to zatwierdzić: w jaki sposób silnik oceny jest oddzielony od interfejsu i bazy danych, jakie elementy przekraczają granicę między nimi oraz czego system celowo nigdy nie zapisuje.

Metaskills nota techniczna, 2026

Nota technicznaMetaskillsOpis metodykiArchitektura wysokiego poziomu - część serii Digital Twin

Jeden silnik, niezależny od Państwa stosu technologicznego

Silnik oceny działa jako usługa backendowa, celowo oddzielona zarówno od interfejsu widocznego dla ucznia, jak i od bazy danych, w której przechowywane są jego dane. Logika aktualizacji psychometrycznej oraz koordynacja modeli językowych znajdują się po jednej stronie tej granicy; prezentacja i przechowywanie danych - po drugiej. W praktyce oznacza to, że silnik jest niezależny od obu tych elementów. Działa on zarówno z systemem treści typu „headless”, jak i z relacyjną bazą danych, a sterują nim w równym stopniu immersyjny klient VR i panel w przeglądarce. Zmiana interfejsu użytkownika lub migracja bazy danych nie wymaga ingerencji w silnik analizy behawioralnej - i to właśnie stanowi różnicę między platformą, z którą można funkcjonować przez pięć lat, a taką, którą trzeba przebudować już po dwóch latach.

Co tak naprawdę przekracza granicę

1

Klient wysyła dwie rzeczy

Po zakończeniu sesji aplikacja przesyła metadane scenariusza oraz zweryfikowaną transkrypcję rozmowy. To wszystko, czego wymaga się od strony klienta - nie ma tu żadnej logiki punktacji, wiedzy o kompetencjach ani obliczeń. Dane umożliwiające identyfikację są usuwane, zanim jakiekolwiek informacje dotrą do modelu oceny: to klient wysyła rozmowę, a nie osoba, która ją przeprowadziła.

2

Silnik wykonuje całą pracę

Wydobywanie dowodów, ocena ich jakości, agregacja wyników z różnych rozmów oraz ocena poziomu pewności - wszystkie te procesy odbywają się za interfejsem API. Złożoność pozostaje tam, gdzie można ją wersjonować i testować.

3

Odpowiedź jest ustrukturyzowana

Otrzymują Państwo zaktualizowany profil kompetencji, informacje dotyczące poziomu pewności co do poszczególnych kompetencji oraz ukierunkowane zalecenia dotyczące rozwoju - gotowe do wyświetlenia, bez konieczności interpretacji po stronie klienta.

4

Nic nie zostało nadpisane

Każda pomyślnie przeprowadzona aktualizacja powoduje zapisanie nowej wersji profilu opatrzonej sygnaturą czasową, zamiast zastępowania poprzedniej wersji. Ścieżka rozwoju pozostaje czytelna od początku do końca, a profil można przeanalizować w stanie, w jakim znajdował się w dowolnym wcześniejszym momencie.

Co architektura trzyma poza logami

W tej sekcji opisano zasady projektowania, a nie wyniki audytu działającego systemu. W przypadku rozwiązań wdrożonych i obecnie działających rozstrzygającym źródłem informacji jest strona poświęcona bezpieczeństwu. Telemetria ma z założenia wąski zakres. Warstwa monitorowania służy do rejestrowania faktów operacyjnych - opóźnień odpowiedzi, limitów czasu połączeń, błędów walidacji danych - ponieważ to właśnie one informują inżyniera o prawidłowym działaniu integracji. Zasada projektowa stanowi, że surowe treści transkrypcji i identyfikatory użytkowników nie są do niej wprowadzane. Logi diagnostyczne są w większości systemów najmniej chronionym obszarem i najłatwiejszym miejscem, w którym treść rozmów może gromadzić się niezauważona, dlatego architektura z góry jej tam nie dopuszcza, zamiast liczyć na to, że ktoś je później wyczyści. Ta sama zasada obowiązuje podczas testowania: procedury wymagają syntetycznych, zanonimizowanych danych, a nie rzeczywistych sesji.

Co ta nota techniczna obejmuje, a czego nie

Co to pokazuje

  • Pokazuje model integracji: silnik oddzielony od interfejsu i warstwy przechowywania danych, sterowany przez niewielki interfejs API.
  • Pokazuje, co aplikacja kliencka musi wysłać i co dostaje w odpowiedzi.
  • Pokazuje dwie decyzje projektowe w architekturze - niezmienne wersjonowanie profilu oraz taki projekt telemetrii, który trzyma transkrypcje i identyfikatory poza logami diagnostycznymi.

Czego to nie dowodzi

  • To nie jest podręcznik integracji. Specyfikacje i procedury wdrożeniowe są udostępniane na podstawie umowy, a nie publikowane.
  • To nie jest ocena bezpieczeństwa. To, co działa na produkcji, gdzie znajdują się dane i co obejmują umowy, opisuje strona poświęcona bezpieczeństwu.
  • Nie mówi nic o jakości oceny. To, jak dobrze silnik ocenia, jest pytaniem badania walidacyjnego, a ono wciąż trwa.

Celowe pominięcia

Strona techniczna może być użyteczna, nie będąc jednocześnie mapą dla kogoś, kto chce zaatakować system. Oto granice, które wyznaczyliśmy.

  • Specyfikacje integracyjne i parametry operacyjne są udostępniane partnerom na podstawie umowy, a nie publikowane.
  • Architektura opisuje silnik Digital Twin i jego warstwę integracji, a nie całą platformę.
  • To jest nota projektowa i integracyjna. Jeśli chodzi o rozwiązania wdrożone i obecnie działające, rozstrzygającym źródłem informacji jest strona poświęcona bezpieczeństwu.

Źródło

Metaskills

2026-08-24

Nota techniczna przygotowana przez firmę Metaskills. Ogólne podsumowanie architektury integracji; pełna dokumentacja dotycząca integracji jest udostępniana partnerom na podstawie umowy.

Powiązane strony

Bezpieczeństwo

Bezpieczeństwo i ochrona danych

Co obecnie działa w środowisku produkcyjnym: gdzie przechowywane są dane, kto ma do nich dostęp oraz co obejmują umowy.

Bezpieczeństwo i ochrona danych
Metodologia

W jaki sposób zachowanie staje się dowodem

Logika oceny działająca w tle tego interfejsu API - zdarzenia dowodowe, poziom pewności oraz ograniczenia wnioskowania.

W jaki sposób zachowanie staje się dowodem
Produkt

Digital Twin

Profil kompetencji generowany przez silnik oraz to, jak wygląda on z perspektywy uczącego się i zespołu.

Digital Twin
Architektura techniczna Digital Twin | Metaskills