Chapter 02 — Ownership and Boundaries

Cortex is a generic runtime and Wire language substrate. A host application embeds Cortex and supplies domain semantics, transport, and persistence. The boundary described here is meant to survive any particular host.

This chapter states which subsystems own which responsibilities, which direction dependencies run, and what may and may not cross each boundary.

Core model

Three subsystems carry the bulk of the weight on either side of the boundary:

Two further subsystems are host-internal and do not interact with Cortex directly:

• Domain core — host domain types and product logic.
• Persistence — schemas, queries, and storage.

Dependency direction is fixed:

Server edge → Product binding → Cortex substrate

Runtime flow may invert — Cortex calls back into host-provided handlers, and Pulse receives callbacks from host-registered executors — but module imports must follow the arrow above. A module in the Cortex substrate that imports anything host-specific is a boundary violation, regardless of what the runtime does.

flowchart LR
    S[Server edge<br/>HTTP + auth + persistence adapters] --> C[Product binding<br/>host-specific Cortex configuration]
    C --> X[Cortex substrate<br/>runtime + language]

    C --> F[Domain core<br/>product semantics]
    S --> D[Persistence<br/>schemas + storage]

The placement rule: if a module would be reusable outside the host as runtime, Wire language, or executor-registration infrastructure, it belongs in the Cortex substrate, even when the product binding is currently the only caller. If it knows about host domain semantics, model providers, product-specific artifacts, truth policy, or host tool authority, it stays downstream or in Logos.

Public import boundary

Downstream products consume Cortex and Platform through two umbrella modules:

import Cortex
import Platform

Those modules are the supported public API boundary. They re-export the stable Cortex substrate surface and the generic Platform runtime utilities that downstream products are expected to use directly. Downstream reasoning libraries, including Logos, are imported as separate packages.

Area modules such as Cortex.Wire, Cortex.Pulse, or Platform.Observability remain available for advanced imports, examples, and focused tests. Implementation-era roots are not the downstream contract. A consumer that reaches past the umbrella modules should do so deliberately and expect that import to be reviewed when Cortex tightens its internal module layout.

Ownership breakdown

Cortex substrate

Cortex is not a thin provider wrapper. It owns the generic substrate end to end, grouped into three layers:

• Source language and graph layer. Algebraic graph primitives (Empty | Vertex | Overlay | Connect), DAG validation, the validated executable Circuit, and the Wire source language that authors circuits. Normative Wire grammar lives at ../Reference/Wire/grammar.md.
• Runtime layer. Pulse executes Circuits in an ephemeral local profile or a durable service profile. Durable Pulse adds checkpointing, rewrite hydration, frontier scheduling, run lifecycle, and stage events as service-owned state.
• Capability layer. Executor registration and native pure-executor capability surfaces.

Product binding

The product binding is host-specific behavior. It configures Cortex for one product’s use case and nothing more:

• executor config and capability-catalog policy
• domain-specific grounding and truth policy
• model-provider binding, artifact assembly, and product-specific IR
• product-specific tool registries
• approval and policy behavior tied to product UX

Server edge

The server edge is the transport and persistence boundary: HTTP routing, auth, SSE/poll, request/response conversion, persistence wiring, usage logging, edge error translation. Nothing else.

Boundaries and invariants

Each boundary has a closed allow-list and an explicit forbid-list. Violations are caught in review today; mechanical enforcement is a direction-of-travel goal.

Cortex substrate

Allowed: executor-registration capability abstractions; Wire / Graph / Circuit / Pulse primitives; generic JSON, text, time, and runtime helpers through Platform; generic observability hooks.

Forbidden: any host-specific import; server transport types; host durable-task scheduling; database queries and schemas; domain-specific imports; host artifact contracts.

The graph layer has a tighter rule than the rest of Cortex: it must contain no Pulse node identity, no rewrite lineage, no task scheduler coupling, no run-outcome semantics. It is pure graph algebra.

Product binding

Allowed: the Cortex substrate, host domain core, host product code.

Forbidden as a long-term home: generic runtime helpers, or any utility that should be reusable by another host. Reasoning-library provider details belong in Logos; product-specific provider policy belongs in the product binding.

Server edge

Allowed: the product binding, the host’s transport API surface, auth, persistence, and route wiring.

Forbidden as a long-term home: provider clients, generic capability types, report or runtime orchestration that is not transport-specific, product-agnostic utility helpers. Edge handlers are thin adapters.

Why this boundary matters

This split is not just cleanup discipline. It is what makes Cortex usable as a real substrate:

• Cortex can evolve as a reusable system rather than as one product’s internal helper layer.
• A second host can adopt Cortex by supplying its own bindings rather than by forking Cortex semantics.
• Product-specific meaning stays where product teams can change it without destabilizing the substrate.
• Transport and persistence concerns stay at the edge instead of leaking into the execution model.

Extensibility

Downstream consumers extend Cortex by registering into closed alphabets, not by modifying Cortex modules:

• executors register under the @qualified.name namespace with declared vocabulary, structural constraints, and purity.
• contracts register with a payload kind and codec in the contract registry.
• tools register in the ambient tool namespace referenced from executor config records.

The boundary is preserved because Wire source only references names in these registries; it does not invent executor authority, contract semantics, or tool behavior. A second host stands up its own registrations and consumes Cortex unchanged.

Related

• ./01-overview.md — three-layer model and orientation.
• ../Reference/terminology.md — normative vocabulary.
• ./05-wire-language.md — Wire substrate architecture.
• ./06-pulse-runtime.md — Pulse runtime details.