Project OS
Project OS is Starfire’s model for treating a project as an operating context rather than a folder full of unrelated chats. The goal is to give long-running AI work continuity without requiring a user to manually reconstruct the entire project state in every prompt.Project as a context boundary
Project OS can tie together several kinds of project state:Persistent context does not mean “send everything”
A project may contain far more material than one model request should receive. Starfire can use retrieval, metadata, project state, and task-specific selection to decide which context is useful. This avoids two bad extremes:- forgetting the project entirely between chats
- stuffing the entire project into every model request
Project instructions
Project-level instructions are best for durable requirements that should apply across related work. Examples:- required technology stack
- naming conventions
- writing style
- architectural constraints
- organization-specific rules
Ownership and billing context
Project OS is organization-aware. A project can carry ownership information that determines which member permissions, billing account, credit pool, and organization policy apply to work performed inside it.Builds and artifacts
FORGE builds can use a project as their context and return artifacts back into the same workspace. That lets generated software, validation results, and downloadable outputs remain connected to the work that produced them.Research and knowledge
Research findings and Knowledge sources can also feed a project, allowing a project to accumulate durable reference material without turning every conversation into a permanent source.Status
Project OS is part of the NEXUS-era expansion of Starfire’s workspace architecture. Individual surfaces and integrations can be Alpha / staged while the underlying project model continues to expand.Knowledge & RAG
See how retrieval selects relevant project knowledge.
FORGE
See how software builds operate inside persistent project context.
