Metaskills
RESEARCH · DIGITAL TWIN · TECHNICAL NOTE

How does the Digital Twin plugin fit into your structure?

Technical note for those responsible for approving this document: How is the evaluation module separated from the interface and the database? Which elements cross the boundary between them? And what does the system intentionally never save?

Data Security and ProtectionDigital Twin series

Metaskills technical note, 2026

Technical noteMetaskillsMethodology noteHigh-level architecture - part of the Digital Twin series

One engine, no opinions about your stack

The assessment engine runs as a backend service, deliberately separated from both the interface a learner sees and the database their records live in. The psychometric update logic and the language-model orchestration sit on one side of that boundary; presentation and storage sit on the other. The practical consequence is that the engine is agnostic about both. It works behind a headless content system or a relational database, and it is driven equally by the immersive VR client and the browser dashboard. Changing the front end or migrating the database does not require touching the behavioural analysis engine - which is the difference between a platform you can live with for five years and one you rebuild after two.

What actually crosses the boundary

1

The client sends two things

When a session ends, the application posts the scenario metadata and the validated conversation transcript. That is the entire obligation on the client side - no scoring logic, no competency knowledge, no computation. Identifying details are stripped before anything reaches the assessment model: the client sends the conversation, not the person who had it.

2

The engine does the work

Evidence extraction, quality assessment, cross-conversation aggregation and confidence scoring all happen behind the API. The complexity stays where it can be versioned and tested.

3

The response is structured

Back comes the updated competency profile, confidence information for the competencies involved and targeted development recommendations - ready to render, with no interpretation required from the client.

4

Nothing is overwritten

Every successful update writes a new timestamped version of the profile rather than replacing the previous one. The development path stays readable end to end, and a profile can be examined as it stood at any earlier point.

What the architecture keeps out of the logs

This section describes design rules, not an audit of the running system - for what is deployed and operating today, the security page is the source of truth. Telemetry is narrow by design. The monitoring layer is there for operational facts - response latency, connection timeouts, payload validation failures - because that is what tells an engineer whether the integration is healthy. The design rule is that raw transcript content and user identifiers do not go into it. Diagnostic logs are the least-guarded surface in most systems and the easiest place for conversation content to accumulate unnoticed, which is why the architecture keeps it out rather than trusting anyone to clean it up later. The same rule governs testing: the procedures require synthetic, anonymised payloads rather than real sessions.

What this note covers and does not

What this shows

  • It shows the integration model: an engine decoupled from interface and storage, driven through a small API surface.
  • It shows what a client application has to send and what it gets back.
  • It shows two design decisions in the architecture - immutable profile versioning, and a telemetry design that keeps transcripts and identifiers out of diagnostic logs.

What this does not show

  • It is not the integration manual. The specifications and deployment procedures are shared under an agreement, not published.
  • It is not a security assessment. What is live in production, where data sits and what the contracts cover is on the security page.
  • It says nothing about assessment quality. How well the engine assesses is the validation study's question, and that is still in progress.

Deliberate omissions

A technical page can be useful without being a map for somebody attacking the system. These are the lines we drew.

  • Integration specifications and operational parameters are shared with partners under agreement, not published.
  • The architecture describes the Digital Twin engine and its integration surface, not the whole platform.
  • This is a design and integration note. For what is deployed and operating today, the security page is the source of truth.

Source

Metaskills

2026-08-24

Technical note prepared by Metaskills. A high-level summary of the integration architecture; the full integration documentation is shared with partners under agreement.

Digital Twin methodology

← PreviousPrivacy, bias and human oversight

Related pages

Security

Security and data protection

What runs in production today: where data is held, who can reach it and what the contracts cover.

Security and data protection
Methodology

How behaviour becomes evidence

The assessment logic that runs behind this API - evidence events, confidence and the limits on inference.

How behaviour becomes evidence
Product

Digital Twin

The competency profile the engine produces, and what it looks like for a learner and a team.

Digital Twin
Technical architecture of the Digital Twin | Metaskills