Beeminder Forum

Progress Report on Yellow Brick Half-Plane


Latest status: Bee is deep in refactoring of how the “no mercy” setting works so that we can generalize that so you can choose how much safety buffer you get when you derail which turns out to be an important feature for killing the last of the auto-widening yellow brick roads, which is just about the last in a long list of prerequisites for killing the concept of lanes. Phew! We’re getting there!

Here’s how @bee put it in a daily beemail:

Do you have value for being able to parameterize how much mercy you get when you derail a goal? I think mostly the feedback we’ve heard about the no-mercy option is that people want less mercy and are frustrated that our idea of “no mercy” still gives them 2 days off because they want for everything to always be an eep day no matter what. However, because of technical reasons, you can’t have an eep day immediately after a derail, so… well, what I’m talking about here does not fix that want. (Not that the technical reasons are insurmountable; just not on the table quite yet because, well, it’s technical.)

But does anyone ever wish they could have like 3 days off after a derail, or 2 weeks, or something?

Here’s the deal: currently with new-world-order weight roads (i.e. razor roads), if you have an up day and derail you’ll be recommitted right on the razor’s edge.

I love that because I hated how in the old version if I derailed my weight goal, my road moved to put my offending datapoint right in the middle of the road, with a big wide buffer above me. That meant that one bad day not only cost me money, it was then allowed to compound into many bad days in a row, which made it really easy to backslide. Now if I screw up, the road recommits with me right on the edge – I get a little buffer above where the road previously was (because my derail point is necessarily above the old road), but I still have to stay in the game and keep making progress.

A better implementation would let you adjust how much room you get on a recommit by having a parameterized “mercy” setting.

What I’m imagining is that this would be quite a bit like specifying your auto-ratchet amount. For do-more goals, you’d specify a number of days. For weight loss roads, and do-less roads too, you’d want to specify how much mercy you got on recommit in terms of units of buffer. If you liked the old style behavior with weight roads where you got a bunch of extra buffer from derailing, you could set your amount-of-mercy equal to your maximum daily fluctuation. If you wanted less buffer, you could decrease that amount, anywhere down to ‘0’, which would be like the current (new) behavior.

Anyhow, this is just kind of spitballing, except I’m probably going to do it.


We obviously got super distracted by a million things – many of which are very related to YBHP, like Javascript graphs! We actually planed for YBHP to be a prereq for Javascript graphs but then @saranli, in his amazingness, managed to port all the hideous lanes cruft, fully backward-compatibly, so now we have a single new codebase for all of that from which to proceed.

Oh and we did ship Generalized Mercy – – and forgot to update this thread [sheepish].

The remaining prereq is finishing death-to-autowidening-roads. All new roads have been sans autowidening for a quite a while and we’ve just been putting off some painful migrations for existing roads. (Upside is that the longer we wait the fewer there are to migrate and the less daunting that job is. :slight_smile:) Plus other loose ends we’re not happy with in the new “razor roads” for weight loss.

Anyway, it’s embarrassing to be “so close” on this this long but it remains true and remains important!

1 Like
Why is yellow brick half plane taking so long?

Thank you for this! Very exciting that we’re so close.

Would you please clarify how the width of the new, sans-autowidening roads is determined? Is it just 1 day’s worth?

And would you clarify the relationship between the width of the road, the color of the goal, and the number of days till derailment? Is it just that the lanes correspond to different colors and the colors represent different numbers of days till derailment?

Request: Easy way to schedule a break for multiple goals simultaneously

The idea is to use a zero-width road but shift it to give you enough safety buffer. This stuff really wants a blog post or other documentation but has to be gleaned in tweet-sized pieces for now:

We do like the colors a lot and want those to stay, just no actual lanes. So the yellow brick road has no width but if you’re on the wrong side of it you’re in the red (will derail within 24 hours), if you have 24-48 hours (< 2 days) till you derail then you’re in the orange zone approaching the YBR, a little further away is the blue zone (2 days of buffer), and then the green zone (3 or more days of buffer).

So, yeah, with YBHP the colors encode nothing more nor less than amount of safety buffer.


No, sorry, I wasn’t clear. I meant now, not after YBHP.

You said:

I’m asking about the roads now, which are sans autowidening.

How is the width of roads now determined? Is it just one day’s worth?

And do the lanes now correspond to different colors and different numbers of days till derailment?


I’m confused. Shouldn’t derailment happen as soon as you cross the wrong side? Or if you’re on the wrong side at the next deadline? (I’m now asking about after YBHP.)

What’s the new derailment condition?


You can be in the red during the current day, before your deadline. In fact, on an emergency day, you start out in the red. If you haven’t moved back to safety (any other color) by your deadline (default: midnight), you derail.

I very, very strongly suppose this will not change.


And I think @dreev’s answer is also true now:


@howtodowtle no - unfortunately it’s a lot more complicated than that currently. Right now, you derail if, at any time, you’re in the red and you were in the red yesterday.

I’m asking @dreev what the new derailment condition under YBHP will be.


Isn’t that (the current situation) de facto what I wrote, just in other words?

If you start in the red today and were in the red yesterday, you derail. That’s the same as being in the red and failing to get back on the road by midnight.


It’s a lot more complicated than that. Check out:

1 Like

@dreev sorry - I was confused.

Wait a second - autowidening was only for weight loss?

So that’s just for weight loss goals, right?

I still don’t understand this.


There’s at least three ways the road width can change:

  1. You use the API to set lanewidth on the goal.
  2. You change the slope of your road (via road dial or derail or any other means), which automatically changes lanewidth as if by #1.
  3. The goal is a weight loss goal and you would be in the red today without being in the orange yesterday.

Type #3 is called “autowidening”. Type #2 (which applies to all goals) is automatic but it doesn’t have a name that I’m aware of.

1 Like

As I understand it, #3 is no longer true:

Some experimenting with changing road width shows that the colors now are inconsistent but generally go with the lanes, not the number of days till derailment, sadly.


So basically beeminder will hit maturity when YBHP is here and all these weird bugs go away.

@dreev With YBHP will derailments occur only if you’re on the wrong side at your deadline? So that’s why it’s “within 24 hours”?


Correct, except we’re not done migrating existing roads and have other loose ends before we’re happy with declaring auto-widening fully dead.

Right. Gory details: Mother of Bugs: Two Consecutive Days In The Red

1 Like

@dreev thanks!

Any chance we’ll get color coding based on the “lead days” setting, like I suggested here?

So rather than “red” triggering the day before, it would trigger at a number of days based on the “lead days” setting.