Rendered from docs/obligations/0125-nine-documents-state-a-warrant-outside-the-closed-set-and-only-a-person-can-set-the-value.md in the Headwater corpus. Every document on this half of the site is typed by the taxonomy the descriptor names: corpus.json.

Nine documents state a warrant outside the closed set, and only a person can set the value

Context

Spec 3 states that the warrant "is required, its value set is closed, and an absent value is a finding rather than a default". The closed set holds accepted, regenerated, transcribed and asserted. Each value requires a different part of the provenance block, and spec 3 says the engine checks the pairing.

The warrant reading of taxonomy audit walks that closed set in full, and its first run over this repository found a fifth value. Nine documents state warrant: proposed. Eight are obligation records numbered 0115 through 0122, and the ninth is HW-DR-0022. Every one of them was drafted by an agent, and every one also names an acceptor.

proposed appears in no package, in no overlay, in no skill and in no part of this specification. An agent coined it, and nine documents carry it.

One check reads a warrant, and it reads a movement rather than a value. warrant.promoted reads the value before a change and the value after it, and it counts the movement from asserted to accepted. It admits any value at either end, because a transition it does not recognize is not a promotion and is not its news either. So the pairing that spec 3 says the engine checks is still checked nowhere. An absent value is a finding nowhere. A value outside the closed set reached no report at all until the warrant reading landed. That reading is advisory and it gates nothing, so such a value is now visible and still unblocked.

A reader is served an unknown warrant as a vouched one, and that is the part with teeth. headwater_query sets the flag that makes a pointer state its warrant out loud by testing the value against asserted alone. Every other value, known or not, leaves the flag clear. Spec 5 makes a pointer to an asserted document state that warrant beside it. docs/decisions/README.md is the proof of what that costs here. It lists HW-DR-0022 in the same form it lists an accepted decision, with no caveat, because proposed is not asserted. So an agent that reads that index sees a document nobody accepted, presented as one that somebody did.

The predicate fails open, which is the direction this project rules against everywhere else. A one-line change would set the flag for any value outside the closed set. It is not made here. The message beside the flag reads "asserted, and no human has accepted it", and that sentence is false about a proposed document. The flag and its message are one decision, and the ruling below decides which way it goes.

Obligation

Two things are owed, and they are separable.

The engine owes a check of the warrant. Spec 3 already states the rule, the value space and the pairing table. So the declaration a check would read exists, and nothing reads it. Whether that value space belongs in a taxonomy or stays with the engine is the prior question, because spec 3 says no taxonomy declares it.

The corpus owes a warrant for the nine documents. Each states an acceptor, so accepted is the value the block already fits. An agent may not choose it. HW-OBL-0108 records that an agent writing the acceptance stamp is the act under review. An agent that resolved these nine by picking accepted would perform that act nine more times.

The query surface owes a reading of a value it does not know. Three answers are open. It treats an unknown value as asserted and says so in a message that fits. It treats one as a defect of the document and refuses to serve a pointer at all. Or it keeps the current behavior, and a check that reads the warrant is what stops an unknown value ever reaching a corpus. The third answer is the one that pairs with the first obligation above.

Discharge

headwater taxonomy audit reports the count on every run, under the warrant reading, apart from the four rows of the closed set. That is the instrument, and it is the whole of what runs today. Nothing reports the third finding, because a pointer that says nothing is what a reader sees.

The first half closes when a check reads the value against the closed set and a fixture fails without it. The second half closes when a human sets the value on the nine documents. A ruling that proposed belongs in the closed set closes it too, and that ruling states what the value requires. The third half closes with a ruling on what a pointer says about a warrant it does not know.

The first half and the third half closed on 2026-09-30, in #1438. The Context above records the state before that change.

• warrant.value.not_permitted is an error on a hand-authored document whose warrant is outside the closed set. engine/crates/check/tests/warrant_value.rs is the fixture that fails without it.
• warrant.acceptance.unpaired reads the pairing that spec 3 states for accepted_by. It found no instance in this corpus on the day it landed (#1437).
• warrant.evidence.unsupported reads a target warrant outside the set as no support, so two more claims that rest on a proposed document are reported.
• A pointer reads no acceptance from a value outside the set. It names the value as written and does not call it asserted. The flag in the MCP contract is unchanged.

The second half stays open, and so does this record. The nine documents keep warrant: proposed. Task AD-2 in the adoption block of .headwater/taxonomy.lock holds their nine findings, so a strict run passes. A human sets each value, or rules that proposed joins the closed set. Either act closes the task and this record.

An absent warrant is still a finding nowhere. Spec 3 calls it a finding, and 134 documents under docs/ declare no warrant. The new rule skips such a document and says why, because a missing value and a wrong value are two defects with two remedies.