Meet HelixWorks: A Platform, Not One AI App

HelixWorks is the platform you will build throughout this course. A platform is a shared product that helps teams create and operate many applications; it is not one application with one fixed purpose.

The source repository uses Forge in implementation names such as the Python Forge class, the gitops/apps/forge directory, and the helixworks-forge Kubernetes namespace. Those names refer to HelixWorks code and deployment resources; Forge is not a second product or component. This course says HelixWorks when it means the product and preserves Forge only when showing an exact code identifier.

Enterprise teams often assemble AI demos that cannot prove who owns data, who may publish, or how an application is revoked. A promising prototype then becomes an operational risk because nobody can review its full lifecycle.

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. A control plane is the part that accepts an owner’s intent and coordinates the work; a runtime is the part that executes the generated application.

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.

By the end of the lesson, you will be able to follow one request from a product owner into the HelixWorks control plane, identify which runtime executes the result, and point to the evidence that proves what happened. You will also be able to explain why a generated application’s own users and data do not belong to the HelixWorks control plane.

Today you focus on three responsibilities in the whole-system map above: the HelixWorks control plane receives and authorizes the owner’s request; the generated-application plane owns its end users and domain rules; and product storage keeps the project, artifact, runtime, and evidence records separate. The local implementation uses containers and SQLite-backed volumes, which you will inspect directly below.

Reproduce the boundary review

A diagram is not evidence when nobody can validate its source. The current monorepo expresses the first runnable boundary as six 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.