ADR-0087: A branch condition has two states, because keeping it is a correction that corrected nothing

Status: Accepted — amends ADR-0086, which stands Date: 2026-09-20

Decisions

D-182 A branch supersession states a condition or records its absence, and there is no third state

ADR-0086's D-180 gave a branch's condition the three states a selection's spans have — stated, kept, or a stated absence. Keeping it is not reachable, and the reason is structural rather than a detail of the implementation.

A branch holds three things. Its ordinal is where it sits, and a correction replaces a row where it sits (D-169), so no act may change it. Its steps are rows of their own that move rather than change (D-177). Its condition is therefore the only content a branch supersession can alter — so a replacement that carries the condition forward has changed nothing, and BRANCH_CONDITION_UNCHANGED refuses it every time. The key could never succeed.

The three-state model transferred from the selection command without transferring the thing that earns it there: a selection row carries values a correction may be about besides its spans — a label, a PPE material, a second span — so keeping one span while changing something else is a real act. A branch has no such second value.

So the request carries condition, stated or null, and nothing else about it.

D-183 Two refusals ADR-0086 declared cannot fire, and are removed

KEPT_CONDITION_RESTATED and CONDITION_NOT_ON_SUPERSEDED_BRANCH both describe states of a key that no longer exists. D-181's count of fourteen becomes twelve — nine borrowed from the shared gates, and three this command defines: SUPERSEDED_BRANCH_NOT_FOUND, BRANCH_ALREADY_SUPERSEDED and BRANCH_CONDITION_UNCHANGED.

D-181's rule is untouched: every code the command can throw is declared in its own table, borrowed ones included. What changes is only which codes it can throw.

Context

ADR-0086 was accepted on 2026-09-20 and built the same day. The spec written against it has a case asserting that a kept condition is carried forward as the same span; that case fails, and it fails for the ruling's reason rather than the code's — the service refuses it under BRANCH_CONDITION_UNCHANGED, correctly, because nothing changed.

Both refusals cannot fire either. KEPT_CONDITION_RESTATED needs a keep key to restate against; CONDITION_NOT_ON_SUPERSEDED_BRANCH needs one to fail at.

This is the third thing implementing ADR-0084's line of rulings has found that the rulings' own text did not reach — ADR-0085 was the first, ADR-0086 the second. The pattern in all three is the same and worth naming once: a rule that is correct for a selection was carried to a neighbouring act without re-deriving whether the thing that earns it there is present.

Decision

A branch supersession's condition is stated or null. keepCondition is removed from the request, and with it the two refusals that describe its failure modes. The command declares twelve codes.

Rejected options

• Keeping the key and letting it always refuse — rejected. A request key that cannot succeed is a key a curator surface has to render, a Curator has to understand, and two Thai sentences have to explain, for an act the product refuses by construction. It would also reach the committed refusal fixture and the frontend's wording table, so the dead states would cross a repository boundary and acquire consumers.
• Making a kept condition legal by letting a branch supersession change something else — rejected, and it is the only shape that would rescue the key. The only candidates are the ordinal and the steps, and both are closed: a correction replaces a row where it sits (D-169), and steps move rather than change (D-177). Opening either to rescue a request key would be the tail wagging the ruling.
• Reverting ADR-0086 and re-ruling the command from scratch — rejected. D-179's reframing, the command's existence, its name, its scope and D-181's declaration rule are all unaffected by this; only the condition's state count and two codes move. A supersession would discard four decisions to correct part of one.

This ruling may not be re-decided

If a change contradicts this ADR: stop and raise it. Do not implement over it.

Specifically: do not reintroduce a keep key on a branch supersession, and do not reintroduce either removed code. If a branch ever gains a second value a correction can be about, that is the ruling that makes a keep key meaningful, and it is a new ADR rather than a restoration of this one.

Consequences

What becomes true. Every key in the request can succeed, and every code in the table can fire.

What this costs. Three new Thai wordings on the curator surface rather than five, so thirty-one codes in its table rather than thirty-three.

What is closed off. A keep key on a branch supersession.

Recorded rather than left implied: this is the third amendment in one day to one line of rulings, and the owner delegated this one — "fix the failure things by your own decision" — rather than ruling it personally. It is recorded as an ADR anyway, because the alternative is a code change that silently contradicts an Accepted ruling, which is the thing this register exists to prevent.

Coverage

No upstream finding lands here. This came from a failing test written against ADR-0086 the same day it was accepted — the same way ADR-0085 and ADR-0086 arose, from implementing a ruling and finding a state its text did not reach (D-104).

Upstream	Landed in	Evidence	Note