A progressive delivery console that can answer "who is seeing this?"

Designing for the reader, not the author

Feature-flag tools are built by people configuring rollouts and used, at the moments that matter, by people diagnosing them. Those are different jobs with opposite requirements, and the category consistently optimises for the first.

Configuration is calm. The person doing it understands the cohorts, has time to read, and benefits from a faithful, complete representation of every rule. That is what these consoles provide, and they provide it well.

Diagnosis is not calm. It happens at 3am, to someone who did not configure the rollout and has no idea why the cohorts are shaped as they are, while a graph goes the wrong way. That person does not want a faithful representation of the rules. They want one sentence: here is who is affected.

Halyard is designed around the second reader, and the first reader is treated as the easier case — they get the rules, one level down, where someone with time will happily click.

Computing the answer changes what the tool is

Leading with a computed audience sounds like a presentation choice. It is actually the architectural decision the whole project turns on.

A console that displays rules is unfalsifiable. It shows you what is stored, and what is stored is by definition correct. There is nothing to check.

A console that computes an audience is making a claim, and a claim can be wrong. That is uncomfortable and it is the point: the computed answer can be compared against what the SDK actually does on the same inputs, and any divergence between the two becomes visible immediately rather than during an outage. The evaluation explainer shows both answers side by side for exactly this reason.

It costs something real. Computing an audience over a large user base is expensive and sometimes only approximate, so the figure carries its freshness and a visible marker when it is an estimate. An approximate number presented with confidence would be worse than the rule list it replaced — trust in a console of this kind is binary, and one confidently wrong answer ends it permanently.

The kill switch argument

The most contested decision here is removing the confirmation dialog, so the reasoning is worth setting out fully.

There are two conventional designs. A guarded kill switch puts a modal in front of the action; an unguarded one does not. The guarded version costs seconds in the one flow where seconds are the entire value of the product, and it prevents nothing, because a dialog in a hot path is clicked through unread by everyone, every time. The unguarded version gets hit by accident.

Both designs assume the failure is pressing the button unintentionally. That is not the common failure. The common failure is pressing it intentionally without knowing what it covers — killing a flag that turns out to be attached to three other services, at 3am, while trying to help.

So the design addresses that instead. The blast radius is stated beside the control, before the press: which services, which environments, how many users. The action is reversible with one click for five minutes. Every kill writes an audit entry naming the person, which matters more for the follow-up than for the prevention.

This is a risk transfer, not a risk elimination, and it should be said plainly. Accidental kills will happen and will briefly affect production. A team whose rollback path is slow, or whose flags routinely have wide blast radii, should keep the dialog — the trade only works if reversal is genuinely instant.

Flag debt is a design problem

The hygiene work is the least glamorous part of this and possibly the most valuable.

Every flag is created as temporary. A large share become permanent, and each survivor is a live conditional in production that nobody remembers the reason for. The usual remedy is a platform engineer with a spreadsheet and persistence, which works exactly as well as one person's persistence.

Mandatory expiry makes the debt a state the tool displays rather than something someone tracks. But the expiry date alone would only produce a queue of notifications, and notifications about other people's cleanup are the easiest thing in the world to ignore. What makes it work is generating the removal pull request once a flag's evaluation has been constant long enough to be safe — because the obstacle was never willingness. It was that removing a flag means finding every call site, and nobody wants to do that on a Thursday.

The part that does not work is expiry churn. Rollouts legitimately run long, extensions become reflexive, and by the third snooze the date means nothing. Requiring a reason and showing extensions in the hygiene view slows the reflex a little. It does not fix it, and this design does not have a good answer.