HDTwin Product Family

• 1: HDTwin Council Application
• 2: HDTwin studio — System Integrator Guide
• 3: Glossary

@startuml
skinparam componentStyle rectangle

rectangle "Source research data" as SRD
rectangle "Panel (.hdt)" as PN
rectangle "Deliberation" as DEL
rectangle "Report" as REP

SRD --> PN : HDTwin studio (build)
PN --> DEL : HDTwin Council (use)
DEL --> REP
@enduml

1 - HDTwin Council Application

This guide walks you through running a deliberation in HDTwin Council, the HDTwin web application: loading a panel, starting the debate, and reading the resulting report.

Prerequisites

Before you start, make sure you have:

• access to the HDTwin Council application (an account may be required);
• an HDTwin panel file (.hdt). If you do not have one yet, you can request a trial panel by booking a personalised demo — open the Get a demo panel tab in the application to find the booking link.

Unfamiliar with terms like panel or deliberation? Check the Glossary.

1. Open the Application

Navigate to the application home page at https://council.hdtwin.eu/. Authenticate if requested.

2. Load a Panel

Once you have your panel file (e.g. mypanel.hdt):

1. Switch to the Upload panel tab.
2. Drag the file into the upload area, or click the area to select it from your computer.

In this guide we use an example panel consisting of 10 Italians.

3. Initiate a Deliberation

After the panel is loaded, fill in the deliberation details. For a quick start, use the Example button next to the Topic Title and select the “De gustibus” example. This example simulates a deliberation among 10 Italians expressing their preferences on gelato flavours.

• Topic Title: De gustibus
• Topic Description: Quale gusto di gelato preferisci?

Three flavours are pre-loaded as seed comments: the deliberation takes them into account during the discussion, and the Human Digital Twins may add others themselves.

Click the Let the debate begin button at the bottom of the page to start the process.

4. Monitor Progress

Once the deliberation starts, you are redirected to the report page. While the deliberation is running:

• the message “Deliberation is running…” appears at the top of the report;
• the report automatically reloads every 10 seconds, updating with new votes and statements until all participants have finished.

You can stop the deliberation process at any time.

5. Understand the Report

When the “Deliberation is running…” message disappears, the deliberation is complete. The report consists of several sections:

• Overview — total participants (voters), grouped participants, total votes cast, and statements submitted.
• Divisiveness — how much consensus or disagreement exists within the panel on the topic.
• Participant Metrics — average votes and statements per author, giving insight into the engagement level of your HDTwin panel.

6. Next Steps

• To understand where panel files come from, read the HDTwin studio System Integrator guide.
• For data protection and responsible-use obligations when working with synthetic personas, see the Compliance section.

2 - HDTwin studio — System Integrator Guide

This guide describes the overall process a certified HDTwin System Integrator follows to design and build an HDTwin panel with HDTwin studio. It is both a practical introduction and a syllabus-style reference for the System Integrator training program.

It answers one question:

As a certified System Integrator, what is the overall process for using HDTwin studio to go from a research/data requirement to a validated HDTwin panel, what tools participate in that process, and what responsibilities remain with me?

It deliberately does not answer:

How do I implement every individual component or manually construct every file?

Implementation details — file formats, schemas, CLI references, personality authoring, and installation commands — belong to the detailed technical documentation and to the hands-on training exercises. This guide is the conceptual map you read before opening those documents.

1. Introduction

1.1 What HDTwin studio is

HDTwin studio is a framework, not a single standalone tool. It is a set of complementary command-line tools that work together as part of a broader workflow. The tools are designed to be integrated into an agentic system — an agentic development environment such as OpenCode, or a similar environment in which a coding agent plans, executes, and supervises a multi-step process.

The purpose of the framework is to transform source research data into a validated HDTwin panel: a collection of synthetic personas (Human Digital Twins) packaged for use in HDTwin deliberation applications.

The framework does not replace the System Integrator. It provides the mechanical stages; the integrator provides direction, domain judgement, validation, and final responsibility for the delivered panel.

1.2 Who this guide is for

This guide is written for certified HDTwin System Integrators who have completed the official HDTwin training course. It assumes you already have:

• the technical background required to operate the tools;
• the conceptual knowledge of how HDTwin works (panels, personas, the Latent Cognitive Model, deliberation);
• the research/domain awareness needed to judge whether a panel is fit for purpose.

It functions as a reminder of the overall workflow and as a syllabus against which the training program’s learning objectives are organised. It does not re-teach the underlying concepts.

1.3 How the pieces relate

Four distinct things are involved in every panel-building project:

These elements are layered: the tools are driven by the agentic environment, and the tools consume LLM models through the gateway. The integrator sits above all four, directing and validating the result.

@startuml
skinparam componentStyle rectangle

actor "System Integrator\n(supervises · validates ·\nsigns off delivery)" as SI
rectangle "Agentic environment\n(e.g. OpenCode + project skills)" as AE
node "studio" as ST <<CLI>>
node "studio-tools" as STT <<CLI>>
node "panel" as PN <<CLI>>
node "..." as DOTS <<CLI>>
database "LLM gateway\n(HDTwin-optimized models)" as LLM

SI --> AE : directs
AE --> ST : invokes
AE --> STT : invokes
AE --> PN : invokes
AE --> DOTS : invokes

ST --> LLM
STT --> LLM
PN --> LLM

DOTS ..> LLM : API key
@enduml

2. Prerequisites and Access

2.1 System Integrator certification and training

Operating HDTwin studio requires certification as a HDTwin System Integrator, obtained by completing the official HDTwin training course. This guide assumes that certification is in place and that the concepts introduced in training are already understood.

2.2 Required access and environment

To work with HDTwin studio you need:

• a working agentic environment (OpenCode or equivalent) in which the tools can be invoked;
• the HDTwin studio tools installed and available on the command path;
• access to the private package registry from which the tools are distributed;
• an HDTwin API key (see below).

The detailed environment requirements (Python version, package manager, registry authentication) are covered in the individual tool user guides — see Further documentation.

2.3 The HDTwin API key

The studio tools require access to LLM models optimized for HDTwin. These models are accessed through an LLM gateway, and access to them requires an API key issued by HDTwin.

Obtaining the API key implies two obligations:

1. Acceptance of the applicable Non-Disclosure Agreement (NDA).
2. Compliance with the rules and obligations applicable under the EU AI Act.

The API key is a credential: it must be treated as a secret. HDTwin requirements for handling it include keeping it out of source control and never committing it to a repository. This is an HDTwin requirement, not merely a general best practice.

2.4 NDA and EU AI Act obligations

NDA. Access to HDTwin studio, to the models optimized for HDTwin, and to the underlying panel methodology is subject to the applicable Non-Disclosure Agreement. Certain artifacts produced or handled during panel construction — in particular the panel source definition — are HDTwin intellectual property and must not be distributed outside the authorized channel. See System Integrator responsibilities.

EU AI Act. HDTwin is classified as a low-risk AI system under the EU AI Act. The integrator’s obligations are therefore primarily about transparency and responsible use:

• synthetic personas (Human Digital Twins) must be clearly identified as AI-generated synthetic personas, never as real individuals;
• the results are generated by an AI system and are probabilistic, not a guarantee of real-world behaviour;
• human oversight is maintained: the integrator (and the end researcher) remain in control of the decisions derived from panel outputs.

The full compliance statement is in the HDTwin EU AI Act compliance document — see Further documentation.

2.5 Security and responsible-use considerations

At a high level, the integrator must respect these principles throughout the workflow:

• Secrets. API keys and cryptographic material stay out of repositories and out of logs.
• Intellectual property. Panel source definitions ship only in compiled form; source is never distributed.
• Synthetic, not real. Synthetic personas and synthetic microdata are never represented as real individuals or recovered observations.
• Epistemic honesty. Inferred characteristics are never silently upgraded into observed facts.

These points are reinforced in the sections that follow where they affect the workflow.

3. The HDTwin studio Framework

3.1 Overview

HDTwin studio is organised as a set of complementary tools, each with a clear, bounded responsibility. The tools are small, command-line programs that read a defined input and write a defined output. Because each stage is separated, the stages can be chained, inspected between steps, and re-run independently.

The framework divides the work into three tool families:

3.2 Complementary tools and their responsibilities

personas2txt and txt2studio are planned tools of the studio-tools family, intended for a second entry path into the pipeline (persona narratives rather than survey microdata). They are not part of the standard .sav-based workflow described here.

3.3 How the tools fit together

The tools form a linear pipeline. Each stage’s output becomes the next stage’s input, with a stable one-to-one mapping between respondents preserved from end to end:

@startuml
skinparam componentStyle rectangle

file "survey source" as SS <<SPSS>>  #technology
file "panel source" as PT <<JSON>>  #technology
node "spss-filter" as FIL <<CLI>> #line.dashed
node "spss2studio" as S2S <<CLI>>
collections "respondents/" as RES <<JSON>>
node "studio evidence" as SE <<CLI>>
node "studio reconstruct" as SR <<CLI>>
node "studio compile" as SC <<CLI>>
file "personality" as PER <<JSON>>
node "panel compile" as PC <<CLI>>
node "panel test" as TST <<JSON>>  #line.dashed 
file "test report" as TR <<JSON>> #line.dashed
file "panel .hdt" as HDT  <<binary>>

SS --> FIL
FIL --> S2S
S2S --> RES
RES --> SE
SE --> SR
SR --> SC
SC --> PER
PER ..> TST
SS --> TST
PER --> PC
PT --> PC
PC --> HDT
TST --> TR

@enduml

Between spss2studio and panel compile, the studio tool performs a per-respondent fan-out: one survey record becomes one personality. The number of records therefore drives the scale and cost of the project.

3.4 Role of the agentic system

The tools are designed to be used by an agentic system, not by a human typing every command by hand. In practice:

• the agentic environment reads project instructions (e.g. an AGENTS.md) that declare which commands and skills are available;
• skills encapsulate multi-step recipes (for example, a skill that chains spss2studio → studio evidence → studio reconstruct → studio compile into one personality per respondent);
• the agent plans the stages, executes them, fans out across many respondents, and reports progress and errors back to the integrator.

The agentic system is an orchestrator. It does not replace the integrator’s judgement; it moves the mechanical work — the repetitive per-respondent loop, the sequencing, the error surfacing — off the integrator’s desk. See Working with an agentic environment.

4. Panel Development Workflow

This section describes the end-to-end process at a high level. Each step is expanded where it matters; implementation detail is deliberately left out.

The workflow proceeds through the following stages, in order:

1. Establish the requirement — what panel is needed and why.
2. Prepare the source data — obtain, validate, and (if necessary) sample the research data.
3. Design the panel — decide the target population, size, and structure.
4. Extract respondents — convert source data into per-respondent input records.
5. Reconstruct personalities — run the cognitive-reconstruction pipeline.
6. Validate — check structural consistency and behavioural quality.
7. Assemble and package — combine personalities into a panel and compile it.
8. Verify and deliver — confirm the package and hand it over.

4.1 Starting from source research/data

Every panel starts from a research question and a source of data about a target population. Two common entry points exist:

• Survey microdata — an existing survey dataset (e.g. an SPSS .sav file) of real respondents. The panel is built to represent this surveyed population.
• Aggregate statistics — published statistics describing a population (from a report or document). Here the integrator first reconstructs a synthetic microdataset, then proceeds as if it were survey data.

The distinction matters for compliance: survey microdata represents real observations, whereas microdata reconstructed from aggregate statistics is synthetic and must be labelled and treated as such throughout.

4.2 Preparing the inputs

Before reconstruction begins, the source data is prepared:

• Validation — confirm the source is readable, well-formed, and of the expected type.
• Sampling — when the source population is larger than the intended panel, draw a representative, deterministic sample. Sampling preserves the distribution of key stratification variables and produces a fidelity report so the integrator can confirm the sample still represents the source.

Preparing inputs is where the integrator makes the first meaningful research decision: which variables define the population’s structure, and how large the panel should be. Sampling is a research choice, not merely a mechanical one.

4.3 Designing the panel

Design decisions are made up front and recorded:

• Population scope — who the panel is meant to represent.
• Panel size — how many personas.
• Structure — which stratification or segmentation the panel must reflect.
• Context — any global context that should frame the panel’s deliberations.
• Delivery target — the tenant and engine the panel will run against.

Most of these are captured later in the panel source definition, but they should be decided here, before reconstruction begins.

4.4 Using the HDTwin studio tools

With inputs prepared and the design decided, the tools execute the transformation:

1. spss2studio (or the equivalent entry path) produces one structured respondent record per individual, each carrying its own study documentation.
2. For each respondent, studio runs the cognitive-reconstruction stages: evidence extraction, then reconstruction of the Latent Cognitive Model, then compilation into a natural-language personality.
3. The result is a directory of personalities, one per respondent, with traceable one-to-one mapping back to the source record.

4.5 Generating and configuring the panel

The personalities are then assembled into a panel. The panel source definition combines:

• panel metadata (identifier, description, expiry, tenant, engine);
• a model configuration that includes the personalities as members, any shared context, and any optional configuration for biased contexts;
• optionally, example deliberation seeds.

The panel tool then compiles this source into the distributable form.

4.6 Validation and review

Validation is a distinct stage, not an afterthought. It happens at two levels:

• Structural validation, performed by the tools (consistency checks on the model, diagnostic quality checks on each LCM).
• Human review, performed by the integrator (do the personalities behave plausibly? does the panel represent the population? are the outputs defensible?).

Validation is covered in depth in Validation and Quality Assurance.

4.7 Iteration

Rarely is a panel correct on the first pass. The workflow is iterative:

• a validation check surfaces a problem in a specific personality or in the panel structure;
• the integrator directs a targeted re-run (a single respondent, a single stage, or a design change);
• the result is re-validated.

The per-stage, per-respondent structure of the tools is what makes targeted iteration cheap: a failure in one personality does not force a full rebuild.

4.8 Packaging and delivery

Once the panel passes validation, it is packaged:

• the panel source is compiled into a signed and encrypted .hdt file;
• the model payload is encrypted at rest (HDTwin IP protection);
• the file is signed so its integrity and origin can be verified.

Delivery means handing over the .hdt file to the consumer (the deliberation application or the end researcher). The source definition is retained by the integrator/HDTwin and is not distributed.

5. From Source Data to Panel

This section generalises the workflow exemplified by the process of building a panel from a survey dataset. It describes the transformation conceptually; the specific example, tool invocations, and file formats are intentionally omitted.

5.1 The transformation in one picture

@startuml
skinparam componentStyle rectangle

rectangle "Research requirement" as RR
rectangle "Source data" as SD
rectangle "(sampling)" as SM
rectangle "Input records" as IR
rectangle "Cognitive reconstruction" as CR
rectangle "Personas\n(one per record)" as PR
rectangle "Panel assembly" as PA
rectangle ".hdt" as HDT
rectangle "delivery" as DL

RR --> SD
SD --> SM
SM --> IR
IR --> CR
CR --> PR
SD --> PA
PR --> PA
PA --> HDT
HDT --> DL
@enduml

The whole pipeline converts research requirements plus source data into a functional HDTwin panel. The key conceptual shift happens in the middle: raw data is not simply reformatted; it is reconstructed into personas that can behave consistently on questions the survey never asked.

5.2 From records to personas: why reconstruction

A survey record is a sparse set of observations about a person. Those observations are manifestations of a much richer internal system — values, motivations, trust relationships, world model, reasoning style. A panel that merely repeats the recorded answers cannot answer new questions; it falls back on demographic stereotypes.

HDTwin studio therefore does not translate records into text. It treats each record as incomplete evidence and reconstructs the hidden cognitive system most likely to have produced it, then compiles that system into a persona — a natural-language simulation prompt.

@startuml
left to right direction
skinparam componentStyle rectangle

rectangle "record\n(observations)" as REC
rectangle "Latent Cognitive Model\n(reconstructed system)" as LCM
rectangle "persona\n(compiled prompt)" as PER

REC --> LCM
LCM --> PER
@enduml

This is the single most important concept for the integrator to internalise: the product is the reconstructed model, not a paraphrase of the survey. Quality is judged on the reconstructed reasoning, not on how closely the prose resembles the original answers.

5.3 The evidence boundary

Reconstruction distinguishes inference from fabrication:

• Inference extends observable evidence using psychologically plausible reasoning, and is permitted.
• Fabrication (hallucination) introduces detail the evidence cannot support, and is prohibited.

The integrator’s validation work is, in large part, guarding this boundary: confirming that each inferred characteristic is plausibly supported by the evidence, and that unsupported detail has not crept in.

The same discipline applies at the data level. When working from aggregate statistics, every value must carry a provenance: observed, derived, assumed, or simulated. These categories must never be conflated — a synthetic value must never be presented as an observed one.

5.4 Generalisation from a concrete example

The reference workflow (building a panel from a survey dataset) is one concrete instance of a general pattern:

1. Acquire a source describing the target population.
2. Prepare it (validate, and sample to the intended panel size, preserving structure).
3. Extract one input record per panel member.
4. Reconstruct each record into a persona.
5. Assemble the personas into a panel definition.
6. Compile the definition into a distributable panel.
7. Deliver the compiled panel.

The same pattern holds regardless of the source format or the specific research domain. The tools that change are those in step 1–2 (how source data is acquired and prepared); steps 3–7 are stable across projects.

6. Working with an Agentic Environment

6.1 How the tools are intended to be used

HDTwin studio tools are command-line tools designed to be invoked by an agentic system, not interactively. In the intended workflow:

• the integrator states the goal and the research requirements;
• the agentic system plans the stages, invokes the tools, fans out across respondents, and reports back;
• the integrator reviews results, directs changes, and signs off.

A concrete illustration: rather than a human running the per-respondent loop hundreds of times, the agentic environment executes the loop, parallelises where appropriate, and surfaces only the outcomes and problems that need the integrator’s attention.

6.2 The role of the System Integrator

Within this arrangement, the integrator’s role is to supervise and guide, not to type commands:

• Set direction. Define the requirement, the population, the design decisions.
• Provide domain judgement. Decide which variables matter, what “representative” means, and whether a persona is behaviourally plausible.
• Gate the process. Decide when a stage’s output is acceptable and when to re-run.
• Own the outcome. Take responsibility for the delivered panel.

6.3 Separation of concerns

A clean separation runs through the whole workflow:

Automation is appropriate for anything mechanical, repeatable, and verifiable by rule. Human intervention is required wherever a judgement call is involved — population definition, acceptability of inference, readiness for delivery. See When to rely on automation and when human intervention is required.

7. Validation and Quality Assurance

Validation is where the integrator earns the “certified” in the job title. It is not a single check at the end; it runs in layers throughout the workflow.

7.1 Conceptual validation stages

Validation happens at three conceptual levels:

7.2 Consistency and completeness checks

The tools enforce structural consistency automatically:

• Input validation — source records must conform to the expected contract; invalid records stop the run rather than producing partial output.
• Model checks — the panel model is checked for internal consistency (for example, that references between configuration elements are valid).
• Output safety — compiled personas are checked to ensure they are plain prose, contain no leaked schema or identifiers, and carry no unsafe instructions.
• Sampling fidelity — the sampling step reports the divergence between the sample and the source distribution.

These checks are deterministic and reproducible. They are necessary but not sufficient: passing them does not mean the panel is good; it means the panel is well-formed.

7.3 Diagnostic quality checks on the reconstruction

studio provides a diagnostic quality check on each Latent Cognitive Model. It evaluates the model against a checklist and reports a pass, warning, or failure, with issues and recommendations when it fails. This is a diagnostic aid for the integrator, not an automatic gate: it flags likely problems and suggests what to revisit.

7.4 Behavioural / research validation

The most important validation is judgement-based and cannot be fully automated. Because a synthetic persona has no single ground truth to compare against, validation asks whether the reconstructed system can reliably generate psychologically plausible behaviour. The integrator assesses, at minimum:

• Evidence fidelity — does the persona faithfully reflect the available evidence, without contradiction?
• Internal coherence — do opinions emerge from deeper motivations, or are they a flat list of traits?
• Generalisation — does the persona behave consistently across unseen situations?
• Stability — does it resist drifting or contradicting itself over a long interaction?
• Psychological realism — does it resemble a plausible, ambivalent human, rather than a demographic stereotype?
• Hallucination resistance — are unsupported or stereotypical inferences absent?

A useful working test: pick a question the source never asked, and ask whether the persona’s answer would follow plausibly from its reconstructed reasoning. A persona that reasons its way to an answer is good; a persona that pattern-matches to a demographic shortcut is not.

7.5 Iterative refinement

Validation findings feed back into the workflow. Refinement is targeted:

• a structural failure in one stage → re-run that stage;
• a specific personality that fails review → re-run that respondent;
• a population-level problem (the sample is unrepresentative, the design is wrong) → return to design.

Because stages and respondents are independent, a targeted fix does not force a full rebuild.

7.6 Criteria for considering a panel ready for delivery

A panel is ready to deliver when all of the following hold:

1. The source data is valid and its provenance is documented.
2. The sample (if any) is verified to represent the source population.
3. Every persona passes the structural/consistency checks.
4. Behavioural review confirms the personas are plausible, coherent, and evidence-grounded.
5. The panel model is internally consistent.
6. The panel compiles successfully into a signed, encrypted .hdt.
7. The integrator has reviewed the panel as a whole and accepts responsibility for it.

Only then should the .hdt be handed to the consumer.

8. System Integrator Responsibilities

The System Integrator is accountable for the panel. The tools execute; the integrator decides and answers for the result. Responsibilities fall into four groups.

8.1 Technical responsibilities

• Ensure the environment and tools are correctly set up and configured.
• Ensure source data is valid and prepared correctly.
• Oversee the correct execution of the pipeline, including fan-out and error handling.
• Ensure the panel compiles and verifies correctly.
• Protect secrets and cryptographic material.

8.2 Research / domain responsibilities

• Translate the research requirement into a concrete panel design (population, size, structure).
• Choose the variables and stratification that define representativeness.
• Judge whether the sample and the resulting panel faithfully represent the target population.
• Interpret and act on distribution-fidelity and quality reports.

8.3 Validation responsibilities

• Review personas for behavioural plausibility and evidence grounding.
• Guard the inference/fabrication boundary.
• Confirm the panel as a whole is fit for its intended research purpose.
• Decide when the panel is ready for delivery.

8.4 When to rely on automation and when human intervention is required

A simple rule: if a decision has a research or ethical consequence, it is the integrator’s. Automation is for the mechanical and the rule-checkable.

8.5 Compliance and governance responsibilities

• Maintain the NDA obligations, including protecting panel source definitions and model IP.
• Respect EU AI Act obligations: label synthetic personas as synthetic, maintain human oversight, and avoid representing synthetic output as real.
• Preserve the evidence boundary: never present synthetic or inferred information as observed fact.
• Keep secrets out of repositories and logs.

9. Training Syllabus / Learning Path

This section reorganises the preceding material as a progression of skills a certified System Integrator should master. It is intended as a reference for the HDTwin training course, and as a self-assessment checklist.

9.1 Understanding (the conceptual foundation)

The integrator understands:

• what HDTwin studio is (a framework of tools) and how it differs from a single tool;
• the roles of the agentic environment, the studio tools, and the HDTwin-optimized LLMs;
• the pipeline: source data → respondents → evidence → Latent Cognitive Model → personas → panel → .hdt;
• why reconstruction (not translation) is the core method, and what the Latent Cognitive Model represents;
• the distinction between inference and fabrication, and the evidence boundary.

9.2 Operating (running the workflow)

The integrator can:

• establish the requirement and translate it into a panel design;
• prepare and sample source data, and interpret the fidelity report;
• direct the agentic environment through the pipeline stages;
• manage fan-out, parallelism, and error recovery;
• assemble and compile a panel.

9.3 Validating (assuring quality)

The integrator can:

• run and interpret the structural consistency checks;
• use the diagnostic quality check and act on its findings;
• conduct behavioural/research review of personas;
• apply the readiness criteria and decide whether a panel is deliverable.

9.4 Delivering (owning the outcome)

The integrator can:

• package the panel into a signed, encrypted .hdt;
• verify the package;
• deliver it correctly, protecting source definitions;
• discharge the compliance and governance responsibilities (NDA, EU AI Act, provenance).

9.5 Skills checklist

10. Further Documentation

This guide is an overview and training-oriented document. It is not a replacement for the detailed technical documentation.

The hands-on details — CLI references for studio, studio-tools, and panel, the rationale behind cognitive reconstruction, the panel and respondent data models, and the .hdt format specification — are covered by the detailed tool documentation and the hands-on exercises provided with the official HDTwin System Integrator training course, and are intentionally out of scope here.

Related pages in this documentation portal:

• EU AI Act Compliance — the regulatory obligations summarised in §2.4
• Terms of Service — the contractual terms governing platform use
• Ethics & AI Safety — bias sterilization and human-oversight commitments
• HDTwin Council guide — how the panels you build are used in practice
• Glossary — definitions of the technical terms used in this guide

3 - Glossary

This page defines the terms used across the HDTwin documentation. Terms are grouped by theme and listed alphabetically within each group.

Core Concepts

Deliberation A simulated focus group or poll run in HDTwin Council: the Human Digital Twins in a panel discuss a topic, vote on statements, and produce an analysed report.

Human Digital Twin (HDT) A synthetic persona — an AI agent that replicates the characteristics, reasoning, and behaviour of a member of a target population. Human Digital Twins are clearly AI-generated and never represent real, identifiable individuals.

Panel A collection of Human Digital Twins representing a target population, built once from research data and reusable for any number of deliberations. Panels are distributed as signed, encrypted .hdt files.

Persona (personality) The compiled, natural-language form of a single Human Digital Twin — the simulation prompt produced by the cognitive-reconstruction pipeline. Used interchangeably with “personality” in the studio documentation.

Products and Tools

HDTwin Council The HDTwin web application in which deliberations happen. Users load a panel, define a topic, and read the analysed report.

HDTwin studio The framework of command-line tools used by certified System Integrators to build panels from source research data. Organised in three tool families: studio-tools (source preparation), studio (cognitive reconstruction), and panel (assembly and packaging).

Habermas Machine The dedicated deliberation engine, configured inside each panel, that executes Council’s deliberations.

LLM gateway The common access point through which the studio tools consume the HDTwin-optimised language models. Access requires an API key issued by HDTwin.

System Integrator A certified professional who designs, builds, validates, and delivers HDTwin panels using HDTwin studio. Certification is obtained by completing the official HDTwin training course.

Data and Formats

.hdt file The compiled, signed, and encrypted distribution format of an HDTwin panel. It is the contract between the two products: whatever studio produces, Council can run.

Evidence The explicit observations and constraints extracted from one source respondent record, used as the input to cognitive reconstruction. Reconstruction distinguishes inference (extending evidence plausibly — permitted) from fabrication (introducing unsupported detail — prohibited).

Latent Cognitive Model (LCM) The reconstructed internal system of a respondent — values, motivations, trust relationships, world model, reasoning style — inferred from the evidence. The LCM, not a paraphrase of the source answers, is the real product of the reconstruction stage.

Seed comments Statements pre-loaded into a deliberation at creation time. The Human Digital Twins take them into account during the discussion and may add further statements of their own.

Source research data The input to panel construction: typically survey microdata (e.g. an SPSS .sav file) or aggregate population statistics from which a synthetic microdataset is first reconstructed.

Analysis and Quality

Bias sterilization HDTwin’s proprietary layer that filters harmful language, corrects stereotypical response distributions, and keeps agents within the logical guardrails of their persona. See Ethics & AI Safety.

Consensum detection The automatic identification of areas of agreement within a panel, even on highly divisive topics. Surfaced in the divisiveness analysis of a deliberation report.

Divisiveness A report metric describing how much consensus or disagreement exists within the panel on a given topic.

Provenance The recorded origin of a data value: observed, derived, assumed, or simulated. These categories must never be conflated — a synthetic value must never be presented as an observed one.