Roadmap

UNOFFICIAL/EXPERIMENTAL. This is the canonical roadmap index for helm-expt. It does not replace generated status surfaces or GitHub issues. It explains the current product direction, the active workstreams, and which planning files are authoritative for each kind of question.

Updated: 2026-08-25.

How To Read The Roadmap

Use generated data for moving status and use GitHub issues for execution. Use this file for priority, ownership, and product shape.

Do not copy live counts into roadmap prose. Counts belong in generated data.

Status Language

Use checkpoint complete when one PR, proof, issue, or generated surface is finished. Use roadmap complete only when no agreed repository work remains and every product, outside-user, hardware, and external dependency is either completed or explicitly removed from scope. A clean branch, green gate, merged PR, or live website proves its named checkpoint only.

The Top 50 may remain partial while every currently unblocked repository change is complete. In that case, report both facts and name the remaining owner. Do not turn a product dependency, outside-user test, GPU run, or upstream change into a repository success.

Current Product Goal

helm-expt should help a person turn configuration they already use into a reviewed, deployable OCI package. That result must remain useful without ConfigHub. When a team needs durable history and operations, the project should show how the same accepted configuration continues into ConfigHub:

New to cub? Install the cub CLI first. Public catalog packages pull and render anonymously, and you sign in only once a command saves or changes ConfigHub data.

Start with Helm first, then support AICR, cub installer packages, existing OCI, and Kubernetes YAML.
Let people inspect, test, and produce public OCI without a ConfigHub account.
Record source inputs, exact objects, prerequisites, hooks, CRDs, checks, and receipts.
Offer an optional ConfigHub handoff when a team needs shared history, variants, approvals, promotions, or fleet rollout.
Publish exact reviewed objects as OCI for Argo CD, Flux, or direct apply.
Keep unsupported cases and missing evidence visible.

Helm remains the first and deepest path. The wider boundary is:

source -> inspect and test -> OCI
OCI -> inspect or change -> OCI
OCI -> ConfigHub -> reviewed variants and operations -> OCI -> delivery

The proof machinery supports that story. It should not be the first thing a new visitor has to understand.

The model keeps four records separate: source and intent, exact configuration, lifecycle work, and runtime result. Helm hooks, CRDs, cloud provisioning, runtime images, models, and configuration OCI have different lifecycle rules. OCI is the common transport between tools and systems; it is not a universal execution model.

The homepage should keep a small number of starting jobs. A well-designed Catalog absorbs the breadth: users can browse by source format, task, lifecycle need, evidence stage, and version. More examples should make the Catalog more useful without turning every format or advanced workflow into another top-level entry point.

Active Workstreams

Completed Repository Checkpoints

These outcomes are complete in helm-expt. Their wider product journeys remain governed by the dependency table below.

Remaining Dependency Classes

AI Infrastructure And Platform Track

This track is informed by an August 2026 discussion with an AI infrastructure partner. The roadmap records the product requirements, not private meeting notes, contact details, or commercial commitments.

The partner feedback makes the job concrete:

• offer tested, versioned ways to run common AI and platform workloads;
• keep a complete open-source reference path, while allowing users to replace components and supply their own images;
• help teams that have Kubernetes and GPUs but do not yet have mature cloud operations;
• let agents request infrastructure without letting a non-deterministic agent rebuild the platform differently on every run; and
• put testing, promotion, rollout, rollback, and measured optimization around the selected configuration.

Two Public Starting Journeys

The first journey begins with an inspection and configuration exercise that needs no GPU. A page may say that inference is running only after a real model request succeeds on a recorded target. GPU-specific claims require a real GPU target and measured workload evidence. The second journey should be presented as Build a platform, not as a Kubara expert reference page. The existing Kubara evidence remains behind that simpler front door.

Named Inference Starting Stacks

"Get inference running" is a family of concrete examples, not one generic AI demo. The public site should first let a person inspect the configuration without specialist hardware, then identify the stack whose model workload they can actually run.

These entries must remain visibly different. AICR describes and composes a platform, Helm supplies many of its components, NIM supplies licensed model-serving runtimes, and eks-inference is an opinionated end-to-end stack. The Workshop gives them the same review path without pretending they are the same format.

Public Site And Customer Path

This track should extend the current site rather than introduce another navigation model. Each named stack follows the same short sequence:

1. Find the stack in the Catalog or Examples page and read what it contains, what it needs, and what has actually been tested.
2. Run the accessible example locally or use the site's no-account checks. Keep the reviewed result as files or configuration OCI.
3. Compare the result with another catalog version, an AI-produced candidate, or the configuration the user already runs.
4. Stop with the reviewed files or OCI, or use Keep this reviewed result in ConfigHub when the result needs shared history, variants, approvals, promotion, release OCI, GitOps delivery, or live comparison.

The source identity and object-set digest must stay visible across step 4. The account is the way to retain and operate an accepted answer, not a prerequisite for learning what a stack will do. The website needs small additions to the existing Catalog, Examples, Check, Promote, and ConfigHub pages; it does not need a separate AI-inference site or another top-level product story.

OCI Is The Common Handoff

The common delivery shape is:

Git -> build -> OCI -> ConfigHub -> OCI -> Argo CD or Flux -> Kubernetes

OCI is the transport and immutable handoff for deployable configuration. It is not the only record in the system, and the site must not use the word OCI as if every artifact had the same job.

Every maintained path also needs a source-and-intent record. It explains the source, selections, exact output, custom images, remaining inputs, prerequisites, lifecycle work, checks, and receipts. Secrets travel as references or target requirements, not as credential material embedded in a portable OCI.

The public no-account boundary remains useful at every starting point:

work -> OCI
OCI -> work
OCI -> work -> OCI

Here, work means inspect, explain, render, compare, test, scan, or edit. A useful anonymous path can end with files or OCI. A user signs in when they choose to retain the result as shared ConfigHub data, promote or approve it, publish a ConfigHub release, or compare it with live systems.

Deterministic Tools Behind Agents

The agent path should be:

request in words
-> agent chooses a deterministic tool and inputs
-> exact candidate objects
-> checks and workload measurements
-> human or policy decision
-> ConfigHub promotion and release OCI
-> GitOps and Kubernetes

An agent may explain the result, select a tested pattern, propose inputs, or choose the next experiment. Deterministic tools render, transform, compare, test, publish, and promote it. The agent does not directly improvise a different cluster or platform on every run.

This creates two related examples:

The first c3agent Workshop example should show one digest-pinned custom runtime image, one Secret reference, and one model or budget change moving from development to staging and production. It should produce a configuration OCI locally, retain the same object set as a ConfigHub base, publish a release OCI, and deliver it through Argo CD or Flux. The live proof must say whether it checked only Kubernetes readiness or exercised the agent workload itself.

Acceptance Ladder

The track graduates one claim at a time.

1. A new user can run the starting example locally without a ConfigHub account.
2. The result names the source package, exact versions, runtime image digests, and every generated Kubernetes object.
3. Required Secrets, controllers, CRDs, hooks, setup work, and target facts are visible before deployment.
4. The user can keep the reviewed objects as files or a configuration OCI.
5. Pulling that OCI back produces the same object-set hash.
6. Uploading the result to ConfigHub retains the same object set and source digest.
7. Development, staging, and production changes appear as exact variant diffs, with overlapping source and post-render changes identified before promotion.
8. Apply gates check schema, placeholders, Secret handling, approved models or runtimes, image pinning, lifecycle routes, and production approval as applicable.
9. A ConfigHub release OCI reaches Argo CD or Flux at the recorded digest, and the target result is observed separately.
10. An optimization example records each candidate, test workload, metric, decision, and promoted winner. A failed or partial target never becomes an overall pass.

Current Boundaries

Next Build Order

1. Completed: publish the four-record lifecycle model and the Catalog browse model in the canonical guides, then keep the public site summary short.
2. Completed: expose the eight existing eks-inference certified-bundle records as one readable stack journey, including the component order, routes, and exact source commit.
3. Completed: independently run and receipt the eks-inference ConfigHub configuration sandbox. Do not add a cloud or model-runtime claim to that receipt.
4. Completed: retain one candidate as a ConfigHub variant, promote it, publish release OCI, and prove Argo CD or Flux consumed the recorded digest.
5. Completed: run one real vLLM model request on a recorded target. Keep cluster readiness, workload readiness, and successful inference as separate results.
6. Completed: present the CPU starter, AICR plus Helm, NIM, and eks-inference as one ordered Catalog family: begin without specialist hardware, then offer the GPU and cloud paths with costs, credentials, prerequisites, and proof boundaries stated first.
7. Completed: build a ConfigHub Workshop c3agent example from local source through configuration OCI, ConfigHub variants, promotion, release OCI, Argo CD, and a bounded Kubernetes check.
8. Completed: add a simple Build a platform journey: choose tested Catalog components, versions, and custom images; generate Kubara configuration and its package index; then continue locally or in ConfigHub.
9. Completed: join the test harness to promotion: generate candidates, run a fixed workload, record metrics and target facts, select an accepted result, and promote that exact configuration.
10. Completed: complete the bounded hosted-anonymous path and its contract without implying that the static site renders arbitrary charts, pulls arbitrary OCI, or contacts clusters.
11. Completed: gate one AI-proposed AICR platform change by exact object identities, declared Application reach, and exact changed fields; refuse the overbroad request.
12. Then: only after the bounded examples pass, generalize the pattern to more AI runtimes, sandboxes, hardware classes, fleet tools, and reference stacks.

Component Ownership

Which part of the wider system owns each kind of work. This is the split issue #949 asked the roadmap to state; it names owners, not delivery dates.

Release Guardrails

The broad verifier should prevent regressions in the claims that users see.

Run scoped checks while editing. Use npm run verify as the broad release gate after focused checks pass. A passing verifier means committed evidence is self-consistent; it does not replace a fresh live run.

Planning File Roles

The active planning corpus has three tiers.

When adding a new planning file, add its role to Documentation Map and decide whether it is canonical, lane-specific, or a snapshot.

Roadmap Cleanup Rules

1. Do not create another broad roadmap without updating this file.
2. Dated files are logs or audits unless they explicitly say otherwise.
3. Generated data remains the authority for counts.
4. GitHub remains the authority for execution state.
5. User-facing claims must be backed by receipts, generated data, or an explicit planned/refused status.
6. If a planning note is no longer current, either archive it or add a short status note at the top.

Near-Term Cleanup Still Worth Doing