Architecture Map

Architecture map

RX connects heterogeneous components through shared responsibility and execution contracts. Repository boundaries support development; they do not define runtime authority, safety qualification, or every core boundary.

The controlling baseline is the pinned core charter and framework master plan. The table below is a migration guide, not a replacement for those contracts.

Responsibilities and development location

Responsibility	Existing source	Migration treatment
Task identity, authority, uncertainty, durable records, and recovery	Platform domain/application/runtime/storage layers	Preserve core semantics and writer ownership.
Device command gate, admission, journal, and binding continuity	Solutions Host	Core responsibility even though it currently lives in Solutions.
Resident process ownership, registration journal, and recovery disposition	Solutions Supervisor	Core execution-management responsibility; it does not create business authority.
Device/native providers	Host backends, drivers, and native integrations	Package-facing integration through core-owned boundaries.
Process authoring and BT execution	Process/compiler/package tools and Executor	Standard implementation packages with explicit internal dependencies.
Operator applications, catalog content, installer and distribution assembly	Solutions apps/catalogs/deployment	Product packages and distribution inputs.
Shared schemas, bindings, and protocol transport	Platform contracts/proto and generated consumers	Canonical source and checked generated artifacts.

Code belongs to the core when it determines evidence meaning, hides an authority/uncertainty/handover failure from external observation, participates in single-writer atomic state changes, or interprets normative fields. Moving a directory does not change that classification.

Dependency direction

External authors and operators
    | public clients / CLI / verified extension artifacts
    v
Contract, API, and adapter boundaries
    | admission, identity, currentness, and authority checks
    v
Platform core + Host gate + resident execution management
    | bounded native requests and observed facts
    v
Device/native providers and operating infrastructure

Packages supply capabilities and native facts. They do not approve themselves, settle UNKNOWN, bypass the Host gate, or infer resource handover from process exit alone.

The validated monorepo retains the existing Platform and Solutions code subtrees and two Cargo workspaces. Product documentation and semantic contracts have already moved to their canonical locations through M4. Later layout work makes dependencies clearer without treating directory names as proof that a boundary has become public or independently replaceable.

Three SDK surfaces

Surface	Current baseline	Planned treatment
Internal Rust implementation sharing	Six Platform crates are vendored into the Solutions SDK inventory.	Keep the inventory through initial import; remove duplication only through the later identity-aware transition.
Public client libraries	Protocol-bundle preparation produces rxclpy and rxclcpp installation packages.	Publish versioned artifacts with isolated consumer checks and ABI/runtime metadata.
External-process adapter support	An installed package tool exports the adapter helper; the protocol carries bounded native facts.	Deliver a small versioned SDK, templates, and conformance fixtures for external authors.

The client-library instructions and external adapter guide describe the existing paths and their limits. SDK artifact availability must be checked separately from source-generation capability.

The bundled Executor currently uses internal ports and SQLite storage for its own durable journals. Keeping that first-party dependency during migration does not expose storage as a stable third-party API. An external Executor SDK requires a separate public contract and verification effort.

Identity-sensitive changes

Contracts are not the only identity inputs. Driver and review fingerprints can include Cargo metadata, the SDK inventory, source-file paths, and compiler or validator source text. Updating a dependency path or removing a generated source copy can therefore change identity even when intended behavior is unchanged.

M7/T2 must enumerate affected identities, record before/after provenance, and handle the resulting package review and qualification requirements. Old evidence keeps its original identities. New code must not impersonate an old implementation by reusing a fixed old digest.

Cell/production handling remains an internal standard domain during this migration. Its transaction, recovery, and qualification responsibilities must be understood before any later package extraction. M8 tracks such boundary improvements separately from repository cutover.