Sheet 03 · Layer M7 · Drawn by the-metafactory · v0.1.0 (MIG-0 bootstrap)

Cortex

The metafactory ecosystem's layer-7 collaboration surface — the M7 application that consumes the myelin stack and presents collaboration, dispatch, and observability to operators.

Source on GitHub ↗ Architecture spec ↗

Where it sits

Cortex is one application at M7 — among siblings pilot (the review loop), signal-collector (telemetry), and any future M7 app that connects to the bus. It consumes contracts from M2–M6 and owns no part of M1–M6 itself.

M7 cortex (this app) · pilot · signal · future apps M6 Composition (myelin) M5 Discovery (myelin) M4 Identity (myelin — MY-400) M3 Envelope (myelin — schema + namespace) M2 Transport (myelin abstraction over NATS) M1 Connectivity (NATS leaf nodes / federation)

The brand metaphor

The metafactory ecosystem uses a nervous-system family of names. Cortex slots in cleanly:

What it does

Three jobs, one process boundary:

  1. Consume the bus. Subscribe to myelin envelopes, validate them, route them to internal handlers.
  2. Render the work. Mission Control v3 — Kanban / Inbox / Cards — backed by Durable Objects that track per-agent state.
  3. Adapt to platforms. Discord, Mattermost, Slack, PagerDuty — each a thin adapter that translates between platform events and bus envelopes.

Three-tier visibility

The original problem cortex was built to solve: a single Discord channel conflates three concerns and produces two opposite visibility failures.

Bots that log every tool call flood the channel with Read · Grep · Bash · Edit noise. Bots that don't log anything go silent for ten minutes and leave operators wondering whether the agent stalled. Both failures share the same root cause: a single surface trying to answer three different questions.

Cortex splits them:

Internal componentisation

cortex/src/
  bus/         — M2–M6 client code (NATS connection, envelope validator,
                 surface-router; the G-1100 ladder lifted from grove-v2)
  surface/     — operator surfaces (Mission Control v3, future TUIs)
  adapters/    — platform-specific (Discord, Mattermost, Slack, PagerDuty)
  runner/      — workflow runner (CC orchestration, worklog state)
  taps/        — publishers onto the bus (CC hooks, GitHub webhooks)
  cli/         — operator CLIs (discord, cldyo-live)
  common/      — shared types + utilities

Each subtree owns one M-layer concern boundary. The bus subtree is the only one that knows about NATS; adapters know about Discord but not about envelopes; surfaces render state and emit dispatch events. Moving between subtrees costs the price of crossing one named contract — never which file is this in?

Where the code comes from

Cortex inherits source from grove-v2, ported over phases MIG-0 (bootstrap, currently shipping) through MIG-8 (legacy retirement). The migration plan at docs/plan-cortex-migration.md is the per-file inventory + acceptance criteria for each phase.

Legacy grove (v0.29.0) is in maintenance-mode and contributes nothing to cortex. It will be archived at MIG-8.

Status

Authors

Open the cortex repo ↗ ← Back: myelin Docs hub →