Startup Sequence

Bring up mBedLM-core in dependency order: validate, start substrate, then admit traffic through governed routes.

Operational Overview

Startup is treated as a gated flow rather than a single script run. Each stage establishes a stable boundary before the next layer is allowed to initialize.

Reference Startup Flow

1. Validate environment and secrets
2. Verify model artifacts and backend reachability
3. Start serving backends (general and specialist)
4. Start memory and tool substrate
5. Start orchestration and routing surfaces
6. Start web/API product surfaces
7. Admit workflow traffic after readiness checks

Readiness Gates

• Serving readiness: required model endpoints respond with healthy status.
• Substrate readiness: memory and tool routing pass synthetic checks.
• Route readiness: core orchestration can complete baseline workflow probes.
• Contract readiness: response schema checks pass against known fixtures.

Operator Checks

python -m cli.main system status
python -m cli.main workflow preflight
python -m cli.main workflow status

Failure Containment

• Do not promote to traffic admission when any dependency remains degraded.
• Prefer rollback to previous known-good runtime tranche on sustained failures.
• Treat route drift and contract failures as blockers, not warnings.

Curated Source Synthesis

• Startup order is explicitly dependency-ordered to protect deterministic routing.
• Health and readiness checks are per-layer so failure domains stay isolated.
• Production admission is tied to route and contract checks, not process uptime only.
• Owner checklists emphasize SLO, alerting, and rollback triggers per subsystem.

What Is Intentionally Not Included

• Environment-specific credentials, hostnames, and secret distribution steps.
• Internal emergency runbooks and on-call escalation internals.
• Team-private deployment automation internals.