Approve Identity Case

The decision, as the approver writes it down.

Every collection is BOUNDED, and the reason is the commit rather than the request. The ceremony is one transaction that locks each participant at stage 70 and then every named row in turn, and it holds all of them until it returns — so the length of these lists is the length of time a recovery blocks every other writer that needs one of those users. Unbounded, a generated document naming a whole tenant's rows is a lock storm nobody typed on purpose. The bounds are orders of magnitude above a real recovery, which reconciles two humans and names a handful of rows; hitting one is a 422 an operator can read, not a database that has gone quiet.

One case in the operator queue: the identifiers, plus what a human needs to recognise them.

The identifiers are the record and the label beside them is orientation. The candidate's name is optional and mutable — an account is deleted and its name goes with it — so it is served next to the stable id it describes rather than in place of it, and a missing label says so instead of rendering blank.

This row carries the captured address, and that reverses an earlier decision. It used to serve only a boolean saying whether that address matched the candidate's, on the reasoning that this queue spans every workspace and an address is the one field identifying somebody outside our own identifier space. That reasoning is sound and it was overruled on 2026-08-24: without the address an operator cannot answer the question the screen exists to ask, so the queue served six opaque ids and no way to act on them. The disclosure carries its own cost instead — the list route sets no_store and commits a platform read-audit row before any address is returned.