Tenant Sovereignty Checklist
The tenant owns their domain, DNS, data project and content. You hold scoped, revocable access. Set this up at the start — retrofitting sovereignty is painful and usually gets skipped.
Syntax
implementor-onboarding
1. The TENANT creates the accounts — registrar, hosting, data project.
Their account, their payment details.
2. They invite you, with the narrowest role that permits the work.
3. You document what you hold, and give them that list.
4. They keep the recovery paths: registrar login, owner email, billing.
5. Test revocation: can they remove your access today, without you?Parameters
| Parameter | Type | Description |
|---|---|---|
| domain | tenant-owned | Registered to them, on their account, paid by them. |
| DNS zone | tenant-owned | You may be granted management access; you do not own the zone. |
| data project | tenant-owned | Their customers and records, on their account. Their liability, not delegable to a contractor account. |
| content | tenant-owned | Including anything you wrote for them. |
| implementor access | scoped, revocable | The narrowest role that permits the work, documented, and removable without your cooperation. |
Example
implementor-onboarding
Why it protects YOU, not only them:
- They can leave. If you own the domain, leaving costs them their web
presence. Even if you would never use that, they know you could —
and that knowledge poisons the relationship quietly.
- You can be unavailable. If their renewal is on your card and your
card expires, their business goes dark and nobody can fix it.
- Their data is their liability, and in some contexts legally cannot
sit in a contractor's personal account.
BETWEEN TENANTS: code may be shared. Data never is — not for
convenience, not for analytics, not for a quick comparison.