ConfigHub Workshop: a frictionless entry for individual developers

Status: consolidated draft for the maintainer. Supersedes and absorbs the config-as-data draft. Anonymised for the public repo: people appear as roles, prospects appear generically.

How to read it. Section 0a records a review of this plan and the discipline it asks for: keep demonstrated capabilities, product gaps, and commercial hypotheses distinct, and keep this proposed direction distinct from agreed decisions. Sections 1 to 3 and 7 to 10 state what has been developed and confirmed in discussion. Section 4 lists the ladder framings we have looked at, as options, on their own terms; it does not choose among them. Section 13 lists the open decisions with their options. Choosing is the maintainer's.

Companion documents. This plan is the umbrella; two companions carry the detail it summarises.

• workshop-stories-entry-mid-keystone.md: the stories behind each band, told in full and anonymised. 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 real wins, each mapped to its band and to the ladder options it exemplifies. Section 10 here is its summary.
• workshop-ai-api-plan.md: the API for AI use cases. The premise that the user is AI-first, the nine things an agent needs to do, the surface that exists today, the concrete gaps, the static-or-SaaS split, the foundation mapping, the flywheel, the developer's ladder in full, machine cards, and the delivery options with a proposed sequence. Sections 6 and 9 here are its summary.

0. The plan in one paragraph

The leadership team is exploring a frictionless entry point for individual developers, to reduce sales friction and expand the user funnel. ConfigHub Workshop is that entry point. It is the Moat around the ConfigHub Castle: a catalog to pull certified configuration from, tools to make and check your own with your AI, and a frictionless doorway into ConfigHub itself, where what you made is kept, placed, and governed. Its position is config as data. Its growth engine is a flywheel in which people pull, make, keep, and publish back. How the climb through it is drawn has been proposed several ways over the months; this plan lists those framings for decision.

0a. The review, and what it sharpened

A review of these documents (a second engineering session, and the fuller transcript of the leadership meeting on 8 September) validated the direction and asked for one discipline throughout: distinguish what is demonstrated from what is a product gap from what is a commercial hypothesis, and distinguish this proposed direction from agreed decisions. Nothing here is an agreed decision unless it is marked as one. The leadership meeting settled a framing (Castle and Moat, usefulness before friction); it did not choose the entry problem.

Demonstrated today, gap, or hypothesis. Read every capability in this plan through this lens.

The entry is not chosen. The transcript's repeated conclusion was usefulness before friction: an individual will not adopt ConfigHub without an immediate problem it solves better than their current tools. It did not pick the Catalog, or chart inspection, as that problem. Kubernetes is an implementation detail, not necessarily the user's starting requirement.

The strongest connecting story is individual-to-team. Not a solo developer on a laptop, but a person inside a team: "I got something working; now I want to share it, adapt it for our environment, keep it, and come back to it." The concrete win named in the room was showing someone an already-running tool rather than asking them to install one. The individual-to-team transition, and the production concerns it drags in (permissions, monitoring, resources, CRDs), deserve more prominence than a solo-laptop framing.

"This" is the full range. Configs, charts, addons, apps, stacks, and platforms, not just Helm charts. The entry question is "find or help me build the right configuration or system for my goal; show me what it contains, what it needs, what has been checked, and what remains uncertain." Helm is an evidence-rich first case, not the product's ceiling, and the common machine interface should be designed for the whole range.

Three testable experiences frame the decision. The review proposes choosing the first user problem and system size to prove from three candidates, keeping all three in the vision:

1. Adapt something for our environment - take a working configuration or system and make it fit here.
2. Create and share a working environment - stand something up and let a teammate see and reuse it.
3. Assemble and manage a heterogeneous stack - compose several parts and operate them together.

Choose one to demonstrate with real users, from first request through a useful, retained result, and measure whether they reach a useful decision and whether keeping it in ConfigHub solves their next problem. Section 13 carries this as an open decision.

Workshop is a path into the core, not the platform. The Castle is a narrow ConfigHub core (the database and control plane) with catalogs, tools, examples, and a possibly pluggable UI around it. The Workshop demonstrates a useful path into that core; it does not try to become the whole platform product.

Hosting and pricing are separate from governance. Authenticated governance can run locally (cub server) or in a hosted service; its value does not inherently require SaaS. Keep deployment (hosted or self-hosted) and entitlement (free or paid) independent of the read/action boundary.

1. Why now: the leadership thread and the mission

The leadership meeting on Sep 8 explored "creating a frictionless entry point for individual developers to reduce sales friction and expand the user funnel." Four things from that discussion shape this plan.

• The co-founder's test. Non-enterprise users will not adopt ConfigHub "without a clear, immediate problem-solving use case." Whatever the first rung is, it has to solve a real, frequent problem before anything is asked of the user. Which problem that is remains a decision (section 13).
• Castle and Moat. The maintainer defined the Castle as the database and control plane, and the Moat as the UI, the catalogs, and the community-facing tools. In this plan: the Castle is ConfigHub itself; the Moat is the Workshop. The moat leads to the castle gate.
• A second candidate entry. The product lead proposed that ConfigHub could give developers visibility into local and cloud-hosted dev environments for shared debugging. This is a different immediate problem from the configuration catalog, and it is listed as an option in section 4.
• The keystone confirmed. Heterogeneous deployments and complex GPU-based stacks were named as the areas of highest enterprise frustration and opportunity.

Two market signals from the same meeting: a database company's enterprise product-led-growth strategy, which prefers frictionless trials to sales cycles, is the model to study (with the open question of which frictionless strategies do not depend on open source); and a compliance-tooling partner reported that compliance, not AI, is the primary enterprise driver for combining their tool with ConfigHub at a GPU vendor.

The leadership meeting on Sep 1 set the mission the entry point serves. The product lead's anchor: model weights just come from Hugging Face without anyone choosing it, and configuration should work the same way. Runnable systems, not weights. 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, with everything flowing from the catalog. Its supply side is chart maintainers as marketplace participants. Its technical differentiator is that everything is queryable, so placement is a query: put this here because this cluster has the right GPU.

Hugging Face's hub grew because people made things on it: pull a base, fine-tune it, push the derivative back. So the mission has two halves in one flywheel: people pull certified systems from ConfigHub, and people, with their AI, make new configs, apps, addons, and stacks on ConfigHub, so what they make is data, certified, traceable, and pullable by the next person. The name already says it. ConfigHub Workshop: the hub you pull from, the workshop you make in.

Two doors, one product. The same meeting notes record that a large bank wants control adherence and change management ahead of aggressive AI adoption, so the team will lead there with a general product introduction rather than an AI pitch; and that a regulated prospect's agreement now carries stipulations on generative AI in delivery. Meanwhile the mission is AI-led. These reconcile because the doors differ. The AI-led marketplace is the Moat's growth motion, for developers and their agents. The Castle sells control, governance, and compliance, to regulated buyers. The plan says this out loud so the AI story never leads in a regulated-buyer room.

2. The position: config as data

Every format the Workshop takes in (Helm, AICR, Kubara, Timoni, plain YAML, OCI) flattens into one shape: the exact Kubernetes objects, as data, carried in OCI with a receipt. The source is a producer. The output is data. "Config as data" names that and makes it a category.

• It counter-positions Infrastructure-as-Code. IaC made infrastructure programmable, and opaque: you cannot query a template, diff it, or know what it does without running it. Data you can. IaC made infrastructure programmable. Config as data makes it provable.
• It restores what Kubernetes intended. The Kubernetes API is declarative data. Templating and patching turned it back into code. The Workshop flattens it back to data, now with provenance, variants, and certification.
• It completes the Hugging Face analogy. Hugging Face is models as data. Config as data is the same move for systems.

The rule: never the noun without the verbs. "Config as data" alone is a data lake. "Config as data, so you can certify, place, and govern it" is a product.

The honest boundary makes it credible. The four flattening verdicts are a config-as-data maturity scale, and the Workshop says where config must stay code.

3. Castle and Moat: what the Workshop is

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.

   THE MOAT: ConfigHub Workshop (open, free, no account)
   ┌──────────────────────────────────────────────────────────┐
   │   CATALOG            TOOLS                DOORWAY        │        THE CASTLE
   │   pull certified  →  make and check   →   walk into   ───┼─→     ConfigHub itself
   │   config-as-data     with cub:            ConfigHub       │       the database and
   │                      compose, vary,       cub server,     │       control plane:
   │                      render, publish,     upload,         │       custody, variants,
   │                      certify              your org        │       placement, govern
   └──────────────────────────────────────────────────────────┘

Catalog. The open store of certified config-as-data: exact objects in OCI with a verdict and a receipt, 139 retained package versions across 112 components today. Where you pull from. Free, no account, crawl-free for agents.

Tools. The cub workshop plugin: check, compose, vary, render, publish, verify, certify. Where you make things, with your AI. Free, local, no account. Certify lives here; it is a check you run, and you can run it all day without touching ConfigHub. The AI composer lives here too.

Doorway. The on-ramp into ConfigHub itself. A ramp, not a wall, whose first step needs no account: cub server runs ConfigHub locally in about twenty seconds (the product lead's framing: like GitHub and the gh CLI, a stepping stone); cub variant upload and cub stack upload move what you made into a Space in your org; the org is where it becomes shared, placed, and governed. The design goal at the doorway is frictionless entry, not strictness. Upload runs certify first as a safety behaviour, but that is what upload does, not what the doorway is.

The Castle. ConfigHub itself: the database and the engine over config-as-data (section 7).

4. The ladder: the options we have looked at

Over the months the climb has been drawn several ways. This section lists them as options, each on its own terms, with its source, what it optimises for, and what it leaves out. It does not pick one. Which framing leads, and whether several combine, is the maintainer's decision (section 13).

Option 1. The verb ladder, on the spine. Source: docs/planning/ladder-on-spine.md, docs/planning/cub-noun-vocabulary.md. Rungs: free check and deploy; account upload, release, promote; paid govern; with stack certify and sandbox as the composition rung. The finding that produced it: the site jumped from check to promote and skipped the middle; upload and release had no first-class page. Optimises for: one cub verb per commercial tier; the site's spine; "read it as a ladder." Leaves out: who the user is and how they arrive.

Option 2. The adoption bands: entry, spine, keystone. Source: docs/planning/demand-to-verbs.md; the website ladder review of Sep 1. Rungs: entry (the three questions: I need a configuration; I have one, is it right; I have an accepted one, can I promote it), spine (mid), keystone (the platform; Kubara). The funnel is measured: of forty sampled demand questions, nineteen are answered at the entry, fourteen on the spine, seven at the keystone. The build order follows the counts: cub check and cub app first, cub stack as the altitude jump. Optimises for: demand-driven build order; personas mapped to bands. Leaves out: a single user's step-by-step path.

Option 3. The product lead's funnel. Source: product and leadership discussions, late August. Rungs: free, account, paid. "Check my config" as the primary call to action. cub server as the stepping stone into the account path, "like GitHub and the gh CLI," a twenty-second exercise to run ConfigHub locally. Optimises for: conversion at the front door; the individual-to-org transition. Leaves out: what happens above the account.

Option 4. The marketplace ladder: the mini-pivot. Source: leadership meeting Sep 1. Rungs: go to the hub; say "I want this kind of system"; get the pieces, templates, and scaffolding; press a button; it lands in your own org and sets up around ten clusters; everything flows from the catalog. A supply side where chart maintainers participate: push a chart, do the steps, and it is ready for the people building AI systems. Differentiator: everything queryable, so placement is a query. Optimises for: the destination state and the vision; a hub that grows. Leaves out or leaves open: the co-founder's "config is not enough, there has to be code behind it"; what kind of marketplace (section 13). Three of its five parts exist today: the variant is the listing, the stack manifest is the system template, cub fleet up is the button.

Option 5. The Workshop columns. Source: this week's discussion with the maintainer. Rungs, as columns: catalog, tools, frictionless doorway, then the Castle (section 3). Optimises for: the structure of the open product and the boundary to the paid one; the Castle and Moat framing. Leaves out: it is a product architecture, not one user's journey.

Option 6. The developer's agent rungs. Source: the maintainer, this week. The developer is a persona: someone who uses Claude Code all day and starts from zero. Rungs: hit a public API (nothing installed); use a skill to make cub and ConfigHub calls; this encourages or eventually requires installing cub and the workshop plugin; then the doorway; then make and publish. Progressive disclosure with a win at every rung, from inside the agent. Optimises for: the agent-first individual developer's first touch. Depends on: per-listing JSON at predictable URLs (today there is none, only the monolithic record set); a ladder-aware skill (today's skill covers the four tasks but does not route zero-install first, offer the one-line install, or teach the doorway). Leaves out: agents without a shell.

Option 7. The flywheel: pull, make, keep, publish back. Source: this week; Hugging Face's pull, fine-tune, push_to_hub. Shape: a loop rather than a ladder. Pull a certified system; make a derivative with your AI (fork is a variant, addon is a component, a new stack is a manifest); walk it through the door; publish it back as a listing. Optimises for: the growth mechanism; creation as the lever; derivatives compounding the data. Leaves out: a single user's ordered steps.

Option 8. The scale ladder: individual, team, fleet. Source: recurring across discussions. Rungs: individual (free), team (account), fleet (paid). Optimises for: the org-scale reading of the commercial tiers. Leaves out: the product steps inside each scale.

Option 9. The website ladder. Source: the website ladder review of Sep 1. Rungs tied to where they live on the site. Entry: see what a chart installs in the browser with no login (Check my config); certify and render a whole platform for free (the ladder terminal, cub stack sandbox). Mid: land CI-rendered YAML as governed data (the CI-rendered catalog journey); promote through an approval gate that refuses first (the operator ladder). Keystone: build a platform and run apps through it (Kubara, recorded live); speak a platform as one certified stack (the stack manifest spec and receipts); generate and read a governed fleet from manifests (starting question six). Optimises for: the site delivering each rung with a page. Leaves out: anything not on the site.

Option 10. The dev-environment visibility entry. Source: leadership meeting Sep 8, the product lead. Shape: a different first rung. ConfigHub gives developers visibility into local and cloud-hosted dev environments, to make shared debugging possible. Optimises for: an immediate individual-developer problem, in the sense of the co-founder's test, that is not tied to the configuration catalog. Leaves out or leaves open: a different first user and product surface; not built; its relationship to the catalog entry.

How they relate, descriptively. Options 1, 3, and 8 all use the free, account, paid tiers. Options 2 and 9 both use entry, spine (mid), keystone. Options 5 and 6 are this week's product-shape and agent-first views. Option 7 is a loop rather than a line. Options 4 and 10 are both the product lead's: one the destination, one an alternative first step. None of this settles which leads.

5. The supply side, as it follows from the marketplace option

If the marketplace framing (option 4) leads, the demand climb ends by feeding a supply climb. This is an elaboration for the maintainer to accept, adjust, or drop.

The product lead's phrase, "push your chart and it becomes ready for the people building AI systems," would then be one workflow file. Certification would be the value offered to a vendor.

6. The developer's first touch: the agent-first view

The developer here is a persona, not a person: someone at work who uses Claude Code all day, starting from zero with a real question. This is an individual working within a team, not a solo developer on a laptop, and the strongest version of the story is the individual-to-team transition (section 0a): "I got something working; now I want to share it, adapt it for our environment, keep it, and come back to it." The rungs below are the agent-first path from that first working result toward sharing it, and they drag in the production concerns a team brings, permissions, monitoring, resources, and CRDs, as the reason to keep the result in ConfigHub. From inside Claude Code they reach everything ConfigHub can do, one win per rung. Mapped to the Workshop columns (option 5):

Principles that came up in shaping this view, for the maintainer to keep or change: the question determines the rung and the skill routes; every rung delivers a win before the ask; when the catalog has no entry, "render it locally" is the on-ramp to the tools (the machine contract already says so); private input stays local until the user chooses to upload, and then only into their own org; the doorway is a reward rather than a toll; instrument every rung.

The shipped skill (v0.1.1) covers the four tasks, resolving through the records, materialize and compare and check, the reviewed result, and CI. It does not yet route zero-install first, offer the one-line install of cub and the plugin as the escalation, teach the doorway or the ConfigHub verbs, or carry a rung structure.

7. The engine: the code behind it (the Castle)

The co-founder's standing objection: config is not enough, there has to be code behind it. As a critique of "config as data," it lands. Data alone is inert.

The resolution is the database. Nobody won on "your data, stored." They won on the engine, and the engine was only possible because the data had a schema. Config as data is the schema. ConfigHub is the database and the engine. None of these verbs can be written over code; every one needs the data form first.

Five of six exist. The composer, with the publish-back loop, is the new engine, the one that makes the hub generative, and the one nobody else has, because nobody else has the data form to certify against or the lineage model to publish into.

8. The flywheel: pull, make, keep, publish back

Hugging Face's loop is pull, fine-tune, push_to_hub. Ours, on ConfigHub primitives, is pull, make, walk through the door, publish back. Everything AI makes is an existing primitive; no new objects.

• The hub becomes generative. The catalog grows because users' AIs make derivatives and publish them back, certified by the engine.
• Creation is a growth lever. Pulling curated stacks is bounded. Making a variant or addon for my case is unbounded. Creation is where AI is transformative and where trust breaks; the Workshop sits at that intersection.
• Lineage is the trust feature of AI-made config. Upstream links, digests, and receipts answer where it came from, what changed, and whether it is safe.
• Config as data is what makes AI creation checkable. The AI writes data, which the engine can read and refuse rather than having to run to understand. That is the bounded claim, not a universal guarantee: an advisory local check, a composition-certify verdict proved on specific examples, and a revision-bound ConfigHub apply gate are three distinct things (the API plan, section 7, states each with its scope). "Nothing runs until certified" is the design intent of that apply gate, not a property flattening confers on its own.
• Where AI makes things is the whole point. Made as loose files, AI output is untrusted code with no lineage. Made in ConfigHub, it is data, certified, traceable, governable, publishable.

9. The agent interface and the API

For the segment building AI systems, the agent interface is the product and the human UI is the brochure. The interface is the Workshop's own shape:

• Catalog: static read at predictable URLs, crawl-free, no auth. Per-listing machine cards (what it needs, provides, its verdict, receipt, placement constraints), the canonical digest address, and the machine contract: resolve the exact version, read coverage before citing a verdict, cite the evidence. Largely shipped (llms.txt, catalog.json, base-variant-records.json, the schemas, the skill). Missing: per-listing JSON.
• Tools: the local cub CLI. Coding agents have a shell. Fetching the corpus plus cub stack certify plus cub variant create is the whole loop today.
• Doorway: the org and auth handoff, the protocol boundary.

The one-line pull, the from_pretrained moment for systems, as a candidate hero:

# I want an inference platform with H100s, in my org
cub stack pull confighub/inference-platform@sha256:... --into my-org --where 'gpu=h100 and region=eu'

On MCP, the positions we have looked at are listed in section 13. The considerations: it is how configuration comes to "just come from" us inside the agent toolchain, one-click into Claude, Cursor, and Codex, so for a be-the-default mission the channel matters; the moat is what the tools expose, not the protocol; hyperscaler MCPs will own "operate my cluster," a layer the Workshop does not compete on; for a Claude Code user the skill already distributes the same capability.

10. Proof: the cohort at each band

The first real cohort of three, as the research mapped them onto the entry/spine/keystone framing (option 2) and the Workshop columns (option 5).

The audit line that ties them together: the site jumped from check to promote and skipped the middle; upload and release had no first-class page, the stack rung was a report rather than a step, and there was no inference-shaped spine.

11. A proposed sequence, for decision

The review asks for a narrower first delivery and a measured user trial: choose one of the three experiences (section 0a), demonstrate it with real users from first request through a useful, retained result, and measure whether they reach a useful decision and whether keeping it in ConfigHub solves their next problem. The steps below serve that, with the ones that do not depend on the open decisions first.

1. Ship per-listing JSON at predictable URLs, so an agent can construct the address without crawling. Needed by every option that starts from the catalog.
2. Make the doorway frictionless and measure it. cub server, one-command upload, land in your org. Measure the time from a certified result to the first Space. Needed by options 3, 5, and 6.
3. Choose one experience to prove, and its system size (section 13), then make that first experience real and update the skill to route it. Run it as a measured trial with real users, not a broad build.
4. Instrument the rungs. API hits, skill installs, plugin installs, first certify, first cub server, first upload, first release, first publish back.
5. Prove the chosen first rung on the cohort and on the developer's ladder with fetch and cub, no new server.
6. Distribute into the toolchain in whatever form section 13 decides.
7. Automate the supply side, if the marketplace option leads.
8. Lead the Castle's API with placement as a query. cub place <stack> --where 'gpu=h100' returns the clusters that fit, the plan, and the gaps.
9. Build the composer. A goal into a certified config, app, addon, or stack, born in ConfigHub.

12. What is already proven (for the pitch)

• The catalog: 139 retained package versions across 112 components, each an OCI image of exact objects with a receipt; upstream-republish cases caught and recorded.
• Config as data, with its honest boundary: every base carries a flattening verdict; the four lanes and their counts are published.
• Certify: real stacks certified and refused with reasons. eks-inference certified at 130 objects across eight bundles; metrics-double refused for nine objects claimed twice. A full inference platform sandboxed for free.
• The Castle: variants with upstream links, promotion, release by digest, rollback across two clusters, placement over the fleet graph.
• The doorway: cub server running ConfigHub locally in about twenty seconds; cub stack upload landing a certified stack as Spaces and links.
• The cohort: three real roles at the three bands, each with a recorded win.
• The machine surface: llms.txt, the JSON records and schemas, a published agent skill.

13. Open decisions, with their options

Which ladder framing leads, and which combine. The ten options in section 4.

The first experience to prove, and the system size (the co-founder's usefulness-before-friction test; see section 0a). The review frames this as three testable experiences, all kept in the vision, one chosen to demonstrate with real users end to end and measure:

• (i) adapt something for our environment - make a working configuration or system fit here;
• (ii) create and share a working environment - stand something up and let a teammate see and reuse it (the concrete win: show an already-running tool rather than ask someone to install one);
• (iii) assemble and manage a heterogeneous stack - compose several parts and operate them together.

The system size is a paired decision: one chart, an existing application, a stack, or a whole platform. "This" spans that whole range; Helm is an evidence-rich first case, not the ceiling.

Earlier candidate framings of the first problem, still on the table and each mappable into one of the three experiences: the most-asked configuration question, "what will this install, and what must already exist?", answered in one fetch with nothing installed; the product lead's dev-environment visibility for shared debugging (option 10, an instance of experience ii); "is my configuration right?" and "why did Helm ignore my values?", the browser check with the user's own chart and values; and certify and render a whole platform for free with cub stack sandbox (an instance of experience iii).

What kind of marketplace. Options:

• (a) the catalog we certify ourselves, as today;
• (b) a public hub of certified systems from many vendors, with curation, liability, and trust to design;
• (c) a hybrid: vendor-published, ConfigHub-certified.

The leadership vision leans to (b) or (c); what exists is (a). This is the "more meat" the pitch has been asked for.

MCP. Options:

• (a) lead with an MCP server as the agent interface;
• (b) treat it as distribution only, built later to expose catalog, tools, and doorway, local for the free path and org-scoped for the SaaS path;
• (c) skip it; the skill plus cub plus the static catalog is the interface.

The composer's free and paid line. Options: an open composer over the public catalog; a composer that learns from an org's derivation graph as the Castle's edge; both, split by data source.

The two doors, held deliberately. The AI-led story as the Moat's growth motion; control, change management, and compliance as the Castle's sale to regulated buyers, one of whose agreements now constrains generative AI in delivery. Whether and how to say this publicly.

Timing. Autonomous agents composing whole systems is early. The hedge on the table: the same surface serves human-driven agents today and autonomous ones later, built once.

"There has to be code behind it." The answer on the table: the engine over config-as-data, five of six parts built; the composer and the publish-back loop are the new code.

14. The line

Config as data, open. The Workshop is the moat: a catalog to pull from, tools to make with, and a frictionless doorway into the ConfigHub castle, where what you made with your AI is kept, placed, and governed. Configuration comes from ConfigHub because it is made in the Workshop and walks through the door.