Observability
Understand what Space observes, how records become views, and where project data, runtime history, and service state live.
Observability connects the work happening in your workspace to the records you can inspect. Space brings project files, agent activity, usage and incoming work into one interface. This section follows that data from its source to its storage location and then to the view you use.
Start with the big picture
There are three kinds of information to keep apart:
- Your project and its portable records. Deliverables, Git history and
operating documents live in the project folder. Its
.xodirectory holds structured records such as project identity, todos and workitems. These help the project retain its context when it moves. - Space's record of this machine. The
.quirqstate directory holds project activity, derived views, watcher progress, Inbox, connection records and local configuration. Some of this can be rebuilt; some is original state that you would lose by deleting it. - The agent's own records. Each runtime has its own conversation logs or database. Space reads supported sources through adapters. Claude Code's aggregate usage also uses a separate Argus ingestion database.
The projects root, Quirq state root and native runtime homes are separate
settings. A .xo directory inside a project is not the same thing as the
machine's .quirq directory.
Runtime adapters · watcher · project services · Git scanners · connector collectors. Different sources feed different views.
This is a local data flow. Optional usage reporting, connected services, Git sharing and agent requests introduce specific network paths; see collection and reporting.
What Space can tell you
Space observes available records rather than every action on the computer. A file can exist without an agent session, an agent can run without a supported usage provider, and an app can be connected without polling turned on.
| Information | What it helps answer | Where you see it |
|---|---|---|
| Project files, metadata and Git history | What exists, how it is organized, and what was committed | Projects and Timeline |
| Supported native activity and live presence | Which project or session recently produced observable activity | Projects and Setup |
| Shared todos and workitems | What work was recorded and how its status changed | Project details, Dashboard and Inbox |
| Recorded session usage and tools | How much usage was recorded and which tools ran | Sessions |
| Selected incoming app and project events | What needs attention | Inbox and Connectors |
| Source, watcher and installation status | Why a source is missing or a view is stale | Setup and local logs |
The reading guide explains time windows, missing costs, refresh delays and the difference between activity and a verified outcome.
Follow the hierarchy
Read these pages in order, or go straight to the detail you need:
1. Storage hierarchy and catalog
Locate the roots, then explore the .xo, .quirq, native, browser and auxiliary stores. Learn what each record contains and who maintains it.
2. Collection and reporting
Follow a file edit through the watcher, understand other writers and sources, and inspect retention and external reporting boundaries.
3. Reading the data
Use the UI to connect activity, todos, files, usage and history without confusing missing data with zero activity.
What is stored and reported
Local records can include user-written task text, selected prompts, paths, app message excerpts and configuration. “Machine-local” describes where a record lives; it does not mean every file is an anonymous statistic or a disposable cache. The catalog identifies these cases.
A local install without an XO credential sends no XO usage summary. Once an XO credential is accepted, usage reporting sends per-model daily aggregates. The normal metric fields do not contain prompts, responses or file contents; diagnostic notes can include source filenames and error details, potentially including paths. Sharing, connectors and agent runtimes have their own network behavior. Read the reporting boundaries before treating one feature's rules as the rules for the entire application.
Version and actual paths
This section follows xo-space development at 5221119.
Setup → Quirq exposes the data catalog for your running build. Older builds
and some legacy labels place derived telemetry under .xo; current writers use
the machine-local state root. The storage guide
explains defaults, overrides and migration leftovers.