Files
acdl/docs/presentations/how-the-platform-works-talking-points.md
T
Jon Chery 4b8577df2e docs(P71): polish leadership decks — action headlines, trim, 6 new diagrams (v1.13)
Polish both leadership decks (how-the-platform-works + the-developer-experience)
across all 4 pipeline layers (source md, marp, html, talking points).

Story-arc restructure (per storytelling best practices):
- Intro ~10% / Body ~80% / Conclusion ~10%; 3-5 body points per deck
- One idea per slide; action headlines replace category names
- Before/after 2-slide sequence (problem -> north star) on platform deck
- Main 10 slides kept; detail pushed to expanded appendix (8 + 7)

Word reduction + natural flow:
- Remove all <em class="story"> transition lines (flow carried by headlines)
- Bullets <= 12 words, 3-4 per main slide (was 5-6)
- Cut parentheticals, sub-clauses, redundant restatements

Design + visuals:
- Larger fonts: body 22 -> 26px, h1 34 -> 40px, h2 26 -> 32px, blockquote 20 -> 24px
- 6 new mermaid diagrams -> PNGs:
  - platform-works-02-frictions (2x2 quadrant)
  - platform-works-03-north-star (before/after)
  - platform-works-07-zero-trust (OIDC + ABAC flow)
  - developer-experience-05-catalog (primitives -> modules)
  - developer-experience-07-decommission (6-node gate flow)
  - developer-experience-08-semver (floating/pinned/major timeline)
- At most 1 diagram per main slide; no diagrams on title/conclusion
- High contrast preserved, no animations, maturity badges intact

Verify:
- Marp renders both decks clean (HTML re-rendered, committed)
- Talking-points sections == Marp slide count per deck
- No stale "deploy-unverified" claims (only closed-status disclosure)
- 522 tests pass (no code touched; only docs/presentations/ files changed)
- 22/22 Verified framing preserved verbatim from v1.12

---ci---
project: acdl
phase: 71
milestone: v1.13
status: complete
---/ci---
2026-07-29 14:43:29 +00:00

236 lines
12 KiB
Markdown

# How The Platform Works — Talking Points
> **Companion to:** `how-the-platform-works-marp.md` (10 main + 8 appendix = 18 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 — Declare intent; the platform delivers safe production
**Talking points:**
- Land the before/after contrast: today's queue vs. ACDL'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 4 — ACDL 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 — ACDL doesn't care how the contract was produced
**Key takeaway:** ACDL is infrastructure only. App build/test/deploy is upstream.
---
## Slide 5 — 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 6 — 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 8) is where the "safety is computed" story lands
**Key takeaway:** Same stages, same checks, every deployment. No "unchecked" path.
---
## Slide 7 — 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 8 — 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 9 — 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 10 — 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 `acdl: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; `ACDL_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.