Document real-world peak detector validation

docs/architecture.md

@@ -52,6 +52,9 @@ This is calculation-domain logic, with no ENLYZE transport dependency.
 The detector uses timestamps rather than a sample count. An interval longer
 than the configured positive `max_sample_gap_seconds` restarts a reset candidate,
 so a timestamp alone does not establish that a signal was continuously below
-threshold. Equal
-timestamps are processed in arrival order but contribute no elapsed time, and
-backwards timestamps are rejected. Reset values are not assumed to be zero.
+threshold. These parameters (`min_peak`, `drop_ratio`, `hold_seconds`, and
+`max_sample_gap_seconds`) are selected per signal rather than treated as global
+process constants. Equal timestamps are processed in arrival order but
+contribute no elapsed time, and backwards timestamps are rejected. Reset values
+are not assumed to approach zero, and peak values may vary materially between
+cycles.

docs/roadmap.md

@@ -31,7 +31,10 @@ tests against sanitized fixtures.
 The generic configurable sawtooth detector is implemented: it retains the
 current maximum, closes a cycle after a configurable below-peak fraction has
 actual sample support for a configurable elapsed duration, and emits one
-completed peak. Its pure state can later be persisted for incremental use.
+completed peak. Its pure state can later be persisted for incremental use. It
+has been validated with a clean K7 roll-length reference signal and a more
+variable Bento 2 roll-weight robustness signal; the latter includes plateaus,
+non-zero resets, and varying peak heights without detector special cases.
 
 ## Later