Learn About

Deep workflow guides aligned to this documentation section.

Opta Local Architecture

Opta Local operating model, architecture, and execution surfaces.

general

Opta CLI Masterclass

Deep command workflows, session control, and production operator patterns.

cli

Opta LMX Masterclass

Advanced LMX runtime behavior, memory strategy, and performance tuning.

lmx

Browse all Opta Learn guides

Ecosystem & Synergies

Opta Local is organized as a two-layer ecosystem: a runtime layer that executes product behavior, and web surfaces that explain, distribute, support, and govern that runtime.

Overview

This page is the bridge between architecture and documentation ownership. Use it to understand which apps are contract authorities, which apps are presentation surfaces, and where to run change-impact checks before shipping updates.

Two-Layer Model

Canonical workspace architecture separates operational runtime from web delivery and management surfaces. This separation is intentional so runtime contracts stay stable while website content can evolve quickly.

Layer	Primary Apps	Primary Responsibility
Runtime layer	`1D`, `1L`, `1M`, `1O`, `1P`	Inference, daemon control plane, desktop clients, and distribution lifecycle
Web surfaces	`1R`, `1S`, `1T`, `1U`, `1V`, `1X`	Accounts, status, marketing, help docs, learn content, and admin control plane

Runtime Layer

The runtime layer owns protocol and behavior contracts. For example, daemon operations and session orchestration are authority-owned by CLI/daemon docs and code; UI clients should consume those contracts rather than redefining them.

Runtime changes commonly impact command behavior, API semantics, model operations, discovery flows, and lifecycle tooling. These are high-blast-radius updates across the ecosystem.

Web Surfaces

Web surfaces describe and operationalize runtime behavior for end users and operators. They include onboarding paths, feature status, release communication, troubleshooting, and account/control workflows.

A web surface should never become a hidden contract authority. It should reference the runtime layer and remain consistent with it.

Contract authority rule

If a runtime contract changes, update runtime docs first, then update dependent web surfaces using the change-impact workflow. Do not let web pages define runtime truth.

content-sync-map

The workspace uses docs/content-sync-map/ as the cross-ecosystem map for change ripple analysis. It tracks app identities, content nodes, and stale conditions.

docs/content-sync-map/

docs/content-sync-map/
+-- registry/apps.yaml
+-- registry/logos.yaml
+-- registry/content-nodes.yaml
\-- workflow/change-impact.md

For the procedural checklist, continue to Change Impact Workflow. For cross-layer relationship guidance, see Synergies.

Next Actions

Read Synergies to understand contract-safe collaboration patterns.
Run Change Impact Workflow for any runtime, web, logo, or release change.

First Session

Synergies