​

Organizations

Organizations are the shared ownership and policy boundary for teams using Starfire AI. They are designed to connect people, permissions, projects, knowledge, billing, developer resources, and usage without forcing everything to belong to one employee’s personal account.

​

Organization model

An organization can contain or own concepts such as:

• members and invitations
• roles and permissions
• seats
• organization billing
• shared credits and usage
• projects
• Knowledge sources
• developer applications and service accounts
• policies and feature controls

​

Why ownership matters

A resource owned by an organization should survive ordinary membership changes. If a developer leaves the team, the organization’s project, API integration, or knowledge base should not disappear because it was tied only to that person’s personal account.

​

Personal vs organization context

Starfire keeps personal and organization context distinct. Before creating or changing an important resource, confirm the active context because it can affect:

• ownership
• permissions
• billing source
• usage accounting
• available models/features
• project visibility
• developer credentials

​

Organizations 3.0

The NEXUS-era Organizations 3.0 work expands organizations beyond a simple member list. The target is a true administrative boundary with deeper membership, billing, project, Knowledge, usage, and policy integration.

​

Organization administrators vs platform administrators

An organization administrator manages resources inside an organization. A Control Center platform administrator can have broader platform-wide authority. Those scopes should remain separate. Running a team does not require permission to operate the entire Starfire service.