Cortex

Cortex (sidebar ▸ Data) is your window into the knowledge graph: the place you browse it, build it out, ask it questions, and keep it healthy. This page is the hands-on guide to the view. For the model behind it — one graph, workspaces as lenses, the three depths — read The knowledge graph first; the deeper technical reference is Knowledge graph infrastructure.

The view is tabbed:

The header works across all tabs: a workspace pill showing the current selection, Export, Refresh, the root-config gear, a shared New workspace action, and live status lamps for the graph services.

Read the Overview

Start here when you want the state of the system at a glance. The Overview tab shows a status strip, an embedded "shape of knowledge" graph, a live activity feed, health lamps for the knowledge services, the distribution of entity types, and an enrichment gradient — how much of your corpus is structure-only, entity-enriched, or vectorized. It updates live as files land and agents work; nothing on it is a static count.

The Overview also carries the root knowledge graph card, which is where the root mirror is steered from — see Steer the root mirror.

Browse the graph

The Workspaces tab is a three-column workbench:

• Left — the workspace tree and, below it, the folder tree of the selected workspace. The tree lists every workspace, including the graphs attached to context artifacts; a toolbar toggle hides those artifact graphs when you want a shorter list.
• Center — the graph canvas. Pan, zoom, and click nodes; folders, documents, and entities are color-coded, and node size tracks document size. Changes animate in live — save a file under documents/ and watch its node appear moments later, no re-index step.
• Right — the details panel for whatever you select: node metadata, a raw Markdown editor for document nodes (edit the file without leaving the graph), a typed "Related" rail of connected nodes, and the action buttons — Enrich, Ingest, Create Workspace, and Delete.

Beside the Entities toggle, the canvas toolbar carries a Refs toggle: it reveals the cross-document reference links, an overlay drawn on the structure graph where those edges exist.

The default selection is the root workspace (_root) — the automatic mirror of your documents/ tree.

What Delete removes, and where

Delete does one of two things, and which one depends on the workspace you are standing in:

• On the root mirror, deleting a file-backed node moves the underlying file to the OS trash. This is deliberate: the mirror follows the filesystem, so removing only the node would be undone by the next sync pass seconds later. The graph catches up on that same pass.
• In a curated workspace, deleting a document node removes it from that workspace and prunes its edges. The file on disk is untouched, and so is its node in any other workspace that includes it.

The confirmation dialog tells you which of the two you are about to do before you click.

The three depths in practice

You never set a depth label by hand — a workspace's badge is derived from what it actually contains: structure (folders and documents), entities (extracted concepts and relationships), or full (vector embeddings on top). In the view this plays out as:

• The root workspace renders structure-first. Flip its Entities toggle to reveal any entity layer it carries.
• A workspace with extracted entities renders them by default — documents, their entities, and the relationship edges in one picture.
• A full workspace renders the same entities picture (vectors are not drawable); "Full" shows on the badge, and semantic search becomes available in the Knowledge Base view.

Ask the graph

The Ask the graph box sits in the Workspaces tab toolbar. Type a plain question about the selected workspace — "what connects the video pipeline to the products engine?" — and it answers from a relevant subgraph of that workspace, in a floating results panel over the canvas. It works at every depth and does not require a key; agents have the same reading capability through their graph tools. What agents may change is governed separately — see What agents may do to the graph.

Create a workspace

Click New workspace in the header (or Create Workspace on a selected node). The dialog builds a workspace from one of three sources:

1. A subtree of the root graph — start from a folder node you selected.
2. A browsed folder — pick any folder on disk.
3. A preset union — combine predefined path sets.

Then choose the kind:

_root is a Root KG, not a special case of one: you can create your own mirrors of any directory you want followed — a code tree, a client folder, an archive — and they render structure-first with the same Entities toggle.

Finally choose the build depth — Structure only, Structure + Entities, or Full (Entities + Vectors). Structure is free and instant; entities cost only your agents' attention; full runs the embedding pipeline and pre-flights your Gemini key before it starts. Structure is a complete state — you can enrich or upgrade later, and the badge follows reality.

Keep a workspace following its folder

Live updating is not a privilege of the root mirror. Any workspace built from a source folder gets its own controls in the canvas toolbar — the same slot the root graph uses:

• Live — follow the bound folder continuously. New files appear, deleted files disappear, no action from you.
• Re-sync — a manual re-walk of the folder, the per-workspace analog of Sync now.

Both write structure only and call no model: live-sync never extracts entities or embeds vectors on its own, so a workspace cannot quietly spend your agents' attention while you are not looking. Enrichment stays a button. A workspace with no source folder bound shows the Live control disabled, with a tooltip saying why — there is nothing for it to follow.

Ingest and enrich

Ingest registers documents into the selected workspace: nodes are created, folders linked, metadata recorded. No file content is sent to any model — ingest at the default depth is mechanical and free. Batch ingests run as jobs you can watch and cancel.

Enrich is the deliberate second step. Select a document — or multi-select several, or a folder to cover everything in it — and click Enrich. An agent reads the material and extracts entities, relationships, and a description and summary for each document; a progress strip tracks the run, and the document's status moves from pending to done. Enrichment doubles as discovery indexing: those descriptions and summaries are what topic search matches on. Cost: your own agent's reasoning, no external API.

Federate two workspaces

Federation answers a question a single workspace cannot: what do these corpora have in common? Tick two or more workspaces in the left rail — any kinds, including the root mirror and context-artifact graphs — and click Build federation.

What comes back:

• Bridging entities — concepts that appear in more than one of the selected workspaces.
• Bridging documents — files that belong to more than one of them.
• A federation report — computed deterministically, with no model calls.

The union graph renders on the canvas, and selection is wired both ways: click a node on the canvas to see it in the inspector, or click a bridge row to jump to it on the canvas. A selection you use often can be saved as a named federation and rebuilt later.

Steer the root mirror

The root workspace maintains itself, so your job is scoping, not upkeep. Its controls sit on the root knowledge graph card at the top of Cortex ▸ Overview:

• Live toggles whether the mirror follows document changes continuously, with a state chip beside it when a first-run baseline is catching up or a drift repair is pending.
• Sync now forces a full reconcile — the thing to click after bulk file moves. In the steady state the live sync engine handles it on its own.
• Configure opens the root configuration: which root paths are mirrored, which file extensions are included, excluded folders, and a per-file size cap. A prune action removes anything newly excluded from the graph. The header gear in Cortex opens the same configuration.

For quick scoping, the folder tree has an edit mode: tick the folders you want excluded directly in the tree and save — the exclusion list and the prune happen together.

Keep the graph healthy

• Lint runs structural checks and offers fixes: orphaned documents and isolated folders can be fixed directly from the pane; stale entries, singleton entities, and cross-workspace duplicates are flagged for review. Documents you simply have not enriched yet are not findings — they are a to-enrich queue, and Lint knows the difference.
• Report computes a deterministic analysis — most-connected hub nodes, topic communities, cross-community surprises, reference cycles, gaps, and suggested questions — with no model calls and no changes to the graph.
• Activity is the graph's own history: ingests, enrichments, deletions, lint actions, in order. Click an entry's subject to jump to that node on the canvas.

What agents may do to the graph

Reading the graph is open to your agents at every depth — that is the point of building it. Changing it is governed: an agent's write crosses your subscription and the Knowledge-graph writes control plane (Settings ▸ Terminals ▸ Agent control planes), and every mutation is written to an audit log you can read. Your own Cortex actions on this page are not affected by that switch — it governs the agent tool surface, which is different code.

The full model, including what "refused" looks like and why the switch fails open, is on Autonomy and controls.

Export

Export in the header writes the selected workspace to portable files — a JSON graph plus GraphML — into the kg_exports/ folder under your install root. That is the hand-off format for outside tooling.

If the graph goes dark

The graph runs on a local database — ArcadeDB, provisioned and run by the platform itself — managed from Settings ▸ Database and Dashboard ▸ Platform Health. If it is not running, Cortex shows honest offline overlays instead of data, and everything resumes when it is back; your documents are never affected. Backend modes and connection settings live in the configuration reference.

When the canvas will not draw

The graph canvas is drawn on the GPU. Command Center checks for a usable graphics path once per session — it acquires a rendering context and allocates a render target, because a machine can pass the first test and fail the second — and if that check fails, the canvas is replaced by an overlay that says so.

You can hit this on a perfectly healthy machine:

• a virtual machine or VDI with a paravirtual display adapter,
• an RDP or screen-shared session with no hardware acceleration,
• hardware acceleration disabled by policy,
• a blacklisted or very old graphics driver.

What still works: everything that is not the canvas. Overview, Report, Lint and Activity keep working, the details panel and its Markdown editor keep working, ingest and enrichment keep working, and agents querying the graph through their own tools are unaffected — none of that needs a GPU. There is deliberately no low-fidelity 2D fallback: a graph of thousands of nodes drawn without acceleration is slow enough to be misleading, and an honest overlay is more useful than a canvas that appears to work.

If you need the canvas on such a machine, the fix is on the host, not in Command Center: turn hardware acceleration back on, update the graphics driver, or open Command Center in a session that has GPU access.

Where to go next

• Knowledge Base — the curation lens over the same graph
• Context Artifacts — attach a purpose-built graph to an agent's briefing
• Autonomy and controls — what agents may change, and the switch that stops it
• Knowledge graph infrastructure — the operating reference