DESIGN PRINCIPLES
Tools for scientists should be fast, friendly, and fit how science is actually done. These are the few, truly independent principles we hold.
Inspired by the HashiCorp Tao, Linear Method, and CLI Guidelines.
Ethnography-first
Design from field evidence: observe real labs, map decisions and hand-offs, then build to fit the actual workflow (not the imagined one).
Workflow > tech
Start from outcomes (reproduce a figure, compare models, publish a dataset); provide opinionated end-to-end paths with escape hatches.
Clarity & simplicity
Minimal, calm surfaces with consistent language and patterns; progressive disclosure for advanced power. Readable typography, whitespace, clear hierarchy.
Speed & feedback
Optimize time-to-first-result and iteration loops: live previews, resumable runs, honest progress and logs.
Right thing == easy thing
Defaults encode best practice (provenance, pinned envs, licenses); preflight checks and gentle guardrails; one-click "share reproducible snapshot."
Composable & extensible
Small parts, loosely joined: stable CLIs/APIs, streamable I/O, open formats, and first-class plugins/scripts/hooks.
Native to the ecosystem
Meet users where they work (terminals, notebooks, editors, CI, HPC, cloud). Portable and interoperable by default.
Reproducible by design
Auto-capture provenance (versions, seeds, params, git SHA, env), emit immutable artifacts/manifests, and make reruns deterministic.
Open & collaborative
Transparent code/specs, welcoming contribution paths, and first-class sharing of runs, data, and figures.
Reliable & safe
Contract/property tests, defensive validation with actionable errors, safe retries/checkpoints, and graceful degradation.
Using these principles
We'd love to see how you're applying these design principles in your scientific tools. Share your work or get feedback from our community.
Share your work