Scale user access
fix(how-to): add dated Correction callouts to 20 of 28 how-to/ articles, worst ratio of any category — two systemic defects (wrong Doorman A/B/C tier semantics across 5 articles; fictional 4-tier pairing model + /v1/tokens API across 4 articles, real model is 3-role User/Admin/Interface via /v1/invite+/v1/pair), plus fictional CLI commands/routes across 11 more articles for fleet nodes, GIS API, exports, ledger reading, deployment, key rotation, and binary-download auth; several already-self-corrected articles independently re-confirmed accurate
@@ -12,6 +12,8 @@ editor: pointsav-engineering paired_with: scale-user-tiers.es.md --- **Correction (2026-08-02, verified against canonical `origin/main`):** this READ/USER/INPUT tier model and the `/v1/tokens` list/issue/revoke REST API below don't exist — same systemic finding as [[pair-a-new-device]] and [[rotate-keys]]. The real `PairingRole` enum has exactly 3 roles (`User`/`Admin`/`Interface`), and the real API is `POST /v1/invite` + `/v1/pair`, not a token-management REST surface. **Flagged, not resolved.** User access tiers determine what platform operations a session can perform. As a deployment grows, the administrator needs to promote users from read-only access (`READ`) to standard session access (`USER`) or full operator access (`INPUT`). This guide covers identifying current tier assignments, promoting individual users, and bulk-updating a set of users as a team scales. For the authorization model that defines tiers, see [[machine-based-auth]]. For issuing the tokens that encode tier assignments, see [[issue-capability-token]].