acdl/docs/presentations/how-the-platform-works-talking-points.md

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.