RAS Bridge Contract

This reference defines the current bridge contract between CDP and the Reticular Activating System (RAS) for substrate boot.

It is narrower than the full application boundary. The RAS bridge describes the CDP-to-RAS boot handoff, while the application boundary describes the broader outside-world interaction model used by different host applications.

Purpose

The RAS bridge is the handoff boundary between:

1. CDP intent and domain selection.
2. RAS launch orchestration and substrate activation.

It exists so CDP stays user-facing while RAS remains orchestration-facing.

Bridge roles

CDP responsibilities

1. Select active domain from Domain Bundle.
2. Resolve the intended launchable substrate entry.
3. Submit a launch request to RAS.
4. Surface status and errors to the user.

RAS responsibilities

1. Validate launch request shape and required fields.
2. Dispatch launch via configured launcher backend.
3. Enforce launch output contract.
4. Return runtime state/identity back across the bridge.

Required launch inputs

The bridge request must include SubstrateDomain-compatible launch fields:

1. definition-id
2. launch.launcher
3. launch.target.module-path
4. launch.target.symbol-name

Optional fields may be forwarded for policy and metadata:

1. lifecycle-policy
2. metadata
3. body

Launch output contract

A successful bridge launch returns a substrate runtime handle equivalent to:

1. definition_id
2. instance_id
3. healthy
4. lifecycle_state

On failure, the bridge must return a structured error that preserves:

1. failing stage (validation, dispatch, import, invoke, runtime)
2. machine-readable reason
3. human-readable message

Lifecycle interactions

The bridge must support at least these runtime operations:

1. boot (launch)
2. status (health/readiness/lifecycle)
3. shutdown (terminate active runtime)

Modulator compatibility note

Modulators are runtime behavior inputs and should be treated as configuration/runtime concerns layered above launch-target resolution.

Implications:

1. RAS bridge resolves and launches substrate identity first.
2. Modulator requests are submitted by RAS to Neuromodulators, fanned out to synthesizers, and resolved before the runtime is returned.
3. Bridge contracts should not rename identity fields based on modulator state.

Boundaries and non-goals

The bridge must not:

1. Embed package-specific composition logic.
2. Mutate domain semantics beyond validation.
3. Reinterpret substrate-specific modulation policy that belongs to RAS, Neuromodulators, and synthesizers.

Related references

1. Substrate Core Contracts
2. Domain Bundle Reference
3. Substrate Package Requirements
4. NeuralRelay Modulator Messages
5. CDP Guide
6. Application Boundary Contract