Meet HelixWorks: A Platform, Not One AI App

This course is built around the public HelixWorks Kubernetes Lab monorepo. The excerpt below is runnable source, not pseudocode.

Source: compose.yaml

control-plane:
    build: { context: ., dockerfile: services/Dockerfile, args: { SERVICE: control_plane } }
    environment: { ENVIRONMENT: local, GENERATOR_URL: "http://generator:8080", RUNTIME_URL: "http://runtime:8080", EVIDENCE_URL: "http://evidence:8080", SERVICE_TOKEN: "local-service-token-32-characters-minimum", JWT_SECRET: "local-jwt-secret-32-characters-minimum", CONTROL_DATABASE_URL: "sqlite:////data/control.db", ARTIFACT_DATABASE_URL: "sqlite:////data/artifacts.db", BROKER_TOPIC: "http://broker:8080" }
    volumes: ["control-data:/data"]
    ports: ["8080:8080"]
    depends_on: [generator, runtime, evidence, broker]

Code to reality

Declared intent

Run six explicit local responsibilities: web, control plane, generator, runtime, broker, and evidence.

Interpreter

Docker Compose resolves the service graph, builds images, creates networks and volumes, and starts containers.

Software effect

The control plane calls generator and runtime, then its outbox publishes to the broker for the independently progressing evidence subscriber.

Hardware effect

Six containers and four persistent volumes consume laptop CPU, memory, storage, and network namespaces.

Observable evidence

docker compose ps proves web, control-plane, generator, runtime, broker, and evidence processes; restart queries prove four durable volumes.

Enterprise problem: Enterprise teams repeatedly assemble AI demos that cannot prove who owns data, who may publish, or how an application is revoked, so a promising prototype becomes an unreviewable operational risk.

Whole-course context: This first day establishes the customer lifecycle and the stable product boundary that every later implementation must preserve.

Today’s slice: Define HelixWorks as a provider control plane plus hosted runtimes for generated applications, not as one support bot or content tool.

End-of-day evidence: A reviewed platform charter names three contrasting application archetypes, three authorization planes, their owners, and falsifiers for the shared platform claim.

Still unsolved: Generation, preview isolation, data provisioning, connectors, deployment, AWS infrastructure, and day-two operations remain deliberately deferred.

The customer outcome is a reviewable meet helixworks forge: a platform, not one ai app change, not a collection of requirements. This day starts with the implementation boundary, then uses the command or manifest below to produce positive, denied, and recovery evidence.

HelixWorks Studio and Platform Policy service; control-plane API process on Docker or Kubernetes; PostgreSQL charter store and immutable S3 evidence objects; cache: not involved because a charter decision must be read from its authoritative revision.

This map names the implementation boundary for this day. The service or controller changes only the state it owns; runtime and audit evidence let the operator distinguish a declared change from an effective one.

Reproduce the boundary review

A diagram is not evidence when nobody can validate its source. The current monorepo expresses the first runnable boundary as five local containers; it does not yet contain a separate charter validator. Read the exact source in compose.yaml.

  control-plane:
    build: { context: ., dockerfile: services/Dockerfile, args: { SERVICE: control_plane } }
    environment: { GENERATOR_URL: "http://generator:8080", RUNTIME_URL: "http://runtime:8080", EVIDENCE_URL: "http://evidence:8080", SERVICE_TOKEN: "local-service-token-32-characters-minimum", JWT_SECRET: "local-jwt-secret-32-characters-minimum", CONTROL_DATABASE_URL: "sqlite:////data/control.db", ARTIFACT_DATABASE_URL: "sqlite:////data/artifacts.db" }
    volumes: ["control-data:/data"]
    ports: ["8080:8080"]
    depends_on: [generator, runtime, evidence]

A platform claim is credible only while the policy portal, approval workflow, and support dashboard share lifecycle machinery without sharing domain authorization. If a fourth archetype requires a fork in identity, release, or retirement services, narrow the advertised envelope before expanding the implementation.