Project: Hypergravity Habitat
Document type: preliminary data-management plan
Status: working document for pre-feasibility and demonstrator planning
Scope: engineering, environmental, biological, human-subject, metadata, code, and open-science data governance
This document defines how data should be generated, documented, stored, shared, and protected in the Hypergravity Habitat project.
The core data-management question is:
How can the project make calculations, demonstrator data, environmental measurements, and experimental results reproducible while protecting sensitive data and avoiding unsupported claims?
This plan should be updated before any real experiment begins.
The project should follow four principles.
| Data type | Examples | Sensitivity | Likely sharing status |
|---|---|---|---|
| calculation data | radius, speed, acceleration tables | low | open |
| simulation data | parameter sweeps, model outputs | low-medium | open where possible |
| sensor data | acceleration, vibration, temperature, humidity | low-medium | open where possible |
| biological data | growth curves, images, assay outputs | medium | share with metadata if safe |
| human physiological data | ECG, blood pressure, sleep, performance | high | restricted or anonymized |
| video/image data | participant or payload recordings | variable | restricted if identifiable |
| operational logs | transfer events, stops, maintenance | medium | project-controlled |
| safety data | incident reports, hazard logs | medium-high | controlled |
| code | calculation and analysis scripts | low | open by default |
Every experiment or demonstrator run should record:
Without metadata, experimental results may not be interpretable.
Suggested convention:
YYYYMMDD_project_stage_payload_run_datatype_version.ext
Example:
20260715_stage2_seedling_run03_acceleration_v01.csv
20260715_stage2_seedling_run03_images_v01.zip
20260715_stage2_seedling_run03_protocol_v01.md
Use Git for:
Do not store large binary datasets directly in Git unless explicitly planned. Use a separate data repository or large-file system for large imaging, sensor, or video datasets.
A future implementation should define:
For human-subject data, storage must comply with applicable data-protection law and institutional rules.
Where possible, data should be:
Not all data can be open. Sensitive human data may require restricted access.
Human-subject data may include:
Requirements:
Human data should not be treated as open by default.
Biological datasets should include:
For genetically modified organisms, pathogens, or controlled materials, additional governance applies.
Engineering data should include:
Acceleration and vibration data are core project data. They should be preserved even when biological or human results are inconclusive.
Every analysis should include:
The project should prefer scripts or notebooks over manual spreadsheet calculations for key outputs.
Suggested defaults:
The repository should not assume that all future data can be public.
A publication-quality dataset should include:
| Risk | Mitigation |
|---|---|
| missing metadata | mandatory metadata template |
| uncalibrated sensors | calibration log |
| undocumented processing | version-controlled scripts |
| privacy breach | access control and pseudonymization |
| large binary file loss | backup and external data storage |
| unsupported claims | link conclusions to data and uncertainty |
| confounders not logged | minimum environmental logging standard |
The Hypergravity Habitat project depends on data quality. Without complete metadata, acceleration logs, vibration data, environmental measurements, and reproducible analysis, biological or human findings would be difficult to interpret.
Data management is therefore not administrative overhead; it is central to scientific validity.