Skip to main content
Orbit’s product family should be designed as a set of connected components with clear roles. Product names in this section describe the intended ecosystem; the actual release status of each component should be maintained in a current product register. Abstract modern architecture with clean geometric lines

​
4.1 Orbit AI Workspace

The primary user-facing environment. It is intended to bring conversation, file context, research, writing, coding support, and approved tool use into a unified interface.

​
4.2 Pulsar

The proposed model family and research program associated with Orbit. Work may include model training, inference, evaluation, checkpoint management, and serving infrastructure. Each model release should publish a clear description of its capabilities, limitations, intended use, and evaluation methodology.

​
4.3 Orbit Developer Platform

The planned interface for developers to access supported models and tools through documented APIs. The platform should prioritize predictable request formats, stable authentication, usage transparency, and compatibility where practical.

​
4.4 Orbit Agents

A framework for executing multi-step tasks using approved tools. Agents should operate within explicit scopes, report their progress, and require confirmation for sensitive or irreversible operations.

​
4.5 Orbit Integrations

Connectors that allow users to bring context from approved applications into Orbit. Each integration should define the data it can access, the actions it can take, and the permissions needed.

​
4.6 Orbit Devices and Robotics

A long-term research direction exploring how AI might interact with physical systems. Any physical product would require its own hardware validation, safety case, security review, and staged deployment. A concept render is not a working robot, despite the internet’s tireless efforts to blur that distinction.

​
4.7 Documentation and community

Documentation should be a first-class product. It should explain how to use Orbit, configure integrations, build applications, understand limits, report issues, and follow release changes. A manageable documentation system should let authorized maintainers update pages without editing the application source for every wording change.