Architecture

Technical Architecture

Open-core architecture for deterministic domains and grounded agent layers.

Back to Overview

Current Open-Core Shape

Open core: |-- principles |-- validation standards |-- deterministic domain substrates |-- generic architecture docs |-- public white papers Private consulting layer: |-- client pairing logic |-- adaptation heuristics |-- live operating playbooks

Execution Layers

Deterministic Domain Layer

Databases, files, rules, and repeatable domain tools provide the substrate.

Validation Layer

Artifacts, audits, and explicit checks determine what can be trusted.

Grounded Agent Layer

Models become useful when they answer against verified local context rather than raw prompt state alone.

Human Control Layer

Supervision, review, and stop conditions remain part of trustworthy operation.

Why This Matters

The main architectural lesson is that reliability comes less from model size alone and more from deterministic substrates, explicit validation, and clear trust boundaries.

That is why the open core emphasizes standards and grounded execution surfaces rather than generic “agent” branding.

OpenClaw Integration Layer

The outer shell problem — interface, operator access, and monitoring — is handled by a separate integration layer built on OpenClaw.

OpenClaw (outer shell) ↓ operator ingress · monitoring · HTTP gateway ShowcaseAgent (internal routing) ↓ domain-compression · benchmark surface Phoenix Backends (authority layer) deterministic scripts · domains · tools

Working rule: OpenClaw makes Phoenix accessible. Phoenix makes OpenClaw outputs trustworthy. The model is absent from the result path; correctness lives in the solver.

HTTP Endpoints

Four deterministic backends exposed via authenticated gateway routes: TSP summary, Gemma protocol verdict, run-trace, and benchmark results. A fifth aggregate endpoint (/phoenix-ops-summary) fans out to all four in parallel.

Per-Backend Health

Every summary call logs one subevent row per backend. /phoenix-ops-status renders a BACKENDS section showing each backend's health state (healthy / degraded / down), last latency, call count, and last failure reason.

Incident Mode

The top of /phoenix-ops-status surfaces the operator-relevant state immediately: ATTENTION NEEDED if any backend is down or degraded, or STATUS: healthy — no incidents with the last known-good summary timestamp.

Trend Visibility

Each summary call writes a snapshot to a rolling log. /phoenix-ops-trends renders a table of latency, backend health, and ok/fail state across the last 40 calls — making regressions legible over time.

Verification Chain

Four-level verification: baseline output check, endpoint shape check, threshold gates (errors, latency, backend down state), and a one-shot report bundle (phoenix_ops_report.sh).

OpenClaw Demo page →  ·  OpenClaw Operator Shell White Paper →