Meet Zheta Forge: A Platform, Not One AI App

This course is built around the public Zheta 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.

The source tables below remain the detailed contract. Begin with these customer paths:

• D01-UC-01
  • Person: Enterprise application creator
  • Job: Describe a policy portal, approval workflow, or support dashboard through one product contract
  • Observable result: All three archetypes fit the same create-to-retire lifecycle without a control-plane fork
• D01-UC-02
  • Person: Enterprise risk owner
  • Job: Review the ownership and authorization boundaries before approving the platform
  • Observable result: Provider, hosted-runtime, and generated-application responsibilities have separate owners and revocation paths

Now turn each customer job into a story with a result that an engineer can check:

• D01-US-01
  • Story: As an enterprise application creator, I want one application specification for three contrasting archetypes, so that the platform is broader than…
  • Observable acceptance: Each archetype maps to create, generate, preview, data, identity, share, publish, operate, export, and delete stages
• D01-US-02
  • Story: As an enterprise risk owner, I want each authorization plane independently revocable, so that one membership cannot silently grant every capability
  • Observable acceptance: The charter names the owner, records, grant, denial, and revocation evidence for every plane

Finally trace each story through the system that owns its state and the evidence that proves the outcome:

• D01-FLOW-01
  • Trigger: Creator submits the three archetype briefs for platform review
  • Responsible systems: Application Catalog and Platform Policy service
  • Authoritative state: Control-plane PostgreSQL application charter
  • Owned record: PlatformCharter
  • Observable evidence: Actor, archetype, lifecycle map, owner, expected boundary, observed review result, local environment, timestamp, charter commit SHA
  • Failure signal: Unsupported archetype rule and rejected revision hash
• D01-FLOW-02
  • Trigger: A brief requires the platform to copy unrestricted enterprise data and inherit source permissions
  • Responsible systems: Platform Policy and Audit Evidence services
  • Authoritative state: Immutable charter and evidence object in S3
  • Owned record: ArchetypeAssessment
  • Observable evidence: Rule ID, rejected brief hash, denial reason, unchanged charter SHA, and accepted positive-control brief
  • Failure signal: Missing owner, conflated grant, or unreviewed boundary

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 Zheta Forge 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.

A platform becomes disguised custom consulting when every new application changes its core services. These use cases make reuse and rejection observable before code is written.

Vague personas hide who accepts risk and who observes success. These stories bind a named actor to evidence that another reviewer can falsify.

A customer enters through a product decision, not a Kubernetes object. The first flow accepts a bounded app idea; the second refuses an idea that would transfer source-system authority into Zheta Forge.

Without explicit planes, a provider login is easily mistaken for permission inside a generated customer application. The control plane governs creation, while each hosted runtime and generated application retain separate authority.

Conflating platform metadata with application data would let provider operations bypass generated-app authorization. This slice stores only the reviewed platform contract.

Generated-application database: Not created in this slice — the platform charter and review evidence are durable control-plane records; no generated application exists yet.

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.