Learning paths¶
Choose the kind of help you need¶
Follow a worked path
Start with bundled synthetic data, complete a successful analysis, then move to the full hands-on workflow and generated outputs.
Solve a taskUse a goal-oriented guide
Set up a project, define metadata, adapt an export, validate a dataset, align clocks, troubleshoot problems, choose a model, or prepare reproducible reporting.
Look up factsUse concise reference material
Find function signatures, domain APIs, signal and column semantics, integration surfaces, citation details, and the complete frozen export reference.
Understand whyRead the reasoning behind the workflow
Understand measurement-before-modelling, research-pipeline design, reproducible multimodal studies, model choice, and the scientific boundaries behind package decisions.
New to the package¶
Use this sequence when the immediate goal is to become productive without starting from the 406-function reference.
- First analysis — get a small, successful synthetic workflow running.
- Hands-on EDA research guide — see QC, signal processing, event candidates, plots, exports and reporting evidence in one connected analysis.
- Workflow map — switch from the teaching example to the modality or task you actually recorded.
- Plot gallery — inspect generated outputs and the analyses that create them.
- API by domain — move to exact function-level reference only when implementation detail is needed.
Starting a real research project¶
For new or unfamiliar data, use the provenance-first onboarding sequence rather than jumping directly into preprocessing.
Choose by research domain¶
| You are working on… | Start here | Then inspect | Before interpretation |
|---|---|---|---|
| EDA / GSR / SCR | EDA / GSR / SCR example | Hands-on EDA research | Measurement accountability |
| PPG / HR / IBI / HRV | PPG / HRV example | Cardiac source provenance | Interpretation guardrails |
| Pupil / gaze / fixation / AOI | Pupil / gaze / AOI example | Eye-tracking ecosystem bridges | Measurement accountability |
| Event-linked multimodal data | Multimodal example | Timebase and alignment guide | Timebase provenance |
| External tool interoperability | Interoperability example | Integrations | Interoperability version testing |
| Grouped prediction | Modelling strategy guide | Grouped mixed-effects boosting | Interpretation guardrails |
| Hierarchical variability models | Methods overview | Choosing a location–scale model | Interpretation guardrails |
Choose by role¶
Researcher bringing new data¶
Use Project → Define → Adapt → Validate → Decide → Analyze → Report. Keep source files immutable, write down field meaning before code depends on it, and separate QC evidence from exclusion decisions.
Researcher reproducing or extending an analysis¶
Start from the end-to-end runnable EDA example and reporting/reproducibility guide. Reuse explicit settings and manifests instead of reconstructing analysis choices from figures alone.
Reviewer, collaborator or auditor¶
Read Parity & validation, Deep validation, Private real-data validation, QC & exclusion decision ledger, Measurement accountability and Interpretation guardrails. These pages are the shortest path to what the package claims, how those claims are tested, and where they stop.
Developer or advanced integrator¶
Use API by domain, Complete 406-function reference, Integrations and Development. The tutorial layer is useful for context, but implementation work should be anchored to the reference and validation contracts.
Common question → best page¶
| Question | Best page |
|---|---|
| “What should I do first?” | Start here |
| “How should I structure a new study project?” | Research project scaffold |
| “What does this field mean?” | Signal and column glossary |
| “How do I document units, clocks and event labels?” | Study metadata and data dictionary |
| “How do I adapt an unfamiliar export?” | Bring your own export safely |
| “Is this dataset ready to analyze?” | Validate a new dataset |
| “A QC check failed—what now?” | Troubleshooting and diagnostics |
| “Should I remove these rows or participants?” | QC & exclusion decision ledger |
| “How do I align events or modalities?” | Timebase and alignment |
| “Which model family fits my design?” | Choose a modelling strategy |
| “How should I report this analysis?” | Reporting and reproducibility |
| “Which exact function do I need?” | API by domain |
| “What evidence supports package parity?” | Deep validation |
| “What claims should I avoid?” | Interpretation guardrails |
Do not treat the documentation types as interchangeable¶
A tutorial is allowed to make choices for a controlled teaching example. A how-to guide assumes you already have a concrete goal. Reference describes the software and its interfaces. Explanation discusses why the scientific workflow is designed as it is. Crossing those purposes carelessly creates two common errors: copying tutorial defaults into a study without review, or treating a concise API description as scientific justification for a measurement claim.