Something happens. The right thing follows.
Status: In build
Cortex turns a signal into one governed action, and keeps the record of why it fired.
A signal arrives
Matched the rule cold-store-temperature, version 1.4.
A governed action follows
criticalThings that must happen nowRunningnormalThe everyday defaultRunningbulkBackfills and anything that can waitRunning
The duty volunteer was notified at 06:12.
Interactive example · an illustrative signal, rule, lane and mode
Every action can say why it fired.
Which signal, which rule, which version, on which lane.
Read the full project overview
This is an experiment on the layer: Cortex consolidates the "when X, then Y" reaction into one shared layer, so every product emits signals instead of reimplementing reactions.
What it is
Cortex is built around three observations:
Reactions are themselves products. "What to do when a critical alert fires" is a decision with a contract, an SLA, an owner, and a lifecycle. Cortex treats reactions as first-class, versioned artifacts.
Resources need governing across reactions. The system cannot serve every signal equally during an incident. Cortex makes resource priority an explicit, modal choice.
Domains evolve faster than the runtime. The runtime stays small and stable; domain logic ships as published, signed, versioned packages that load dynamically.
The flow
any signal → Cortex → a governed, prioritized actionA signal is anything an upstream service decides is interesting: a webhook, an alert, a system event, a sensor reading, a scheduled poll. An action is anything the system can do in response: notify a team, dispatch an investigation, start a workflow, escalate to a human, run a remediation, kick off an agent.
Three layers
| Layer | What it is | Who owns it |
| Domains | Per-source rule packs and per-domain action modules | Domain teams |
| Runtime | The execution surface: cause analysis, effect dispatch, dynamic loading | Platform team |
| Governance | Lane policy and operational modes that decide what runs and how aggressively | Platform and operations |
Priority lanes
Resources are finite, so Cortex makes allocation a first-class product surface.
critical: pre-warmed, paused only under explicit emergency stop. For things that must happen immediately.
normal: the default. Scales as needed; pauses during incidents.
bulk: backfills, sync work, anything that can wait. First to pause under pressure.
Modes
Priority also depends on what the whole system is doing right now.
default: everything runningsecurity-incident: bulk and normal pause, critical scales upblocking-task: bulk pauses, critical and normal keep runningmaintenance: a trickle of critical; everything else parkedfreeze: emergency stop
Rules can set modes when the system detects an incident, and humans can set them when the system needs to be told.
Pluggability as a contract
Dynamic loading is what makes Cortex sustainable as a shared service. The runtime never rebuilds to add a domain; domains live as published, signed, versioned packages the runtime loads on demand.
This shapes the product two ways:
Domains ship at their own cadence. A fast-moving team never waits on a slow runtime release.
The runtime stays small. It does exactly four things: route events, run rules, forward actions, govern lanes.
Auditability by default
Every action that fires answers these questions without inference: which signal caused it, which rule built the intent, which module ran, at what version, with what input, returning what result, on which lane, in which mode.
The audit log is a first-class data stream. This is structural trust applied to automation: the record shows why the system believed each action was allowed.
Who it is for
Platform engineers, who want to say "when X happens, do Y" without writing a reaction service for every X.
Operations and SRE, who want a single place to govern resource allocation across the whole reaction layer.
Domain teams, who want a system that takes their domain knowledge seriously, with plug-in rule packs and action modules.