PEBERS Research Study Platform

Project Overview

PEBERS is a configurable research platform I built for the HAX Lab at the University of Rhode Island from June through August 2026. The goal was to create a common system for defining and running participant studies without rebuilding the application infrastructure for every study.

I was responsible for the full implementation of the platform, with Shaun Wallace guiding the project requirements and research needs. I designed PEBERS to be modular for different types of study goals, and I worked with other members of the lab to integrate systems they were developing into PEBERS, such as head track and brightness monitoring, which helped shaped what features PEBERS needed to support and create flexible task interfaces.

An important goal of PEBERS was to allow study configuration to be lightweight and understandable by nontechnical researchers without having to deal with the syntax of JSON or create a large number of custom components. Instead of hard-coding an experiment directly into the participant application, a researcher describes a study in human-readable YAML. That definition controls the study metadata, participant behavior, ordered tasks, task-specific configuration, materials, enabled measures, instructions, consent, and completion behavior. PEBERS validates and compiles that authoring input before it can be published to participants.

A public demo is currently pending release by the lab and fellow lab members are already using PEBERS to run their own studies.

Configuration-Driven Study Authoring

A major goal of PEBERS was to keep study authoring separate from the application that executes a study.

Researchers can assemble a study from reusable pieces without modifying the SvelteKit application itself. PEBERS uses Zod throughout the authoring process to validate study definitions, task configuration, participant settings, materials, manifests, and result contracts. Unknown fields and invalid combinations are rejected rather than silently ignored.

Validation also goes beyond basic YAML structure. The platform checks relationships such as:

• unique study and task identifiers;
• task and measure types;
• task-specific configuration semantics;
• required material types and availability;
• participant identity and repeat-session settings;
• task placement rules;
• result and execution-plan requirements.

In short, a heavy emphasis was put on validation and diagnostics so researchers could easily understand what was wrong with a study definition before it was published with checks along every step of the authoring, validation, and publication process.

A full admin interface was created to support this workflow. Researchers can inspect authored studies, see validation errors and warnings, and publish studies when they are ready. Admin also supports extensive debugging reports and viewing the answers and diagnostics from respondents.

Modular Tasks & Measures

Tasks are independent packages rather than components hard-coded into the study runner.

Each task owns its own manifest, configuration schemas, and runtime behavior designed in a way to allow task-specific logic to remain close to the task while the participant application stayed responsible for the common study lifecycle.

The included task packages grew to cover:

• configurable surveys with reusable question libraries;
• reading-comprehension passages and reading-duration instrumentation;
• visual preference comparisons with deterministic per-session presentation plans;
• crowdsourcing completion codes for systems such as Prolific.

PEBERS also defines a parallel registration model for measurement systems such as mouse tracking, head position, and eye tracking. This was particularly important for collaboration inside the lab: other systems could be developed independently and integrated through the platform’s task and measure contracts instead of requiring project-specific changes throughout the core application.

Reproducible Study Execution

One of the most interesting parts of the project was handling asynchrony between what a researcher is authoring and what a participant is actually running.

PEBERS separates authoring state from published state. Editing a YAML file does not immediately change the study being served to participants. A researcher reviews the candidate in the admin dashboard and explicitly publishes it when it is ready.

State management is completely handled through study revisions, referenced material hashes, participant-safe configuration, and the executable revision required to run it. Existing participant sessions remain bound to the revision they started with even if a newer study definition is authored or published later, and the reports are extensive enough to allow a researcher to understand exactly what a participant saw and how the study was configured at the time of their session.

I also implemented execution fingerprints for the participant application, tasks, and measures. If executable code changes after a session begins, PEBERS can detect that the deployed implementation no longer matches the one the session was created against. Rather than silently continuing under different code, the platform routes the participant through a defined recovery or restart path.

Dealing with all these questions of state and validation elevated PEBERS from a simple idea of study modules and configuration into a full a platform enough foundation to support running extensive studies.

Participant Sessions, Recovery & Data Integrity

Participant studies use durable server-side sessions backed by SQLite.

PEBERS supports multiple identity modes depending on the study: anonymous session-scoped identity, recruitment-platform identifiers, and pseudonymous longitudinal identities stored in the browser. Researchers can configure whether sessions may resume, whether participants may participate more than once, and how broadly repeat restrictions apply.

I spent a significant amount of the project working through edge cases around session recovery and durable writes. The final system handles interrupted creation requests, task submission retries, completed-session restoration, incompatible execution revisions, and shared participant identification (or anonymous sessions).

These details are mostly invisible during a successful study, but they matter significantly when participant data is being collected remotely and a refresh, network failure, or deployment cannot simply mean losing or corrupting a response.

Researcher Administration

The researcher-facing admin application became a substantial part of PEBERS rather than a thin configuration screen.

Researchers can inspect authored and published studies, validation errors and warnings, normalized configuration, material audits, enabled measures, revision information, and publication history. Publication and participant access are deliberately separate controls, allowing a study to be published without immediately accepting responses or appearing in the public study list.

The session-record interface provides a durable view of participant activity, including:

• session and participant identity information;
• current response state and replacement history;
• task progress and accepted result envelopes;
• the exact per-session execution plan (useful for dynamic tasks that randomize or reorder content);
• ordered interaction events;
• material and revision metadata;
• completion state and timestamps.

This was useful both operationally and as a debugging tool while building the platform because the application could expose exactly what it believed had happened during a participant session rather than reconstructing state from the newest version of the study files.

←→

Participant-facing study experience running a configured task sequence.

Showing image 1 of 3: PEBERS participant study interface

Reflection

PEBERS was one of the projects that pushed me the most toward thinking about all the possible cases and edge scenarios that a system might encounter. It has a different degree of correctness and control than a typical website requires to ensure it runs as smoothly as possible and avoiding major issues such as missing data or participant frustration. We also have to consider issues areound the design and experience of using the system, as to not bias the results of the research.

At first, the central problem appeared to be configuration: make it possible to describe a study in YAML and load different tasks dynamically. As the platform grew, the harder questions became about reproducibility, participant identity, failure recovery, immutable state, and how separately developed research components should interact.

By the end of the project, PEBERS had grown from an early configuration prototype into a complete participant-study platform with a reusable task architecture, researcher publication workflow, durable sessions, revision tracking, and a substantial test suite. That progression made it one of the most technically involved systems I’ve worked on.