Composition Recipes

Five workflows that chain platform services into real outcomes. Each recipe = one demo video, one blog post, one Show HN moment. Runnable end-to-end via platform-ctl recipe run <name> or via the Portal UI.

The platform isn’t its components — it’s the workflows that chain components into outcomes a user cares about. The recipes here are the public proof that Abukix Studio is one product, not a stack of disjoint services. Each one chains basecamp tiers (lakehouse, ML, LLM, agents) into a result a visitor can watch happen end-to-end, runnable via platform-ctl recipe run <name> or the Portal UI.

The five recipes deliberately span the program’s data + ML + agent surface so that no single tier dominates: Recipe 4 (Homelab life API) is the data-tier showcase; Recipes 1 and 3 (Personal RAG, train→deploy) are the ML/LLM showcase; Recipes 2 and 5 (Auto-incident triage, AI on-call) are the agent showcase. Together they prove the platform is whole.

The cadence matters too: Recipe 4 lands first in Year 3 once the data tier is operational. Recipes 1 and 3 land in Year 4 once the ML/LLM tiers are alive. Recipes 2 and 5 land in Year 5 when agents come online. By the Studio launch in Y5 P29, all five are runnable; by Y5 P30 the mlship v2 capstone demo video centers on Recipe 3.

Recipes are demos, not features

The recipes do not introduce new platform capabilities — every component they chain already exists in basecamp from prior phases. Their job is narrative: making it obvious that the platform’s parts compose into outcomes. If a recipe needs new code in Y5 P29, it’s not a recipe — it’s a service. Cut it, ship the service first, then return to the recipe.

---

Recipe 1: Personal RAG over your weekly logs

The moment: “What was I stuck on in March 2027?” → useful answer from your own homelab.

Lands: Year 4 Phase 24

Services chained:

JupyterHub                    →  notebook (chunk + embed weekly logs)
  ↓ Spark + sentence-transformers
pgvector (Tier 7)             ←  embeddings stored
  ↓
llm-gateway v1 (Tier 7)       ←  RAG endpoint: query → retrieve top-5 → vLLM
  ↓ streaming SSE
notes-rag UI (Tier 9)         ←  small Go HTTP server with htmx
  ↓
Portal command palette (Y5 P29)         ←  same llm-gateway endpoint

Runnable: basecamp/examples/recipe-personal-rag/

Why it matters: the homelab as your second brain. Five years of weekly logs from ops-handbook = 250+ entries; querying them via your own infrastructure is a cinematic moment that no portfolio piece can match.

---

Recipe 2: Auto-incident triage loop

The moment: alert fires at 2am → AIOps gives you a 75%-helpful first hypothesis instead of a blank Grafana dashboard.

Lands: Year 5 Phase 28

Services chained:

Prometheus AlertManager       →  webhook on alert
  ↓
services/aiops/ (Tier 9)
  ↓ via basecamp-mcp:
       query_trino   — "what services alerted in last hour?"
       read_logs     — "tail of triage's logs around alert time"
       list_services — "what changed? recent deploys?"
       vector_search_postmortems — "similar past incidents?"
  ↓
llm-gateway v1.5 (Tier 7)     ←  reasoning step
  ↓
notify_slack                  →  "Hypothesis: X. Suggested first action: Y. Confidence: 75%."
  ↓ if AI-executable runbook + confidence > threshold:
runbook executor              →  step 1 (read-only OK; destructive needs human)

Runnable: basecamp/examples/recipe-incident-triage/

Why it matters: the operational loop closes — agents you built, running on the platform you built, helping you operate that same platform. The vector search step uses the postmortems accumulated in ops-handbook, and the read_logs step pulls from triage — the recipe is the program’s compounding made visible.

---

Recipe 3: Train → register → deploy in one flow

The moment: platform-ctl recipe run train-deploy → 30 minutes later, a new model is canary-deploying with eval-gated promotion.

Lands: Year 4 Phase 23

Services chained:

JupyterHub                    →  notebook starts the workflow
  ↓
KFP pipeline (Tier 6)         ←  compiles to Argo Workflow
  ↓ steps:
       1. Extract — Iceberg + Feast (PIT-correct features)
       2. Train  — Ray-distributed (sklearn or PyTorch)
       3. Eval   — gate on threshold; abort otherwise
       4. Register — MLflow as Staging
       5. Deploy — mlship v0/v0.5 to KServe canary 90/10
       6. Drift  — wire KS-test for auto-rollback

Runnable: basecamp/examples/recipe-train-deploy/

Why it matters: the full ML lifecycle as one declarative pipeline. Reproducible, observable, reversible — the contract every senior ML platform team wants. This is the recipe most likely to appear in the mlship v2 capstone demo video.

---

Recipe 4: Homelab life API

The moment: GET /v1/commits-per-language?start=2026-01&end=2027-12 → answer from your own platform, end-to-end.

Lands: Year 3 Phases 15-18 (incrementally; full by P18)

Services chained:

GitHub webhook                →  events
  ↓
Redpanda topic (Tier 4)       ←  stream side
  ↓ Flink (parse, enrich)
Iceberg abukix.commits (Tier 3)  ← stream-side write

GitHub Events API             →  batch backfill
  ↓
Airflow DAG (Tier 4)          ←  Spark transformation
  ↓ MERGE INTO Iceberg
Iceberg abukix.commits (Tier 3)  ← batch-side write (converges with stream)

  ↓ dbt models
abukix.commits_per_repo_per_day, etc. (Iceberg materialized views)
  ↓ Trino (Tier 8)
personal-api Go service       ←  REST endpoints with Redis cache
  ↓
Portal (Y5 P29)               ←  surfaces in command palette + dashboards

Runnable: basecamp/examples/recipe-life-api/

Why it matters: the platform serves you with content (your own data) before it serves anyone else. Lambda-or-Kappa architectural choice made concrete; full data engineering depth on display.

---

Recipe 5: AI-assisted on-call

The moment: PagerDuty wakes you up → you open the Studio command palette → “what’s wrong?” → triage hypothesis + suggested runbook + recent similar postmortems.

Lands: Year 5 Phase 28-29 (P28 builds the loop; P29 surfaces it in Studio)

Services chained:

Studio command palette (Portal)         →  natural-language query
  ↓
query-helper agent (Tier 9)
  ↓ via basecamp-mcp:
       triage.list_open_incidents — current open-pages
       services/aiops/.get_hypothesis — for the most-recent alert
       postmortems.search — similar past incidents (vector search)
       runbooks.list_executable — what's auto-runnable?
  ↓
llm-gateway v1.5 (Tier 7)     ←  synthesize
  ↓ streaming
Portal command palette UI               ←  user reads, decides next step

Optional next step: user clicks “execute runbook” in command palette → triggers services/aiops/ runbook executor with approval gate.

Runnable: basecamp/examples/recipe-ai-oncall/

Why it matters: the highest-stakes moment of operating a platform (3am page) is where AIOps + Studio + command palette converge. Demonstrates that the platform isn’t 30 disjoint services — it’s one product with a coherent on-call experience. The triage.list_open_incidents call is a direct integration with the triage service shipped in Year 1; the postmortems.search is over ops-handbook content.

---

How recipes are documented

Each recipe lives at basecamp/examples/recipe-{name}/ with:

recipe-{name}/
├── README.md           ← this recipe's page (the content above + screenshots)
├── pipeline.yaml       ← if Kubeflow Pipeline involved
├── values.yaml         ← Helm overrides if recipe deploys components
├── notebook.ipynb      ← if the recipe starts in a notebook
├── demo-video-link.md  ← link to the demo video on YouTube/Loom
└── blog-post-link.md   ← link to the blog post on abukix.dev/blog

The Studio Portal surfaces them at studio.abukix.dev/recipes/{name}. The hosted demo runs sandboxed versions visitors can try.

---

Recipe priorities for Y5 launch

By the Abukix Studio launch (Y5 P29), all 5 recipes must be runnable. But for the Y5 P30 capstone launch (mlship v2), the recipe most likely to be in the Show HN demo video is Recipe 3 (train → register → deploy) — because it’s where mlship shines.

Plan the demo video script around recipes 3 + 1 + 5 — the trio that shows training, querying, and operating an AI platform in 5 minutes.

Three recipes, not five, in the launch demo

The Y5 P30 demo video should pick three recipes (3 + 1 + 5) and tell one story across them: a model gets trained and deployed (3), a knowledge worker queries it via natural language (1), and an on-call engineer uses the same surface to triage an incident (5). All five recipes still need to be runnable at launch, but the cinematic narrative is sharper with three.

---

Anti-patterns

Anti-pattern	Why
10 recipes when 5 deliver	Each recipe is a video + blog + maintenance burden
Recipes that don’t actually run end-to-end	The whole point is they’re real
Shoehorning every service into every recipe	Recipes should chain only what naturally belongs together
Recipe README without a demo video link	Cinematic content was the brand promise

---

Cross-references

• Phase docs: Y3 P15-18, Y4 P23-24, Y5 P28-29
• Studio PLAN
• basecamp PLAN
• platform-ctl PLAN
• mlship PLAN
• triage PLAN
• ops-handbook PLAN
• Brand context: Abukix Studio identity
• Master plan context: Master Plan — composition recipes