# How The Platform Works — Talking Points > **Companion to:** `how-the-platform-works-marp.md` (11 main + Appendix TOC + 8 appendix = 20 slides) > **Content source:** `how-the-platform-works.md` (full source of truth with speaker notes) > **Purpose:** Presenter-ready cues — 3-6 talking points per slide + the one key takeaway the audience should remember. > **Audience:** Senior Leadership — CTO, Head of Cloud, Head of Infrastructure, Head of DevOps --- ## Slide 1 — Title **Talking points:** - Brief introduction — this deck explains *how* the platform works internally, not the developer experience (that's the companion deck) - Set the frame: the platform is not a CI/CD tool — it's the organizational lever for shipping safely at the pace the business demands - Every "Testing" claim is Verified — 22/22 capabilities via the v1.11 lifecycle pipeline (see A8) **Key takeaway:** The platform is the organizational lever for safe, fast shipping. --- ## Slide 2 — Four frictions slow every team **Talking points:** - Open with the cost of the status quo — every team running its own pipeline, Terraform, and review checklist pays a tax that doesn't differentiate the business - The four frictions are categorically parallel: cognitive load, operational work, red tape, scalability - The platform absorbs all four — that is the value proposition in one sentence - Don't dwell here; this is the setup for the before/after contrast on the next slide **Key takeaway:** Four frictions slow every team. The platform absorbs all four. --- ## Slide 3 — The platform at a glance **Talking points:** - One-slide map of the whole platform — use it to orient the audience before diving into any single component - The leadership-relevant beats: (1) two surfaces, one pipeline, one evidence stream — the convergence is the design; (2) the pipeline stages are fixed and identical for every consumer; (3) the engine adapter is the only engine-specific code, which makes the catalog and confidence model portable - Don't walk every node — point to the boundaries and say "the rest of this deck zooms into each of these" - The contract schema is the boundary between upstream and Nova; everything left of it is the consumer's, everything right of it is the platform's **Key takeaway:** Two surfaces, one pipeline, one evidence stream. The rest of the deck zooms in. --- ## Slide 4 — Declare intent; the platform delivers safe production **Talking points:** - Land the before/after contrast: today's queue vs. Nova's autonomous flow - The litmus test: if a platform engineer still has to touch a ticket for a dev→qa promotion, we haven't delivered the vision - The North Star is one sentence: "declare intent → safe production deployment" - A non-technical consumer ships by declaring intent — no workflow, no config file, no module **Key takeaway:** Declare intent; the platform delivers safe production — autonomously, with a complete audit trail. --- ## Slide 5 — Nova owns infrastructure, not your app **Talking points:** - The platform is deliberately scoped — it is not trying to be everything - The sovereign boundary: the platform team owns delivery and infrastructure, not the upstream development process - The anti-goals are as important as the goals — they tell leadership what not to expect - Upstream is anything: IDE, agentic SDLC, or vibe coding — Nova doesn't care how the contract was produced **Key takeaway:** Nova is infrastructure only. App build/test/deploy is upstream. --- ## Slide 6 — One YAML file. The platform owns everything else. **Talking points:** - Hold this slide — emphasize the asymmetry. The consumer's surface is intentionally tiny; the platform's surface is large and opinionated - The contract names three things: module, environment, inputs — that's the entire consumer-facing interface to production - The contract shows infrastructure inputs (cpu, memory, desired_count, port) — not a container image. The image is upstream; the platform governs infrastructure - The consumer provides no AWS account, no VPC, no state backend — the platform owns the blast radius **Key takeaway:** One YAML file. The platform owns everything else. --- ## Slide 7 — Same stages, same checks, every deployment **Talking points:** - Walk left to right once — don't dwell on internals; the point is the flow is fixed, opinionated, and identical for every consumer - The two leadership-relevant beats: (1) checks before creation, (2) every stage is evidenced - No team-specific pipelines, no tribal runbooks — the flow is the contract - The confidence signal (Slide 9) is where the "safety is computed" story lands **Key takeaway:** Same stages, same checks, every deployment. No "unchecked" path. --- ## Slide 8 — No long-lived credentials. Blast radius contained. **Talking points:** - This is the slide for the Head of Cloud/Security — the key phrase is "blast radius contained to the consumer's own stack" - Contrast with the common failure mode of shared CI roles that can touch any account resource - OIDC federation: short-lived token per job, no credential stored in the consumer repo or runner secret - ABAC, not role-based: repo identity + resource tags scope every action — a consumer can only touch its own tagged resources - The static-key override exists for edge cases but is rotated daily on platform runners; it is never the default **Key takeaway:** No long-lived credentials. A consumer can only touch its own tagged resources. --- ## Slide 9 — Safety is a measurable signal, not a black box **Talking points:** - This is the bet that separates this platform from "yet another CI/CD tool" — reliance on operator instinct or tenure is not a substitute - The signal is auditable; the thresholds are tunable by Infra & Ops + SRE jointly, and any override is itself a confidence-event in the audit stream - Six weighted inputs: policy, validation, freshness, provenance, history, NFRs — manually tuned, auditable per-input breakdown - If a consumer asks "why 0.62?", the platform answers with a per-input breakdown — not a black box - A single critical finding hard-blocks — critical findings are not averaged away **Key takeaway:** Safety is a measurable, explainable signal — not a black box. --- ## Slide 10 — Every change traceable to a human attestation **Talking points:** - The "lower environments autonomous, higher environments attested" tenet resolves the classic "move fast vs. be safe" false dichotomy - Be honest: the separation-of-duties *mechanism* is designed and the dev path is wired; qa/prod/dr wiring is on the roadmap - The audit trail is a byproduct of deployment, not a project — every production change is traceable to a human attestation - The full regulatory ledger (S3 Object Lock, JWS signatures, daily checkpoints) is planned; what ships today is the outbox + hash chain that makes every event tamper-evident and queryable - RPO = 0 — the evidence write is synchronous; a deployment is not acknowledged until the evidence event is durably recorded **Key takeaway:** Every change is traceable to a human attestation and a tamper-evident evidence event. --- ## Slide 11 — The vision realized **Talking points:** - Close on the strategic frame — the platform is not "a CI/CD tool," it's the organizational lever for shipping safely at the pace the business demands - Velocity without sacrificing safety: speed is in the ergonomics, safety is in the unbypassable gates - Security, observability, compliance as platform defaults — not per-team effort, not post-hoc remediation - A path to the citizen developer: the same safety envelope serves a senior engineer and a non-technical consumer - Invite questions; the companion deck ("The Developer Experience") covers who uses the platform and how fast/safe they ship **Key takeaway:** Ship safely at the pace the business demands, with the security and audit posture the regulators require. --- ## Appendix TOC — Appendix **Talking points:** - These are deep-dive slides for follow-up questions — don't walk them in the main 15-minute talk - Pull them up when an audience member wants detail on a specific topic - The appendix is indexed to match the Marp deck's A1-A8 structure **Key takeaway:** Deep dives available — pull the relevant appendix slide when asked. --- ## A1 — Platform-Managed Environments **Talking points:** - For the Head of Cloud: this is the governance story — the platform team owns the accounts, the network design, the state hygiene - Consumers can't drift into misconfigured state backends or over-permissioned roles because they never touch them - The onboarding prompt matters — first impressions of a platform are made when it fails for the first time - Self-service environment provisioning is planned **Key takeaway:** The consumer never sees raw credentials. The platform owns the blast radius. --- ## A2 — Observability Built In **Talking points:** - The Head of DevOps cares about this — "you don't deploy a service and *then* remember to set up monitoring; the platform does it as part of the deploy" - Uptime monitoring deployed automatically with every stack — separate state, feature flag to disable - The feature flag means teams with existing monitoring (e.g. Datadog) can opt out cleanly - Deeper observability bootstrap (dashboards, runbooks, on-call bindings) is on the roadmap **Key takeaway:** Monitoring is a platform default, not a per-team project. --- ## A3 — Security by Construction **Talking points:** - The phrase to land is "secure by default, not secure by effort" - The selling point is *normalization* — we can add a new security tool without changing the confidence model or the evidence stream - For the Head of Security: tagging standards are enforced, not advisory — a missing `nova:owner` tag fails the check, not a warning - The decommission flow is the counter-argument to "deletion protection makes cleanup impossible" — it's a deliberate, gated, two-approval path **Key takeaway:** Secure by default, not secure by effort. Checks run before infra is created. --- ## A4 — The Road to the North Star **Talking points:** - Be clear with leadership: this is a proposed phasing, not a formally committed plan - The phases are sequenced by dependency, not by calendar — each phase's items are gated on the prior phase's maturity - Phase 1 is now fully Verified (22/22) and torn down to zero-cost — it is no longer aspirational - Invite questions on any phase boundary **Key takeaway:** Proposed phasing, not formally planned. Phase 1 is Verified; Phase 4 is the North Star. --- ## A5 — Testing vs. Planned (Full Inventory) **Talking points:** - Close on honesty — the platform delivers real, verifiable value today: 22/22 auto-verifiable capabilities Verified via the v1.11 lifecycle pipeline - The roadmap is concrete, not aspirational hand-waving — 9 planned items, each with a defined milestone and a clear reason it isn't shipped yet (usually an upstream dependency, not an engineering gap) - Emphasize: 0 consumer adoption today — "Testing" means it works internally and is dev pilot-ready, not that it's released - The lifecycle pipeline defaults to plan-only on every PR; `NOVA_LIFECYCLE_MODE=full` overrides for milestone verification **Key takeaway:** 22/22 Verified today. 9 planned, each with a clear milestone and reason. --- ## A6 — Glossary **Talking points:** - Use this slide as a reference when the audience asks for term definitions - Don't read it aloud — point to it as a takeaway reference - All acronyms used in the deck are defined here **Key takeaway:** Reference slide — don't read aloud. --- ## A7 — Operating Model & Cost **Talking points:** - The headline for the Head of Cloud / Finance: less than one cent over 8 days of active development; zero BAU cloud spend - The lifecycle pipeline defaults to plan-only so the PR-time cost is zero - The pre-mortem is the credibility slide — we already asked "how does this fail?" and the mitigations are structural - The v1.10 decay incident is disclosed honestly, not hidden — that disclosure IS the mitigation **Key takeaway:** Zero BAU cloud cost. Pre-mortemed failure modes with structural mitigations. --- ## A8 — Verified by Construction **Talking points:** - This is the deep-dive slide for the Head of Engineering / Architecture — the two pillars answer "how do you keep the decks honest?" - The adapter is simple enough to reason about (a stateless assembler); the lifecycle pipeline is the automated verification that backs every "Testing" claim - The v1.10 lesson is the negative space: a 918-line adapter with type-specific branches decayed silently because the VERIFY gate was diff-scoped - The ~80-line stateless adapter + the milestone regression gate are the structural fix - The plan-only default (v1.12) means verification runs on every PR at zero cost, with the full apply→destroy gated behind a CI variable override **Key takeaway:** "Verified" is a structural property, not a claim — the stateless adapter + lifecycle pipeline make it so.