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

# How The Platform Works — Talking Points

> **Companion to:** `how-the-platform-works-marp.md` (10 main + 7 appendix = 17 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 what the developer experience is (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
- The deck has 10 main slides plus a 7-slide appendix for deep-dive questions
- v1.12 re-verification: every "Testing" claim in this deck is now Verified — 22/22 capabilities via the v1.11 lifecycle pipeline (see A7)

**Key takeaway:** This is a platform that computes safety, doesn't assume it.

---

## Slide 2 — The Problem & The North Star

**Talking points:**
- Open with the cost of the status quo — every team running its own pipeline, its own Terraform, its own review checklist is paying a tax that doesn't differentiate the business
- Walk through the 4 frictions quickly: cognitive load, operational work, red tape, scalability. Don't dwell — the North Star is the resolution
- Land the North Star quote: "declare intent → safe production deployment" — this is the entire value proposition in one sentence
- The litmus test: if a platform engineer still has to touch a ticket for a dev→qa promotion, we haven't delivered the vision
- Note: the 2 anti-goals ("not a general-purpose AI" and "not a permissive delivery highway") have moved to slide 3 — they belong with the scope boundary, not the North Star

**Key takeaway:** The platform absorbs all four frictions. Declare intent, not execute operations.

---

## Slide 3 — Where ACDL Sits in Your World

**Talking points:**
- This is the scope-boundary slide — it tells leadership where ACDL fits and, just as importantly, where it doesn't
- Upstream is anything — your IDE, an agentic SDLC, or a citizen developer vibe coding on a laptop. ACDL doesn't care how the contract was produced
- ACDL is infrastructure only — it provisions and governs AWS resources. It does not build, test, or deploy your application code. That's upstream
- Land the 2 anti-goals: "not a general-purpose AI" (autonomy is narrow, scoped to delivery, bounded by strict policy) and "not a permissive delivery highway" (no escape hatches to bypass the confidence framework)
- The sovereign boundary means the platform team owns delivery and infrastructure, not the upstream development process

**Key takeaway:** ACDL is the delivery and infrastructure boundary. Upstream is anything; ACDL is infra only.

---

## Slide 4 — The Contract-Driven Model

**Talking points:**
- Emphasize the asymmetry — the consumer's surface is intentionally tiny (module + environment + inputs), the platform's surface is large and opinionated
- Note: the contract examples now show **infrastructure inputs** (cpu, memory, desired_count, port) — not a container image. The image is upstream; the platform governs infrastructure
- The contract is the API — it's deliberately small so it can be reviewed, validated, and audited
- The consumer does not write infrastructure modules, workflow logic, or adapter code — they declare intent; the platform reconciles, provisions, and progresses
- Land the "no AWS account, no VPC, no state backend" point — the platform owns the blast radius. Consumers can't drift into misconfigured state or over-permissioned roles because they never touch them

**Key takeaway:** A single YAML contract. The platform owns everything else — including the blast radius.

---

## Slide 5 — The End-to-End Flow

**Talking points:**
- Walk the flow left to right once — don't dwell on internals. The point is that the flow is fixed, opinionated, and identical for every consumer
- Land beat 1: security and policy checks run *before* any infrastructure is created — not after the fact, not as a post-deployment audit
- Land beat 2: every stage produces a record that feeds the confidence signal and the evidence stream. There is no "unchecked" path
- Tease the confidence signal (slide 7) — this is where "safety is computed" lands

**Key takeaway:** The same pipeline, every time. Checks before creation, evidence at every stage.

---

## Slide 6 — Zero-Trust by Default

**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: shared CI roles that can touch any account resource. The platform's ABAC model scopes every action to the consumer's own tagged resources
- OIDC means no long-lived credentials in consumer repos — each job mints a short-lived token. Be honest: this is testing on GitHub Actions runners today; all-runner coverage is planned
- The static-key override exists for edge cases but is rotated daily on platform runners — it is never the default

**Key takeaway:** A consumer can only touch the resources it created. One consumer can never affect another.

---

## Slide 7 — Safety is Computed, Not Assumed

**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 for a computed, auditable signal
- The confidence signal diagram makes the six inputs and the per-input breakdown visible — walk it briefly so the audience sees the signal is *not* a black box
- The weights are **manually tuned**, the inputs are **observable**, and the breakdown is **auditable** — if a consumer asks "why 0.62?", the platform answers with a per-input breakdown. This is the "auditable, not magic" point
- Walk the threshold table: dev ≥ 0.50 (autonomous, Testing) → qa ≥ 0.75 (QA, Planned) → prod ≥ 0.90 (SRE, Planned). The bar rises automatically with sensitivity
- A single critical policy finding hard-blocks the deployment — critical findings are not averaged away. This is non-negotiable
- The thresholds are tunable by Infra & Ops + SRE jointly, and any override is itself a confidence-event in the audit stream

**Key takeaway:** Safety is a measurable, explainable signal — manually tuned, observable inputs, auditable breakdown. A single critical finding blocks everything.

---

## Slide 8 — Security by Construction

**Talking points:**
- The phrase to land is "secure by default, not secure by effort" — teams don't opt in to security, it's on by construction
- Policy checks (Checkov, Wiz, Kyverno) are normalized to a single schema — we can add a new security tool without changing the confidence model or the evidence stream
- Tagging standards are enforced, not advisory — a missing `acdl:owner` tag fails the check, it doesn't warn
- Encryption is on every resource with per-stack customer-managed keys — no shared keys across stacks, 90-day rotation
- The decommission flow is the counter-argument to "deletion protection makes cleanup impossible" — it's a deliberate, gated, two-SRE-approval path with CMDB validation, not a lock with no key

**Key takeaway:** Encryption, deletion protection, policy checks — on by default. Decommission is gated, not impossible.

---

## Slide 9 — Accountability & Audit

**Talking points:**
- The "lower environments autonomous, higher environments attested" tenet is the resolution to the classic "move fast vs. be safe" false dichotomy
- The attestation flow diagram shows the human-in-the-loop path — dev autonomous → qa/prod/dr human attestation → evidence event. Walk it briefly
- Land the QA clarification: **QA attests to infrastructure readiness — the contract, the planned Terraform changes, and the accumulated evidence. QA does not review application code (that's upstream).** This is the scope-boundary point reiterated
- Badge reclassification to be clear about: separation of duties = **Planned** (not "design tested"); dev autonomous = **Testing**; qa/prod/dr attestation = **Planned**
- The audit trail is a byproduct of deployment, not a project — every deployment writes a hash-chained evidence event synchronously (RPO = 0)
- Be honest about the ledger: the outbox + hash chain is testing today; the full regulatory ledger (S3 Object Lock, JWS signatures, daily checkpoints) is planned

**Key takeaway:** Dev is autonomous. Higher environments are attested. QA attests to infra readiness, not app code. Every change is evidenced.

---

## 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 (a simple contract, a one-line `uses:`), safety is in the gates the consumer cannot bypass
- Security, observability, and compliance as platform defaults — not per-team effort, not post-hoc remediation
- Auditability as a byproduct, not a project — every production change traceable to a human attestation and a tamper-evident evidence event
- Infrastructure as a utility, not a craft — teams consume, they don't maintain. The platform compounds value over time by learning from recurring patterns
- The path to the citizen developer — the same safety envelope that serves a senior engineer will serve a non-technical consumer. Expanding who can ship safely without lowering the bar

**Key takeaway:** The investment is in the abstraction, not the tool. Ship safely at the pace the business demands, with the security and audit posture the regulators require.

---

## Appendix TOC — Deep Dives

**Talking points:**
- These slides are 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: environments, observability, roadmap, full inventory, glossary, cost, or the v1.11 architecture
- The appendix now has 7 slides (A1–A7), including two new ones: A6 (Operating Model & Cost with real AWS figures + pre-mortem) and A7 (Verified by Construction — the v1.11 architecture)
- The appendix exists so the main deck stays tight while still having answers ready

**Key takeaway:** The appendix is the backup — detail on demand, not on the critical path.

---

## A1 — Platform-Managed Environments

**Talking points:**
- A consumer provides no AWS account, no VPC, no subnet, no state backend, no runner key — the platform owns the entire blast radius
- A named environment is a platform-owned bundle: an AWS account (or scoped partition), a network, a state backend, and an IAM role surfaced via ABAC
- The consumer selects an environment by name (`environment: dev`) and the platform resolves it at run time — the consumer never sees raw credentials
- Friendly onboarding is testing today: the first run detects no environment and emits a guided prompt, not an opaque failure. Self-service provisioning is planned
- For the Head of Cloud: this is the governance story — the platform team owns accounts, network design, and state hygiene; consumers can't drift because they never touch them

**Key takeaway:** Environments are platform-owned bundles. Consumers pick a name; the platform owns the rest.

---

## A2 — Observability Built In

**Talking points:**
- Monitoring is a platform default, not a per-team project — you don't deploy a service and *then* remember to set up monitoring
- Uptime monitoring (Uptime-kuma on ECS Fargate) is provisioned automatically after any module deploy, in a separate state, with a feature flag to disable
- Monitored endpoints come from the deployment's own outputs — no manual endpoint registration. The platform constructs the synthetic monitoring contract from what was just deployed
- Alert channels: Microsoft Teams webhook, email, SMS, and GitHub issues — all testing today
- The uptime URL is published to the developer via a PR comment so they don't hunt for it
- Roadmap: deeper observability bootstrap (dashboards, runbooks, on-call bindings) as first-class contract fields for prod/dr — planned

**Key takeaway:** Monitoring ships with the deploy, not after it. The feature flag lets teams with existing monitoring opt out cleanly.

---

## A3 — The Road to the North Star

**Talking points:**
- Be explicit up front: this is **proposed phasing, not formally planned** — the phases are sequenced by dependency, not by calendar
- Phase 1 — Testing baseline (current, v1.12): contract-driven deploys, zero-trust OIDC + ABAC, confidence signal, hash-chained evidence, encryption by default, safe decommission, uptime monitoring, platform-managed environments. **22/22 capabilities Verified** via the v1.11 lifecycle pipeline (apply→modify→destroy against live AWS, then torn down to zero-cost). The stateless adapter + lifecycle pipeline are the structural verification (see A7)
- Phase 2 — Production readiness: HITL wiring for qa/prod/dr, all-runner OIDC, full regulatory ledger (S3 Object Lock + JWS signatures + daily checkpoints), environment self-service
- Phase 3 — Compliance & expansion: compliance milestone (GDPR, SOX, SOC2, DORA), additional engine adapters (OpenTofu, Pulumi, Kubernetes CRDs), deeper observability bootstrap
- Phase 4 — Agentic frontier: dynamic module creation from a contract (citizen-developer flow), pattern recognition that compounds value over time
- Each phase's items are gated on the prior phase's maturity — invite questions on any phase boundary

**Key takeaway:** A dependency-sequenced path from testing baseline to agentic frontier — proposed, not formally committed. Phase 1 is now Verified (22/22), not aspirational.

---

## A4 — Testing vs. Planned (Full Inventory)

**Talking points:**
- Close on honesty — the platform delivers real, verifiable value today, and the roadmap is concrete, not aspirational hand-waving
- **22/22 capabilities Verified** via the v1.11 lifecycle pipeline (apply→modify→destroy against live AWS for every L1 + L2 module) + the D-091 regression gate. The v1.10 "6 deploy-unverified (IAM drift)" status is closed (CAP-013 fixed in P67)
- Walk the Testing column (22 capabilities) — from contract-driven deploys to encryption by default to uptime monitoring. These work internally and are dev pilot-ready
- Walk the Planned column (9 capabilities) — be clear about what's not yet done: HITL wiring, full regulatory ledger, compliance milestone, environment self-service, dynamic module creation, additional engine adapters, deeper observability
- Two agentic items are flagged: dynamic module creation and pattern recognition — both involve AI agents or autonomous decision-making
- 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 (fast, no AWS mutation, no cost); `ACDL_LIFECYCLE_MODE=full` overrides to apply→destroy for milestone verification (REQ-134, v1.12)

**Key takeaway:** 22/22 capabilities Verified via lifecycle pipeline + regression gate. 9 planned items on a concrete roadmap. Zero consumer adoption — yet.

---

## A5 — Glossary

**Talking points:**
- This is a reference slide — don't read it aloud, point to it as a takeaway reference for term definitions
- The terms most likely to come up in questions: OIDC (short-lived tokens), ABAC (tag-scoped access), CMK (per-stack encryption keys), RPO = 0 (synchronous evidence write)
- HITL is the human-attestation term for qa/prod/dr; NFR is the non-functional-requirements input to the confidence signal
- IR (Intermediate Representation) is the engine-agnostic stack definition between the contract and Terraform — the abstraction that makes the platform portable

**Key takeaway:** A shared vocabulary — keep it as a reference for follow-up questions.

---

## A6 — Operating Model & Cost

**Talking points:**
- This is the slide for the Head of Cloud / Finance — the headline: less than one cent ($0.001883) over 8 days of active development; zero BAU cloud spend
- Walk the cost table: total $0.001883 / 8 days, daily average $0.000235, projected monthly ~$0.007, peak day 2026-07-27 at $0.000867 (a v1.10 regression + verify run)
- S3 dominates the spend (98.8%, the terraform state bucket) — no compute (ECS/Lambda) ran because v1.0→v1.10 was plan-only for IAM-gated capabilities
- Live-AWS verification is milestone-scoped, then torn down: the v1.11 lifecycle pipeline ran apply→modify→destroy for every module, then tore down to zero-cost (D-096 — teardown mandatory before milestone COMPLETE)
- The lifecycle pipeline now defaults to **plan-only** on every PR (fast, no AWS mutation, no cost); `ACDL_LIFECYCLE_MODE=full` overrides to apply→destroy for milestone verification (REQ-134, v1.12)
- The pre-mortem (`PRE_MORTEM.md`) is the credibility slide — we already asked "how does this fail?" The v1.10 decay incident (diff-scoped VERIFY missed 7 adapter defects) is the root pattern: *a claim outruns the verification that backs it.* Four forward failure modes + structural mitigations (regression-tested IAM baseline, mandatory teardown, verified-only deck claims, honest scope)

**Key takeaway:** Less than one cent over 8 days. Zero BAU cloud spend. The pre-mortem + plan-only default make cost a non-issue and verification structural.

---

## A7 — 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?"
- Pillar 1 — the **stateless adapter** (918 → ~80 lines): the old adapter was a monolith with 3 constant tables and 39 type-specific branches. The new adapter is a stateless assembler that owns no module content — each L1 module ships a real `terraform/` module dir owning its shape, nested blocks, and defaults. A new module is a new terraform dir, not a code change
- The v1.12 P67 fix closed a dedup defect for multi-resource L1s (ecs-service, alb) — CAP-013 is now Verified
- Pillar 2 — **pipeline-driven lifecycle testing**: a `modules-lifecycle` pipeline matrix-runs each L1 and L2 module's contracts through apply→modify→destroy against live AWS. The "test" = the pipeline cell going green. No per-module Python
- The pipeline defaults to plan-only on every PR (zero cost); `ACDL_LIFECYCLE_MODE=full` runs the real apply→destroy for milestone verification. The regression gate (D-091) re-runs all 22 capabilities at milestone completion — 22/22 Verified as of v1.12
- 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

**Key takeaway:** "Verified" is a structural property, not a claim — a stateless ~80-line adapter + a lifecycle pipeline that defaults to plan-only and goes green on every PR.