· Red light · Characterization v4 delay

Feedback delay: why balanced GSRF fails as a command path

Published loss. If you need delay-tolerant command smoothing, start with EMA—not GSRF.

Control engineers sometimes ask: “Can I drop GSRF on the measured plant signal that arrives late and use that as a softer command?” The workbench answer is a hard red light for balanced Practical.

Locked delay numbers

MAD to delayed measured plant versus EMA (characterization v4 delay pack):

Plant delay τGSRF vs EMA (MAD-to-measured)
3 minutes~+59% worse
6 minutes~+97% worse
10 minutes~+106% worse

Full cage: Evidence · Boundaries · narrative: When GSRF lost.

Mechanism (why the spring loses)

GSRF’s spring pulls toward a declared normal \(x^*\) while softly listening to observations. When the “observation” is a delayed truth, the spring still fights for the normal and the delayed measurement fights for where the plant was minutes ago. EMA has no restoring thermostat— it is happier lagging the delayed stream. On this job, lagging is the lesser evil.

What to use instead

Verdict

Do not deploy balanced GSRF as a delayed closed-loop command smoother on the tested timescales. Deploy it to calm signals before models and actuators when delay is not the dominant plant truth path. Publishing this loss is intentional—same trust architecture as red lights on the Evidence page.

Sources: characterization v4 delay · Evidence boundaries · when-gsrf-lost · compare decision table

Questions people actually ask

How bad is feedback delay for GSRF commands?

Locked packs: MAD-to-measured about +59%, +97%, and +106% worse than EMA at 3, 6, and 10 minute delays.

Can I still use GSRF near control loops?

Prefer measurement hygiene and shadow mode; do not treat multi-minute delayed command smoothing as a supported claim.

Where is the longer control guide?

See autonomous control and runaway-feedback-loop-prevention application guides.

Related research