Phase 12 — Leadership & the Capstone Platform
Difficulty: ⭐⭐⭐⭐⭐ | Estimated Time: 2 weeks Roles supported: Head of Engineering [GPU] (the whole role) Hardware needed: none — the capstone composes the prior phases' CPU-runnable components
Why This Phase Exists
The JD is a leadership role: "Lead the development of a standalone orchestration platform," "build and scale a developer-focused platform," "drive integrations with OEMs," "own platform adoption and commercialisation," and "stay hands-on where needed — maintaining technical credibility." Phases 01–11 built the technical depth and the hands-on artifacts. This phase does two things:
- Leadership practice — the non-code judgment a Head of Engineering is paid for: technical strategy, org design, OEM/partner engineering, build-vs-buy, the release/quality bar, and the executive-and-customer communication the JD demands.
- The capstone — compose the prior phases into one mini GPU orchestration platform: a HAL (Phase 09) under a scheduler (Phase 06), serving a model with KV-cache management (Phase 07), behind a licensed (Phase 11), observable (Phase 10) control plane — with a design doc and the release-cycle artifacts (Phase 10) that make it a product, not a prototype. This is the portfolio piece that proves you can do the job.
Concepts
Leadership
- Technical strategy: writing the platform vision and the decision records (the Phase 09 ADR, generalized); the "decouple from hardware" strategy as an executable roadmap
- Org design for a deep-tech platform team: the skill mix (kernels, runtime, distributed, serving, security, SRE), how to structure it, hiring signals (the interview-prep folder), and the build-vs-buy boundary
- OEM/partner engineering: onboarding a vendor's chip as a HAL backend (Phase 09) as a commercial+technical process; conformance certification as a relationship lever
- The quality bar: the kernel-PR checklist (Phase 02), the runtime contract (Phase 05), the conformance suite (Phase 09), the release gates (Phase 10) — codified as engineering standards you own and defend
- Commercialization: how the technical artifacts (HAL, sovereign security) map to revenue and adoption; pricing tiers tied to isolation/capability (Phase 06)
- Executive + customer communication: explaining roofline economics, the sovereign-AI value prop, and honest security claims (Phase 11) to non-engineers
- Operating model: SLOs/error budgets (Phase 10), incident culture, "failures are the steady state" (Phase 08) as a management philosophy
Capstone integration
- Composing HAL + scheduler + serving + licensing + observability into one control plane
- The platform's internal API contract (the runtime guarantees from Phase 05, the ABI discipline from Phase 09)
- Release-cycle artifacts: design doc, runbook, compatibility matrix, demo, retrospective
The Capstone
Capstone — Mini GPU Orchestration Platform (Python, integrates all phases)
| Field | Value |
|---|---|
| Goal | Build a working mini GPU orchestration platform that composes the prior phases: a capability-routed HAL (Phase 09) under a scheduler (Phase 06) that admits requests, serves a model with paged KV-cache + continuous batching (Phase 07), gated by an offline license (Phase 11), exporting metrics + SLOs (Phase 10) — all behind one control-plane API, with a design doc and release artifacts (Phase 10). |
| Concepts | System integration; the control-plane API; capability routing; admission control; licensing gate; observability; the release cycle. |
| Steps | 1) python platform.py — boots the platform: loads backends, validates the license, advertises capabilities, serves a batch of requests through the scheduler+KV-cache, exports metrics, and prints a status report. 2) Read each subsystem and trace a request end to end against the design doc. 3) Run the included scenarios: license-expired (refuses to serve), capability-routing (FP8 request → capable backend), overload (admission control + goodput), a backend failure (fail over). 4) Write the design doc, runbook, and retrospective. |
| Stack | Python (stdlib) — reuses patterns from Phases 06/07/09/10/11 |
| Output | A running mini platform + DESIGN-DOC.md + RUNBOOK.md + a release/retrospective writeup. |
| How to Test | Built-in scenarios assert: an expired license blocks serving; FP8 work routes to a capable backend (Phase 09); continuous batching beats sequential (Phase 07); admission control protects goodput under overload; a backend marked unhealthy triggers failover; metrics export validly (Phase 10). |
| Talking Points | How the pieces compose; where the abstraction boundaries are; the build-vs-buy decisions; the commercialization story; what you'd do differently at real scale. |
| Resume Bullet | "Built a mini GPU orchestration platform integrating a capability-routed hardware-abstraction layer, request scheduler, paged-KV-cache continuous-batching server, offline licensing, and Prometheus observability behind one control-plane API — with design doc, runbook, and release artifacts." |
| Extensions | Multi-node (Phase 08 collectives) for a TP-sharded model; a TypeScript CLI for the control plane (the JD's JS/TS-for-tooling line); a real backend (CUDA via the HAL) if hardware is available. |
Leadership Artifacts (write these — they're the portfolio)
In leadership/:
PLATFORM-STRATEGY.md— the vision + roadmap: the "decouple from hardware" thesis as an executable 18-month plan with the build-vs-buy boundary (Phase 09 ADR generalized).ORG-DESIGN.md— the team structure, skill mix, and hiring plan for the platform; which roles, what each owns, the build-vs-hire calls.OEM-ONBOARDING.md— the process to onboard a vendor's chip as a certified HAL backend (technical + commercial), using the conformance gate (Phase 09) as the relationship lever.ENGINEERING-STANDARDS.md— the codified quality bar: kernel-PR checklist (Phase 02), runtime contract (Phase 05), ABI discipline (Phase 09), release gates (Phase 10), security claims discipline (Phase 11).
(Templates/rubrics provided in leadership/.)
Deliverables Checklist
- Capstone platform boots and passes all integration scenarios
-
DESIGN-DOC.md— the platform architecture with the abstraction boundaries -
RUNBOOK.md— operational procedures for the platform's failure modes - The four leadership artifacts written
- A retrospective: what you'd do differently at real scale
- You can present the platform end-to-end to (a) an engineer and (b) an executive
Interview Relevance
This phase is the interview for the role.
- "Walk me through a platform you've built." (the capstone)
- "How would you decouple our software from hardware?" (Phase 09 + the strategy doc)
- "How do you structure and hire a GPU platform team?" (org design)
- "How do you onboard an OEM's accelerator?" (OEM doc + conformance)
- "How do you balance shipping fast with production quality?" (error budgets, standards)
- "Sell me the sovereign-AI value proposition." (the commercialization story)
See ../interview-prep/ and ../system-design/ for the full interview surface.