RBE / DESIGN PHILOSOPHY

Authority should be visible before execution.

RBE treats backend structure as part of the runtime contract. A source file's role, imports, capabilities, Runtime ENV, executable identity and process boundary should be known before the application is activated—not discovered later through ambient privilege.

FOUR RULES

Keep the language coherent. Keep authority narrow.

01 / ONE LANGUAGE

Grammar should not encode organizational chaos.

Route, Module, Service and server policy can share REL's programming model. The extension changes authority and lifecycle, not whether normal application logic suddenly needs a different language.

02 / SCOPED AUTHORITY

The source role is a capability boundary.

Routes own HTTP. Modules own reusable in-process logic. Services own managed process work. server.server owns whole-server policy. RELC rejects imports that cross those boundaries without authority.

03 / IMMUTABLE ACTIVATION

Link the application before serving it.

RELC resolves policy, source identity, Runtime ENV and executable state into an immutable Runtime Image so activation has one exact identity instead of mutable live interpretation.

04 / FAIL CLOSED

A safer runtime does not quietly widen privilege.

If a native artifact, capability manifest or execution boundary fails admission, RBE should report the failure rather than silently fall back through a path that bypasses capability mediation.

THE CONTRACT

Source role → RELC link → immutable identity → supervised execution.

The Rust host owns what ordinary application code should not: process lifecycle, capability admission, Container/WASM execution, media process authority, backup/recovery and provider synchronization.

REL source ├─ *.route HTTP authority ├─ *.module application authority ├─ *.service managed-process authority └─ server.server server policy ↓ RELC ↓ immutable Runtime Image ↓ supervised runtime / Container / Service fabric

WHAT IT REFUSES

Convenience should not quietly become authority.

Ambient privilege

A Route should not gain Service, shared Runtime ENV, quickDB, Video Manager or filesystem authority merely because another source role can use it.

Silent security fallback

A native execution failure should not become an excuse to run through a less constrained path when that would bypass the capability boundary that failed.

Mutable identity as runtime truth

Runtime Image identity participates in capability authority. Linking and hashing need an exact application state rather than a partially recovered identity.

Accelerators pretending to be databases

quickDB can prove synchronized absence cheaply; a positive membership result still goes back to authoritative storage. Fast is not the same thing as true.

START SOMEWHERE USEFUL

Pick the boundary you are trying to understand.

SOURCE ROLES

What may each file control?

Start with Route, Module, Service and server.server authority boundaries.

Open →

REQUEST PATH

How does work move?

Follow the normal Route → Module → Service shape through real REL examples.

Open →

ACTIVATION

What is a Runtime Image?

Read the immutable application identity and activation contract.

Open →

OPERATIONS

How does recovery work?

Move into the runtime and Cloud Node docs for process, storage and recovery ownership.

Open →