This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

HDTwin studio — System Integrator Guide

End-to-end overview of the HDTwin studio workflow for certified System Integrators: from research data to a validated, delivered HDTwin panel.

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:

Element What it is Role in the workflow
HDTwin studio The framework: a set of complementary CLI tools Performs the mechanical transformations from data to panel
The studio tools studio, studio-tools, panel Each tool owns a defined stage of the pipeline
The agentic environment An agentic development system (e.g. OpenCode) Orchestrates the tools, manages skills, iterates under supervision
HDTwin-optimized LLMs Language models optimized for HDTwin, accessed through an LLM gateway Provide the cognitive-reconstruction and compilation capabilities

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:

Tool family Purpose
studio-tools Convert source material into the structured input format the pipeline expects
studio Perform the cognitive reconstruction of each respondent into a synthetic persona
panel Assemble and package the personas into a distributable panel

3.2 Complementary tools and their responsibilities

Tool Responsibility Stage of the workflow
spss-filter Deterministic stratified sampling of a survey dataset, with a distribution-fidelity report Source preparation
spss2studio Extract individual respondents plus study documentation from a survey file Source preparation → input
studio evidence Extract explicit observations and constraints from one respondent Cognitive reconstruction
studio reconstruct Rebuild the Latent Cognitive Model (LCM) from the evidence Cognitive reconstruction
studio validate Diagnostic quality check of an LCM Validation (support)
studio serialize Visualise an LCM’s causal graph Validation (support)
studio compile Compile the LCM into a natural-language persona (simulation prompt) Cognitive reconstruction
panel compile Assemble the panel source and produce the signed, encrypted .hdt Packaging
panel decompile Reverse the .hdt back to source (with optional signature verification) Packaging (verification)

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:

Activity Who performs it
Executing tool stages (deterministic transformations) The agentic system / tools
LLM-based reconstruction and compilation The tools, via the gateway
Judging research validity and plausibility The System Integrator
Signing off a panel for delivery The System Integrator

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:

Level Question it answers Performed by
Consistency & completeness Is the artifact structurally sound and complete? Tools (deterministic checks)
Distribution fidelity Does the sample/panel represent the source population? Tools (statistical report) + integrator
Behavioural/research validity Would the reconstructed personas behave plausibly and defensibly? Integrator (with tool support)

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

Situation Automation (agentic system / tools) Human (integrator)
Reading, validating, sampling source data ✓ interprets results
Fanning out reconstruction across respondents ✓ monitors
Consistency, completeness, output-safety checks ✓ responds to failures
Distribution-fidelity report ✓ (generated) ✓ (judged)
Choosing population, size, stratification ✓
Judging persona plausibility and evidence grounding ✓
Deciding a failed diagnostic is acceptable in context ✓
Signing off delivery ✓

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

Area Skill Evidence of mastery
Understanding Explain the framework and pipeline Can describe the end-to-end flow and name each tool’s role
Understanding Explain reconstruction vs translation Can state why the model, not the prose, is the product
Operating Prepare source data Produces a valid, documented, sampled input
Operating Drive the pipeline Directs an agentic run end-to-end
Validating Judge behavioural quality Distinguishes evidence-grounded inference from fabrication
Validating Apply readiness criteria Defends a deliver/not-deliver decision
Delivering Package and hand over Produces a verified .hdt, protects source and secrets
Delivering Comply with obligations Applies NDA, EU AI Act, and provenance rules

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: