Skip to content

Core Infrastructure

The foundational layer that every other G6 component depends on -- result types, configuration, LLM routing, deployment targets, and operational services.

Overview

Core Infrastructure provides the primitives that make G6 a coherent system rather than a collection of scripts. The core component defines Result[T], AIBlock, SearchTree, and ResourceBounds -- the type-level contracts that all 270 registry components speak. The config component loads environment variables through pydantic-settings so that API keys, safety limits, and LLM caps are consistent everywhere.

Beyond primitives, this cluster includes the deployment spine (Docker, Kubernetes, AWS, GCP, bare-metal, Podman), billing integration via Stripe, compliance tooling, cross-language support through polyglot, and the simulation-only realtime_bridge test harness.

The cluster follows a strict layering rule: core and config have zero internal dependencies; everything else in the cluster may depend on them but never on components outside the cluster.

Launch readiness boundary

Passing core infrastructure checks means the shared foundation is usable for launch pilots. It does not prove the full customer path is production-ready. MCP clean install, Docker images, staging deployment, Stripe E2E, production environment validation, database migrations, email delivery, and onboarding still need separate verification before paid-user launch.

Kubernetes is not the default launch path

deploy_k8s is available for operators who already have a Kubernetes cluster and deployment practices. For first-user pilots and the current launch plan, prefer the simpler VPS/Docker path unless there is a specific cluster requirement.

Components

Component Description MCP Tools
core Result[T], AIBlock, SearchTree, ResourceBounds, CSF primitives --
config pydantic-settings with .env, CSF limits, LLM caps --
llm_router Model-agnostic LLM interface (OpenRouter, Ollama) --
database SQLite/PostgreSQL adapter with in-memory support --
workspace_manager Sandbox boundary enforcement, write-allow checks --
observability Logging, metrics, and tracing infrastructure --
integration Cross-component wiring and dependency edges --
deploy_core Shared deployment abstractions --
deploy_docker Docker container deployment --
deploy_k8s Kubernetes orchestration --
deploy_aws AWS deployment targets --
deploy_gcp GCP deployment targets --
deploy_baremetal Bare-metal server deployment --
deploy_podman Podman rootless container deployment --
compliance Regulatory compliance checks --
component_creator Scaffolding tool for new Polylith bricks --
polyglot Cross-language FFI and interop --
realtime_bridge Simulation-only controller test harness; not a hardware realtime layer --

Architecture

graph TD
    CONFIG[config] --> CORE[core]
    LLM[llm_router] --> CONFIG
    DB[database] --> CORE
    WS[workspace_manager] --> CORE
    OBS[observability] --> CORE
    INT[integration] --> CORE
    DC[deploy_core] --> CONFIG
    DD[deploy_docker] --> DC
    DK[deploy_k8s] --> DC
    DA[deploy_aws] --> DC
    DG[deploy_gcp] --> DC
    DBM[deploy_baremetal] --> DC
    DP[deploy_podman] --> DC
    BILL[billing_stripe] --> CONFIG
    COMP[compliance] --> CORE

Key Patterns

Result Railway. Every component returns Result[T] with .ok() / .fail() constructors. Errors propagate via .flat_map() and .or_else() without exceptions, enabling composable pipelines with the >> operator on PipelineBlock.

Settings Singleton. config.settings is a module-level singleton loaded at import time. Components read it lazily (e.g., get_openrouter_api_key()) so tests can patch environment variables before first access.

Deploy Spine. All six deploy targets inherit from deploy_core abstractions. Each base (cli, mcp, rest, grpc, soap, erlang) has a corresponding Dockerfile under bases/mvp/<base>/Dockerfile.