ADR-0042 A toast reports an event; a demand is a live condition, and arrival is not escalation

#Context

Twenty components are built. Every one of them is placed by the product into a composition, and every check in this system reads that composition as a static render: measure.js rasterises one frame, engine.js counts the declarations in it, and the two cap checks compare those counts to numbers ADR-0010 ratified. Nothing anywhere runs twice.

A toast is the first component in the set whose ordinary life is described in the language that machinery does not have. It arrives because something happened elsewhere; it arrives after the reader has already looked at the screen and decided it was calm; it leaves without being dismissed. Every sentence in that description is about time, and the budget has no clock.

ADR-0010 is the record this pressure lands on. It ratified VIEW_DEMAND_CAP at 1, decided that live interfaces grant demands in arrival order — "a Scope requesting Demanded while the View is at cap is held at Directed and promoted when a slot frees" — and decided that a static scene declaring more concurrent Demanded elements than the cap is a build failure naming every offending Scope. It deferred one thing, in its own words: the arrival-order arbitration "is stated here and implemented nowhere, because there is no runtime yet. It is a Phase 4 obligation on the first component that can escalate, and stating it now is what stops that component inventing its own rule."

ADR-0037 is the record that came closest to discharging it and did not. It decided that the scrim dims light without lowering a declaration, that occlusion reorders the queue arrival order otherwise governs, that a covered demand is suspended to Directed for the overlay's lifetime rather than exempted, that a static scene showing both at Demanded is a build failure, and that an occluding Scope's own level has a floor at Directed. It deferred the suspension mechanism and named its addressee precisely: "The transition from Demanded to Directed and back is a Phase 4 obligation on the first component that can escalate at runtime, which is not this one: a modal hosts a demand, it does not become one."

So the deferral has been passed twice and has a stated criterion. This record tests the criterion against the component it was written for, and the test does not come out the way the phrasing suggests.

#Decision

A toast is an Emitter, and its legal levels are Marked and Directed. It may not carry Demanded. The reason is not transience and is not the timer: it is that Demanded is a claim about a live condition, and a toast reports an event.

§2 rations level 4 to "the only level permitted sustained motion, and only while the demand is live." Liveness is the ration's own term, and it is a property of a condition — the seal is still losing pressure, the transfer is still failing. An event has no liveness to have. "Seal pressure lost" is over the instant it is true; what is live is the seal, and the seal is a thing on the screen with its own component and its own allocation. A toast declaring Demanded would be claiming the region maximum for a report *about* something that needs the reader, while the thing that needs them sits somewhere else declaring whatever it declares. That is a demand pointing at a demand.

A toast therefore names where the condition lives, and that part is required. origin is not a courtesy. It exists because of the ceiling: a component that cannot be the demand has to say where the demand is, or it has reported an emergency and given the reader nowhere to go. §6's Error pattern makes the same move with "what to do", and this is that obligation arriving through a ceiling rather than through a pattern.

Arrival is not escalation, and this component is therefore not ADR-0037's addressee. The deferral is not discharged here, and the reason is a correction to how it was filed rather than an inability to do the work.

A toast's premise — "a demand that arrives after the View was resolved" — is a statement about a product's runtime, not about this system's unit of analysis. There is no resolved-and-closed View here. The budget is computed over a rendered frame (ADR-0026's answer for the unsummoned tooltip, ADR-0040's for the collapsed panel), and a frame containing a toast is a frame: salience — view counts it, emission load charges its Scope for it, and the scene either passes or fails on the same terms as every other scene. Nothing about the toast is invisible to the analysis. What the toast changes is *presence*, and presence is already the thing the engine measures.

What ADR-0037 deferred is different in kind: an element that stays in the frame while its declared level changes underneath it. Demanded to Directed and back is a re-declaration, and nothing in this component performs one. A toast enters carrying a level and leaves carrying the same level; it never re-declares itself and it never re-declares anything else.

So the deferral is restated with a corrected addressee. It is not an obligation on the first *component* that can escalate — a component cannot escalate, because a component declares and a declaration is a constant of the frame it appears in. It is an obligation on the first runtime that re-declares an element already on screen. Two are already specified and unimplemented: ADR-0010's arbiter, which holds a request at Directed and promotes it when a slot frees, and ADR-0037's suspension, which lowers a covered demand for an overlay's lifetime and restores it. Both are the same machinery, and neither is reachable by adding components. Naming it as a component's obligation is what let it be passed twice; naming the runtime is what makes it findable when one is built.

The static half needs no new check, and that is the claim, not a shortfall. A scene with a toast at Demanded and a resident demand would be two declarations against a cap of one and would fail salience — view today, unchanged. Because the ceiling forbids the first half of that scene outright, the enforcement is a type: ToastLevel excludes Demanded, so level={4} on a toast fails to compile at every call site, static fixtures included. That is where a rule about a declaration a component may *make* belongs. The engine reads frames and answers what is on the screen; it has no opinion about what a component was permitted to declare, and giving it one would mean a check that reads component identity — which the pairing matrix and the enforcement table have both refused since ADR-0021.

The floor is Marked, not Ambient, and ADR-0026's floor argument does not transfer. That record kept the tooltip at Ambient against a real objection — an occluding element at "minimal deviation from the substrate" is one nobody can tell from what it covers — by answering that findability comes from the ground, surface-raised being "a step in position rather than a fourth thing drawn." The answer holds for a tooltip because the reader is already pointing at the anchor: the ground makes it legible once found, and it is found by construction. A toast has no anchor and no pointing reader. It appears somewhere the reader is not looking, unbidden, and a step in position does not make an unannounced thing noticed. §2's Marked — "distinguishable, not attention-seeking" — is exactly the description of an unbidden report, so the floor is one rung up and the difference is in the summoning rather than in the occlusion.

Transience is still a presence property, and it is still not a layer. ADR-0026's central sentence transfers unchanged and is not re-argued: a toast hosts nothing and ranks nothing, so it is an Emitter, and its duration is not an answer to §3's question. It follows that this system's toast renders where it is written, inside whichever Scope hosts it, and is never portalled to a global toast region, which is the same consequence that record drew for the tooltip and for the same reason — a portalled toast would emit into a region whose budget it does not belong to while the region it visually occupies paid nothing for it.

That is also the second argument for origin being required, and it is the one the ceiling does not supply. The Scope that hosts a toast is the one the reader is working in; the condition is generally somewhere else. Without a portal there is nothing to carry the reader across that distance but the string naming where the condition lives.

What does *not* transfer is that record's use of transience to dismiss the question of what summons a component. "This component differs in what summons it, which is not a question §3 asks" is true of §3 and false of §2. §3 asks about authority; §2 rations level 4 on liveness, and whether a thing's presence is held by a reader's attention or by a clock is precisely a question about liveness. Borrowing the tooltip's sentence to settle this component's ceiling would be answering §2 with an argument built for §3.

#Rejected options

Let a toast carry Demanded, governed by ADR-0010's arrival order unamended. The strongest alternative, and it has the better fit with the existing rules on first reading: the toast arrives second by construction, arrival order holds it at Directed and promotes it when the resident demand clears, and the static check already fails a frame showing both. It also survives ADR-0037's inversion objection, which the modal did not — a toast occludes nothing and withdraws nothing from interaction, so the demand that was already there is still reachable and still correctly outranks the newcomer. Lost on liveness. The rule it would rely on has a promotion step, and promotion is the re-declaration this system has no runtime to perform, so the permission would be real in every frame and the restraint on it would be real in none. A ceiling enforced by machinery nobody has built is a ceiling in prose, and the component would ship with the loudest thing it can say governed by a sentence.

Let a toast carry Demanded and forbid it a timer, the way demandLive gates the alert's sustained motion. Merit: it answers the liveness objection on the objection's own terms — if the toast is dismissed by the condition ending rather than by a clock, its presence tracks liveness exactly, and Alert already proves the shape. It is also the option that keeps the component honest about urgency rather than legislating from the common case. Lost because it deletes the component. A toast whose lifetime is the condition's lifetime and which sits at the region maximum is an alert in a corner, and this system already has the alert. The distinction that survives is the one this record builds on: an alert *is* the condition, a toast *reports* it, and a report that outlives its own reading has stopped being a report.

Forbid a toast entirely — a report of an event is a row in a log. Merit: it is the cleanest answer to the whole problem and has ADR-0021's own precedent behind it, which drops ai-label because the system has no position on what it encodes. Lost because the system does have a position here. §6 names Confirmation as a message pattern — "what happened, in the verb they used" — and a pattern with no component that speaks it is a schema with nothing to validate. A log is a different claim: it is a place the reader goes, and the whole point of this component is a report reaching a reader who did not go anywhere.

Cap it at Marked, on the tooltip's ceiling reasoning. Merit: symmetry with ADR-0026, and a genuinely good argument that an unbidden report should never be the local focus, since the reader was doing something else and the toast interrupted it. Lost on §2's own description of Directed: "May move once to arrive. No sustained animation." That is a toast, written down before this component existed. A report that names the next action — open the Scope where the condition lives — is naming the next action, which is what Directed is for, and holding it at Marked would put the urgent case and the routine confirmation on one rung with nothing left to tell them apart but hue.

Give the toast its own ceiling per variant — Directed for failed, Marked for confirmed. Merit: it encodes the obvious intuition that a failure report is louder than a success one, and the variants already exist. Lost because it makes the variant axis do the level's job, which is exactly what ADR-0027 refused for the button's emphasis: the level is the level, and a variant that constrains it means two channels are saying one thing and a caller can no longer state intensity without also restating kind. A confirmed toast at Directed is a legitimate screen — a long-running export finishing while the reader waited for it — and a rule keyed on the variant would forbid it for a reason about a different instance.

Add a runtime here, and discharge ADR-0010 and ADR-0037 together. Merit: the obligation is two records old, it has been passed twice, and passing it a third time is the outcome nobody wants. Lost on the phase gate and on the shape of the work. §14's gates are hard, and a client-side arbiter that re-declares levels is not a component: it is a coordination layer over every Scope in a View, it needs a View-scoped owner none of these components has, and its correctness is a property of transitions that no static fixture and no rendered frame can witness. Building it inside a component unit would produce exactly the invented rule ADR-0010 wrote its deferral to prevent. What this record does instead is name the addressee correctly so the next attempt starts from a runtime rather than from a component.

#Consequences

The roster grows by one, and the row is a split rather than an addition. ADR-0021 maps Carbon's notification slug wholly to alert, and Carbon documents the inline and toast forms on that one page. This record splits it the way that record split menu-buttons into button and menu: two components with different layers of the same behaviour do not become one row because one vendor's documentation groups them. Section A gains toast, Emitter, levels 2 to 3, and the roster reads 47.

One question this record does not answer. ADR-0005's level-3 plurality is untouched and is now load-bearing in a place it was not before: a screen can carry several toasts at Directed at once, and what "clearly dominant" means among them is the same open question it was for every other level-3 element. The engine's salience — share (undecided) note reports the case rather than failing it, which is the existing behaviour and is correct until that record closes.

Two scenes, and the pair is split across two instruments. 42-toast-calm is the calm view with a toast in it. 43-toast-over-demand is the scene the arrival decision makes necessary — a toast at Directed in a View that already carries a live Demanded element — and it passes, with the View's count at one of one, because arrival is not escalation and nothing needed arbitrating. Its must-fail sibling is the same scene with the toast at Demanded, and it is not a fixture: it is packages/react/test/toast-violations.tsx, where level={4} fails to compile. That is a deliberate asymmetry with ADR-0040's 40/41 pair, whose two halves are both scenes because that decision created an engine check. This one creates a permission, and a permission is refused in the type.

What a static fixture proves here and what it does not. It proves that a toast is in the frame, that it is charged to the Scope it renders in, that its declaration is counted by the View check like any other, and that a screen carrying both a toast and a live demand is a legal screen. It cannot prove anything about arrival, dismissal or duration, because those are transitions and a fixture is one frame. That is not a gap this record works around: it is the reason the ceiling is a type and not a check. Every rule here that a frame could witness is witnessed by an existing check, and every rule a frame could not witness is enforced before a frame exists.

Enforcement table. Touches nothing. No new check kind, no new rule text, no change to engine.js or report.js. The pairing matrix is keyed on layers and levels and gains no cell, exactly as ADR-0026 predicted for a component that adds neither.