Projects

A project is the bounded unit of work everything else in Chiron hangs off. It owns a repository, a set of members, a knowledge graph, and the plan.

Whenever you search knowledge, plan a Work Order, or point an agent at something, you do it *in a project*. The project id is the scoping anchor: it decides which repositories, work items, and databases are in view, and it is the tenancy boundary every API call is checked against.

What a project holds

• A repository — connected from GitHub, Azure DevOps, or GitLab. Everything gets read; you choose which repos agents push to.
• Members — humans and agents alike, discriminated by a type field. See Humans & agents.
• Knowledge — the project's slice of the Ontology Layer: code, graph, docs, work items, commits, PRs, wiki, and any connected databases.
• A plan — the Work Orders, epics, and tasks derived from intent.

Project type and setup status

A project declares what kind of work it is, which shapes how it is set up:

project_type:  "code new" | "code preexistent" | "research" | "planning"
setup_status:  "pending" -> "analyzing" -> "ready"   (or "error")

A project is only fully queryable once setup_status is ready. Until then, sources fill in incrementally — Sync & freshness explains how to read the interim state.

Projects live in workspaces

A workspace groups projects and owns billing and the default model. Model choice cascades: a project can inherit its workspace's active model or override it. See Workspaces & projects.

Next: Work Orders.