Imagine a rate tracking system where you specified something like “On January 1, I’ll start doing 10 units per day and if my average rate falls below that ever, I’ll call it a ‘derail’”. Beeminder is not that system.
If you have a flat road for a Beeminder goal and then set your road dial to “10 units per day starting January 1” you probably won’t derail if you do 9 units that day instead. This is because the goal’s road has a “width” which is the thing that creates the “lanes” and all the related concepts.
The road width on Beeminder goals is dynamically calculated based on a number of factors such as its current road slope. So when the slope of your road changes, the width changes. But it gets better because the graph UI renders your graph using today’s width at every data point. So if you’re looking ahead or looking behind, you can’t see the width as it was yesterday or the width as it will be in the future.
You derail when you’re in the red relative to the width as it is today, so if you want to make prospective edits to the road or even just guess “Will I derail tomorrow if I do X units?” you need to understand all this stuff and be able to model the width system in your mind or code.
The “yellow brick halfplane” project is the effort to turn Beeminder into the simple system I described in the first paragraph. One where your road dial and the derail behavior match directly.