Outcome#
You can place code, durable research data, temporary files, GUI work, and compute intentionally instead of treating every available drive or service as interchangeable.
Concept#
Git is not a data archive, scratch is not a backup, a laptop is not a shared compute node, and an AI provider is not automatically approved for unpublished material. Correct placement prevents data loss, leakage, and blocked projects.
Worked Example#
The map separates source control, durable storage, temporary storage, GUI access, and scheduled computation.
A correct example uses these decisions:
- Where does maintained source code belong? In an approved GitHub repository.
- Where should a heavy batch computation run? In a bounded Slurm allocation on Euler or another approved compute system.
- Where should an approved collaborative dataset remain authoritative? In the supervisor-approved durable project location on NAS or another named project store.
- What may be placed in scratch storage? Temporary high-throughput files that can be recreated from recorded inputs.
- Where should you use an approved Windows-only engineering GUI? On Blade for interactive GUI work, while heavy batch computation uses an approved compute system.
- What project context may you send to an AI service during onboarding? Only the fictional fixture provided by the mission, unless the real data owner approved the exact service and content.
Common Trap#
Choosing a location because it is convenient today rather than because its ownership, backup, and lifecycle fit the data.
If Blocked#
Do not guess a storage path or AI approval. Record the unresolved decision and ask the project information owner or supervisor. The data and AI policy defines the escalation boundary.
Useful references:
Understand Before Accepting AI Output#
Zero-data-retention marketing does not decide whether project material may be uploaded. The information owner, ETH policy, lab policy, account terms, and data classification all still apply.