Let’s see if we can justify/rationalize just setting the razor road (we’re calling zero-width roads “razor roads” now) at what’s currently the critical edge.
To be clear, this is only for existing goals we need to transition – new goals all have razor roads already, with explicitly chosen dfluxes.
So as you say, the one case where just setting a razor road at the current critical edge is technically harsher than the status quo is if you’re in the blue, close to the centerline, and the road is narrow so far but then you eat a horse and leap into the red the next day. I think we can solve this well enough by generously choosing dflux for existing goals.
In all of the following cases, after determining dflux, we set the razor road to shift up by dflux (technically subtract yaw*dflux so it shifts in the good/generous direction). If dflux is set to the lane width (lnw) that means setting the razor road to what’s currently the critical edge.
Cases:
- Frozen goal
- Active goal in the green with recent data
- Active goal in the green w/o recent data
- Active goal in the blue with recent data
- Active goal in the blue w/o recent data
- Active goal in the orange or red with recent data
- Active goal in the orange or red w/o recent data
For case 4 there’s an argument for coming up with a more generous dflux. For case 6, dflux=lnw is what the status quo does but it could be nice of us to add some leniency as part of this transition. For all other cases, dflux=lnw seems uncontroversial.
Question for @bee: How many goals are in cases 4 and 6? Maybe we could eyeball them all or look at enough of them to pick a heuristic for a more generous dflux?
[talking out loud ensues]
DONE item for @bee: Every existing weight-loss/noisy goal needs an explicit dflux. Beebrain computes a nice one based on your data so put that in the database. It’s what we’ll use when explicitly restarting a frozen goal as well.