How Echo sees a project
How Echo turns scattered sources into one typed ontology a human or agent can query.
A project is the scoping boundary for everything Echo knows. Every query, every search, every ref resolution happens *in a project*. The project id is the tenancy anchor: it decides which repositories, work items, and databases are in view, and it is the boundary every API call is checked against.
What a project contains
When you connect sources to a project, Echo ingests them independently and models them into one ontology:
- Repositories — connected from GitHub, Azure DevOps, or GitLab. Echo reads everything; the consumer decides what agents can act on.
- Work items — tickets, issues, and tasks from the project tracker.
- Databases — schema and catalog, profiled and classified, with governed live query access.
- Company docs — wikis, specs, and policies linked to the entities they reference.
Each source syncs on its own schedule, records its own outcome, and can be paused, resumed, or restarted independently. One expired credential never blocks the rest.
Ingestion is deterministic first
Structure is extracted by language-native parsers — the module graph, the symbol table, the call paths — and the result is reproducible. Models run second, over that verified structure, and their output is always labeled as interpretation. This is why the ontology can be audited: the foundation is computed, not guessed.
Cost scales with change, not with size
Every expensive step is gated on whether the underlying thing actually changed. Re-running the pipeline over an unchanged repository or an unchanged table costs effectively nothing. Spend tracks the rate of change, not the size of the estate.
Next: Getting connected.