RFC 001 — Kortex Ecosystem Map
RFC 001 — Kortex Ecosystem Map
Approved Descriptive Blocks: RFC 002..006
1. Summary
Before Kortex can be architected as "the brain of Koder DevOps", the ecosystem it intends to orchestrate must be documented. A preliminary audit of ~/dev/koder uncovered ten observe/devops products already implemented plus a descriptive umbrella (observe/observability) and two empty placeholders under platform/. This RFC maps every product, records its purpose, APIs, data shape, maturity, dependencies and overlaps, identifies duplications and gaps, and positions Kortex as the coordination layer above the existing stack — not as yet another silo. It is strictly descriptive. Decisions about Kortex's internal architecture, common event schema, common control plane, LLM abstraction and reflex engine are deferred to RFCs 002..006.
This document catalogues what exists today in the monorepo. Anything that sounds like a proposal is marked clearly and forwarded to a follow-up RFC or a ticket in another product's backlog.
2. Context and motivation
Kortex is described in platform/kortex/README.md as the /central nervous system for DevOps/ — an autonomic layer that senses, thinks, acts, remembers, and coordinates across every Koder product. The risk of building such a layer without a map is obvious: Kortex would re-implement ingestion, storage, query, alerting, and dashboards that the Koder ecosystem already ships. The result would be fragmentation, duplicated databases, and divergent schemas.
A first pass through observe/ and platform/ (20260407) found the following reality:
| Directory | Kind | State |
|---|---|---|
observe/log |
Log aggregation + search (Loki-compatible) | Implemented, Go, koder.toml |
observe/mon |
Infrastructure monitoring (agent + server) | Implemented, Go |
observe/notify |
Unified notification gateway | Implemented, Go |
observe/probe |
Synthetic monitoring + E2E + load | Implemented, Go (MVP) |
observe/wire (formerly observe/trace) |
Network diagnostics + correlation | Implemented, Go |
observe/apm (formerly observe/trace-apm) |
Distributed tracing + APM | Implemented, Go |
observe/uptime |
External uptime + status pages | Implemented, Go |
observe/observability |
Umbrella product family page; schema registry owner (§12.3) | Descriptive today, operational target (§12.3) |
platform/dash |
Observability dashboards (Grafana-like) | Implemented, Go |
platform/console |
Cloud platform management UI | Implemented, Go |
platform/log |
SaaS hosted version of observe/log |
Reserved (Phase 0, see §12.5) |
platform/wire |
SaaS hosted version of observe/wire |
Reserved (Phase 0, see §12.5) |
platform/apm |
SaaS hosted version of observe/apm |
Reserved (Phase 0, see §12.5) |
The ticket text for 001 referred to platform/{log,trace,trace-apm} as "vazios (placeholders)". The audit revealed they were absent, not empty — the directories did not exist in the monorepo at the time of writing. After §12.5 they have been reserved as platform/{log,wire,apm} placeholders for the SaaS hosted versions of the corresponding `observe