index 966cd22..d53f88b 100644
@@ -4,7 +4,7 @@ visibility: public-edit
# how to design tests, iterate, and ensure robustness
-from running dozens of experiments at a [[neurotech startup|wiki/research-notes/signal-processing-workflow]] — on brains, on hardware, on signals — i developed a sense for what separates experiments that produce useful data from experiments that produce noise.
+from running dozens of experiments at a [[neurotech startup|signal-processing-workflow]] — on brains, on hardware, on signals — i developed a sense for what separates experiments that produce useful data from experiments that produce noise.
## the experiment design framework
@@ -73,7 +73,7 @@ timestamp synchronization was a recurring nightmare. each device (EEG headset, s
- tried software timestamps — "current script might not be using some settings that are important"
- tried logging approach — eventually worked but required careful validation
-"need to get correct times" — without precise timing, epoch-averaging is meaningless. this is an unsexy but critical part of [[experiment design|wiki/research-notes/experiment-design]] that textbooks don't emphasize enough.
+"need to get correct times" — without precise timing, epoch-averaging is meaningless. this is an unsexy but critical part of [[experiment design|experiment-design]] that textbooks don't emphasize enough.
## designing for robustness
@@ -94,4 +94,4 @@ the meta-skill: knowing when you have enough data to make a decision vs when you
---
-*see also: [[signal processing workflow|wiki/research-notes/signal-processing-workflow]], [[debugging hardware|wiki/research-notes/debugging-hardware]], [[reading papers|wiki/research-notes/reading-papers]]*
\ No newline at end of file
+*see also: [[signal processing workflow|signal-processing-workflow]], [[debugging hardware|debugging-hardware]], [[reading papers|reading-papers]]*
\ No newline at end of file