Status
status is the operation that asks Cortex what is happening across all of
its content. It is the equivalent of an inbox view: not a query, but a
snapshot.
Status takes minimal arguments:
| Argument | Description |
|---|---|
scope | Optional scope to bound the status |
since | Optional time bound for “recent” |
include | Optional toggles for sections, e.g. overdue, stale, recent |
It returns a structured view: total record counts, per-scope counts, recent activity, overdue items, stale items.
What status returns
Section titled “What status returns”The default response includes:
- Total counts — total records, open items, closed items.
- Active projects — per-project record counts, with open item counts called out.
- Recent activity — records updated in the last N days.
- Overdue items — open action items past their due date.
- Stale items — open items not updated for N+ days.
Each section is bounded in size so the response stays small enough to be useful in a session-start injection.
Why status is its own operation
Section titled “Why status is its own operation”Status could be implemented as a series of recall calls with carefully tuned scopes. It is a separate operation because:
- It is the answer to a single user question. “What is happening?” The user does not care which scopes were queried; they want one coherent picture.
- It is what session-start injection actually needs. The L0+L1 bundle is conceptually a status snapshot for the active project: what is open, what is recent, what is overdue.
- The shape is fixed. Recall returns lists of records; status returns a structured snapshot with named sections. They are different artefacts.
Status in the index file
Section titled “Status in the index file”The Cortex index.md is essentially a rendered version of status for
the entire store. It is regenerated by the rebuild script after every
normalize pass that produces new records, so it is always reasonably
fresh.
The MCP status operation returns a structured form of the same data.
The two are kept in sync by sharing the underlying queries.
Status is cheap. It is a fixed set of indexed queries against the records and access tables in the SQLite sidecar, with no LLM calls and no body reads. It is fast enough to call on every session start.