Project ownership & access
Every Starfire project should have a clear ownership context because ownership affects permissions, billing, policy, and continuity.
Personal projects
A personal project belongs to the account that created it unless the product explicitly supports transfer.
Personal projects are appropriate for individual work that does not need organization governance or shared billing.
Organization projects
An organization-owned project can remain with the team even when the member who created it leaves.
Organization ownership can affect:
- member access
- organization policy
- model/feature eligibility
- credit attribution
- storage limits
- developer applications
- artifact ownership
Resource-level access
Organization membership does not necessarily grant access to every project. Project-level permissions can create narrower collaboration boundaries.
Transfer considerations
Before changing ownership or moving a project between contexts, review:
- connected Knowledge sources
- repository integrations
- FORGE artifacts
- automation and agents
- developer applications
- billing/credit attribution
- members who currently depend on access
Offboarding
Before removing a team member, identify business-critical personal projects that should be moved to organization ownership where supported.
Do not use ownership transfer as a shortcut around resource permissions. After transfer, verify that the intended members still have the right access and that former members no longer do.
