Skip to main content
Zas identity architecture is built on eight entities grouped into four areas. The design keeps personal and corporate data separate, ensures clean offboarding, and prevents account fragmentation.

The four groups

Key invariants

  • One account, many memberships. You never need more than one Zas account. The word “Workspace” is not used.
  • Identity has an owner: personal or lent. A corporate email is lent by the organization. On membership removal, the identity is unbound, leaving only a hash tombstone.
  • Recovery links are never sent to a corporate address after unbind. Once an identity is detached from an org, it cannot be used for recovery.
  • Domain is the sole source of org power. Proof is a DNS TXT record, re-checked on a schedule. If proof lapses, powers lapse.
  • The last Owner of an org cannot be removed or downgraded, even by SCIM.
  • SCIM deprovisioning means everything that person had in transit leaves today.
  • Departure after losing a corporate-only identity uses a grace window and a live device claim flow, not a new account. Your Zas is still yours.

Solid and dashed borders

Every relationship in Zas has a defined end state and TTL, just like files.
  • Solid borders (permanent): Account ownership, Space ownership
  • Dashed borders (lent or expiring): Identity, Membership, Domain proof