honors-thesis/thesis/chapters/04_system_design.tex

\chapter{Architectural Design}
\label{ch:design}

Chapter~\ref{ch:background} established six requirements for modern WoZ infrastructure, labeled R1 through R6, and Chapter~\ref{ch:reproducibility} showed the reproducibility problems that motivate them. This chapter presents the architectural contribution of this thesis: a hierarchical specification model, an event-driven execution model, a modular interface architecture, and an integrated data flow that together address all six requirements. These are design principles, not implementation details; they apply to any system built with the same goals.

\section{Hierarchical Organization of Experiments}

WoZ studies involve multiple experiments, shared protocol phases, and platform-specific behaviors that span the full research lifecycle. To organize these elements without requiring researchers to write code, the system structures every study as a four-level hierarchy: \emph{study} $\rightarrow$ \emph{experiment} $\rightarrow$ \emph{step} $\rightarrow$ \emph{action}. This structure separates high-level protocol design from low-level execution behavior, keeping the authoring process code-free while integrating design, execution, and analysis into a single unified workflow.

I define the elements in this hierarchy as follows. A \emph{study} is the top-level container that groups related experiments. An \emph{experiment} is one independently runnable protocol within that study (for example, a control or experimental condition). A \emph{step} is one phase of the protocol timeline (for example, an introduction, telling a story, or testing information recall). An \emph{action} is the smallest executable unit inside a step (for example, trigger a gesture, play audio, or speak a prompt).

Figure~\ref{fig:experiment-hierarchy} shows this hierarchical structure. Reading top-down, one study contains one or more experiments, each experiment contains one or more steps, and each step contains one or more actions.

Figure~\ref{fig:trial-instantiation} illustrates how a protocol definition relates to its instantiation. The left column holds the protocol, defined before the study begins; the right column shows how the abstraction defined as a protocol is instantiated as independent trials. A dashed line marks the protocol/trial boundary: everything to its left was authored by the researcher before any participant arrived; everything to its right was generated during a live session. The \textit{instantiates} arrows from the experiment node fan out to each trial record, making the relationship explicit. This separation is central to reproducibility: the same experiment specification generates a distinct, timestamped record per participant, so researchers can compare across participants without conflating what was designed with what was executed.

To illustrate the hierarchy with a concrete example, consider an interactive storytelling study with the research question: \emph{Does how the robot tells a story affect how a human will remember the story?} The two experiments use different robots: the NAO6, a humanoid robot with expressive gestures and a human-like form, and the TurtleBot, a wheeled mobile robot that is visibly machine-like with no social movement cues. The narrative task remains the same across both experiments; only how the robot delivers it changes.

Figure~\ref{fig:example-hierarchy} maps the study presented above onto the hierarchical elements defined in Figure~\ref{fig:experiment-hierarchy}. The study branches into two experiments (TurtleBot with only voice, NAO6 with added gestures), each experiment uses the same sequence of ordered steps (Intro, Story Telling, Recall Test), and each step defines the specific actions the robot will perform. The figure expands only the Story Telling step to keep the diagram readable, but Intro and Recall Test follow the same structure.

Together, these three figures motivate why the hierarchy is useful in practice. These three figures are interrelated as follows: Figure~\ref{fig:experiment-hierarchy} defines the experimental structure as an abstraction; Figure~\ref{fig:trial-instantiation} shows how the abstract experimental structure is instantiated as concrete trial records; and Figure~\ref{fig:example-hierarchy} shows the expansion of each element of the experimental structure.

\begin{figure}[htbp]
\centering
\begin{tikzpicture}[
	nodebox/.style={rectangle, draw=black, thick, fill=gray!15, align=center,
		text width=3.2cm, minimum height=1.0cm, font=\small, inner sep=4pt},
	nodeboxdark/.style={rectangle, draw=black, thick, fill=gray!35, align=center,
		text width=3.2cm, minimum height=1.0cm, font=\small, inner sep=4pt},
	arrow/.style={->, thick},
	label/.style={font=\small\itshape, fill=white, inner sep=2pt}]

	\node[nodebox]     (study)  at (0,  6.0) {Study};
	\node[nodebox]     (exp)    at (0,  4.0) {Experiment};
	\node[nodebox]     (step)   at (0,  2.0) {Step};
	\node[nodeboxdark] (action) at (0,  0.0) {Action};

	\draw[arrow] (study.south)  -- node[label, right=6pt] {has one or more} (exp.north);
	\draw[arrow] (exp.south)    -- node[label, right=6pt] {has one or more} (step.north);
	\draw[arrow] (step.south)   -- node[label, right=6pt] {has one or more} (action.north);

\end{tikzpicture}
\caption{The four-level experiment specification hierarchy.}
\label{fig:experiment-hierarchy}
\end{figure}

\begin{figure}[htbp]
\centering
\begin{tikzpicture}[
	spec/.style={rectangle, draw=black, thick, fill=gray!15, align=center,
		text width=3.2cm, minimum height=1.0cm, font=\small, inner sep=4pt},
	trial/.style={rectangle, draw=black, thick, dashed, fill=gray!5, align=center,
		text width=3.2cm, minimum height=1.0cm, font=\small, inner sep=4pt},
	arrow/.style={->, thick},
	darrow/.style={->, thick, dashed}]

	%% ---- Column headers ----
	\node[font=\small\bfseries] at (1.9,  7.0) {Protocol (designed once)};
	\node[font=\small\bfseries] at (7.9,  7.0) {Trials (run per participant)};

	%% ---- Protocol column ----
	\node[spec] (study) at (1.9, 5.8) {Study};
	\node[spec] (exp)   at (1.9, 4.2) {Experiment};
	\node[spec] (step)  at (1.9, 2.6) {Step};

	\draw[arrow] (study.south) -- (exp.north);
	\draw[arrow] (exp.south)   -- (step.north);

	%% ---- Trial column ----
	\node[trial] (t1) at (7.9, 5.5) {Trial: P01\\{\footnotesize timestamped log}};
	\node[trial] (t2) at (7.9, 4.2) {Trial: P02\\{\footnotesize timestamped log}};
	\node[trial] (t3) at (7.9, 2.9) {Trial: P03\\{\footnotesize timestamped log}};

	%% ---- Separator ----
	\draw[gray!60, thick, dashed] (4.85, 1.8) -- (4.85, 6.6);
	\node[font=\footnotesize\itshape, gray!80] at (4.85, 1.4) {protocol\,/\,trial boundary};

	%% ---- Instantiation arrows + label ----
	\node[font=\small\itshape] at (6.35, 6.3) {instantiates};
	\draw[darrow] (exp.east) -- (t1.west);
	\draw[darrow] (exp.east) -- (t2.west);
	\draw[darrow] (exp.east) -- (t3.west);

\end{tikzpicture}
\caption{One experiment protocol instantiated as a separate trial record per participant.}
\label{fig:trial-instantiation}
\end{figure}

\begin{figure}[htbp]
\centering
\begin{tikzpicture}[
	nodebox/.style={rectangle, draw=black, thick, fill=gray!15, align=center, text width=2.0cm, font=\small, minimum height=1.2cm, inner sep=2pt},
	nodeboxdark/.style={rectangle, draw=black, thick, fill=gray!30, align=center, text width=1.6cm, font=\small, minimum height=1.2cm, inner sep=2pt},
	arrow/.style={->, thick}]

	% Study
	\node[nodebox] (study) at (0, 7.0) {\textit{Study}\\Recall Study};

	% Experiments
	\node[nodebox] (nao_exp) at (-3.8, 5.0) {\textit{Experiment}\\NAO6 with Gestures};
	\node[nodebox] (tb_exp) at (3.8, 5.0) {\textit{Experiment}\\TurtleBot with Voice};
	\draw[arrow] (study.south) -- (nao_exp.north);
	\draw[arrow] (study.south) -- (tb_exp.north);

	% NAO steps (independent branch)
	\node[nodebox] (nao_s1) at (-6.1, 3.0) {\textit{Step 1}\\Intro};
	\node[nodebox] (nao_s2) at (-3.8, 3.0) {\textit{Step 2}\\Story Telling};
	\node[nodebox] (nao_s3) at (-1.5, 3.0) {\textit{Step 3}\\Recall Test};
	\draw[arrow] (nao_exp.south) -- (nao_s1.north);
	\draw[arrow] (nao_exp.south) -- (nao_s2.north);
	\draw[arrow] (nao_exp.south) -- (nao_s3.north);

	% TurtleBot steps (independent branch)
	\node[nodebox] (tb_s1) at (1.5, 3.0) {\textit{Step 1}\\Intro};
	\node[nodebox] (tb_s2) at (3.8, 3.0) {\textit{Step 2}\\Story Telling};
	\node[nodebox] (tb_s3) at (6.1, 3.0) {\textit{Step 3}\\Recall Test};
	\draw[arrow] (tb_exp.south) -- (tb_s1.north);
	\draw[arrow] (tb_exp.south) -- (tb_s2.north);
	\draw[arrow] (tb_exp.south) -- (tb_s3.north);

	% NAO: multiple real actions for Story Telling
	\node[nodeboxdark] (nao_a1) at (-5.9, 1.0) {\textit{Action 1}\\Gesture Hand};
	\node[nodeboxdark] (nao_a2) at (-3.8, 1.0) {\textit{Action 2}\\Gesture Head};
	\node[nodeboxdark] (nao_a3) at (-1.7, 1.0) {\textit{Action 3}\\Speak};
	\draw[arrow] (nao_s2.south) -- (nao_a1.north);
	\draw[arrow] (nao_s2.south) -- (nao_a2.north);
	\draw[arrow] (nao_s2.south) -- (nao_a3.north);

	% TurtleBot: multiple real actions for Story Telling
	\node[nodeboxdark] (tb_a1) at (1.7, 1.0) {\textit{Action 1}\\Play Audio};
	\node[nodeboxdark] (tb_a2) at (3.8, 1.0) {\textit{Action 2}\\Beep};
	\node[nodeboxdark] (tb_a3) at (5.9, 1.0) {\textit{Action 3}\\Speak};
	\draw[arrow] (tb_s2.south) -- (tb_a1.north);
	\draw[arrow] (tb_s2.south) -- (tb_a2.north);
	\draw[arrow] (tb_s2.south) -- (tb_a3.north);

\end{tikzpicture}
\caption{A recall study with two conditions mapped onto the four-level hierarchy.}
\label{fig:example-hierarchy}
\end{figure}

The layered structure compels researchers to define experimental protocols at multiple levels of granularity without writing code, which creates a process that is accessible to non-programmers. The step and action elements also align naturally with the sequence of events in a trial, so the wizard stays guided by the protocol while retaining control over the timing of each event, which supports the real-time control requirement (R3). Action-level execution provides a natural unit for timestamped logging and post-trial analysis, satisfying the automated logging requirement (R4). Finally, keeping experiment definitions separate from trial instances means the same protocol can be reproduced across participants and experiments, supporting both the integrated workflow (R1) and collaborative support (R6) requirements.

\section{Event-Driven Execution Model}

To achieve real-time responsiveness while maintaining methodological rigor (R3, R5), the system uses an event-driven execution model rather than a time-driven one. In a time-driven approach, the system advances through actions on a fixed schedule regardless of what the participant is doing, so the robot might speak over a participant who is still talking, or move on before a response has been given. The event-driven model avoids this by letting the wizard trigger each action when the interaction is ready for it. Figure~\ref{fig:event-driven-timeline} contrasts the two approaches using the same four-action sequence: Greet (G), Begin Story (BS), Ask Question (AQ), and End (E). In the time-driven row, fixed intervals $t_0$ through $t_2$ define when each event fires, and dashed vertical lines show where those moments fall relative to the event-driven rows below. In both event-driven rows, the wizard fires the same four labeled events at different real-time positions (T1, a faster participant, finishes well before T2, a slower one), while both preserve the same action order.

\begin{figure}[htbp]
\centering
\begin{tikzpicture}[
	dot/.style={circle, fill=black, minimum size=6pt, inner sep=0pt},
	tline/.style={->, thick}]

	% Row y positions
	% 3.5 = Time-Driven, 2.0 = Event-Driven S1, 0.5 = Event-Driven S2

	% Timelines
	\draw[tline] (0, 3.5) -- (11.5, 3.5);
	\draw[tline] (0, 2.0) -- (11.5, 2.0);
	\draw[tline] (0, 0.5) -- (11.5, 0.5);

	% Row labels
	\node[font=\small, anchor=east] at (-0.15, 3.5) {Time-Driven};
	\node[font=\small, anchor=east] at (-0.15, 2.0) {Event-Driven (T1)};
	\node[font=\small, anchor=east] at (-0.15, 0.5) {Event-Driven (T2)};

	% Time-driven events at fixed positions
	\node[dot] at (1.0,  3.5) {};
	\node[dot] at (3.5,  3.5) {};
	\node[dot] at (7.0,  3.5) {};
	\node[dot] at (10.5, 3.5) {};

	% Action labels above time-driven row
	\node[font=\scriptsize, above=3pt] at (1.0,  3.5) {Greet};
	\node[font=\scriptsize, above=3pt] at (3.5,  3.5) {Begin Story};
	\node[font=\scriptsize, above=3pt] at (7.0,  3.5) {Ask Question};
	\node[font=\scriptsize, above=3pt] at (10.5, 3.5) {End};

	%% ---- Time interval braces below time-driven row ----
	\draw[decorate, decoration={brace, amplitude=4pt, mirror}]
		(1.0, 3.2) -- (3.5, 3.2) node[midway, below=6pt, font=\scriptsize] {$t_0$};
	\draw[decorate, decoration={brace, amplitude=4pt, mirror}]
		(3.5, 3.2) -- (7.0, 3.2) node[midway, below=6pt, font=\scriptsize] {$t_1$};
	\draw[decorate, decoration={brace, amplitude=4pt, mirror}]
		(7.0, 3.2) -- (10.5, 3.2) node[midway, below=6pt, font=\scriptsize] {$t_2$};

	% Dashed vertical alignment lines
	\draw[dashed, gray!70] (1.0,  3.35) -- (1.0,  0.35);
	\draw[dashed, gray!70] (3.5,  3.35) -- (3.5,  0.35);
	\draw[dashed, gray!70] (7.0,  3.35) -- (7.0,  0.35);
	\draw[dashed, gray!70] (10.5, 3.35) -- (10.5, 0.35);

	% Event-driven S1 (fast participant)
	\node[dot] at (1.0, 2.0) {};
	\node[dot] at (2.5, 2.0) {};
	\node[dot] at (5.5, 2.0) {};
	\node[dot] at (7.8, 2.0) {};

	% Event-driven S1 labels
	\node[font=\scriptsize, below=3pt] at (1.0, 2.0) {G};
	\node[font=\scriptsize, below=3pt] at (2.5, 2.0) {BS};
	\node[font=\scriptsize, below=3pt] at (5.5, 2.0) {AQ};
	\node[font=\scriptsize, below=3pt] at (7.8, 2.0) {E};

	% Event-driven S2 (slower participant)
	\node[dot] at (1.0,  0.5) {};
	\node[dot] at (4.3,  0.5) {};
	\node[dot] at (8.5,  0.5) {};
	\node[dot] at (10.8, 0.5) {};

	% Event-driven S2 labels
	\node[font=\scriptsize, below=3pt] at (1.0,  0.5) {G};
	\node[font=\scriptsize, below=3pt] at (4.3,  0.5) {BS};
	\node[font=\scriptsize, below=3pt] at (8.5,  0.5) {AQ};
	\node[font=\scriptsize, below=3pt] at (10.8, 0.5) {E};

	% Time axis label
	\node[font=\small\itshape] at (5.75, -0.25) {time};

\end{tikzpicture}
\caption{Time-driven (top) versus event-driven (bottom, two trials) execution of the same four-action protocol.}
\label{fig:event-driven-timeline}
\end{figure}

This approach has several implications. What the event-driven model guarantees is not identical timing across trials, but consistent action ordering: every participant experiences the same sequence of protocol steps, even if the pace varies. Timing is recorded accurately, permitting researchers to analyze natural variation across participants. The wizard responds contextually without departing from the protocol; the wizard remains guided by the sequence of available actions while retaining control over when to advance based on participant cues.

The system guides the wizard through the protocol step-by-step, ensuring the intended sequence is followed. Every action is logged with a timestamp whether it was scripted or not, and anything outside the protocol is flagged as a deviation. This means inconsistent wizard behavior can be evident in the data rather than disappearing into it.

\section{Modular Interface Architecture}

Researchers interact with the system through three interfaces, each one encapsulating a specific phase of an experimental study: designing a protocol, running a trial, and reviewing the results.

\subsection{Design Interface}

The \emph{Design} interface gives researchers a drag-and-drop canvas for building experiment protocols, creating a visual programming environment. Researchers drag pre-built action components, including robot movements, speech, wizard instructions, and conditional logic, onto the canvas and drop them into sequence. Clicking a component opens a side panel where its parameters can be set, such as the text for a speech action or the gesture name for a movement.

By treating experiment design as a visual specification task, the interface lowers technical barriers (R2). Researchers can assemble interaction logic by dragging components into sequence and setting parameters naturally, without even having to write code. The resulting protocol specification is also human-readable and shareable alongside experimental results. The specification is stored in a structured format that can be displayed as a timeline for analysis and executed directly by the platform's runtime. This property is central to reproducibility: a third party with access to the specification can run the experiment faithfully without reverse-engineering the original system.

\subsection{Execution Interface}

During trials, the \emph{Execution} interface keeps the wizard informed of exactly where they are in the protocol. The current step, the available actions, and the robot's current state are all updated in real time as the trial progresses.

The \emph{Execution} interface also exposes a set of manual controls for actions that fall outside the scripted protocol. A \emph{deviation} is a spontaneous action introduced by the wizard in response to a reaction of the human subject that was not anticipated when the script was created. Consider a human subject who asks an unexpected question mid-trial: the wizard can trigger an unscripted speech response on the spot rather than leaving the interaction to stall, keeping the interaction feeling natural for the human subject. Critically, the system does not ignore these deviations from the script. Every deviation is timestamped and written to the trial log, giving researchers a complete picture of what actually happened versus what was planned. This makes unscripted actions a feature rather than a source of noise: the wizard retains real-time control over the interaction, and the logging infrastructure captures everything needed for post-trial analysis.

Additional researchers can simultaneously access a live view of a trial through the platform's Dashboard by selecting a trial to ``spectate.'' Multiple researchers observing the same trial view an identical synchronized display of the wizard's controls, human subject interactions, and robot state, supporting real-time collaboration and interdisciplinary observation (R6). Observers can take notes and mark significant moments without interfering with the wizard's control or the human subject's experience.

\subsection{Analysis Interface}

After a trial concludes, the \emph{Analysis} interface lets researchers review everything that was recorded: video of the interaction, audio, timestamped action logs, and robot sensor data, all scrubable from a single timeline. Researchers can annotate significant moments and export segments for further analysis. Because the same platform produced both the protocol and the recording, the interface eliminates the need for manual cross-referencing by showing exactly where the execution matched the design and where it deviated.

\section{Data Flow and Infrastructure Implementation}

To ensure that data from every experimental phase remains traceable, the system organizes its internals into three architectural layers and defines a clear data pathway from protocol design through post-trial analysis, covering how experiment specifications, control commands, and recorded data move through the system.

\subsection{Architectural Layers}

Like the ISO/OSI reference model for networking software, HRIStudio separates its communicative and functional responsibilities into distinct layers, as shown in Figure~\ref{fig:three-tier}. More specifically, the system is organized as a three-layer architecture, each layer with a specific responsibility:

\begin{description}
\item[User Interface layer.] Runs in researchers' web browsers and exposes the three interfaces (Design, Execution, Analysis), managing user interactions such as clicking buttons, dragging and dropping experiment components, and reviewing experimental results.
\item[Application Logic layer.] Operates as a server process that manages experiment data, coordinates trial execution, authenticates users, and orchestrates communication between the interface and the robot.
\item[Data and Robot Control layer.] Encompasses long-term storage of experiment protocols and trial data, as well as direct communication with robot hardware.
\end{description}

This separation of concerns provides two concrete benefits. First, each layer can evolve independently: improving the user interface requires no changes to robot control logic, and swapping in a different storage backend requires no changes to the execution engine. Second, the separation enforces clear responsibilities: the user interface never directly commands robot hardware; all robot actions flow through the application logic layer, which maintains consistent logging. Figure~\ref{fig:three-tier} shows that HRIStudio separates interface behavior, execution logic, and robot/data operations into distinct layers with explicit boundaries.

\begin{figure}[htbp]
\centering
\begin{tikzpicture}[
    layer/.style={rectangle, draw=black, thick, fill, minimum width=6.5cm, minimum height=1cm, align=center, text width=6.2cm},
    arrow/.style={->, thick, line width=1.5pt}]
    
    % Layer 1: UI
    \node[layer, fill=gray!15] (ui) at (0, 3.5) {
        \textbf{User Interface}\\[0.1cm]
        {\small Design, Execution, Analysis}
    };
    
    % Layer 2: Logic
    \node[layer, fill=gray!30] (logic) at (0, 1.8) {
        \textbf{Application Logic}\\[0.1cm]
        {\small Trial Engine, Authentication, Logger}
    };

    % Layer 3: Data
    \node[layer, fill=gray!45] (data) at (0, 0.1) {
        \textbf{Data \& Robot Control}\\[0.1cm]
        {\small Database, File Storage, ROS}
    };

    % Arrows (bidirectional)
    \draw[<->, thick, line width=1.5pt] (ui.south) -- (logic.north);
    \draw[<->, thick, line width=1.5pt] (logic.south) -- (data.north);
    
\end{tikzpicture}
\caption{Three-layer architecture separates user interface, application logic, and data/robot control.}
\label{fig:three-tier}
\end{figure}

\subsection{Data Flow Through Experimental Phases}

During the design phase, researchers create experiment specifications that are stored in the system database. During a trial, the system manages bidirectional communication between the wizard's interface and the robot control layer. All actions, sensor data, and events are streamed to a data logging service that stores complete records. After the trial, researchers can inspect these records through the Analysis interface.

The flow of data during a trial proceeds through six distinct phases, as shown in Figure~\ref{fig:trial-dataflow}:

\begin{enumerate}
\item A researcher creates an experiment protocol using the Design interface.
\item When a trial begins, the application server loads the protocol and allows the wizard to step through it, sending commands to the robot and waiting for events such as wizard inputs, sensor readings, or timeouts.
\item Every action, both planned protocol steps and deviations, is immediately written to the trial log with precise timing information.
\item The \emph{Execution} interface continuously displays the current state, allowing the wizard and observers to monitor the progress of a trial in real-time.
\item When the trial concludes, all recorded media (video and audio) is transferred from the browser to the server and persisted in a database as part of the trial record.
\item The \emph{Analysis} interface retrieves the stored trial data and reconstructs exactly what happened, synchronizing notable events with the video and audio recordings.
\end{enumerate}

This design creates automatically a comprehensive documentation of every trial, supporting both fine-grained analysis and reproducibility. Researchers can review not just what they intended to happen, but what actually did happen, including timing variations and deviations.

\begin{figure}[htbp]
\centering
\begin{tikzpicture}[
    stage/.style={rectangle, draw, thick, rounded corners, minimum width=3.5cm, minimum height=1cm, align=center, font=\footnotesize},
    arrow/.style={->, thick, line width=1.3pt}]
    
    % Six stages stacked vertically with descriptions inside
    \node[stage, fill=gray!10] (s1) at (0, 7.5) {1. Design Protocol\\{\scriptsize Researcher creates workflow}};
    \node[stage, fill=gray!15] (s2) at (0, 6) {2. Load \& Execute\\{\scriptsize System loads and runs trial}};
    \node[stage, fill=gray!20] (s3) at (0, 4.5) {3. Log Events\\{\scriptsize Actions recorded with timestamps}};
    \node[stage, fill=gray!25] (s4) at (0, 3) {4. Display Live State\\{\scriptsize Wizard sees real-time progress}};
    \node[stage, fill=gray!30] (s5) at (0, 1.5) {5. Transfer Media\\{\scriptsize Video/audio saved to server}};
    \node[stage, fill=gray!35] (s6) at (0, 0) {6. Analyze \& Playback\\{\scriptsize Review data with synchronized media}};
    
    % Downward arrows
    \draw[arrow] (s1.south) -- (s2.north);
    \draw[arrow] (s2.south) -- (s3.north);
    \draw[arrow] (s3.south) -- (s4.north);
    \draw[arrow] (s4.south) -- (s5.north);
    \draw[arrow] (s5.south) -- (s6.north);
    
\end{tikzpicture}
\caption{Trial data flow: from protocol design through execution and recording, to analysis and playback.}
\label{fig:trial-dataflow}
\end{figure}

\subsection{Requirements Satisfaction}

The design choices described in this chapter were made to meet the requirements from Chapter~\ref{ch:background}. Having the researcher work through a single platform from protocol creation to post-trial review satisfies R1 (integrated workflow: design, execution, and analysis in one environment) without extra tooling. The visual drag-and-drop Design interface removes the need for programming knowledge, satisfying R2 (low technical barriers) by keeping the system accessible to researchers without a software background. Event-driven execution satisfies R3 (real-time control) by giving the wizard control over pacing while keeping the trial on protocol. All actions are logged automatically at the system level, satisfying R4 (automated logging) without requiring researchers to add logging by hand. The three-layer architecture decouples action specifications from robot-specific commands, satisfying R5 (platform agnosticism) by letting the same protocol run on different hardware without modification. Finally, shared live views and multi-user access let interdisciplinary teams observe and annotate the same trial simultaneously, satisfying R6 (collaborative support).

\section{Chapter Summary}

This chapter described the architectural design with emphasis on how each design choice directly implements the infrastructure requirements identified in Chapter~\ref{ch:background}. The hierarchical organization of experiment specifications enables intuitive, executable design. The event-driven execution model balances protocol consistency with realistic interaction dynamics. The modular interface architecture separates concerns across design, execution, and analysis phases while maintaining data coherence. The integrated data flow ensures that reproducibility is supported by design rather than by afterthought. The following chapter presents HRIStudio, the platform built on these design principles, describing the specific technologies and architectural components that bring them to life.