Docs
The Chiron Model · Concept

Projects

The bounded unit of work that Chiron works within.

A project is the bounded unit of work that Chiron works within. 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, acting as 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.
  • 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:

text
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.

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.

Next: Work Orders.