In short
A project is saved like any other entity: a ZIP archive, or a git repository. The mechanism is common to all nine types and covered in Git versioning; this page says what is specific to a project — what its export contains, and what it leaves behind.
What an exported project contains
The export produces a tree of readable files — JSON and Markdown — where each part of the project has its own file.
| What leaves | In what form |
|---|---|
| The project | Its metadata, readme, license, tasks and notes. |
| Cohorts | One file per cohort: its inclusion and exclusion criteria. |
| Concept lists | One file per list. |
| Dashboards | One file per dashboard, with its tabs and widgets. |
| IDE scripts | Your R and Python files, as they are. |
| Dataset structure | Columns, types, labels and constraints — without the rows. |
The format matters: because these files are text, a comparison tool shows exactly what changed between two versions of a cohort. An added criterion reads as one line.
Data does not leave by default
Your datasets’ rows are excluded from export and versioning. What leaves is the structure: enough to rebuild the table, not its contents.
To include a specific file, mark it explicitly — right-click the dataset, Mark for versioning. The decision is made file by file, never globally.
What 'versioning a dataset' really carries
Marking a data file also includes its edit log — your cell corrections. That is consistent: for a hand-filled collection the log is part of the data. Both leave together, or neither does.
Saving and versioning
The Export tab offers Download ZIP: the complete tree, ready to be archived, sent, or re-imported elsewhere. It is the simplest gesture, and often enough — archiving a project’s state at submission time, passing work to a colleague.
The Repository tab connects the project to a remote repository, for history and multi-person work.
Both ways out are common to every entity
Connecting a repository, syncing, pulling other people’s work, and choosing between one repository or one per element: all of it works the same way for a project, an ETL pipeline or a workspace, and is described once and for all in Git versioning and Import and export.
What does not leave
Patient data — unless explicitly marked, file by file —, connection passwords and tokens, and execution results: a cohort’s count and its attrition depend on the database queried, not on the definition, and every installation recomputes them.
The pipeline is not versioned either
The diagram on the Pipeline page stays local as long as its execution does not exist.
Importing a project
A ZIP re-imports, and a git repository clones. You get back cohorts, dashboards and scripts — and you reconnect your own databases, since connections do not travel.
That is what makes a Linkr project genuinely reproducible: a colleague in another hospital replays your approach on their data, without yours ever leaving your institution.
Going further
- Git versioning — the repository, syncing, and choosing one repository per element.
- Import and export — both ways out, and what an archive holds.
- Datasets — marking a data file for versioning.
- Publishing content — going beyond project-to-project sharing.