turn-stages.md halves the settle hold: it says 10s, the cap is 20s, and telemetry says 19.9997s #1078

New issue

Closed

opened 2026-08-19 15:35:11 +00:00 by coilyco-ops · 0 comments

coilyco-ops commented

2026-08-19 15:35:11 +00:00

Member

The defect

docs/sirens-echo-turn-stages.md states in bold:

A member's answer can be held for up to 10 seconds after it is ready

The cap is turnProgressEvery, which deriveKnobs sets to turnProgressAfter * 2, so at the packaged 10s wait the ceiling is 20 seconds. settleDelay returns turnProgressEvery - remainder, so the beat is the bound rather than the wait.

docs/sirens-echo-progress.md already describes the same mechanism correctly, with the line posting at ten seconds and later messages releasing on a twenty second grid. The two pages disagree, and the one carrying the bold claim is the wrong one.

The telemetry disagreed with it in the open

Measured on the sirens-dowel lane over 24h to 2026-08-19:

turn.progress.settle p50 - 15.97s
turn.progress.settle p95 - 19.9997s, on 33 of 120 turns

A p50 of 15.97s is not reachable under a 10s ceiling. The number was refutable from the backend the whole time.

Why it matters more than a typo

That sentence exists to hand someone a decision. It continues "whether that trade is right is a separate question from whether it is visible", so it is the sentence a reader weighs when deciding whether the hold is acceptable. Halving the cost being weighed changes the answer.

It also misplaces where the hold bites. Splitting sirens-dowel turns into stages shows the settle dominating ordinary turns rather than slow ones:

22.3s turn - 9.5s settle, 10.0s model across 2 calls, 0.63s tools
35.3s turn - 20.0s settle, 12.2s model across 2 calls, 1.12s tools
17.2s turn - 0s settle, 15.1s model across 2 calls, 2.02s tools

Against a 300.8s turn where the settle was 0s and model time was 99% across 10 calls. A reader working from "up to 10 seconds" would rank the settle behind tool time on a median turn, where it is in fact larger than everything except the model.

Fix

Correct the sentence, name the derivation so the number cannot drift from the knob again, and cite the measurement. PR attached.

coilyco-bridge/deploy#739 and coilyco-bridge/deploy#740 - the sirens-dowel lane sets SIRENS_ECHO_PROGRESS_AFTER to 5s, which moves this ceiling to 10s. The doc is wrong at any knob value, so this is not fixed by that change.
#1002 - the turn-cost question. The stage split above is posted there.

## The defect [`docs/sirens-echo-turn-stages.md`](/coilyco-gaming/sirens-echo/src/branch/main/docs/sirens-echo-turn-stages.md) states in bold: > **A member's answer can be held for up to 10 seconds after it is ready** The cap is `turnProgressEvery`, which `deriveKnobs` sets to `turnProgressAfter * 2`, so at the packaged 10s wait the ceiling is **20 seconds**. `settleDelay` returns `turnProgressEvery - remainder`, so the beat is the bound rather than the wait. [`docs/sirens-echo-progress.md`](/coilyco-gaming/sirens-echo/src/branch/main/docs/sirens-echo-progress.md) already describes the same mechanism correctly, with the line posting at ten seconds and later messages releasing on a twenty second grid. The two pages disagree, and the one carrying the bold claim is the wrong one. ## The telemetry disagreed with it in the open Measured on the sirens-dowel lane over 24h to 2026-08-19: * `turn.progress.settle` p50 - **15.97s** * `turn.progress.settle` p95 - **19.9997s**, on 33 of 120 turns A p50 of 15.97s is not reachable under a 10s ceiling. The number was refutable from the backend the whole time. ## Why it matters more than a typo That sentence exists to hand someone a decision. It continues "whether that trade is right is a separate question from whether it is visible", so it is the sentence a reader weighs when deciding whether the hold is acceptable. Halving the cost being weighed changes the answer. It also misplaces where the hold bites. Splitting sirens-dowel turns into stages shows the settle dominating ordinary turns rather than slow ones: * 22.3s turn - **9.5s** settle, 10.0s model across 2 calls, 0.63s tools * 35.3s turn - **20.0s** settle, 12.2s model across 2 calls, 1.12s tools * 17.2s turn - 0s settle, 15.1s model across 2 calls, 2.02s tools Against a 300.8s turn where the settle was 0s and model time was 99% across 10 calls. A reader working from "up to 10 seconds" would rank the settle behind tool time on a median turn, where it is in fact larger than everything except the model. ## Fix Correct the sentence, name the derivation so the number cannot drift from the knob again, and cite the measurement. PR attached. ## Related * `coilyco-bridge/deploy#739` and `coilyco-bridge/deploy#740` - the sirens-dowel lane sets `SIRENS_ECHO_PROGRESS_AFTER` to 5s, which moves this ceiling to 10s. The doc is wrong at any knob value, so this is not fixed by that change. * #1002 - the turn-cost question. The stage split above is posted there.

coilyco-ops referenced this issue from a commit

2026-08-19 15:35:30 +00:00

docs(turn-stages): the settle hold is 20s, not the 10s this page claimed

coilyco-ops referenced this issue from a pull request that will close it,

2026-08-19 15:35:45 +00:00

docs(turn-stages): the settle hold is 20s, not the 10s this page claimed #1079

coilyco-ops referenced this issue

2026-08-19 15:36:30 +00:00

Measure where the 32.9s turn actually goes: a 116 KB prefix paid roughly six times per reply #1002