Workshop strategy: context, decisions, and handoff

Status: handoff package for the catalog backend session (Codex) to take a fresh, independent pass. Anonymised for the public repo: people appear as roles, prospects appear generically. The maintainer holds a named copy privately.

0. What this is, and what we ask you to take on

Over an extended session, the website session developed the ConfigHub Workshop strategy with the maintainer; you reviewed it and gave sharp, correct feedback (bound claims to evidence; separate demonstrated from proposed; keep hosting apart from pricing). This document packages the whole of that analysis - the plan docs, the decision log behind them, the entry-point and first-value inventory, and the open decisions - so you can take it on.

What to take on. Given the entry-point inventory (section 4) and the open decisions (section 5), take an independent pass and propose: the smallest first delivery for one of the three testable experiences, the concrete build items behind it, and how you would measure the trial. Keep the maintainer's decisions open - catalogue options, do not pick the answer.

Working agreements (both sessions).

• Present options, don't decide. On strategy, positioning, and ladders, catalogue the options with sources; do not consolidate into one framing or pick the rung-1 / marketplace / experience answers for the maintainer.
• Keep three buckets distinct: demonstrated (evidence exists), product gap (to build), commercial hypothesis (to test). Bound every claim to its receipt.
• No personal names in repo files (the no-personal-names gate is live). The cohort is anonymised here; the maintainer holds a named copy off-repo.
• Parallel work: the website session is executing the AICR NVIDIA-catalog mirror (below) in parallel. Coordinate via issue #1757; do not duplicate it.

1. The package (supporting docs, all in this repo)

• workshop-frictionless-entry-plan.md - the umbrella. Config as data; Castle and Moat; the ten ladder framings as options (section 4); the pull-and-make flywheel; section 0a records the review and its demonstrated/gap/hypothesis discipline; section 13 lists the open decisions.
• workshop-stories-entry-mid-keystone.md - the per-band stories: the doctrine's worked examples (the assistant does the easy part, the gate does the safe part), the six personas' success signals, the app proofs, and the three cohort wins, evidence-bounded.
• workshop-ai-api-plan.md - the AI-first API plan: the surface that exists today, the concrete gaps, the static-or-SaaS split, the foundation mapping, the developer's ladder, machine cards, and delivery options.

Held privately by the maintainer, not in the repo (real names and logos): an SLT/VC one-pager, and named copies of the three docs above.

2. The mission and the SLT context

• The mini-pivot (leadership, Sep 1). The product lead's anchor: model weights just come from Hugging Face without anyone choosing it; configuration should work the same way. A hub where you say "I want this kind of system," get the pieces and templates, press a button, and it lands in your own org and sets up your clusters. Supply side: chart maintainers as marketplace participants. Differentiator: everything queryable, so placement is a query.
• The frictionless-entry thread (leadership, Sep 8). The theme was usefulness before friction: an individual will not adopt without an immediate problem solved better than their current tools. The meeting settled a framing (Castle and Moat; the maintainer's Castle = database and control plane, Moat = UI, catalogs, community tools) but did not choose the entry problem. The strongest connecting story was individual-to-team. A co-founder's standing challenge: config is not enough, there has to be code behind it.
• Two doors. The AI-led marketplace is the growth motion (developers, agents); control, governance, and compliance is the enterprise sale (a large bank wants control first; a regulated prospect's agreement stipulates genAI terms). Never lead with AI in a regulated-buyer room. A database company's product-led-growth motion is the model to study for the open door.
• The cohort as first trial. Three real design partners, one per band: a product owner at the entry, a platform-generator maintainer at the compose stage, and a large GPU-fleet operator at the keystone.

3. The decision log (the framing, developed and corrected turn by turn)

Load-bearing points the maintainer confirmed in discussion:

• Config as data is the category. Every format flattens to the same exact Kubernetes objects, in OCI, with a receipt. Never say the noun without the verbs. The four flattening verdicts are the honest boundary (what must stay code is labelled).
• ConfigHub is the foundation. Every marketplace verb maps to an existing primitive: fork → derived variant, build → stack + certify, the button → cub fleet up, a listing → a base variant or released OCI, placement → Where / labels / fleet. The new code is small and nameable: the composer, the publish-back loop, the placement-query surface, per-listing JSON.
• The Workshop = catalog + tools + a frictionless doorway into ConfigHub. The doorway is a reward, not a toll; cub server runs ConfigHub locally in about twenty seconds. The gate is a doorway, not a strict filter (gate ≠ certify).
• Independent axes. Data locality (public static vs private per-org), execution locality (local cub / cub server vs hosted SaaS), and entitlement (free vs paid) are separate decisions. Private state does not by itself require paid SaaS.
• MCP is distribution, not foundation. The moat is the corpus and the certify gate, not the protocol. Hyperscaler cluster-MCPs (EKS/GKE/AKS) are a commodity we do not compete on. For a coding-agent user the skill plus cub plus the static catalog is already the interface.
• People make more config with AI, not just pull it. The flywheel: pull, make, keep, publish back. Where they make it - in ConfigHub, as certified data with lineage - is the point; made as loose files it is untrusted code.
• Certification is a scoped claim. Distinguish an advisory local check, a composition-certify verdict proved on named examples, and a revision-bound ConfigHub apply gate. "Nothing runs until certified" is the design intent of that gate, not a property flattening confers.
• Individual-to-team is the strongest story. Not a solo laptop developer: "I got something working; now I want to share it, adapt it for our environment, keep it, and come back to it."
• "This" is the full range (configs, charts, addons, apps, stacks, platforms). Helm is the first evidence-rich case, not the ceiling.
• The SLT decision is one of three testable experiences - adapt for our environment; create and share a working environment; assemble and manage a heterogeneous stack - plus the system size, proven with a measured trial.

4. Entry points and first steps to value (the inventory)

A catalogue of how a user can arrive and get first value, with whether the site supports it today and the gap. It is not a choice; it is the map behind the first-experience decision.

What is really missing (the pattern across the gaps):

1. The zero-install first-value surface is thin - only rows 1, 2, 11 give value with nothing installed; the frictionless "paste your config, see what it does" moment exists but is not the front door.
2. The individual-to-team share/keep/adapt flow (row 9) has no entry point - the strongest story, with no first-class site experience. Likely the biggest hole.
3. The agent-first loop (row 8) is half-built - the skill answers questions but does not guide install → doorway; no per-listing JSON; no one-line pull.
4. The composer (row 3) and "show a running thing" (row 10) do not exist.

Honest read: the site is strong at inspect-or-pull-a-known-thing and weak at make-something-then-share-and-keep-it-with-my-team - exactly the experience the leadership transcript pointed at.

5. Open decisions (maintainer / SLT only)

• Which experience to prove first, and the system size (adapt / create-and-share / assemble-and-manage; one chart, an app, a stack, a platform).
• Which ladder framing leads (the ten options in umbrella section 4).
• What kind of marketplace (self-certified catalog / many-vendor hub / hybrid).
• MCP (lead with it / distribution-only-later / skip it).
• The composer's free and paid line (open over the public catalog / learns from an org's derivation graph / both).
• The two doors - whether and how to say the AI-led and compliance stories publicly.

6. Shipped since your review (so you are current)

• Site (website session): the home hero explains config-as-data; the Catalog surfaces the trust case; Config gained an on-ramp and progressive disclosure; Stacks folded its two reference sections; Operate's header polished; and every supported format is now discoverable (a Format filter, a Catalog formats-and-patterns panel, and a home Supports strip).
• Plans: the three plan docs merged and were amended for your review feedback (the demonstrated/gap/hypothesis discipline, the three experiences, individual-to-team, "this" as the full range).
• AICR (parallel, in flight): we found that AICR is NVIDIA's own open recipe system (github.com/NVIDIA/aicr, Apache-2.0): 47 components and 119 GPU×cloud×workload overlays. The website session is proving the single-entry ingestion on one overlay, then fanning out cheap agents to mirror the corpus (issue #1757, task in flight). Our catalog already certifies one of NVIDIA's overlays (eks-inference, 130 objects), so the count of 7 scales toward the full corpus by ingestion, not authoring.