# 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 ACDL; 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. 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 5 — 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 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 `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.