Ask to widen what a fact applies to
Asks a person to widen one repository-scoped fact to everywhere this owner works, and WRITES NOTHING. A fact was allowed in one checkout; “everywhere I work” is a different claim, so it is put to a person again with the fact’s own text, its provenance, its citations and — for a capability that executes — its program and the hash it was allowed under.
It answers 202 with the round that is now standing, exactly as proposeRefinement does, and the widening happens when somebody answers that round through answerRefinementRound. There is no destination to name: the ledger keeps two scopes, so widening has one direction.
Its sibling demoteRefinement is the other direction and does not ask, because a restriction composes where a permission never does.
Autorizações
Enforced on every transport, with no exempt operation. A person's request — over the default local unix socket exactly as over a TCP listener — must carry a JWT issued by the configured identity provider, which the host verifies itself against that issuer's key set: signature, issuer, expiry, and the person and organisation it names. Requests without a valid one receive 401 NRY-0011. The socket's file permissions are transport and are not an authorisation.
Parâmetros de caminho
The refinement's id.
Resposta
The round now standing for a person to answer.
A round of proposed refinements standing on the consent surface, waiting on a person. It is what proposeRefinement answers with, and the id an answer is posted against.
x >= 1The conversation the round was learned from.
The canonical checkout path the round is answered against, absent at the owner's global scope — the ledger's own repository column verbatim. It is what keeps a round a complete question after the session that proposed it has been purged.

