ADR-0050 Acknowledgement descends a demand, and is a rule rather than a component

#Context

ADR-0010 caps concurrent Demanded elements in a View at 1. That cap is the system's central claim and every check in the budget engine is built around it.

It is only humane if something clears it, and nothing does.

The engine counts demands like this:

const viewDemands = dom.nodes.filter((n) => n.rendered && n.level === DEMAND_LEVEL && !n.inExemptSlot);

A level-4 element counts. Nothing else is consulted. So an alarm an operator has already seen, understood and started dealing with occupies the View's only slot for as long as it is rendered — and the next thing to go wrong cannot demand, because the first thing is still holding the ration. A supervision system whose second alarm is structurally unable to reach the operator has the failure mode ADR-0048 was written about, arriving from the opposite direction: there the screen could not say a source had died, here it cannot say a second thing is on fire.

And the repository already contradicts itself about this. Two stylesheets say:

a demand that has been acknowledged stops moving without changing level, because it is still the region maximum and still says so in light

while ADR-0021's roster note says acknowledging *"drops the demand and does not touch the condition."* Both were written by someone reasoning correctly about a different half of the problem, and the engine's behaviour is what makes the first one mean *the screen is stuck*.

demandLive — the flag both stylesheets are about — is invisible to the engine. It appears in no file under packages/budget/src. It stops a CSS animation and does nothing else.

#Decision

Acknowledgement descends a demand one rung, from Demanded to Directed, and does not touch the condition.

Three parts, and the second is the one that keeps this honest.

#The level descends, so the ration is freed

A demand an operator has acknowledged is no longer competing for the View's only slot. It descends to Directed — still clearly the local focus, still saying so in light, still the largest thing in its Scope. What it stops doing is claiming the one rung the system rations, so the next thing to go wrong can have it.

This is what makes a cap of 1 workable over a shift rather than only in a screenshot.

#The condition does not change, and this is the half that must not be relaxed

Acknowledging is a claim about the operator, not about the machine. The seal press is still over temperature; a human has said *I have seen this*. So the mark stays, the copy stays, and the component keeps reporting exactly what it reported before.

A system where acknowledgement cleared the condition would let an operator clear a fire by pressing a button — the gaming ADR-0010's cap exists to refuse, arriving through the interaction layer instead of through the markup. The descent is one rung and not off the ladder.

#demandLive: false is the rendering, not the mechanism

The existing flag is correct about what it does: at the moment of acknowledgement the sustained motion stops, because sustained motion is §2's grant for a *live* demand and the demand is no longer live in that sense. What the two stylesheet comments got wrong is the clause after it — the level does change, and it has to, or the ration is never returned.

Both comments are amended by this record.

#The finding: acknowledgement is a rule, not a component

ADR-0021's section F lists acknowledge as a component to build, layer Arbiter, levels 1 to 3. Building it is the wrong move and this record removes it from the roster.

Read what the roster entry actually says. Its content is a *rule* — "the control that clears an alarm may be the local focus and may never itself be the alarm", "acknowledging drops the demand and does not touch the condition". That is this record. What would be left after the rule is extracted is a control with a label, and the system already has one:

Identical in every dimension the component tier has. Building it would add a twenty-sixth component that differs from the twelfth in its name, which is the scenery §11 warns about — *depth on twelve components beats shallowness on sixty* — and it would put a rule about a state transition inside a widget, where no check could reach it.

The control that performs an acknowledgement is a Button. What was missing was never the button. It was the rule about what happens to the demand when it is pressed, and a record is where that lives.

The roster moves 53 → 52.

#Rejected options

Stop the motion and leave the level. The current stylesheet prose, and it leaves the screen stuck: the cap stays spent until the condition itself resolves, so an operator who has acknowledged a two-hour condition cannot be told about anything else for two hours. It also makes acknowledgement a comfort signal — something that changes how the screen looks and nothing about what it can do next.

Count only live demands in the engine. Tempting, because it makes both existing statements true at once, and wrong for the reason ADR-0040 gave about hidden demands: it lets a screen become compliant by an act. A scene with two alarms would pass by acknowledging one, which is the same shape as passing by collapsing a panel over one. The cap must be a property of what is declared, not of what has been dismissed.

Descend to Marked, or off the ladder. Too far. The condition is still true and still the most important thing in its Scope; a reader scanning the screen must still land on it first. Directed is defined as "clearly the local focus", which is exactly what an acknowledged alarm still is.

#Consequences

The two stylesheet comments in status-indicator.css and alert.css are amended: the level does change, and the sentence saying otherwise was the reason this went unnoticed.

ADR-0021's section F loses a row and gains a sentence. 52 components, 25 built.

A check is owed and is not written here. The illegal state this record creates is *level 4 with acknowledgement*, and it is a static property of a scene exactly as an over-cap scene is — so the engine could refuse it. It cannot yet: demandLive is a CSS class and the engine reads declarations, so the state is invisible to it. Making it checkable means serializing acknowledgement as a data-wr-* attribute, which is the shape ADR-0048 used for data-wr-vouched and rippled through eight components, every fixture and core's own two-sided attribute check. That is its own unit and is named here rather than half-done.

Until then this record is enforced by the type system and by reading, which is one witness. The ADR-0048 precedent says plainly what that is worth: *a rule enforced in one layer and untested in the other is a rule with one witness.*

#Measured

Nothing moves in this pass. No component, no token, no baseline, no fixture: the two amendments are comments, and the roster change is a row.

The figure the record turns on is the one already in the engine, quoted above — n.level === DEMAND_LEVEL and nothing else — and the count of files under packages/budget/src that mention demandLive, which is zero.