Data Privacy Protocols & Research Data Management
This policy explains how PRACSYS collects, stores, and uses research and simulation data while protecting participants, collaborators, and visitors.
Commitment to Research Privacy
We treat privacy as an engineering constraint: if a dataset cannot be handled safely, we do not collect it.
Most of our work lives in autonomous systems and motion planning, where "data" often means telemetry, logs, and synthetic traces rather than personal profiles. Even so, research logs can accidentally capture identifiers (a device name in a network trace, a face in a lab video, a voice in a hallway recording). Our default posture is to minimize collection, isolate storage, and document access.
When we run studies involving people, we align handling practices with the study protocol and the approvals that govern it. In practice, that means we separate research records from operational website records, and we keep a clear chain of custody for datasets that leave the lab environment.
Working rule: we design experiments so the algorithm can be validated without needing direct identifiers. If identifiers are necessary, we scope them tightly and remove them as early as the workflow allows.
Data Collection in Autonomous Systems
We collect data in three common settings: simulation, bench testing, and in-lab robotic trials. Each setting produces different artifacts, and we handle them differently.
What we collect
- Simulation telemetry: state trajectories, planner outputs, collision checks, cost terms, and timing traces.
- Robot and sensor logs: joint states, IMU readings, depth or RGB streams, LiDAR scans, and calibration files when needed for reproducibility.
- System metadata: software versions, parameter sets, and hardware configuration snapshots used to reproduce results.
- Website contact submissions: information you choose to send us via inquiry forms (typically name, email, and message content).
What we try not to collect
We avoid collecting sensitive personal data unless a study explicitly requires it. For example, we do not set up "always-on" recording as a default lab practice. If video is required for an experiment, we define the camera field-of-view to match the task area rather than the room.
How we store and protect it
Research datasets are stored in access-controlled locations with role-based permissions. Raw logs remain separate from derived datasets so we can apply de-identification steps without losing the original provenance. Access is granted on a need-to-use basis and reviewed when projects change hands.
Field note: telemetry can be surprisingly identifying when combined (timestamps + device IDs + video). Our reviews focus on combinations, not just single files.
Collaborators and Funding Agencies
Some projects involve external collaborators, shared infrastructure, or sponsor reporting requirements. When that happens, we define data boundaries up front: what leaves PRACSYS, what stays internal, and what must be deleted at the end of a project.
When data is shared
- Research collaboration: datasets may be exchanged under a written data management plan tied to the project scope and timeline (for example, a multi-year research collaboration with periodic dataset releases).
- Funding and compliance: sponsors may receive aggregate results, metrics, or documentation that supports reproducibility; raw participant data is not shared unless the protocol and agreements explicitly require it.
- Service providers: limited operational data may be processed by vendors that support hosting, email, or security monitoring, constrained to what is necessary to run the site and lab operations.
We do not sell research datasets or participant information. If a project requires broader dissemination (for example, a public benchmark), we prepare a release version that removes direct identifiers and strips unnecessary metadata.
Utilization for Algorithmic Validation
We use collected data to debug systems, validate algorithms, and support reproducible research. That usually means comparing planner behavior across scenarios, measuring failure modes, and verifying that reported metrics can be regenerated from stored artifacts.
Typical uses
- Regression testing after code changes (e.g., ensuring a planner update does not change collision outcomes on a fixed scenario set).
- Model and parameter selection using held-out runs.
- Safety analysis in controlled environments, including review of near-miss events in lab trials.
De-identification and minimization in practice
When human-related signals appear in a dataset, we prefer transformations that preserve what the algorithm needs. For example, we may downsample video, crop to the workspace, or replace raw frames with derived features. Some tasks—like diagnosing perception failures—can require short retention of raw sensor streams, so we time-box that retention to the debugging window rather than keeping it indefinitely.
Because autonomous systems experiments vary widely by sensor suite and environment, de-identification is sometimes a judgment call made at the dataset level rather than a single universal rule.
Participant and Visitor Rights
If you participate in a study, your rights are governed by the study materials you receive at the time of participation, including any consent documentation and the protocol's contact pathway for questions.
Requests we can usually support
- Access: asking what information we hold about you within the scope of a specific study or contact submission.
- Correction: fixing inaccurate contact details you provided.
- Deletion: removing contact-form submissions and, when feasible, removing identifiable study records tied to you.
For research datasets, deletion can be constrained by how the data was used (for example, if it has been aggregated into summary statistics or embedded into derived artifacts). When that constraint applies, we focus on removing direct identifiers and preventing further use of the identifiable source records.
To make a privacy request related to PRACSYS research data or website communications, contact us with enough detail to locate the relevant project or submission.
Contact PRACSYSPolicy Versioning and Notifications
We update this policy when our data practices change—new sensors, new collaboration patterns, or new retention needs tend to trigger revisions.
When changes are material, we post the updated version on this page and adjust operational workflows to match. If a change affects an active study, we handle notifications through the study's established communication channel rather than relying on general website announcements.
Last updated information is maintained with the published page version. If you need a prior version for a specific project timeline, request it through the contact page.