docs(P51): full presentation rework — scope, story arc, visuals, appendix

Major rework of both presentation decks based on leadership feedback. Addresses: story arc, concept clarity, scope clarification, more visuals, appendix for detail-heavy slides, and a complete Road to the North Star. 6 new mermaid diagrams: - platform-works-03-scope-boundary (Upstream → Contract → ACDL → AWS) - developer-experience-01b-scope-boundary (both consumer paths + scope) - platform-works-04-confidence-signal (6 inputs → score → gate → decision) - platform-works-05-attestation-flow (deploy → gate → approver → evidence) - developer-experience-04-promotion-journey (dev → qa → prod → dr) - road-to-north-star (v1.0 demo → v1.9 → v1.10 → v2.0 → North Star) Both Marp decks restructured to 10 main + 6 appendix slides: PW deck (17 slides): 1. Title 2. The Problem & The North Star (anti-goals moved to slide 3) 3. Where ACDL Sits in Your World (NEW — scope boundary, infra only) 4. The Contract-Driven Model (image: removed, infra inputs instead) 5. The End-to-End Flow 6. Zero-Trust by Default 7. Safety is Computed (NEW confidence signal diagram) 8. Security by Construction 9. Accountability & Audit (NEW attestation flow diagram, QA clarification, badge reclassification: dev=Testing, qa/prod/dr=Planned) 10. Testing vs. Planned (summary, full inventory in appendix) 11. The Vision Realized + Appendix: TOC, Platform-Managed Environments, Observability, Road to North Star, Full Inventory, Glossary DX deck (16 slides): 1. Title 2. Where ACDL Sits in Your World (REPLACES Two Consumer Surfaces — scope boundary with both consumer paths) 3. The Contract — The Entire Consumer Surface (image: removed) 4. The Developer Feedback Loop 5. Versioned, Predictable Releases 6. Friendly Onboarding 7. Safe Promotion Path (NEW promotion journey diagram, rising bar annotated: dev=Testing, qa/prod/dr=Planned) 8. Safe Decommission 9. Self-Service Module Catalog 10. The Desired Outcomes + Appendix: TOC, Citizen Developer Experience, No Platform Code, Local Reproducibility, Road to North Star, Glossary Story arc: every slide has an italic 'Story beat' line connecting it to the narrative progression. Scope clarification: ACDL is infrastructure only. Upstream is anything (IDE, agentic SDLC, citizen dev vibe coding). ACDL provisions and governs AWS resources; application deployment is upstream. Contract examples now show infrastructure inputs (cpu, memory, desired_count, port) not image:. QA attestation reclassification: 'Design tested' → 'Planned'. QA attests to infrastructure readiness (contract + Terraform plan + evidence), not application code. Dev is autonomous (Testing); qa/prod/dr are Planned. Road to the North Star: phased timeline (v1.0 → v1.9 → v1.10 → v2.0 → North Star), annotated 'proposed phasing, not formally planned.' Also: scripts/sync_to_gl.sh added (GitLab mirror sync utility). ---ci--- phase: 51 milestone: v1.9 status: complete requirements: covered: [] partial: [] ---/ci---
verify(P51): code review — 1 P0 auto-fixed, 2 P1+ flagged
2026-07-27 14:46:05 +00:00 · 2026-07-27 14:44:12 +00:00 · 2026-07-23 15:59:20 +00:00 · 2026-07-23 15:58:35 +00:00 · 2026-07-23 15:44:36 +00:00
26 changed files with 2555 additions and 598 deletions
@@ -458,6 +458,51 @@ across presentation files, consumer guide, and test fixtures.
 No code changes (test fixture strings only); 494 tests pass; `run_ci.sh` +
 `run_platform.sh --check-only` green. PPTX files uploaded to Gitea release.

+## Patch v1.9.6 (complete, tag `v1.9.6`)
+
+Docs-only NFR patch on the v1.9 line. Both Marp presentation decks
+consolidated to 10 high-impact slides each — every slide high-impact, fluff
+eliminated.
+
+**How The Platform Works (16 → 10):**
+- Merged Problem + North Star + What It Is/Isn't → 1 slide (4 frictions →
+  North Star → 3 success criteria → 2 anti-goals)
+- Merged Policy & Security + Secure by Default → 'Security by Construction'
+- Merged Immutable Audit + Human-in-the-Loop → 'Accountability & Audit'
+- Folded Observability, Platform-Managed Environments, Portability into
+  existing slides as bullets
+- Added 'The Vision Realized' closing slide
+
+**The Developer Experience (15 → 10):**
+- Merged What Dev Does + Contract + No Platform Code → 'The Contract — The
+  Entire Consumer Surface'
+- Merged Instant Feedback + Deploy Outputs → 'The Developer Feedback Loop'
+- Merged Safe Promotion Path + Rising Bar → 1 slide
+- Cut Citizen Developer Experience standalone (mentioned on slides 2 + 10)
+- Kept Versioned Releases, Friendly Onboarding, Safe Decommission
+
+**Also:** Removed '5-line YAML' claim from both decks (credibility — complex
+stacks require more lines). Source markdown files unchanged (remain complete
+reference with speaker notes for all original slides).
+
+No code changes; 494 tests pass; `run_ci.sh` + `run_platform.sh --check-only`
+green. PPTX files uploaded to Gitea release.
+
+## Patch v1.9.7 (complete, tag `v1.9.7`)
+
+Docs-only NFR patch on the v1.9 line. Created two talking points markdown
+files — one per deck — distilling the source of truth (speaker notes +
+content) into presenter-ready cues indexed by the Marp deck's 10-slide
+structure. Each file has one section per Marp slide with 3-6 talking point
+bullets (punchy, actionable cues) + a key takeaway per slide. The talking
+points are the middle layer between the source of truth (full detail) and
+the Marp deck (what the audience sees). README updated from 3-step to 4-step
+process (added Step 4: talking points), with updated diagram, directory
+layout, checklist, and decks table.
+
+No code changes; 494 tests pass; `run_ci.sh` + `run_platform.sh --check-only`
+green.
+
 ## Requirements

 ### v1.0 (Prior milestone — the demo)
@@ -16,6 +16,8 @@
 - **v1.9.3 (complete, tag `v1.9.3`):** rendered presentation decks. HTML renderings of both Marp decks committed to docs/presentations/ (self-contained, base64-embedded images, S&P Global Energy theme). PPTX files uploaded to the Gitea release as downloadable attachments. README updated to document HTML as committed artifacts and PPTX as release attachments. Docs-only NFR patch.
 - **v1.9.4 (complete, tag `v1.9.4`):** presentation slide updates + complete removal of a specific compliance framework from all docs. Title slide redesigned (deck title as H1, 'Agentic Cloud Delivery Platform' as subtitle). DX deck: removed Local Reproducibility slide, redesigned Safe Promotion Path with side-by-side layout, 'an agent' → 'an AI agent', What a Developer Does diagram floated right. All references to that framework removed from 25 files (presentations, module READMEs, docs). Compliance lists now: GDPR, SOX, SOC2, DORA. HTML re-rendered. PPTX uploaded to release. Docs-only NFR patch.
 - **v1.9.5 (complete, tag `v1.9.5`):** vision gaps + Testing badge + engine terminology + agentic tags + CR format. 9 requirements: (1) DX closing slide strengthened with 'infrastructure as a utility' vision bullet; (2) 'moving' → 'promoting'; (3) added red tape + scalability bullets to Problem slide; (4) Roadmap slide redesigned side-by-side; (5) new 'What This Platform Is — and Isn't' slide (PW deck 16 slides); (6) 'shipped'/'Available today' → 'Testing' (0 consumer adoption); (7) global 'substrate' → 'engine' (88 matches, 30+ files); (8) 'forge' → 'VCS' in presentation files only; (9) new Agentic badge (purple) on agentic features. CR format changed to CHG0678912. HTML re-rendered. PPTX uploaded to release. Docs-only NFR patch.
+- **v1.9.6 (complete, tag `v1.9.6`):** consolidate both Marp decks to 10 high-impact slides. PW deck 16 → 10 (merged Problem+North Star+Anti-goals, merged Policy+Secure by Default, merged Audit+HITL, folded Observability/Environments/Portability into existing slides, added Vision Realized closing). DX deck 15 → 10 (merged What Dev Does+Contract+No Platform Code, merged Feedback+Deploy Outputs, merged Promotion+Rising Bar, cut Citizen Developer standalone, kept Versioned Releases/Onboarding/Decommission). Removed '5-line YAML' claim from both decks. Source markdown unchanged. Docs-only NFR patch.
+- **v1.9.7 (complete, tag `v1.9.7`):** talking points files + 4-step process. Created two talking points markdown files (one per deck) distilling the source of truth into presenter-ready cues indexed by the Marp deck's 10-slide structure. Each file has 3-6 talking point bullets + key takeaway per slide. README updated from 3-step to 4-step process (added Step 4: talking points). Directory layout, checklist, and decks table updated. Docs-only NFR patch.
 - **v1.0 demo URL:** https://git.cloudinit.dev/continuous-intelligence/acdl-evidence/raw/branch/main/index.html

 ---
@@ -2,20 +2,23 @@

 Leadership-facing presentation decks for the ACDL platform.

-## The 3-step slide creation process
+## The 4-step slide creation process

-Every presentation in this folder is produced by the same three-step process.
-**Never edit the Marp deck or the PPTX directly** — always start from the full
-markdown source of truth (Step 1), synthesize the Marp deck (Step 2), then
-export to PPTX (Step 3). This keeps a reviewable, plain-text source of truth
-for every deck.
+Every presentation in this folder is produced by the same four-step process.
+**Never edit the Marp deck, the PPTX, or the talking points directly** —
+always start from the full markdown source of truth (Step 1), synthesize the
+Marp deck (Step 2), export to HTML + PPTX (Step 3), then distill the talking
+points (Step 4). This keeps a reviewable, plain-text source of truth for
+every deck and a presenter-ready cue sheet for delivery.

 ```
-Step 1: full markdown       Step 2: Marp deck           Step 3: PPTX export
-(source of truth)    ──►    (lean, no notes)     ──►    (presentation-ready)
-*.md                        *-marp.md                   *.pptx
-+ speaker notes             + embedded PNG diagrams     + embedded images
-+ mermaid code blocks       + Marp frontmatter
+Step 1: full markdown       Step 2: Marp deck           Step 3: HTML + PPTX         Step 4: Talking points
+(source of truth)    ──►    (lean, 10 slides)    ──►    (rendered)           ──►    (presenter cues)
+*.md                        *-marp.md                   *.html / *.pptx             *-talking-points.md
+ speaker notes             + embedded PNG diagrams                                 + 3-6 bullets per slide
+ mermaid code blocks       + Marp frontmatter                                     + key takeaway per slide
+                            + maturity badges                                      + indexed by Marp slide #
+                            + no speaker notes                                     + content distilled from Step 1
 ```

 ### Step 1 — Full markdown (source of truth)
@@ -103,35 +106,96 @@ PNG diagrams are embedded in the file. PPTX files are not committed to the
 repo (binary, no meaningful diffs) — they are uploaded to the Gitea release
 as downloadable attachments.

+### Step 4 — Talking points (presenter cues)
+
+**File convention:** `<deck-name>-talking-points.md` (e.g.
+`how-the-platform-works-talking-points.md`).
+
+Distill the source of truth (Step 1) into presenter-ready cues, indexed by
+the Marp deck (Step 2) slide structure:
+
+- **One section per Marp slide** — `## Slide N — Title`, matching the Marp
+  deck's 10 main + 6 appendix slide structure exactly. The Marp deck
+  provides the indexing and context (what the audience sees); the source
+  markdown provides the content (the speaker notes, the detail, the nuance).
+- **3-6 talking point bullets per slide** — punchy, actionable cues distilled
+  from the source markdown's speaker notes. NOT the speaker notes verbatim
+  (those are too long and too contextual). These are prompts: "Land this
+  point," "Contrast with X," "Be honest about Y."
+- **Key takeaway per slide** — the one memorable thing the audience should
+  walk away with from that slide.
+- **No content duplication** — the talking points reference the Marp slides
+  for visual context and the source markdown for full detail. They don't
+  repeat either; they bridge them.
+
+**Why this file exists:** a presenter needs a cue sheet they can glance at
+during delivery — not the full speaker notes (too long), not the Marp slides
+(no detail). The talking points file is the middle layer: what to say, in
+what order, with what emphasis, per slide.
+
+**When to update:** re-distill the talking points whenever the Marp deck
+structure changes (slides added, removed, merged, or re-ordered) or whenever
+the source markdown's speaker notes are updated. The talking points are a
+*derived artifact* — if a fact is wrong, fix it in the source markdown (Step 1)
+and re-distill.
+
 ## Directory layout

 ```
 docs/presentations/
 ├── README.md                                  ← this file
 ├── how-the-platform-works.md                  ← Step 1: full source of truth
-├── how-the-platform-works-marp.md              ← Step 2: Marp deck
+├── how-the-platform-works-marp.md              ← Step 2: Marp deck (10 main + 6 appendix)
 ├── how-the-platform-works.html                  ← Step 3: rendered HTML (committed)
+├── how-the-platform-works-talking-points.md    ← Step 4: presenter cues (16 sections)
 ├── the-developer-experience.md                 ← Step 1: full source of truth
-├── the-developer-experience-marp.md            ← Step 2: Marp deck
+├── the-developer-experience-marp.md            ← Step 2: Marp deck (10 main + 6 appendix)
 ├── the-developer-experience.html               ← Step 3: rendered HTML (committed)
+├── the-developer-experience-talking-points.md  ← Step 4: presenter cues (16 sections)
 └── assets/
    ├── puppeteer-config.json                   ← no-sandbox config for mmdc
    ├── mmd/                                     ← mermaid source files (Step 2 input)
    │   ├── platform-works-01-contract-driven.mmd
    │   ├── platform-works-02-end-to-end-flow.mmd
-    │   ├── developer-experience-01-two-surfaces.mmd
+    │   ├── platform-works-03-scope-boundary.mmd
+    │   ├── platform-works-04-confidence-signal.mmd
+    │   ├── platform-works-05-attestation-flow.mmd
+    │   ├── developer-experience-01b-scope-boundary.mmd
    │   ├── developer-experience-02-what-dev-does.mmd
-    │   └── developer-experience-03-no-cloning.mmd
+    │   ├── developer-experience-03-no-cloning.mmd
+    │   ├── developer-experience-04-promotion-journey.mmd
+    │   └── road-to-north-star.mmd
    └── png/                                     ← rendered PNGs (embedded in Marp)
        ├── platform-works-01-contract-driven.png
        ├── platform-works-02-end-to-end-flow.png
-        ├── developer-experience-01-two-surfaces.png
+        ├── platform-works-03-scope-boundary.png
+        ├── platform-works-04-confidence-signal.png
+        ├── platform-works-05-attestation-flow.png
+        ├── developer-experience-01b-scope-boundary.png
        ├── developer-experience-02-what-dev-does.png
-        └── developer-experience-03-no-cloning.png
+        ├── developer-experience-03-no-cloning.png
+        ├── developer-experience-04-promotion-journey.png
+        └── road-to-north-star.png
 ```

 ## Conventions

+### Appendix structure
+
+Each Marp deck has **10 main slides + 6 appendix slides** (16 total). The
+main 10 are the presentation; the appendix is for deep dives and Q&A backup.
+
+- **Main slides** (1-10): the story arc, high-impact, minimal text,
+  visual-heavy. These are what the audience sees during the talk.
+- **Appendix slides** (A1-A5 + TOC): detail-heavy slides moved out of the
+  main 10 to preserve the narrative flow. The appendix starts with a TOC
+  slide listing the contents, followed by detail slides and a glossary.
+- **The Road to the North Star** is a required appendix slide in both decks
+  — a phased timeline from v1.0 demo to the North Star, annotated as
+  "proposed phasing, not formally planned."
+- **The Glossary** is a required appendix slide in both decks — defines
+  acronyms (OIDC, ABAC, CMK, CMDB, RPO, HITL, VCS, NFR) for the audience.
+
 ### Maturity framing

 Every capability claim in a deck is tagged with one of three badges:
@@ -241,7 +305,11 @@ attachments to the Gitea release.
   `docs/presentations/<deck-name>.html`.
 5. **Render to PPTX** with `--allow-local-files` and upload to the Gitea
   release (do not commit PPTX to git).
-6. **Verify** the PPTX slide count and that media files are embedded:
+6. **Distill the talking points** as `<deck-name>-talking-points.md` — one
+   section per Marp slide, 3-6 talking point bullets + key takeaway, content
+   distilled from the source markdown (Step 1), indexed by the Marp deck
+   (Step 2) slide structure.
+7. **Verify** the PPTX slide count and that media files are embedded:
   ```bash
   python3 -c "
   import zipfile, re
@@ -254,7 +322,7 @@ attachments to the Gitea release.

 ## Current decks

-| Deck | Source of truth (Step 1) | Marp deck (Step 2) | Rendered HTML (Step 3) | Audience |
-|---|---|---|---|---|
-| How the Platform Works | `how-the-platform-works.md` | `how-the-platform-works-marp.md` | `how-the-platform-works.html` | CTO, Head of Cloud, Head of Infra, Head of DevOps |
-| The Developer Experience | `the-developer-experience.md` | `the-developer-experience-marp.md` | `the-developer-experience.html` | CTO, Head of Cloud, Head of Infra, Head of DevOps |
+| Deck | Source of truth (Step 1) | Marp deck (Step 2) | Rendered HTML (Step 3) | Talking points (Step 4) | Slides | Audience |
+|---|---|---|---|---|---|---|
+| How the Platform Works | `how-the-platform-works.md` | `how-the-platform-works-marp.md` | `how-the-platform-works.html` | `how-the-platform-works-talking-points.md` | 10 main + 6 appendix | CTO, Head of Cloud, Head of Infra, Head of DevOps |
+| The Developer Experience | `the-developer-experience.md` | `the-developer-experience-marp.md` | `the-developer-experience.html` | `the-developer-experience-talking-points.md` | 10 main + 6 appendix | CTO, Head of Cloud, Head of Infra, Head of DevOps |
@@ -1,7 +0,0 @@
-flowchart LR
-    A["Technical developer"] --> C["Contract YAML"]
-    B["Citizen developer<br/>(non-technical)"] --> D["Declares intent<br/>in natural language"]
-    D --> E["Agent produces<br/>the contract"]
-    C --> F["Same platform:<br/>resolve → check → plan →<br/>policy → confidence → apply"]
-    E --> F
-    F --> G["Same safety guarantees,<br/>same audit trail"]
@@ -0,0 +1,21 @@
+flowchart LR
+    subgraph UP ["Upstream — anything"]
+        direction TB
+        A["Technical dev\n(app code + contract)"]
+        B["Citizen dev\n(intent → AI agent\n→ contract)"]
+    end
+    subgraph ACDL ["ACDL — infrastructure only"]
+        C["Same contract\nSame pipeline\nSame safety"]
+        D["Provision\nAWS resources"]
+        E["Evidence\nhash-chained"]
+    end
+    subgraph DOWN ["Downstream"]
+        F["AWS resources\nrunning"]
+        G["Consumer pipeline\ndeploys image"]
+    end
+    A --> C
+    B --> C
+    C --> D
+    C --> E
+    D --> F
+    F --> G
@@ -0,0 +1,8 @@
+flowchart LR
+    A["dev\n≥ 0.50\nautonomous"] -->|promotion| B["qa\n≥ 0.75\nQA attests"]
+    B -->|promotion| C["prod\n≥ 0.90\nSRE attests"]
+    C -->|promotion| D["dr\n≥ 0.95\nSRE + DR drill"]
+    A -.->|"Testing\n(pilot-ready)"| A
+    B -.->|"Planned"| B
+    C -.->|"Planned"| C
+    D -.->|"Planned"| D
@@ -0,0 +1,25 @@
+flowchart LR
+    subgraph UP ["Upstream — anything"]
+        direction TB
+        A["IDE / IDE + AI\n(dev writes contract)"]
+        B["Agentic SDLC\n(agent writes contract)"]
+        C["Citizen dev\n(vibe codes → AI agent\n→ contract)"]
+    end
+    subgraph ACDL ["ACDL — infrastructure only"]
+        D["Contract\nvalidated"]
+        E["Resolve → Plan\nSecurity + Policy checks\nConfidence signal"]
+        F["Provision\nAWS resources"]
+        G["Evidence\nhash-chained"]
+    end
+    subgraph DOWN ["Downstream"]
+        H["AWS resources\nrunning"]
+        I["Consumer pipeline\ndeploys image"]
+    end
+    A --> D
+    B --> D
+    C --> D
+    D --> E
+    E --> F
+    E --> G
+    F --> H
+    H --> I
@@ -0,0 +1,15 @@
+flowchart LR
+    subgraph IN ["6 weighted inputs"]
+        direction TB
+        A["Policy\nconformance"]
+        B["Validation"]
+        C["Freshness"]
+        D["Source\nprovenance"]
+        E["History"]
+        F["NFRs"]
+    end
+    IN --> G["Weighted sum\n→ Confidence score"]
+    G --> H{"Threshold\ngate"}
+    H -->|Meets threshold| I["Proceed"]
+    H -->|Below threshold| J["Halt +\nexplainable reason"]
+    H -->|Critical finding| J
@@ -0,0 +1,13 @@
+flowchart LR
+    A["Deployment arrives\nat env gate"] --> B["Confidence signal\ncomputed"]
+    B --> C{"Meets\nthreshold?"}
+    C -->|No / Critical| D["Halt —\nexplainable reason"]
+    C -->|Yes| E{"Human attestation\nrequired?"}
+    E -->|No — dev| F["Autonomous\nproceed"]
+    E -->|Yes — qa/prod/dr| G["Approver reviews:\ncontract + plan + evidence"]
+    G --> H{"Approver\ndecides"}
+    H -->|Approve| I["Attestation recorded\n(identity + state)"]
+    H -->|Reject| J["Halt — rejection\nextends audit chain"]
+    I --> K["Deployment\nproceeds"]
+    F --> K
+    K --> L["Evidence written\nRPO=0"]
@@ -0,0 +1,11 @@
+flowchart LR
+    A["v1.0\nDEMO\ncomplete"] --> B["v1.1–v1.8\nPLATFORM BUILD\ncomplete"]
+    B --> C["v1.9\nPRESENTATIONS + PATCHES\ncomplete"]
+    C --> D["v1.10\nNEXT\nHITL wiring\nall-runner OIDC\nregulatory ledger"]
+    D --> E["v2.0\nFUTURE\ncompliance milestone\nself-service\ndynamic modules\nengine adapters"]
+    E --> F["North Star\nREALIZED\nfull autonomy (lower)\nattested (higher)\ncitizen dev live\nevidence regulatory-grade"]
+    A -.->|"stub-driven proof"| A
+    B -.->|"IR + OIDC + ABAC +\nmodule catalog +\nencryption + decommission"| B
+    C -.->|"10-slide decks +\ntalking points +\nS&P theme"| C
+    D -.->|"proposed phasing\nnot formally planned"| D
+    E -.->|"proposed phasing\nnot formally planned"| E
@@ -18,7 +18,8 @@ style: |
  table { font-size: 18px; width: 100%; }
  th { background: #F0F0F0; }
  blockquote { border-left: 4px solid #D6002A; color: #2E2E2E; font-size: 20px; }
-  img { display: block; margin: 0 auto; max-height: 320px; }
+  img { display: block; margin: 0 auto; max-height: 300px; }
+  em.story { color: #6B7280; font-size: 16px; font-style: italic; }
  .badge {
    display: inline-block; padding: 2px 8px; border-radius: 4px;
    font-size: 14px; font-weight: 600;
@@ -44,6 +45,8 @@ section.title h3 { color: #F0F0F0; font-weight: 400; font-size: 22px; margin-top

 # The Problem & The North Star

+<em class="story">Story beat: Here's the problem we're solving and where we're going.</em>
+
 Four frictions slow every team:

 - **Cognitive load** — authoring infrastructure correctly; the long tail of services inconsistent in security and observability
@@ -56,6 +59,17 @@ Four frictions slow every team:
 - A merged change progresses **without a platform engineer joining a thread or approving a ticket**
 - A **non-technical consumer** ships by declaring intent — no workflow, no config file, no infrastructure module
 - Every production change is **traceable to a human attestation and an immutable evidence stream**
+
+---
+
+# Where ACDL Sits in Your World
+
+<em class="story">Story beat: Now that we know the problem, here's where ACDL fits — and where it doesn't.</em>
+
+![w:1100](assets/png/platform-works-03-scope-boundary.png)
+
+- **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.
 - **Not a general-purpose AI** — autonomy is narrow, scoped to delivery, bounded by strict policy
 - **Not a permissive delivery highway** — no escape hatches to bypass the confidence framework

@@ -63,19 +77,23 @@ Four frictions slow every team:

 # The Contract-Driven Model

-A single YAML contract is all a consumer writes — **module, environment, inputs**. The platform owns everything else.
+<em class="story">Story beat: The contract is the boundary between upstream and ACDL. It's all a consumer writes.</em>
+
+A single YAML contract — **module, environment, inputs**. The platform owns everything else.

 ![w:850](assets/png/platform-works-01-contract-driven.png)

 - **Which module** — a catalog of pre-built, security-reviewed building blocks
 - **Which environment** — the platform raises the safety bar automatically as sensitivity rises
- **Which inputs** — the handful of values that vary per deployment
- The consumer provides **no AWS account, no VPC, no state backend, no runner key** — the platform owns the blast radius
+- **Which inputs** — infrastructure values that vary per deployment (cpu, memory, port, desired_count)
+- The consumer provides **no AWS account, no VPC, no state backend** — the platform owns the blast radius

 ---

 # The End-to-End Flow

+<em class="story">Story beat: Once the contract is written, here's what the platform does with it — every time.</em>
+
 Every deployment runs the same stages, in the same order, with the same checks — no team-specific pipelines, no tribal runbooks.

 ![w:1100](assets/png/platform-works-02-end-to-end-flow.png)
@@ -87,6 +105,8 @@ Every deployment runs the same stages, in the same order, with the same checks

 # Zero-Trust by Default

+<em class="story">Story beat: Before any infrastructure is created, here's how access is scoped.</em>
+
 Consumer repositories hold **no long-lived cloud credentials.** Ever.

 - **Authentication — OIDC federation.** Each job mints a short-lived token; no credential is stored in the consumer repo or in a runner secret. <span class="badge testing">Testing (GitHub Actions)</span> <span class="badge planned">Planned: all runners</span>
@@ -100,25 +120,29 @@ Consumer repositories hold **no long-lived cloud credentials.** Ever.

 # Safety is Computed, Not Assumed

-Every delivery action produces a **measurable, explainable confidence signal** — the platform's certified answer to *"is this safe to proceed?"* <span class="badge agentic">Agentic</span>
+<em class="story">Story beat: Now let's look at how the platform decides whether a deployment is safe.</em>

- **Six weighted inputs:** policy conformance, validation, freshness, source provenance, history, NFRs
+Every delivery action produces a **measurable, explainable confidence signal** — a weighted sum of observable facts, not a black box. <span class="badge agentic">Agentic</span>
+
+![w:1100](assets/png/platform-works-04-confidence-signal.png)
+
+- **Six weighted inputs** — manually tuned, auditable. If a consumer asks "why 0.62?", the platform answers with a per-input breakdown
 - **Per-environment thresholds** that rise with sensitivity:

 | Environment | Threshold | Attester |
 |---|---|---|
-| dev | ≥ 0.50 | No one — autonomous |
-| qa | ≥ 0.75 | QA |
-| prod | ≥ 0.90 | SRE |
-| dr | ≥ 0.95 | SRE + DR drill |
+| dev | ≥ 0.50 | No one — autonomous <span class="badge testing">Testing</span> |
+| qa | ≥ 0.75 | QA <span class="badge planned">Planned</span> |
+| prod | ≥ 0.90 | SRE <span class="badge planned">Planned</span> |

- **A single critical finding hard-blocks the deployment** — critical findings are not averaged away
- **When the platform halts, it gives a measured reason** — never an opaque debugging exercise
+- **A single critical finding hard-blocks** — critical findings are not averaged away

 ---

 # Security by Construction

+<em class="story">Story beat: Beyond the confidence signal, security defaults are on by construction — not by opt-in.</em>
+
 Security defaults that **do not require a team to opt in.** Checks run on **every** deployment, normalized to a single schema. <span class="badge testing">Testing</span>

 - **Policy checks** (Checkov, Wiz, Kyverno) — secrets in plaintext, public ingress, IAM wildcards, **required tagging standards** — all run *before* infra is created
@@ -130,13 +154,15 @@ Security defaults that **do not require a team to opt in.** Checks run on **ever

 # Accountability & Audit

-Autonomy and accountability are **not in tension** — they apply at different environments.
+<em class="story">Story beat: Computed safety handles the gate. But humans still matter — here's how accountability works.</em>

- **Dev is fully autonomous.** The confidence signal (≥ 0.50) is the only gate. Queue-based handoffs are eliminated. <span class="badge agentic">Agentic</span>
- **qa, prod, dr require deliberate human attestation** — policy-mandated acts of accountability, not rubber stamps
- **Separation of duties is enforced** — the QA approver **cannot** be the prod approver. The platform **blocks on a match.** <span class="badge testing">Design tested</span> <span class="badge planned">Wiring: planned</span>
- **Every deployment writes a hash-chained evidence event** — tampering breaks the chain. **RPO = 0** — the evidence write is synchronous <span class="badge testing">Testing</span>
- **Every production change is traceable to a human attestation** — the only durable record outside the VCS's audit log
+![w:1100](assets/png/platform-works-05-attestation-flow.png)
+
+- **Dev is fully autonomous.** The confidence signal (≥ 0.50) is the only gate. <span class="badge testing">Testing</span> <span class="badge agentic">Agentic</span>
+- **qa, prod, dr require human attestation** — the approver reviews the contract, the planned Terraform changes, and the accumulated evidence <span class="badge planned">Planned</span>
+- **QA attests to infrastructure readiness, not application code** — the contract, the plan, and the evidence. Application code review is upstream
+- **Separation of duties** — the QA approver **cannot** be the prod approver. The platform **blocks on a match.** <span class="badge planned">Planned</span>
+- **Every deployment writes a hash-chained evidence event** — tampering breaks the chain. **RPO = 0** <span class="badge testing">Testing</span>

 ---

@@ -145,9 +171,112 @@ Autonomy and accountability are **not in tension** — they apply at different e

 # Testing vs. Planned

+<em class="story">Story beat: Let's be honest about what works today and what's on the roadmap.</em>
+
 <style>
-section { font-size: 16px; }
-td { font-size: 15px; vertical-align: top; }
+section { font-size: 20px; }
+</style>
+
+**11 capabilities testing today** (dev pilot-ready):
+
+- Contract-driven deploys · Module catalog · Zero-trust OIDC + ABAC
+- Security + policy checks before infra creation · Confidence signal gating
+- Hash-chained evidence outbox (RPO = 0) · Encryption by default + per-stack CMKs
+- Deletion protection + safe decommission · Uptime monitoring
+- Platform-managed environments · Engine-agnostic core + VCS-agnostic ingestion
+
+**9 planned** (production path):
+
+- HITL wiring for qa/prod/dr · All-runner OIDC · Full regulatory ledger
+- Compliance milestone (GDPR, SOX, SOC2, DORA) · Environment self-service
+- Dynamic module creation <span class="badge agentic">Agentic</span> · Pattern recognition <span class="badge agentic">Agentic</span>
+- Additional engine adapters · Deeper observability bootstrap
+
+*Full inventory + phased roadmap in the appendix.*
+
+---
+
+<!-- _class: title -->
+<!-- _paginate: false -->
+
+# The Vision Realized
+
+<em class="story">Story beat: Here's what success looks like when the North Star is reached.</em>
+
+- **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 is traceable to a human attestation and a tamper-evident evidence event.
+- **Blast radius contained by design.** Zero-trust OIDC + ABAC means a consumer can only touch its own tagged resources.
+- **Infrastructure as a utility, not a craft.** Teams consume infrastructure, they don't maintain it.
+- **A path to the citizen developer.** The same safety envelope that serves a senior engineer will serve a non-technical consumer. <span class="badge agentic">Agentic</span>
+
+---
+
+<!-- _class: title -->
+<!-- _paginate: false -->
+
+# Appendix
+
+<em class="story">For deep dives — these slides cover details omitted from the main 10.</em>
+
+**Contents:**
+
+1. Platform-Managed Environments (detail)
+2. Observability Built In (detail)
+3. The Road to the North Star (phased roadmap)
+4. Testing vs. Planned (full inventory)
+5. Glossary
+
+---
+
+# A1 — Platform-Managed Environments
+
+A consumer provides **no AWS account, no VPC, no subnet, no state backend, no runner key.** The platform owns the blast radius.
+
+A named environment is a platform-owned bundle of:
+
+- An AWS account (or a scoped partition of one)
+- A network (VPC + subnets)
+- A state backend (S3 + DynamoDB for state + locking)
+- An IAM role surfaced via ABAC, scoped to the consumer's identity and resource tags
+
+The consumer selects an environment **by name** in their contract. The platform resolves the name to the underlying resources at run time. **The consumer never sees raw credentials.**
+
+**Friendly onboarding:** the first run detects no environment and emits a guided prompt (not an opaque failure). <span class="badge testing">Testing</span> <span class="badge planned">Self-service: planned</span>
+
+---
+
+# A2 — Observability Built In
+
+Monitoring is **a platform default, not a per-team project.** <span class="badge testing">Testing</span>
+
+- **Uptime monitoring deployed automatically with every stack** — a dedicated monitoring instance is provisioned after any module deploy, in a separate state, with a feature flag to disable
+- **Monitored endpoints passed from the deployment's own outputs** — no manual endpoint registration
+- **Alert channels:** Microsoft Teams webhook, email, SMS, and GitHub issues
+- **The uptime URL is published to the developer** via a PR comment — they don't hunt for it
+- **Roadmap:** deeper observability bootstrap (dashboards, runbooks, on-call bindings) as first-class contract fields <span class="badge planned">Planned</span>
+
+---
+
+<!-- _class: title -->
+<!-- _paginate: false -->
+
+# A3 — The Road to the North Star
+
+*Proposed phasing — not formally planned.*
+
+![w:1100](assets/png/road-to-north-star.png)
+
+---
+
+<!-- _class: title -->
+<!-- _paginate: false -->
+
+# A4 — Testing vs. Planned (Full Inventory)
+
+<style>
+section { font-size: 15px; }
+td { font-size: 14px; vertical-align: top; }
 ul { margin: 0; padding-left: 1.2em; }
 li { margin-bottom: 2px; }
 </style>
@@ -156,7 +285,7 @@ li { margin-bottom: 2px; }
 <tr>
 <td style="width: 52%; border: none; padding-right: 12px;">

-**Testing** (works internally, not yet released to consumers)
+**Testing** (works internally, dev pilot-ready)

 - Contract-driven deploys with a versioned reusable workflow
 - Module catalog (primitives + modules) with validated examples
@@ -191,14 +320,16 @@ li { margin-bottom: 2px; }

 ---

-<!-- _class: title -->
-<!-- _paginate: false -->
+# A5 — Glossary

-# The Vision Realized
-
- **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. Encryption, deletion protection, uptime monitoring, policy checks, and evidence are on by construction.
- **Auditability as a byproduct, not a project.** Every production change is traceable to a human attestation and a tamper-evident evidence event.
- **Blast radius contained by design.** Zero-trust OIDC + ABAC means a consumer can only touch its own tagged resources.
- **Infrastructure as a utility, not a craft.** The platform abstracts compute, networking, and state. Teams consume infrastructure, they don't maintain it.
- **A 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. <span class="badge agentic">Agentic</span>
+| Term | Meaning |
+|---|---|
+| **OIDC** | OpenID Connect — federation protocol for short-lived tokens, no long-lived credentials |
+| **ABAC** | Attribute-Based Access Control — access scoped by resource tags + repo identity, not roles |
+| **CMK** | Customer-Managed Key — per-stack encryption key, 90-day rotation, no shared keys |
+| **CMDB** | Configuration Management Database — validates change requests for decommission |
+| **RPO** | Recovery Point Objective — RPO = 0 means evidence is written synchronously, no data loss |
+| **HITL** | Human-in-the-Loop — deliberate human attestation required for qa/prod/dr environments |
+| **VCS** | Version Control System — the git hosting platform (GitHub, Gitea, GitLab) |
+| **NFR** | Non-Functional Requirement — encryption, tagging, observability standards |
+| **IR** | Intermediate Representation — the engine-agnostic stack definition between contract and Terraform |
@@ -0,0 +1,213 @@
+# How The Platform Works — Talking Points
+
+> **Companion to:** `how-the-platform-works-marp.md` (10 main + 6 appendix = 16 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 6-slide appendix for deep-dive questions
+
+**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 new 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 new 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 new 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, or glossary terms
+- 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): contract-driven deploys, zero-trust OIDC + ABAC, confidence signal, hash-chained evidence, encryption by default, safe decommission, uptime monitoring, platform-managed environments
+- Phase 2 — Production readiness: HITL wiring for qa/prod/dr, all-runner OIDC, full regulatory ledger, 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.
+
+---
+
+## 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
+- Walk the Testing column (11 capabilities) quickly — 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
+- Invite questions on any "planned" item — each has 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
+
+**Key takeaway:** 11 capabilities testing today. 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.
@@ -2,54 +2,51 @@

 > **Subtitle:** Agentic Cloud Delivery Platform
 > **Audience:** Senior Leadership, CTO, Head of Cloud, Head of Infrastructure, Head of DevOps
-> **Length:** ~15 minutes · 14 slides
+> **Length:** ~15 minutes · 10 main + 6 appendix = 16 slides
 > **Purpose:** Sell the platform's value to tech leadership — zero-trust, security, observability, auditability, and the shift from "operators guess" to "the platform computes safety."
-> **Maturity framing:** "Testing" = shipped and verified. "Planned" = on the roadmap, not yet shipped.
+> **Maturity framing:** "Testing" = works internally, dev pilot-ready. "Planned" = on the roadmap, not yet implemented. "Agentic" = involves AI agents or autonomous decision-making.

 ---

-## Slide 1 — The Problem We Solve
+## Slide 1 — Title
+
+# How The Platform Works
+
+### Agentic Cloud Delivery Platform
+
+> **Speaker notes:** 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.
+
+---
+
+## Slide 2 — The Problem & The North Star

 Software delivery scales with the **coordination surface around it**, not the engineering inside it. Most teams can write code; far fewer get the infrastructure right.

-Two frictions slow every team down:
+Four frictions slow every team:

- **Cognitive load** — authoring the infrastructure that runs a service correctly. The long tail of well-meaning services that are difficult to deploy, inconsistent in security and observability posture.
- **Operational work** — promoting a change from "merged" to "running in production with policy, observability, and security enforced." Manual work that **scales with the system, not with the change.**
- **Red tape** — every deployment requires tickets, approvals, and manual handoffs that scale with the organization, not with the change. A merged change waits in a queue for someone to press a button.
- **Scalability without increasing headcount** — the platform allows delivery throughput to scale without linearly scaling platform engineers. Today, every new team adds load to the same ticket queue.
+- **Cognitive load** — authoring infrastructure correctly; the long tail of services inconsistent in security and observability.
+- **Operational work** — promoting a change from "merged" to "running in production." Manual work that **scales with the system, not the change.**
+- **Red tape** — tickets, approvals, and handoffs that scale with the organization. A merged change waits in a queue.
+- **Scalability without increasing headcount** — throughput scales without linearly scaling platform engineers.

-> **Speaker notes:** Open with the cost of the status quo. Every team that stands up its own pipeline, its own Terraform, its own review checklist is paying a tax that doesn't differentiate the business. The platform absorbs all four frictions — that is the value proposition in one sentence.
+> Consumers **declare intent**; the platform delivers **safe production deployment** — automatically, safely, with a complete audit trail.

---
-
-## Slide 2 — The North Star
-
-> Consumers **declare intent**; the platform delivers **safe production deployment** through an agentic stack — automatically, safely, and with a complete audit trail.
-
-What success looks like:
-
- A merged change progresses through lower environments **end-to-end without a platform engineer joining a thread, approving a ticket, or manually triggering a stage.**
- A **non-technical consumer** ships a production deployment by declaring intent — without authoring a workflow, a configuration file, or an infrastructure module.
+- A merged change progresses **without a platform engineer joining a thread or approving a ticket.**
+- A **non-technical consumer** ships by declaring intent — no workflow, no config file, no infrastructure module.
 - Every production change is **traceable to a human attestation and an immutable evidence stream.**

-> **Speaker notes:** This is 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 two consumer surfaces (technical developer + citizen developer) are covered in the companion deck. Here we focus on *how* the platform makes the North Star real.
+> **Speaker notes:** Open with the cost of the status quo. Every team that stands up its own pipeline, its own Terraform, its own review checklist is paying a tax that doesn't differentiate the business. The platform absorbs all four frictions — that is the value proposition in one sentence. Land the North Star quote: "declare intent → safe production deployment." The litmus test: if a platform engineer still has to touch a ticket for a dev→qa promotion, we haven't delivered the vision.

 ---

-## Slide 3 — What This Platform Is — and Isn't
+## Slide 3 — Where ACDL Sits in Your World

-**What it is:**
+Now that we know the problem, here's where ACDL fits — and where it doesn't.

- **A sovereign delivery boundary.** The platform governs infrastructure and delivery. It does not penetrate upstream product or software development lifecycles. Integration happens through validated, published contracts.
- **Infrastructure consumed, not maintained.** Compute is abstract, containerized, or serverless. The platform does not manage node, OS, or bare-metal lifecycles. Infrastructure is a utility, not a craft.
-
-**What it isn't:**
-
- **Not an upstream development platform.** No product backlogs, sprint ceremonies, or IDE workflows.
- **Not a general-purpose AI.** Autonomy is narrow, scoped to delivery and infrastructure reconciliation, bounded by strict policy envelopes.
- **Not a legacy infrastructure bridge.** No VMs, bare metal, or OS lifecycles.
- **Not a permissive delivery highway.** No escape hatches to bypass the confidence framework or human attestation requirements.
+- **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.
+- **Not a general-purpose AI** — autonomy is narrow, scoped to delivery, bounded by strict policy envelopes.
+- **Not a permissive delivery highway** — no escape hatches to bypass the confidence framework or human attestation requirements.

 > **Speaker notes:** This slide gives leadership the framing they need. The platform is deliberately scoped — it is not trying to be everything. The sovereign boundary means 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.

@@ -57,7 +54,9 @@ What success looks like:

 ## Slide 4 — The Contract-Driven Model

-One small YAML file is all a consumer writes. The platform owns everything else.
+The contract is the boundary between upstream and ACDL. It's all a consumer writes.
+
+A single YAML contract — **module, environment, inputs**. The platform owns everything else.

 ```mermaid
 flowchart LR
@@ -69,15 +68,18 @@ The contract names three things:

 - **Which module** — a catalog of pre-built, security-reviewed building blocks (a static site, a microservice, a database, and more).
 - **Which environment** — `dev`, `qa`, `prod`, or `dr`. The platform raises the safety bar automatically as the environment gets more sensitive.
- **Which inputs** — the handful of values that vary per deployment (a bucket name, a container image, a port).
+- **Which inputs** — infrastructure values that vary per deployment (cpu, memory, port, desired_count).
+- The consumer provides **no AWS account, no VPC, no state backend** — the platform owns the blast radius.

 The consumer does **not** write infrastructure modules, workflow logic, or adapter code. They declare intent; the platform reconciles, provisions, and progresses.

-> **Speaker notes:** Emphasize the asymmetry. The consumer's surface is intentionally tiny — a contract that fits on one screen. The platform's surface is large and opinionated. That asymmetry is what makes "declare intent, not execute operations" concrete.
+> **Speaker notes:** Emphasize the asymmetry. The consumer's surface is intentionally tiny — a contract that fits on one screen. The platform's surface is large and opinionated. That asymmetry is what makes "declare intent, not execute operations" concrete. Note that the contract examples now show infrastructure inputs (cpu, memory, desired_count, port) — not a container image. The image is upstream; the platform governs infrastructure.

 ---

-## Slide 4 — The End-to-End Flow
+## Slide 5 — The End-to-End Flow
+
+Once the contract is written, here's what the platform does with it — every time.

 Every deployment runs the same stages, in the same order, with the same checks — no team-specific pipelines, no tribal runbooks.

@@ -98,16 +100,18 @@ Two properties matter to leadership:
 - **Security and policy checks run *before* any infrastructure is created** — not after the fact, not as a post-deployment audit.
 - **Every stage produces a record** that feeds the confidence signal and the evidence stream. There is no "unchecked" path.

-> **Speaker notes:** Walk left to right once. Don't dwell on internals — the point is that the flow is fixed, opinionated, and identical for every consumer. The two leadership-relevant beats are (1) checks before creation, (2) every stage is evidenced. The confidence signal (Slide 6) is where the "safety is computed" story lands.
+> **Speaker notes:** Walk left to right once. Don't dwell on internals — the point is that the flow is fixed, opinionated, and identical for every consumer. The two leadership-relevant beats are (1) checks before creation, (2) every stage is evidenced. The confidence signal (Slide 7) is where the "safety is computed" story lands.

 ---

-## Slide 5 — Zero-Trust by Default
+## Slide 6 — Zero-Trust by Default
+
+Before any infrastructure is created, here's how access is scoped.

 Consumer repositories hold **no long-lived cloud credentials.** Ever.

- **Authentication** is **OIDC federation** between the platform runners and the cloud provider. Each job mints a short-lived token; no credential is stored in the consumer repo or in a runner secret. *(Testing on GitHub Actions runners; planned for all platform runners.)*
- **Authorization** is **attribute-based (ABAC), not role-based.** Two attribute classes scope every action:
+- **Authentication is OIDC federation** between the platform runners and the cloud provider. Each job mints a short-lived token; no credential is stored in the consumer repo or in a runner secret. *(Testing on GitHub Actions runners; planned for all platform runners.)*
+- **Authorization is attribute-based (ABAC), not role-based.** Two attribute classes scope every action:
  - **Repository identity** — the role's trust policy binds to the exact consumer repo + branch that invoked the workflow.
  - **Resource-creation attributes** — every resource is tagged with `acdl:owner=<consumer-repo>` and `acdl:contract=<contract-id>`. The session policy grants view/update/delete **only on resources whose tags match the calling repo.**

@@ -117,96 +121,101 @@ Consumer repositories hold **no long-lived cloud credentials.** Ever.

 ---

-## Slide 6 — Safety is Computed, Not Assumed
+## Slide 7 — Safety is Computed, Not Assumed

-Every delivery action produces a **measurable, explainable confidence signal** — the platform's certified answer to "is this safe to proceed?"
+Now let's look at how the platform decides whether a deployment is safe.

- **Six weighted inputs:** policy conformance, validation, freshness, source provenance, history, and non-functional requirements (NFRs).
+Every delivery action produces a **measurable, explainable confidence signal** — a weighted sum of observable facts, not a black box. *(Agentic.)*
+
+- **Six weighted inputs** — policy conformance, validation, freshness, source provenance, history, and non-functional requirements (NFRs). 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.
 - **Per-environment thresholds** that rise with sensitivity:

 | Environment | Threshold | Who must attest |
 |---|---|---|
-| dev | ≥ 0.50 | No one — fully autonomous |
-| qa | ≥ 0.75 | QA |
-| prod | ≥ 0.90 | SRE |
-| dr | ≥ 0.95 | SRE + a disaster-recovery drill reference |
+| dev | ≥ 0.50 | No one — fully autonomous *(Testing)* |
+| qa | ≥ 0.75 | QA *(Planned)* |
+| prod | ≥ 0.90 | SRE *(Planned)* |
+| dr | ≥ 0.95 | SRE + a disaster-recovery drill reference *(Planned)* |

 - **A single critical policy finding hard-blocks the deployment**, regardless of every other input. Critical findings are not averaged away.
 - **When the platform halts, it gives a measured reason** — a policy violation, an insufficient signal, a missing attestation — never an opaque, manual-debugging exercise.

-> **Speaker notes:** 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. Leadership cares about this because it makes promotion decisions *reviewable*.
+> **Speaker notes:** 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. Leadership cares about this because it makes promotion decisions *reviewable*. The new confidence signal diagram makes the six inputs and the per-input breakdown visible — emphasize that the weights are manually tuned and the breakdown is auditable, not a black box.

 ---

-## Slide 7 — Policy & Security Enforcement
+## Slide 8 — Security by Construction

-Checks run on **every** deployment, normalized to a single schema regardless of which engine produced them.
+Beyond the confidence signal, security defaults are on by construction — not by opt-in.

- **Infrastructure-as-code policy** (Checkov) — secrets in plaintext, public ingress, IAM wildcards, KMS key references, **required tagging standards** (`acdl:owner`, `acdl:contract`, `acdl:environment`, `acdl:cost-center`).
- **Cloud security posture** (Wiz adapter) — translates cloud security findings into the same normalized record. *(Adapter available today; activates when a Wiz tenant is configured.)*
- **Kubernetes-native policy** (Kyverno adapter) — ready for the GitOps reconciler roadmap item. *(Adapter available today; inactive for Terraform-only stacks.)*
-
-Every check produces a record with **severity, rule ID, pass/fail status, and human-readable message** — consumed uniformly by the confidence signal. No engine-specific escapes.
-
-> **Speaker notes:** 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.
-
---
-
-## Slide 8 — Secure by Default
-
-Security defaults that **do not require a team to opt in.**
+Security defaults that **do not require a team to opt in.** Checks run on **every** deployment, normalized to a single schema regardless of which engine produced them. *(Testing.)*

+- **Infrastructure-as-code policy** (Checkov) — secrets in plaintext, public ingress, IAM wildcards, KMS key references, **required tagging standards** (`acdl:owner`, `acdl:contract`, `acdl:environment`, `acdl:cost-center`). All run *before* infra is created.
+- **Cloud security posture** (Wiz adapter) — translates cloud security findings into the same normalized record. *(Adapter testing; activates when a Wiz tenant is configured.)*
+- **Kubernetes-native policy** (Kyverno adapter) — ready for the GitOps reconciler roadmap item. *(Adapter testing; inactive for Terraform-only stacks.)*
 - **Encryption on every resource** — at-rest encryption is on by default for every primitive (S3, RDS, ECR, ECS, and more). *(Testing.)*
 - **Per-stack customer-managed keys (CMKs)** — one key per deployment, 90-day rotation at creation, **no shared keys across stacks.** *(Testing.)*
- **Managed-key fallback with a loud warning** — standalone primitives fall back to cloud-managed keys only when no CMK is provided, and the platform warns explicitly. Silent use of cloud-managed keys is a security gap we refuse to hide. *(Testing.)*
+- **Managed-key fallback with a loud warning** — standalone primitives fall back to cloud-managed keys only when no CMK is provided, and the platform warns explicitly. *(Testing.)*
 - **Deletion protection on by default** — every resource has `prevent_destroy` on unless a consumer explicitly disables it via a documented feature flag. *(Testing.)*
 - **Safe decommission** — a 2-step pipeline (disable protection → zero counts → destroy) with **two SRE human-attestation gates** and a **change-request validated against the platform CMDB** before any destructive action. *(Testing.)* Encryption keys enter a grace window (default 30 days) so encrypted data remains recoverable during decommission.

-> **Speaker notes:** The phrase to land is "secure by default, not secure by effort." The decommission flow is the counter-argument to "deletion protection makes cleanup impossible" — it's a deliberate, gated, two-approval path, not a lock with no key.
+> **Speaker notes:** 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, not a lock with no key.

 ---

-## Slide 9 — Immutable Audit & Evidence
+## Slide 9 — Accountability & Audit
+
+Computed safety handles the gate. But humans still matter — here's how accountability works.
+
+- **Dev is fully autonomous.** The confidence signal (≥ 0.50) is the only gate. Queue-based handoffs are eliminated from lower environments. *(Testing, Agentic.)*
+- **qa, prod, and dr require deliberate human attestation** — not rubber stamps, but policy-mandated acts of accountability via protected deployment approvals. The approver reviews the contract, the planned Terraform changes, and the accumulated evidence. *(Planned.)*
+- **QA attests to infrastructure readiness — the contract, the planned Terraform changes, and the accumulated evidence. QA does not review application code (that's upstream).**
+- **Separation of duties is enforced** *(Planned)* — the person who approved the qa promotion **cannot** be the person who approves the prod promotion. The platform reads both identities from the outbox and **blocks** on a match, emitting a `SEPARATION_OF_DUTIES_VIOLATION` and routing a halt artifact to SRE on-call.
+- **Timeout discipline** — 1 business day = warn + escalate; 2 business days = auto-freeze + re-submit. Rejection extends the audit chain; it does not tear it up.

 Version control is a **coordination tool, not an evidentiary fortress.** True compliance requires an immutable, externally-stored ledger.

- **Every deployment writes a hash-chained evidence event** — each event links to the previous via a cryptographic hash. Tampering breaks the chain. *(Testing. the DynamoDB outbox.)*
+- **Every deployment writes a hash-chained evidence event** — each event links to the previous via a cryptographic hash. Tampering breaks the chain. *(Testing — the DynamoDB outbox.)*
 - **Tiered storage design:** cold, tamper-proof source of truth (S3 Object Lock, compliance mode, 7-year retention) + a hot query index for fast lookup. *(Outbox tested; S3 Object Lock + JWS detached signatures are planned regulatory-ledger build-out.)*
 - **RPO = 0** — the evidence write is synchronous; a deployment is not acknowledged until the evidence event is durably recorded.
 - **Every production change is traceable to a human attestation** — the QA and prod approver identities are the only durable record outside the VCS's audit log, stored in the outbox keyed by contract.

-> **Speaker notes:** This is the slide for the Head of Infrastructure and anyone who has been through an audit. "The audit trail is a byproduct of deployment, not a project." Note honestly that 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.
+> **Speaker notes:** The "lower environments autonomous, higher environments attested" tenet is the resolution to the classic "move fast vs. be safe" false dichotomy. Be honest: the separation-of-duties *mechanism* (CODEOWNERS routing, identity-distinctness check, the 8-concern attestation matrix) is designed and the dev path is wired; the qa/prod/dr wiring is on the roadmap. The new attestation flow diagram makes the human-in-the-loop path visible. Note the QA clarification: QA attests to infrastructure readiness — the contract, the plan, and the evidence — not application code. The audit trail is a byproduct of deployment, not a project. Note honestly that 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. Badge reclassification: separation of duties = Planned (not "design tested"), dev autonomous = Testing, qa/prod/dr attestation = Planned.

 ---

-## Slide 10 — Human-in-the-Loop Where It Matters
+## Slide 10 — The Vision Realized

-Autonomy and accountability are **not in tension** — they are applied at different environments.
+Here's what success looks like when the North Star is reached.

- **Dev is fully autonomous.** No human gate. The confidence signal (≥ 0.50) is the only gate. Queue-based handoffs are eliminated from lower environments.
- **qa, prod, and dr require deliberate human attestation** — not rubber stamps, but policy-mandated acts of accountability via protected deployment approvals.
- **Separation of duties is enforced** *(design shipped; wiring for qa/prod/dr is planned)* — the person who approved the qa promotion **cannot** be the person who approves the prod promotion. The platform reads both identities from the outbox and **blocks** on a match, emitting a `SEPARATION_OF_DUTIES_VIOLATION` and routing a halt artifact to SRE on-call.
- **Timeout discipline** — 1 business day = warn + escalate; 2 business days = auto-freeze + re-submit. Rejection extends the audit chain; it does not tear it up.
+- **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 is traceable to a human attestation and a tamper-evident evidence event.
+- **Blast radius contained by design.** Zero-trust OIDC + ABAC means a consumer can only touch its own tagged resources.
+- **Infrastructure as a utility, not a craft.** Teams consume infrastructure, they don't maintain it.
+- **A path to the citizen developer.** The same safety envelope that serves a senior engineer will serve a non-technical consumer. *(Agentic.)*

-> **Speaker notes:** The "Lower environments autonomous, higher environments attested" tenet is the resolution to the classic "move fast vs. be safe" false dichotomy. Be honest: the *mechanism* (CODEOWNERS routing, identity-distinctness check, the 8-concern attestation matrix) is designed and the dev path is wired; the qa/prod/dr wiring is on the roadmap.
+> **Speaker notes:** 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. 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.

 ---

-## Slide 11 — Observability Built In
+## Appendix — Table of Contents

-Monitoring is **a platform default, not a per-team project.**
+For deep dives — these slides cover details omitted from the main 10.

- **Uptime monitoring deployed automatically with every stack** — a dedicated monitoring instance (Uptime-kuma on ECS Fargate) is provisioned after any module deploy, in a separate state, with a feature flag to disable. *(Testing.)*
- **Monitored endpoints passed from the deployment's own outputs** — the platform constructs a synthetic monitoring contract from what was just deployed. No manual endpoint registration.
- **Alert channels:** Microsoft Teams webhook, email, SMS, and GitHub issues. *(Testing.)*
- **The uptime URL is published to the developer** via a PR comment — they don't hunt for it.
- **Roadmap:** deeper observability bootstrap (dashboards, runbooks, on-call bindings) as first-class contract fields for prod/dr.
+**Contents:**

-> **Speaker notes:** The Head of DevOps cares about this. The framing: "you don't deploy a service and *then* remember to set up monitoring — the platform does it as part of the deploy." The feature flag means teams with existing monitoring (e.g. Datadog) can opt out cleanly.
+1. Platform-Managed Environments (detail)
+2. Observability Built In (detail)
+3. The Road to the North Star (phased roadmap)
+4. Testing vs. Planned (full inventory)
+5. Glossary
+
+> **Speaker notes:** 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.

 ---

-## Slide 12 — Platform-Managed Environments
+## A1 — Platform-Managed Environments

 A consumer provides **no AWS account, no VPC, no subnet, no state backend, no runner key.** The platform owns the blast radius.

@@ -225,44 +234,79 @@ The consumer selects an environment **by name** in their contract (`environment:

 ---

-## Slide 13 — Portability & Future-Proofing
+## A2 — Observability Built In

-The platform is **opinionated, but not painted into a corner.**
+Monitoring is **a platform default, not a per-team project.** *(Testing.)*

- **Angine-agnostic core.** The contract, the resolved stack, the policy results, the confidence signal, and the evidence stream are all defined *without reference to any specific infrastructure tool.* Today there is one adapter (Terraform). *(OpenTofu, Pulumi, Kubernetes CRDs are future adapters — no architectural change required.)*
- **Forge-agnostic contract ingestion.** The platform Lambda reads a configurable API base for GitHub or Gitea. *(Testing.)*
- **Portable contracts.** The contract schema, the confidence signal, and the audit stream are engine- and VCS-agnostic. A second VCS (e.g. GitLab) needs a VCS adapter + a workflow-template translator — **no change to the modules, the contract standard, the confidence model, or the audit stream.**
- **Pattern recognition compounds value over time.** As the platform observes recurring contract patterns, it can synthesize and offer reusable modules. *(Future capability, not a current commitment — but the design allows it.)*
+- **Uptime monitoring deployed automatically with every stack** — a dedicated monitoring instance (Uptime-kuma on ECS Fargate) is provisioned after any module deploy, in a separate state, with a feature flag to disable.
+- **Monitored endpoints passed from the deployment's own outputs** — the platform constructs a synthetic monitoring contract from what was just deployed. No manual endpoint registration.
+- **Alert channels:** Microsoft Teams webhook, email, SMS, and GitHub issues. *(Testing.)*
+- **The uptime URL is published to the developer** via a PR comment — they don't hunt for it.
+- **Roadmap:** deeper observability bootstrap (dashboards, runbooks, on-call bindings) as first-class contract fields for prod/dr. *(Planned.)*

-> **Speaker notes:** This is the "we won't have to rewrite this in two years" slide. The bet is that the engine (Terraform today) will change, but the contract + confidence + audit model won't. Leadership should hear: the investment is in the abstraction, not the tool.
+> **Speaker notes:** The Head of DevOps cares about this. The framing: "you don't deploy a service and *then* remember to set up monitoring — the platform does it as part of the deploy." The feature flag means teams with existing monitoring (e.g. Datadog) can opt out cleanly.

 ---

-## Slide 14 — Roadmap: Honest Testing vs. Planned
+## A3 — The Road to the North Star

-**Testing:**
+*Proposed phasing — not formally planned.*
+
+A phased roadmap from the current Testing baseline to the full North Star:
+
+- **Phase 1 — Testing baseline (current):** contract-driven deploys, zero-trust OIDC + ABAC on GitHub Actions, confidence signal gating, hash-chained evidence, encryption by default, deletion protection + safe decommission, uptime monitoring, platform-managed environments.
+- **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 extension points), additional engine adapters (OpenTofu, Pulumi, Kubernetes CRDs), deeper observability bootstrap.
+- **Phase 4 — Agentic frontier:** dynamic module creation from a contract (the agentic citizen-developer composition mechanism), pattern recognition that compounds value over time.
+
+> **Speaker notes:** 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. Invite questions on any phase boundary.
+
+---
+
+## A4 — Testing vs. Planned (Full Inventory)
+
+**Testing** (works internally, dev pilot-ready) — 11 capabilities:

 - Contract-driven deploys with a versioned reusable workflow.
 - Module catalog (primitives + modules) with validated examples.
 - Zero-trust OIDC + ABAC on GitHub Actions runners.
 - Security + policy checks before infra creation (Checkov; Wiz + Kyverno adapters ready).
- Confidence signal (6 inputs, per-env thresholds) gating promotion.
+- Confidence signal (6 inputs, per-env thresholds) gating promotion. *(Agentic.)*
 - Hash-chained, tamper-evident evidence outbox (RPO = 0).
 - Encryption by default + per-stack customer-managed keys.
 - Deletion protection by default + safe decommission with SRE gates + CMDB validation.
 - Uptime monitoring deployed automatically with every stack.
 - Platform-managed environments + friendly onboarding.
- Local reproducibility (`run_ci.sh` mirrors the CI pipeline).
- Forge-agnostic contract ingestion (GitHub + Gitea).
+- Engine-agnostic core (1 adapter: Terraform) + VCS-agnostic ingestion (GitHub + Gitea).

-**Planned (on the roadmap, not yet shipped):**
+**Planned** (on the roadmap, not yet implemented) — 9 capabilities:

 - Real OIDC federation on all platform runners (Gitea Actions OIDC pending an upstream merge).
 - HITL wiring for qa / prod / dr environments (design shipped; wiring is next).
 - Full regulatory ledger: S3 Object Lock (7-yr compliance mode) + JWS detached signatures + daily checkpoints.
 - Compliance milestone: per-module extension points for GDPR, SOX, SOC2, DORA.
 - Environment self-service (a consumer-facing flow to request and provision a new environment).
- Dynamic module creation from a contract (the agentic "citizen developer" composition mechanism).
+- Dynamic module creation from a contract (the agentic "citizen developer" composition mechanism). *(Agentic.)*
+- Pattern recognition compounds value over time. *(Agentic.)*
 - Additional engine adapters (OpenTofu, Pulumi, Kubernetes CRDs).
+- Deeper observability bootstrap (dashboards, runbooks, on-call bindings).

-> **Speaker notes:** Close on honesty. The platform delivers real, verifiable value today — and the roadmap is concrete, not aspirational hand-waving. Invite questions on any "planned" item; each has a defined milestone and a clear reason it isn't shipped yet (usually an upstream dependency, not an engineering gap).
+> **Speaker notes:** Close on honesty. The platform delivers real, verifiable value today — 11 capabilities that work internally. 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.
+
+---
+
+## A5 — Glossary
+
+| Term | Meaning |
+|---|---|
+| **OIDC** | OpenID Connect — federation protocol for short-lived tokens, no long-lived credentials |
+| **ABAC** | Attribute-Based Access Control — access scoped by resource tags + repo identity, not roles |
+| **CMK** | Customer-Managed Key — per-stack encryption key, 90-day rotation, no shared keys |
+| **CMDB** | Configuration Management Database — validates change requests for decommission |
+| **RPO** | Recovery Point Objective — RPO = 0 means evidence is written synchronously, no data loss |
+| **HITL** | Human-in-the-Loop — deliberate human attestation required for qa/prod/dr environments |
+| **VCS** | Version Control System — the git hosting platform (GitHub, Gitea, GitLab) |
+| **NFR** | Non-Functional Requirement — encryption, tagging, observability standards |
+| **IR** | Intermediate Representation — the engine-agnostic stack definition between contract and Terraform |
+
+> **Speaker notes:** 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.
@@ -20,7 +20,8 @@ style: |
  blockquote { border-left: 4px solid #D6002A; color: #2E2E2E; font-size: 20px; }
  pre { font-size: 14px; line-height: 1.3; }
  code { font-size: 14px; }
-  img { display: block; margin: 0 auto; max-height: 300px; }
+  img { display: block; margin: 0 auto; max-height: 280px; }
+  em.story { color: #6B7280; font-size: 16px; font-style: italic; }
  .badge {
    display: inline-block; padding: 2px 8px; border-radius: 4px;
    font-size: 14px; font-weight: 600;
@@ -44,24 +45,26 @@ section.title h3 { color: #F0F0F0; font-weight: 400; font-size: 22px; margin-top

 ---

-# Two Consumer Surfaces, One Platform
+# Where ACDL Sits in Your World

-The platform serves **two kinds of consumer** — both converge on the **same contract, the same policy envelope, and the same evidence stream.**
+<em class="story">Story beat: Here's who uses the platform and where the boundary is.</em>

-![w:1000](assets/png/developer-experience-01-two-surfaces.png)
+![w:1100](assets/png/developer-experience-01b-scope-boundary.png)

 - **Technical developer** — owns app code + a contract + a thin CI definition
 - **Citizen developer** — declares intent in plain language; an AI agent produces a contract that passes the **same** safety envelope <span class="badge agentic">Agentic</span>
-
-The platform is **opinionated in what it accepts, regardless of who is declaring.** There is no "citizen developer mode" with weaker checks.
+- **Upstream is anything** — your IDE, an agentic SDLC, or vibe coding on a laptop. ACDL doesn't care how the contract was produced
+- **ACDL is infrastructure only** — it provisions and governs AWS resources. Application deployment is upstream

 ---

 # The Contract — The Entire Consumer Surface

+<em class="story">Story beat: Now let's look at what a consumer actually writes — it's tiny.</em>
+
 Three things. That is the entire consumer-side surface.

-<img src="assets/png/developer-experience-02-what-dev-does.png" style="float: right; width: 40%; margin-left: 20px; margin-bottom: 10px;" />
+<img src="assets/png/developer-experience-02-what-dev-does.png" style="float: right; width: 38%; margin-left: 20px; margin-bottom: 10px;" />

 - **1. App code** — the consumer's service, at the top level of the repo
 - **2. A contract** — a single YAML file: module, environment, inputs
@@ -71,7 +74,9 @@ uses: acdl/pipelines/deploy.yaml@v1.6
 module: microservice
 environment: dev
 inputs:
-  image: my-registry/my-microservice:latest
+  cpu: 256
+  memory: 512
+  desired_count: 2
  port: 8080
 ```

@@ -82,7 +87,9 @@ inputs:

 # The Developer Feedback Loop

-Developers see **what the platform is doing**, in real time, in their own run logs. <span class="badge testing">Testing</span>
+<em class="story">Story beat: Once you push, here's what you see — in real time, in your own logs.</em>
+
+Developers see **what the platform is doing**, in real time. <span class="badge testing">Testing</span>

 - **Streamed output by default** — the infrastructure plan, policy-check results, and each check record flow to stdout
 - **PR comments after every successful pipeline stage** — a developer always knows where they stand without refreshing a dashboard
@@ -95,6 +102,8 @@ Developers see **what the platform is doing**, in real time, in their own run lo

 # Versioned, Predictable Releases

+<em class="story">Story beat: You control when you absorb platform improvements — no surprise upgrades.</em>
+
 Consumers control **when** they absorb platform improvements. <span class="badge testing">Testing</span>

 - **Floating MAJOR + MINOR tags** (e.g. `@v1.6`) — a consumer automatically receives patch updates within the line
@@ -107,6 +116,8 @@ Consumers control **when** they absorb platform improvements. <span class="badge

 # Friendly Onboarding

+<em class="story">Story beat: First impressions matter — the platform fails gracefully, not opaquely.</em>
+
 First impressions of a platform are made **when it fails for the first time.** The platform fails gracefully. <span class="badge testing">Testing</span>

 When no environment is bound, the platform emits a **user-friendly onboarding prompt** instead of failing opaquely:
@@ -124,13 +135,17 @@ The pipeline then **exits without attempting a deployment** — no partial state

 # Safe Promotion Path

-The contract is environment-agnostic by design. Promotion is **a workflow choice, not a contract edit** — the platform raises the bar automatically.
+<em class="story">Story beat: Promotion is a workflow choice, not a contract edit — and the bar rises automatically.</em>
+
+The contract is environment-agnostic. The platform raises the bar automatically.
+
+![w:1000](assets/png/developer-experience-04-promotion-journey.png)

 <table style="width: 100%; border: none;">
 <tr>
 <td style="width: 50%; vertical-align: top; border: none; padding-right: 12px;">

-**Approach A — One contract, one job per environment.** The environment is passed by each job and interpolated at runtime.
+**Approach A — One contract, one job per environment.** Environment passed by each job.

 ```yaml
 jobs:
@@ -146,7 +161,7 @@ jobs:
 </td>
 <td style="width: 50%; vertical-align: top; border: none; padding-left: 12px;">

-**Approach B — Environment-specific contracts.** When inputs genuinely differ, each job points at its own contract file.
+**Approach B — Environment-specific contracts.** When inputs differ per environment.

 ```yaml
 jobs:
@@ -163,25 +178,20 @@ jobs:
 </tr>
 </table>

-| Environment | What the platform adds |
-|---|---|
-| dev | Confidence ≥ 0.50, fully autonomous <span class="badge agentic">Agentic</span> |
-| qa | QA human attestation + confidence ≥ 0.75 |
-| prod | SRE human attestation + confidence ≥ 0.90 |
-
 <style>
 section { font-size: 16px; }
 pre { font-size: 10px; line-height: 1.2; }
 code { font-size: 10px; }
 td { font-size: 14px; }
-table { font-size: 14px; }
 </style>

 ---

 # Safe Decommission

-Tearing down a stack is **as deliberate as deploying one** — and just as gated. <span class="badge testing">Testing</span>
+<em class="story">Story beat: Tearing down is as deliberate as deploying — and just as gated.</em>
+
+Tearing down a stack is **as deliberate as deploying one.** <span class="badge testing">Testing</span>

 ```yaml
 uses: acdl/.github/workflows/deploy.yml@v1.8
@@ -202,12 +212,14 @@ The per-stack encryption key enters a **grace window** (default 30 days) so encr

 # Self-Service Module Catalog

-Developers pick from **pre-built, security-reviewed building blocks** — they don't author infrastructure from scratch. <span class="badge testing">Testing</span>
+<em class="story">Story beat: You don't author infrastructure — you pick from pre-built, security-reviewed building blocks.</em>
+
+Developers pick from **pre-built, security-reviewed building blocks.** <span class="badge testing">Testing</span>

 - **Primitives** — single-purpose resources (S3, VPC, ECS, IAM, load balancer, container registry, CloudFront, WAF, RDS), each with documented inputs/outputs, usage, compliance extension points, and versioning
 - **Modules** — composed patterns (a static site with CDN + WAF; a microservice with VPC + ECS + load balancer + registry)
 - **Validated examples per module** — `simple.yaml` + `complex.yaml` + variation files, validated against the contract schema in CI. Examples cannot drift from the schema silently
- **Auto-promotion of patterns** — a thin-composition layer is auto-promoted to the catalog after 3 observed usages <span class="badge planned">Planned</span> <span class="badge agentic">Agentic</span>
+- **Auto-promotion of patterns** — auto-promoted to the catalog after 3 observed usages <span class="badge planned">Planned</span> <span class="badge agentic">Agentic</span>
 - **Compliance extension points** — each module lists where GDPR, SOX, SOC2, DORA controls will wire in <span class="badge planned">Planned</span>

 ---
@@ -217,10 +229,97 @@ Developers pick from **pre-built, security-reviewed building blocks** — they d

 # The Desired Outcomes

+<em class="story">Story beat: Here's what this delivers to the organization.</em>
+
 - **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. Encryption, deletion protection, uptime monitoring, policy checks, and evidence are on by construction.
+- **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 is traceable to a human attestation and a tamper-evident evidence event.
 - **Blast radius contained by design.** Zero-trust OIDC + ABAC means a consumer can only touch its own tagged resources.
 - **The bottleneck moves off the platform team's ticket queue.** A merged change progresses through lower environments without a platform engineer joining a thread.
- **Infrastructure as a utility, not a craft.** The platform abstracts compute, networking, and state. Teams consume infrastructure, they don't maintain it — and the platform compounds value over time by learning from recurring patterns.
- **A 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. <span class="badge agentic">Agentic</span>
+- **Infrastructure as a utility, not a craft.** Teams consume infrastructure, they don't maintain it — and the platform compounds value over time by learning from recurring patterns.
+- **A path to the citizen developer.** The same safety envelope that serves a senior engineer will serve a non-technical consumer. <span class="badge agentic">Agentic</span>
+
+---
+
+<!-- _class: title -->
+<!-- _paginate: false -->
+
+# Appendix
+
+<em class="story">For deep dives — these slides cover details omitted from the main 10.</em>
+
+**Contents:**
+
+1. The Citizen Developer Experience (full)
+2. No Platform Code, No Cloning (detail)
+3. Local Reproducibility (detail)
+4. The Road to the North Star (phased roadmap)
+5. Glossary
+
+---
+
+# A1 — The Citizen Developer Experience
+
+A non-technical consumer ships a production deployment **by declaring intent** — without authoring a workflow, a configuration file, or an infrastructure module.
+
+- The consumer opens an issue describing what they need (e.g. "a web API for the pricing service")
+- An AI agent maps the intent to a contract referencing a module from the **reviewed skill catalog**
+- The contract enters the **same pipeline** and must clear the **same confidence gate** before promotion
+
+**Guardrails that make this safe:**
+
+- Skills are **versioned, signed, and reviewed for sensitive data before release** (Infra & Ops owns the review)
+- Agents are **stateless** — all state lives in the platform; the platform trusts and **always verifies**
+- The agent's trace and submission confidence are captured in the contract for review
+
+<span class="badge planned">Skill catalog + real agent runtime: planned</span> <span class="badge agentic">Agentic</span>
+
+---
+
+# A2 — No Platform Code, No Cloning
+
+Consumers `uses:` a **versioned** central workflow. The platform fetches itself at run time. The consumer **never touches platform internals.**
+
+![w:1000](assets/png/developer-experience-03-no-cloning.png)
+
+- The consumer's CI definition is a thin wrapper — one `uses:` line
+- The runner checks out the consumer repo, then checks out the platform repo into the workspace
+- The platform installs its own runtime dependencies — the consumer installs nothing
+- When the platform ships a fix, every consumer on a floating tag gets it on their next run
+
+---
+
+# A3 — Local Reproducibility
+
+The entire CI pipeline runs **from the shell**, not just in CI. <span class="badge testing">Testing</span>
+
+- `scripts/run_ci.sh` mirrors the CI pipeline locally — the same three stages (lint → test → check-only) in sequence
+- `scripts/run_platform.sh --check-only` runs the platform **offline** — no AWS, no policy engine, no outbox required. Validates a contract end-to-end before pushing
+- `--plan-only` runs through the infrastructure plan without applying
+- The CI and deploy pipelines are defined by **declarative contracts** (YAML instances validated against JSON Schemas) — a single source of truth that both workflows implement
+
+---
+
+<!-- _class: title -->
+<!-- _paginate: false -->
+
+# A4 — The Road to the North Star
+
+*Proposed phasing — not formally planned.*
+
+![w:1100](assets/png/road-to-north-star.png)
+
+---
+
+# A5 — Glossary
+
+| Term | Meaning |
+|---|---|
+| **OIDC** | OpenID Connect — federation protocol for short-lived tokens, no long-lived credentials |
+| **ABAC** | Attribute-Based Access Control — access scoped by resource tags + repo identity, not roles |
+| **CMK** | Customer-Managed Key — per-stack encryption key, 90-day rotation, no shared keys |
+| **CMDB** | Configuration Management Database — validates change requests for decommission |
+| **RPO** | Recovery Point Objective — RPO = 0 means evidence is written synchronously, no data loss |
+| **HITL** | Human-in-the-Loop — deliberate human attestation required for qa/prod/dr environments |
+| **VCS** | Version Control System — the git hosting platform (GitHub, Gitea, GitLab) |
+| **NFR** | Non-Functional Requirement — encryption, tagging, observability standards |
@@ -0,0 +1,215 @@
+# The Developer Experience — Talking Points
+
+> **Companion to:** `the-developer-experience-marp.md` (10 main + 6 appendix = 16 slides)
+> **Content source:** `the-developer-experience.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 covers *who uses the platform and how fast/safe they ship*, not the internal mechanics (that's the companion deck)
+- Set the frame: velocity without sacrificing safety, and security/observability/compliance as platform defaults rather than per-team effort
+
+**Key takeaway:** The consumer surface is intentionally tiny. The platform's surface is large and opinionated.
+
+---
+
+## Slide 2 — Where ACDL Sits in Your World
+
+**Talking points:**
+- This is the scope-boundary slide — here's who uses the platform, and here's where ACDL's responsibility starts and stops
+- Two consumer paths converge on the same contract: **technical** developer writes the contract directly; **citizen** developer declares intent and an AI agent produces a contract that passes the same safety envelope
+- Upstream is anything — your IDE, an agentic SDLC, or vibe coding on a laptop. ACDL doesn't care how the contract was produced
+- ACDL is infrastructure only — it provisions and governs AWS resources. Application deployment is upstream of the contract
+- The two surfaces are *parallel*, not a progression. A citizen developer doesn't "graduate" to the developer surface. There is no "citizen developer mode" with weaker checks
+
+**Key takeaway:** Two consumer paths, one safety envelope. ACDL is infra only — anything upstream is fair game.
+
+---
+
+## Slide 3 — The Contract — The Entire Consumer Surface
+
+**Talking points:**
+- Hold this slide — the audience should sit with how small the consumer surface is. Three things: app code, a contract, a one-line CI definition
+- The contract is a single YAML file: module, environment, inputs. That's the entire consumer-facing interface to production
+- The contract example now shows **infrastructure inputs** (cpu, memory, desired_count, port) — not an `image:` field. The consumer declares capacity and shape; the platform resolves the rest
+- Walk the "does not" list quickly — no infrastructure modules, no platform repo cloning, no cloud credentials, no state backends. Every item is a category of toil the platform removes
+- For the Head of DevOps: this is the lever for throughput — the bottleneck moves off the platform team's ticket queue
+
+**Key takeaway:** Three things. That's the entire consumer-side surface. Everything else is the platform's job.
+
+---
+
+## Slide 4 — The Developer Feedback Loop
+
+**Talking points:**
+- This directly answers "but developers hate platforms that hide what they're doing" — the platform is opinionated about *what* runs, not *opaque* about *that* it runs
+- Streamed output by default — the plan, policy results, and each check record flow to stdout
+- PR comments after every successful pipeline stage — a developer always knows where they stand without refreshing a dashboard
+- Connection strings posted as PR comments — human-readable, no hunting. Runtime secrets go to encrypted Parameter Store (KMS-encrypted, namespaced), never to logs
+- The "errors become GitHub issues" point is a DX win that also helps the platform team — every consumer failure is a tracked, queryable artifact, not a lost log line
+- Clear, explainable halt reasons — a policy violation, an insufficient confidence signal, or a missing attestation. Never an opaque debugging exercise
+
+**Key takeaway:** The platform closes the feedback loop — streamed output, PR comments, clear halt reasons, no secrets in logs.
+
+---
+
+## Slide 5 — Versioned, Predictable Releases
+
+**Talking points:**
+- This is the "no surprise upgrades" story — consumers aren't forced to chase the platform, and the platform isn't forced to support N forks of every workflow
+- Floating MAJOR + MINOR tags (e.g. `@v1.6`) — a consumer automatically receives patch updates within the line. Pin to exact version for stability, or float on MAJOR only for new features
+- Semantic versioning with a clear contract: interface → MAJOR, behavior → MINOR, lifecycle → PATCH
+- Unversioned references (`@main`, bare) are discouraged — the versioned tag is the only immutability lever a consumer has
+- The automated release job computes the next semver on merge to main, creates the tag, and updates the floating tags — no manual release process
+
+**Key takeaway:** Consumers control when they absorb platform improvements. No surprise upgrades.
+
+---
+
+## Slide 6 — Friendly Onboarding
+
+**Talking points:**
+- This looks like a small thing; it's actually a cultural one — the platform's posture is "help me get started," not "you should have known"
+- First impressions of a platform are made when it fails for the first time. The platform fails gracefully with a guided prompt, not an opaque error
+- The prompt tells the consumer: what's missing, what the platform will provision, the expected turnaround, and how to request an environment
+- The pipeline exits without attempting a deployment — no partial state, no confusing errors
+- Be honest: the citizen developer onboarding path is planned, not yet shipped
+
+**Key takeaway:** The platform fails gracefully. First impressions drive adoption — platforms that fail opaquely get routed around.
+
+---
+
+## Slide 7 — Safe Promotion Path
+
+**Talking points:**
+- Promotion is a workflow choice, not a contract mutation — this matters because it means a promotion can be reviewed as a *diff in the workflow*, not as a rewritten contract
+- The new promotion journey diagram shows the rising bar: dev (autonomous) → qa (QA attests) → prod (SRE attests) → dr (SRE attests + DR drill)
+- Approach A (one contract, environment passed by the job) keeps the single source of truth — the contract never changes
+- Approach B (environment-specific contracts) lets teams whose inputs genuinely vary keep that variation explicit and reviewable
+- The rising bar is annotated with maturity: **dev = Testing** (works internally, pilot-ready); **qa/prod/dr = Planned** (on the roadmap). Be honest about that split
+- Separation of duties is enforced — the QA approver cannot be the prod approver. No staging environment — the design deliberately removes the "staging is basically prod but not really" anti-pattern
+
+**Key takeaway:** Change the environment field, not the contract. The platform raises the bar automatically. The consumer can't bypass the gates.
+
+---
+
+## Slide 8 — Safe Decommission
+
+**Talking points:**
+- The counter-argument to "deletion protection makes cleanup impossible" — decommission is a first-class, gated, two-approval flow, not a lock with no key
+- The change request must be `approved` in the CMDB and match the consumer repo — no CR, no decommission
+- Two SRE human-attestation gates: one to disable deletion protection, a second to zero counts and destroy
+- The per-stack encryption key enters a 30-day grace window so encrypted data remains recoverable — the key is permanently deleted only after the window expires
+- For the Head of Infrastructure: the CMDB validation means decommission is auditable, not just possible
+
+**Key takeaway:** Tearing down is as gated as deploying. Two SRE approvals, CMDB-validated change request, 30-day key grace window.
+
+---
+
+## Slide 9 — Self-Service Module Catalog
+
+**Talking points:**
+- The catalog is what makes "declare intent" practical — you can only declare a module that exists
+- Primitives are single-purpose resources (S3, VPC, ECS, IAM, ALB, ECR, CloudFront, WAF, RDS) — each with documented inputs/outputs, usage, compliance extension points, and versioning
+- Modules are composed patterns (a static site with CDN + WAF; a microservice with VPC + ECS + ALB + registry) — one well-reviewed module serves every consumer
+- Validated examples per module — `simple.yaml` + `complex.yaml` + variation files, validated against the contract schema in CI. Examples cannot drift from the schema silently
+- For leadership: the catalog is the leverage — a fix to a module serves every consumer on the next run. This is the compounding asset
+- Auto-promotion of patterns (after 3 observed usages) and compliance extension points (GDPR, SOX, SOC2, DORA) are planned
+
+**Key takeaway:** The catalog is the compounding asset. One well-reviewed module serves every consumer. A fix serves everyone on the next run.
+
+---
+
+## Slide 10 — The Desired Outcomes
+
+**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. Encryption, deletion protection, uptime monitoring, policy checks, and evidence are on by construction
+- Auditability as a byproduct, not a project — every production change is traceable to a human attestation and a tamper-evident evidence event
+- The bottleneck moves off the platform team's ticket queue — a merged change progresses through lower environments without a platform engineer joining a thread
+- 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:** Velocity without sacrificing safety. Security and auditability as byproducts. The bottleneck moves off the platform team's queue.
+
+---
+
+## Appendix — Contents
+
+**Talking points:**
+- These are backup slides for Q&A — don't walk through them in the main talk unless time permits
+- Use A1 when asked about the citizen developer detail; A2 for the no-cloning mechanism; A3 for local reproducibility; A4 for the roadmap; A5 for term definitions
+
+**Key takeaway:** The appendix is the deep-dive drawer. Pull a slide when the audience asks for the detail behind a main-slide claim.
+
+---
+
+## A1 — The Citizen Developer Experience
+
+**Talking points:**
+- The framing is **vibe coding on a laptop** — the consumer describes what they want in plain language; an AI agent turns that into a contract the platform treats identically to a senior engineer's
+- The consumer opens an issue (e.g. "a web API for the pricing service"); an AI agent maps the intent to a contract referencing a module from the reviewed skill catalog
+- The contract enters the same pipeline and must clear the same confidence gate — no weaker mode
+- Guardrails: skills are versioned, signed, and reviewed for sensitive data before release (Infra & Ops owns the review); agents are stateless — all state lives in the platform; the platform trusts and always verifies
+- The agent's trace and submission confidence are captured in the contract (`profile: agentic`), so a reviewer can see how the contract was produced
+- Be honest about maturity: the mechanism is designed and stub-proven; the full skill catalog and real agent runtime are planned
+
+**Key takeaway:** Vibe coding on a laptop — but every submission passes the same safety envelope. The agent produces the contract; the platform verifies it.
+
+---
+
+## A2 — No Platform Code, No Cloning
+
+**Talking points:**
+- The consumer's CI definition is a thin wrapper — one `uses:` line pointing at a versioned tag. That's the only coupling
+- The runner checks out the consumer repo, then checks out the platform repo into the workspace. The platform installs its own runtime dependencies — the consumer installs nothing
+- The consumer never clones the platform repo, never invokes platform scripts locally (optional `--check-only` validation is available but not required)
+- When the platform ships a fix, every consumer on a floating MAJOR.MINOR tag gets it on their next run — no per-repo upgrade project
+- For the Head of Cloud: there is no "platform code in every consumer repo" problem. The version-pinned `uses:` line is the only coupling, and it updates itself within the line
+
+**Key takeaway:** One `uses:` line is the only coupling. The platform fetches itself at run time. No per-repo upgrade projects.
+
+---
+
+## A3 — Local Reproducibility
+
+**Talking points:**
+- The entire CI pipeline runs from the shell, not just in CI — no "works on my machine, fails in CI" gap
+- `scripts/run_ci.sh` mirrors the CI pipeline locally — the same three stages (lint → test → check-only) in sequence
+- `scripts/run_platform.sh --check-only` runs the platform offline — no AWS, no policy engine, no outbox required. Validates a contract end-to-end before pushing
+- `--plan-only` runs through the infrastructure plan without applying
+- The CI and deploy pipelines are defined by declarative contracts (YAML instances validated against JSON Schemas) — a single source of truth that both workflows implement
+
+**Key takeaway:** Validate offline, plan offline, push when confident. The same declarative contract drives local tooling and CI.
+
+---
+
+## A4 — The Road to the North Star
+
+**Talking points:**
+- Call this out explicitly: **proposed phasing, not formally planned** — don't let the audience read it as a commitment
+- Phase 1 is what's tested today — core platform (contract, catalog, evidence)
+- Phase 2 is the next milestone — safe promotion wiring for qa/prod/dr
+- Phase 3 introduces the agentic surface — skill catalog + agents
+- Phase 4 is the north star — citizen developer GA on the same safety envelope
+- Use this slide only when an audience member asks "how do you get from here to there"
+
+**Key takeaway:** A proposed path from the tested core to the citizen developer north star — proposed phasing, not formally planned.
+
+---
+
+## A5 — Glossary
+
+**Talking points:**
+- Keep this slide in your back pocket for the audience member who asks "what does ABAC actually mean?" — don't read it aloud
+- OIDC = short-lived federation tokens, no long-lived credentials; ABAC = access scoped by resource tags + repo identity, not roles
+- CMK = per-stack encryption key, 90-day rotation; CMDB = validates change requests for decommission
+- RPO = 0 means evidence written synchronously, no data loss; HITL = deliberate human attestation for qa/prod/dr
+- VCS = the git hosting platform (GitHub, Gitea, GitLab); NFR = encryption, tagging, observability standards
+
+**Key takeaway:** The deck uses real security and ops vocabulary. The glossary is the cheat sheet for the audience member who wants the definitions.
@@ -2,45 +2,67 @@

 > **Subtitle:** Agentic Cloud Delivery Platform
 > **Audience:** Senior Leadership, CTO, Head of Cloud, Head of Infrastructure, Head of DevOps
-> **Length:** ~15 minutes · 13 slides
+> **Length:** ~15 minutes · 10 main + 6 appendix = 16 slides
 > **Purpose:** Sell the developer experience and the citizen developer experience to tech leadership — velocity without sacrificing safety, and security/observability/compliance as platform defaults rather than per-team effort.
-> **Maturity framing:** "Testing" = shipped and verified. "Planned" = on the roadmap, not yet shipped.
+> **Maturity framing:** "Testing" = works internally, dev pilot-ready. "Planned" = on the roadmap. "Agentic" = involves AI agents or autonomous decision-making.

 ---

-## Slide 1 — Two Consumer Surfaces, One Platform
+## Slide 1 — Title

-The platform serves **two kinds of consumer** through two coordinated interfaces — but both converge on the **same contract, the same policy envelope, and the same evidence stream.**
+The consumer surface is intentionally tiny. The platform's surface is large and opinionated.
+
+> **Speaker notes:** Brief introduction — this deck covers *who uses the platform and how fast/safe they ship*, not the internal mechanics (that's the companion deck). Set the frame: velocity without sacrificing safety, and security/observability/compliance as platform defaults rather than per-team effort.
+
+---
+
+## Slide 2 — Where ACDL Sits in Your World
+
+Story beat: Here's who uses the platform and where the boundary is.
+
+The platform serves **two kinds of consumer** through two coordinated paths — but both converge on the **same contract, the same policy envelope, and the same evidence stream.**

 ```mermaid
 flowchart TD
-    A["Technical developer"] --> C["Contract YAML"]
-    B["Citizen developer<br/>(non-technical)"] --> D["Declares intent in<br/>natural language"]
-    D --> E["Agent produces<br/>the contract"]
-    C --> F["Same platform:<br/>resolve → check → plan → policy<br/>→ confidence → evidence → apply"]
-    E --> F
-    F --> G["Same safety guarantees,<br/>same audit trail"]
+    U1["Anything upstream<br/>(IDE / agentic SDLC / vibe coding)"] --> T["Technical developer<br/>writes app + contract"]
+    U1 --> C["Citizen developer<br/>declares intent"]
+    T --> K["Contract YAML"]
+    C --> AI["An AI agent maps intent<br/>to a reviewed-skill contract"]
+    AI --> K
+    K --> ACDL["ACDL — infrastructure only<br/>resolve → check → plan → policy<br/>→ confidence → evidence → apply"]
+    ACDL --> AWS["AWS resources provisioned + governed"]
 ```

 - **Technical developer** — owns app code + a contract + a thin CI definition. Uses the full module catalog and inputs.
- **Citizen developer** — declares intent in plain language; an AI agent produces a contract that passes the **same** safety envelope as a senior engineer's.
+- **Citizen developer** — declares intent in plain language; an AI agent produces a contract that passes the **same** safety envelope as a senior engineer's. <span class="badge agentic">Agentic</span>
+- **Upstream is anything** — your IDE, an agentic SDLC, or vibe coding on a laptop. ACDL doesn't care how the contract was produced.
+- **ACDL is infrastructure only** — it provisions and governs AWS resources. Application deployment is upstream.

 The platform is **opinionated in what it accepts, regardless of who is declaring.** There is no "citizen developer mode" with weaker checks.

-> **Speaker notes:** This is the thesis of the deck. The two surfaces are *parallel*, not a progression — a citizen developer doesn't "graduate" to the developer surface. Both produce a contract; both get the same treatment. The leadership takeaway: we expand who can ship safely without lowering the bar.
+> **Speaker notes:** This is the thesis of the deck. The two surfaces are *parallel*, not a progression — a citizen developer doesn't "graduate" to the developer surface. Both produce a contract; both get the same treatment. The scope boundary matters: anything upstream of the contract is out of ACDL's concern — ACDL is the infrastructure layer that takes a contract and governs the AWS resources. The leadership takeaway: we expand who can ship safely without lowering the bar.

 ---

-## Slide 2 — What a Developer Actually Does
+## Slide 3 — The Contract — The Entire Consumer Surface
+
+Story beat: Now let's look at what a consumer actually writes — it's tiny.

 Three things. That is the entire consumer-side surface.

-```mermaid
-flowchart LR
-    A["1. App code<br/>(top level of the repo)"] --> D["Push to main"]
-    B["2. Contract<br/>(.acdl/contract.yaml)"] --> D
-    C["3. CI definition<br/>(.github/workflows/deploy.yml<br/>— one 'uses:' line)"] --> D
-    D --> E["Platform does the rest"]
+1. **App code** — the consumer's service, at the top level of the repo
+2. **A contract** — a single YAML file: module, environment, inputs
+3. **A one-line CI definition** — a thin `uses:` wrapper pointing at a versioned platform workflow
+
+```yaml
+uses: acdl/pipelines/deploy.yaml@v1.6
+module: microservice
+environment: dev
+inputs:
+  cpu: 256
+  memory: 512
+  desired_count: 2
+  port: 8080
 ```

 The developer does **not**:
@@ -51,16 +73,196 @@ The developer does **not**:
 - Hold cloud credentials.
 - Maintain a state backend, a VPC, or a runner.

-> **Speaker notes:** Hold this slide. The audience should sit with how small the consumer surface is. Every item in the "does not" list is a category of toil the platform removes. For the Head of DevOps: this is the lever for throughput — the bottleneck moves off the platform team's ticket queue.
+> **Speaker notes:** Hold this slide. The audience should sit with how small the consumer surface is. Every item in the "does not" list is a category of toil the platform removes. The contract is the API — deliberately tiny so that it can be reviewed, validated, and audited. For the Head of DevOps: this is the lever for throughput — the bottleneck moves off the platform team's ticket queue.

 ---

-## Slide 3 — The Citizen Developer Experience
+## Slide 4 — The Developer Feedback Loop

-A non-technical consumer ships a production deployment **by declaring intent** — without authoring a workflow, a configuration file, or an infrastructure module.
+Story beat: Once you push, here's what you see — in real time, in your own logs.
+
+Developers see **what the platform is doing**, in real time. <span class="badge testing">Testing</span>
+
+- **Streamed output by default** — the infrastructure plan, policy-check results, and each check record flow to stdout.
+- **PR comments after every successful pipeline stage** — a developer always knows where they stand without refreshing a dashboard.
+- **Clear, explainable halt reasons** — a policy violation, an insufficient confidence signal, or a missing attestation. **Never an opaque debugging exercise.**
+- **Connection strings posted as PR comments** — human-readable, no hunting. Runtime secrets go to encrypted Parameter Store (KMS-encrypted, namespaced), never to logs.
+- **Errors become GitHub issues, automatically** — a failed deploy opens an issue on the platform repo. The consumer's only grant is the onboarding-granted Lambda-invoke permission — no separate `issues: write` scope on the consumer side.
+
+> **Speaker notes:** This directly answers "but developers hate platforms that hide what they're doing." The platform is opinionated about *what* runs, not *opaque* about *that* it runs. The PR-comment-after-each-stage pattern is a small thing that compounds into trust. The "errors become issues" point is a DX win that also helps the platform team — every consumer failure is a tracked, queryable artifact, not a lost log line. The Head of DevOps should hear: the platform closes the feedback loop, it doesn't just push a green/red status.
+
+---
+
+## Slide 5 — Versioned, Predictable Releases
+
+Story beat: You control when you absorb platform improvements — no surprise upgrades.
+
+Consumers control **when** they absorb platform improvements. <span class="badge testing">Testing</span>
+
+- **Floating MAJOR + MINOR tags** (e.g. `@v1.6`) — a consumer automatically receives patch updates within the line.
+- **Semantic versioning with a clear contract:** interface → MAJOR, behavior → MINOR, lifecycle → PATCH.
+- **A consumer can pin to an exact version** for maximum stability, or float on MAJOR only (`@v1`) to absorb new features on their own cadence.
+- **Unversioned references (`@main`, bare) are discouraged** — the versioned tag is the only immutability lever a consumer has.
+- **Automated release job** computes the next semver on merge to main, creates the tag, and updates the floating tags.
+
+> **Speaker notes:** This is the "no surprise upgrades" story. Leadership hears two things: (1) consumers aren't forced to chase the platform, (2) the platform isn't forced to support N forks of every workflow. The versioning discipline is what makes both true.
+
+---
+
+## Slide 6 — Friendly Onboarding
+
+Story beat: First impressions matter — the platform fails gracefully, not opaquely.
+
+First impressions of a platform are made **when it fails for the first time.** The platform fails gracefully. <span class="badge testing">Testing</span>
+
+When no environment is bound, the platform emits a **user-friendly onboarding prompt** instead of failing opaquely. The prompt tells the consumer:
+
+1. That no environment is bound to their repo yet.
+2. What the platform will provision on their behalf (account, network, state, role).
+3. The expected turnaround for the platform team to grant the environment.
+4. How to request an environment.
+
+The pipeline then **exits without attempting a deployment** — no partial state, no confusing errors.
+
+<span class="badge planned">Citizen developer onboarding path: planned</span>
+
+> **Speaker notes:** This looks like a small thing; it's actually a cultural one. The platform's posture is "help me get started," not "you should have known." For the Head of DevOps: this is what drives adoption. Platforms that fail opaquely on first run get routed around.
+
+---
+
+## Slide 7 — Safe Promotion Path
+
+Story beat: Promotion is a workflow choice, not a contract edit — and the bar rises automatically.
+
+The contract is environment-agnostic. The platform raises the bar automatically.
+
+```mermaid
+flowchart LR
+    DEV["dev<br/>autonomous"] -->|raise the bar| QA["qa<br/>QA attests"]
+    QA -->|raise the bar| PROD["prod<br/>SRE attests"]
+    PROD -->|raise the bar| DR["dr<br/>SRE attests + DR drill"]
+```
+
+**Approach A — One contract, one job per environment.** A single contract is referenced by multiple jobs; the environment is passed by each job and interpolated at runtime. The contract itself never changes.
+
+```yaml
+jobs:
+  dev:
+    uses: acdl/.github/workflows/deploy.yml@v1.6
+    with: { contract: .acdl/contract.yaml, environment: dev }
+  qa:
+    needs: dev
+    uses: acdl/.github/workflows/deploy.yml@v1.6
+    with: { contract: .acdl/contract.yaml, environment: qa }
+```
+
+**Approach B — Environment-specific contracts.** When inputs genuinely differ per environment, each job points at its own contract file. The pipeline, policy, and confidence model stay identical.
+
+```yaml
+jobs:
+  dev:
+    uses: acdl/.github/workflows/deploy.yml@v1.6
+    with: { contract: .acdl/contract-dev.yaml }
+  qa:
+    needs: dev
+    uses: acdl/.github/workflows/deploy.yml@v1.6
+    with: { contract: .acdl/contract-qa.yaml }
+```
+
+Whichever approach a team picks, the platform applies the same rising bar:
+
+| Environment | What the platform adds | Maturity |
+|---|---|---|
+| dev | Confidence ≥ 0.50, fully autonomous | <span class="badge testing">Testing</span> |
+| qa | QA human attestation + confidence ≥ 0.75 | <span class="badge planned">Planned</span> |
+| prod | SRE human attestation + confidence ≥ 0.90 | <span class="badge planned">Planned</span> |
+| dr | SRE human attestation + confidence ≥ 0.95 + a disaster-recovery drill reference | <span class="badge planned">Planned</span> |
+
+- **No staging environment** — the design deliberately removes the "staging is basically prod but not really" anti-pattern. Dev is the only autonomous environment.
+- **Separation of duties is enforced** — the QA approver cannot be the prod approver.
+- **Timeout discipline** — 1 business day = warn + escalate; 2 business days = auto-freeze + re-submit.
+
+> **Speaker notes:** Promotion is a workflow choice, not a contract mutation — this matters because it means a promotion can be reviewed as a *diff in the workflow*, not as a rewritten contract. Approach A keeps the single source of truth; Approach B lets teams whose inputs genuinely vary keep that variation explicit and reviewable. For leadership: the DX win is that the contract stays stable across environments; the safety win is that the platform raises the threshold and attestation bar automatically based on the target environment the job declares. The consumer can't bypass the gates — they pick *which* environment to target, and the platform applies the right bar. Be honest about maturity: dev is tested and pilot-ready; qa/prod/dr wiring is planned.
+
+---
+
+## Slide 8 — Safe Decommission
+
+Story beat: Tearing down is as deliberate as deploying — and just as gated.
+
+Tearing down a stack is **as deliberate as deploying one.** <span class="badge testing">Testing</span>
+
+```yaml
+uses: acdl/.github/workflows/deploy.yml@v1.8
+with:
+  contract: .acdl/contract.yaml
+  mode: decommission
+  changeRequestId: "CHG0678912"
+```
+
+A 2-step pipeline with **two SRE human-attestation gates**:
+
+1. **Validate the change request** — the platform queries the CMDB and asserts the CR is `approved` and matches the consumer repo. No CR, no decommission.
+2. **Disable deletion protection** → **SRE approves** → **Zero all counts + destroy** → **a second SRE approves.**
+
+The per-stack encryption key enters a **grace window** (default 30 days) so encrypted data remains recoverable. The key is permanently deleted only after the window expires.
+
+> **Speaker notes:** The counter-argument to "deletion protection makes cleanup impossible" is this slide. Decommission is a first-class, gated, two-approval flow — not a lock with no key, and not an ungated `terraform destroy`. For the Head of Infrastructure: the CMDB validation means decommission is auditable, not just possible.
+
+---
+
+## Slide 9 — Self-Service Module Catalog
+
+Story beat: You don't author infrastructure — you pick from pre-built, security-reviewed building blocks.
+
+Developers pick from **pre-built, security-reviewed building blocks.** <span class="badge testing">Testing</span>
+
+- **Primitives** — single-purpose resources (S3, VPC, ECS, IAM, load balancer, container registry, CloudFront, WAF, RDS). Each has documented inputs/outputs, usage, compliance extension points, and versioning.
+- **Modules** — composed patterns (a static site with CDN + WAF; a microservice with VPC + ECS + load balancer + registry).
+- **Validated examples per module** — `simple.yaml` + `complex.yaml` + variation files, validated against the contract schema in CI. Examples cannot drift from the schema silently.
+- **Auto-promotion of patterns** — auto-promoted to the catalog after 3 observed usages. <span class="badge planned">Planned</span> <span class="badge agentic">Agentic</span>
+- **Compliance extension points** — each module lists where GDPR, SOX, SOC2, DORA controls will wire in. <span class="badge planned">Planned</span>
+
+> **Speaker notes:** The catalog is what makes "declare intent" practical — you can only declare a module that exists. For leadership: the catalog is the leverage. One well-reviewed module serves every consumer; a fix to the module serves every consumer on the next run. This is the compounding asset.
+
+---
+
+## Slide 10 — The Desired Outcomes
+
+Story beat: Here's what this delivers to the organization.
+
+- **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. Encryption, deletion protection, uptime monitoring, policy checks, and evidence are on by construction.
+- **Auditability as a byproduct, not a project.** Every production change is traceable to a human attestation and a tamper-evident evidence event — captured during the deploy, not reconstructed for the audit.
+- **Blast radius contained by design.** Zero-trust OIDC + ABAC means a consumer can only touch its own tagged resources. One consumer can never affect another.
+- **The bottleneck moves off the platform team's ticket queue.** A merged change progresses through lower environments without a platform engineer joining a thread. The platform team invests in the platform, not in per-deployment hand-holding.
+- **Infrastructure as a utility, not a craft.** Teams consume infrastructure, they don't maintain it — and the platform compounds value over time by learning from recurring patterns.
+- **A path to the citizen developer.** The same safety envelope that serves a senior engineer will serve a non-technical consumer. <span class="badge agentic">Agentic</span>
+
+> **Speaker notes:** Close on the strategic frame. The platform is not "a CI/CD tool" — it is the organizational lever for shipping safely at the pace the business demands, with the security and audit posture the regulators require. Invite questions; the companion deck ("How the Platform Works") covers the internal mechanics in more depth.
+
+---
+
+## Appendix — Contents
+
+For deep dives — these slides cover details omitted from the main 10.
+
+1. **A1 — The Citizen Developer Experience** (full)
+2. **A2 — No Platform Code, No Cloning** (detail)
+3. **A3 — Local Reproducibility** (detail)
+4. **A4 — The Road to the North Star** (phased roadmap)
+5. **A5 — Glossary**
+
+> **Speaker notes:** These are backup slides for Q&A. Use them when the audience asks for the detail behind a main-slide claim. Don't walk through them in the main talk unless time permits.
+
+---
+
+## A1 — The Citizen Developer Experience
+
+A non-technical consumer ships a production deployment **by declaring intent** — without authoring a workflow, a configuration file, or an infrastructure module. Think of this as **vibe coding on a laptop** — the consumer describes what they want; an AI agent turns that into a contract that the platform treats identically to a senior engineer's.

 - The consumer opens an issue describing what they need (e.g. "a web API for the pricing service").
- An AI agent maps the intent to a contract referencing a module from the **reviewed skill catalog.**
+- An AI agent maps the intent to a contract referencing a module from the **reviewed skill catalog.** <span class="badge agentic">Agentic</span>
 - The contract enters the **same pipeline** and must clear the **same confidence gate** before promotion.

 **Guardrails that make this safe:**
@@ -68,54 +270,15 @@ A non-technical consumer ships a production deployment **by declaring intent**
 - Skills are **versioned, signed, and reviewed for sensitive data before release** (Infra & Ops owns the review — it is the mandatory release gate).
 - Agents are **stateless** — all state lives in the platform. The platform does not run the skill blindly; it trusts and **always verifies** on the platform side.
 - The agent's trace and submission confidence are captured in the contract (`profile: agentic`), so a reviewer can see *how* the contract was produced.
- **Initial skill catalog:** web API, worker, scheduled job, static asset, basic observability bootstrap. *(Catalog is planned; the agentic surface is on the roadmap.)*
+- **Initial skill catalog:** web API, worker, scheduled job, static asset, basic observability bootstrap.

-> **Speaker notes:** Be honest about maturity: the *mechanism* (agent → contract → same pipeline) is designed and the stub was proven in the v1.0 demo; the full skill catalog and real agent runtime are planned. But the design point matters to leadership now: we are building for a world where more of the org can ship safely, not where more of the org has to become a platform engineer.
+<span class="badge planned">Skill catalog + real agent runtime: planned</span> <span class="badge agentic">Agentic</span>
+
+> **Speaker notes:** Be honest about maturity: the *mechanism* (agent → contract → same pipeline) is designed and the stub was proven in the v1.0 demo; the full skill catalog and real agent runtime are planned. The "vibe coding on a laptop" framing is intentional — it meets the citizen developer where they already are, but every submission still passes the same safety envelope. The design point matters to leadership now: we are building for a world where more of the org can ship safely, not where more of the org has to become a platform engineer.

 ---

-## Slide 4 — The Contract
-
-A 5-line YAML file. This is the entire consumer-facing interface to production.
-
-```yaml
-# .acdl/contract.yaml — a static site
-uses: acdl/pipelines/deploy.yaml@v1.6
-module: static-assets
-environment: dev
-inputs:
-  bucket_name: my-static-site-assets
-  region: us-east-1
-```
-
-```yaml
-# .acdl/contract.yaml — a microservice
-uses: acdl/pipelines/deploy.yaml@v1.6
-module: microservice
-environment: dev
-inputs:
-  image: my-registry/my-microservice:latest
-  port: 8080
-  env:
-    LOG_LEVEL: info
-```
-
-Four fields:
-
-| Field | Meaning |
-|---|---|
-| `uses` | The central pipeline, pinned to a versioned tag |
-| `module` | A name from the module catalog |
-| `environment` | `dev`, `qa`, `prod`, or `dr` |
-| `inputs` | The handful of values that vary per deployment |
-
-An invalid contract (missing field, unknown module, wrong type) **fails fast at validation** with a clear error — not an opaque failure three stages in.
-
-> **Speaker notes:** The contract is the API. It is deliberately tiny so that it can be reviewed, validated, and audited. For leadership: this is what makes "declare intent" concrete — it's a one-screen file, not a 300-line Terraform root module.
-
---
-
-## Slide 5 — No Platform Code, No Cloning
+## A2 — No Platform Code, No Cloning

 Consumers `uses:` a **versioned** central workflow. The platform fetches itself at run time. The consumer **never touches platform internals.**

@@ -132,186 +295,51 @@ flowchart LR
 - The runner checks out the consumer repo, then checks out the platform repo into the workspace.
 - The platform installs its own runtime dependencies. The consumer installs nothing.
 - The consumer **never clones the platform repo, never invokes platform scripts locally** (optional `--check-only` validation is available but not required for the happy path).
+- When the platform ships a fix, every consumer on a floating MAJOR.MINOR tag gets it on their next run — no per-repo upgrade project.

-> **Speaker notes:** The Head of Cloud cares about this: there is no "platform code in every consumer repo" problem. When the platform ships a fix, every consumer on a floating MAJOR.MINOR tag gets it on their next run — no per-repo upgrade project.
+> **Speaker notes:** The Head of Cloud cares about this: there is no "platform code in every consumer repo" problem. The version-pinned `uses:` line is the *only* coupling, and it's a coupling that updates itself within the line.

 ---

-## Slide 6 — Versioned, Predictable Releases
+## A3 — Local Reproducibility

-Consumers control **when** they absorb platform improvements.
+The entire CI pipeline runs **from the shell**, not just in CI. <span class="badge testing">Testing</span>

- **Floating MAJOR + MINOR tags** (e.g. `@v1.6`) — a consumer on `@v1.6` automatically receives patch updates within the 1.6 line.
- **Semantic versioning with a clear contract:** interface changes → MAJOR, behavior changes → MINOR, lifecycle fixes → PATCH.
- **A consumer can pin to an exact version** for maximum stability, or float on MAJOR only (`@v1`) to absorb new features on their own cadence.
- **Unversioned references (`@main`, bare) are discouraged** — the versioned tag is the only immutability lever a consumer has.
- **Automated release job** computes the next semver on merge to main, creates the tag, and updates the floating tags. *(Testing.)*
+- `scripts/run_ci.sh` mirrors the CI pipeline locally — the same three stages (lint → test → check-only) in sequence.
+- `scripts/run_platform.sh --check-only` runs the platform **offline** — no AWS, no policy engine, no outbox required. Validates a contract end-to-end before pushing.
+- `--plan-only` runs through the infrastructure plan without applying.
+- The CI and deploy pipelines are defined by **declarative contracts** (YAML instances validated against JSON Schemas) — a single source of truth that both workflows implement.

-> **Speaker notes:** This is the "no surprise upgrades" story. Leadership hears two things: (1) consumers aren't forced to chase the platform, (2) the platform isn't forced to support N forks of every workflow. The versioning discipline is what makes both true.
+> **Speaker notes:** This is the "no surprises before you push" story. A consumer can validate their contract offline, run the plan offline, and only push when they're confident. The same declarative contract drives both the local tooling and CI — there's no "works on my machine, fails in CI" gap.

 ---

-## Slide 7 — Instant Feedback
+## A4 — The Road to the North Star

-Developers see **what the platform is doing**, in real time, in their own run logs.
+*Proposed phasing — not formally planned.*

- **Streamed output by default** — the infrastructure plan, policy-check results, and each `PolicyCheckResult` record (severity, rule ID, pass/fail) flow to stdout. *(Testing.)*
- **PR comments after every successful pipeline stage** — a developer always knows where they stand without refreshing a dashboard. *(Testing.)*
- **Clear, explainable halt reasons** — a policy violation, an insufficient confidence signal, or a missing attestation. **Never an opaque, manual-debugging exercise.**
- **A `--quiet` mode** suppresses streaming for log-only contexts.
-
-> **Speaker notes:** This directly answers "but developers hate platforms that hide what they're doing." The platform is opinionated about *what* runs, not *opaque* about *that* it runs. The PR-comment-after-each-stage pattern is a small thing that compounds into trust.
-
---
-
-## Slide 8 — Deploy Outputs That Just Work
-
-After a successful deploy, the developer gets their connection information **without hunting for it** — and without secrets leaking into logs.
-
- **Human-readable connection strings** posted as a structured GitHub PR comment / job summary. *(Testing.)*
- **Runtime-injectable values** written to encrypted Parameter Store (`SecureString`, KMS-encrypted, namespaced `/acdl/{env}/{contractId}/{output_name}`). *(Testing.)*
- **No raw secrets in logs** — the platform enforces this by construction.
- **Errors become GitHub issues, automatically** — a failed deploy reports through the platform Lambda, which opens (or comments on) an issue on the platform repo. The consumer's only grant is the onboarding-granted Lambda-invoke permission — no separate `issues: write` scope on the consumer side. *(Testing.)*
-
-> **Speaker notes:** The "errors become issues" point is a DX win that also helps the platform team — every consumer failure is a tracked, queryable artifact, not a lost log line. The Head of DevOps should hear: the platform closes the feedback loop, it doesn't just push a green/red status.
-
---
-
-## Slide 9 — Friendly Onboarding
-
-First impressions of a platform are made **when it fails for the first time.** The platform fails gracefully.
-
- When a consumer pipeline runs for the first time and **no environment is bound**, the platform detects this and emits a **user-friendly onboarding prompt** instead of failing opaquely. *(Testing.)*
- The prompt tells the consumer:
-  1. That no environment is bound to their repo yet.
-  2. What the platform will provision on their behalf (account, network, state, role).
-  3. The expected turnaround for the platform team to grant the environment.
-  4. How to request an environment.
- The pipeline then **exits without attempting a deployment** — no partial state, no confusing errors.
- **Both onboarding paths end in a sandbox dev submission that must pass the confidence gate** before the consumer is promoted. *(Developer path shipped; citizen developer path planned.)*
-
-> **Speaker notes:** This looks like a small thing; it's actually a cultural one. The platform's posture is "help me get started," not "you should have known." For the Head of DevOps: this is what drives adoption. Platforms that fail opaquely on first run get routed around.
-
---
-
-## Slide 11 — Safe Promotion Path
-
-The contract is environment-agnostic by design. Promotion is **a workflow choice, not a contract edit** — the same contract carries cleanly from dev to qa to prod. The platform raises the bar automatically as the target environment becomes more sensitive.
-
-**Approach A — One contract, one job per environment.** A single contract is referenced by multiple jobs in the CI workflow; the environment is passed by each job and interpolated at runtime. The contract itself never changes.
-
-```yaml
-# .github/workflows/deploy.yml — one job per environment, one shared contract
-jobs:
-  dev:
-    uses: acdl/.github/workflows/deploy.yml@v1.6
-    with:
-      contract: .acdl/contract.yaml
-      environment: dev
-  qa:
-    needs: dev
-    uses: acdl/.github/workflows/deploy.yml@v1.6
-    with:
-      contract: .acdl/contract.yaml
-      environment: qa
-  prod:
-    needs: qa
-    uses: acdl/.github/workflows/deploy.yml@v1.6
-    with:
-      contract: .acdl/contract.yaml
-      environment: prod
+```mermaid
+flowchart LR
+    P1["Phase 1<br/>Core platform<br/>(contract, catalog, evidence)"] --> P2["Phase 2<br/>Safe promotion<br/>qa/prod/dr wiring"]
+    P2 --> P3["Phase 3<br/>Agentic surface<br/>(skill catalog + agents)"]
+    P3 --> P4["Phase 4<br/>North star<br/>citizen developer GA"]
 ```

-**Approach B — One job per environment, environment-specific contracts.** When inputs genuinely differ per environment (different capacity, different config), each job points at its own contract file. The pipeline, policy, and confidence model stay identical.
+> **Speaker notes:** This is a proposed phasing, not a formally committed plan — call that out explicitly. Phase 1 is what's tested today. Phase 2 is the next milestone (qa/prod/dr wiring). Phase 3 introduces the agentic surface. Phase 4 is the north star: citizen developer GA on the same safety envelope. Use this only when an audience member asks "how do you get from here to there."

-```yaml
-jobs:
-  dev:
-    uses: acdl/.github/workflows/deploy.yml@v1.6
-    with:
-      contract: .acdl/contract-dev.yaml
-  qa:
-    needs: dev
-    uses: acdl/.github/workflows/deploy.yml@v1.6
-    with:
-      contract: .acdl/contract-qa.yaml
-  prod:
-    needs: qa
-    uses: acdl/.github/workflows/deploy.yml@v1.6
-    with:
-      contract: .acdl/contract-prod.yaml
-```
+---

-Whichever approach a team picks, the platform applies the same rising bar:
+## A5 — Glossary

-| Environment | What the platform adds |
+| Term | Meaning |
 |---|---|
-| dev | Confidence ≥ 0.50, fully autonomous |
-| qa | QA human attestation + confidence ≥ 0.75 |
-| prod | SRE human attestation + confidence ≥ 0.90 |
-| dr | SRE human attestation + confidence ≥ 0.95 + a disaster-recovery drill reference |
+| **OIDC** | OpenID Connect — federation protocol for short-lived tokens, no long-lived credentials |
+| **ABAC** | Attribute-Based Access Control — access scoped by resource tags + repo identity, not roles |
+| **CMK** | Customer-Managed Key — per-stack encryption key, 90-day rotation, no shared keys |
+| **CMDB** | Configuration Management Database — validates change requests for decommission |
+| **RPO** | Recovery Point Objective — RPO = 0 means evidence is written synchronously, no data loss |
+| **HITL** | Human-in-the-Loop — deliberate human attestation required for qa/prod/dr environments |
+| **VCS** | Version Control System — the git hosting platform (GitHub, Gitea, GitLab) |
+| **NFR** | Non-Functional Requirement — encryption, tagging, observability standards |

- **No staging environment** — the design deliberately removes the "staging is basically prod but not really" anti-pattern. Dev is the only autonomous environment.
- **Separation of duties is enforced** — the QA approver cannot be the prod approver. *(Design tested; wiring for qa/prod/dr is planned.)*
- **Timeout discipline** — 1 business day = warn + escalate; 2 business days = auto-freeze + re-submit.
-
-> **Speaker notes:** Promotion is a workflow choice, not a contract mutation — this matters because it means a promotion can be reviewed as a *diff in the workflow*, not as a rewritten contract. Approach A (one contract, environment passed by the job) keeps the single source of truth; Approach B (environment-specific contracts) lets teams whose inputs genuinely vary keep that variation explicit and reviewable. For leadership: the DX win is that the contract stays stable across environments; the safety win is that the platform raises the threshold and attestation bar automatically based on the target environment the job declares. The consumer can't bypass the gates — they pick *which* environment to target, and the platform applies the right bar.
-
---
-
-## Slide 12 — Safe Decommission
-
-Tearing down a stack is **as deliberate as deploying one** — and just as gated.
-
-```yaml
-# Consumer's deploy workflow call
-uses: acdl/.github/workflows/deploy.yml@v1.8
-with:
-  contract: .acdl/contract.yaml
-  mode: decommission
-  changeRequestId: "CHG0678912"
-```
-
-A 2-step pipeline with **two SRE human-attestation gates** *(available today)*:
-
-1. **Validate the change request** — the platform queries the CMDB and asserts the CR is `approved` and matches the consumer repo. No CR, no decommission.
-2. **Disable deletion protection** (resolve with `deletion_protection: false`, plan + apply) → **SRE approves.**
-3. **Zero all counts + destroy** (the platform zeroes every scalable count, plan + apply) → **a second SRE approves.**
-4. **Confirmation** — the platform confirms the stack is destroyed.
-
-**After decommission:**
-
- The per-stack encryption key enters a **grace window** (default 30 days) so encrypted data remains recoverable. The key is permanently deleted only after the window expires.
- Uptime monitoring is **not** automatically destroyed — it can be left running to watch the decommissioned endpoints go dark, or destroyed separately.
-
-> **Speaker notes:** The counter-argument to "deletion protection makes cleanup impossible" is this slide. Decommission is a first-class, gated, two-approval flow — not a lock with no key, and not an ungated `terraform destroy`. For the Head of Infrastructure: the CMDB validation means decommission is auditable, not just possible.
-
---
-
-## Slide 13 — Self-Service Module Catalog
-
-Developers pick from **pre-built, security-reviewed building blocks** — they don't author infrastructure from scratch.
-
- **Primitives** — single-purpose resources (S3, VPC, ECS cluster, ECS service, IAM role, load balancer, container registry, CloudFront, WAF, RDS). Each has documented inputs, outputs, usage, compliance extension points, and versioning. *(Testing.)*
- **Modules** — composed patterns (a static site with CDN + WAF; a microservice with VPC + ECS + load balancer + registry). *(Testing.)*
- **Validated examples per module** — every module ships `simple.yaml` + `complex.yaml` + variation files, validated against the contract schema in CI. Examples cannot drift from the schema silently. *(Testing.)*
- **Auto-promotion of patterns** — a thin-composition layer is auto-promoted to the catalog after 3 observed usages. *(Mechanism planned.)*
- **Compliance extension points** — each module lists where GDPR, SOX, SOC2, DORA controls will wire in. *(Compliance milestone is planned.)*
-
-> **Speaker notes:** The catalog is what makes "declare intent" practical — you can only declare a module that exists. For leadership: the catalog is the leverage. One well-reviewed module serves every consumer; a fix to the module serves every consumer on the next run. This is the compounding asset.
-
---
-
-## Slide 14 — The Outcome for Leadership
-
-What this platform delivers to the organization:
-
- **Velocity without sacrificing safety.** The speed is in the ergonomics (a 5-line contract, a one-line `uses:`); the safety is in the gates the consumer cannot bypass.
- **Security, observability, and compliance as platform defaults** — not per-team effort, not post-hoc remediation. Encryption, deletion protection, uptime monitoring, policy checks, and evidence are on by construction.
- **Auditability as a byproduct, not a project.** Every production change is traceable to a human attestation and a tamper-evident evidence event — captured during the deploy, not reconstructed for the audit.
- **Blast radius contained by design.** Zero-trust OIDC + ABAC means a consumer can only touch its own tagged resources. One consumer can never affect another.
- **The bottleneck moves off the platform team's ticket queue.** A merged change progresses through lower environments without a platform engineer joining a thread. The platform team invests in the platform, not in per-deployment hand-holding.
- **Infrastructure as a utility, not a craft.** The platform abstracts compute, networking, and state. Teams consume infrastructure, they don't maintain it — and the platform compounds value over time by learning from recurring patterns.
- **A path to the citizen developer.** The same safety envelope that serves a senior engineer is the one that will serve a non-technical consumer — expanding who can ship safely without lowering the bar.
-
-> **Speaker notes:** Close on the strategic frame. The platform is not "a CI/CD tool" — it is the organizational lever for shipping safely at the pace the business demands, with the security and audit posture the regulators require. Invite questions; the companion deck ("How the Platform Works") covers the internal mechanics in more depth.
+> **Speaker notes:** Keep this slide in your back pocket for the audience member who asks "what does ABAC actually mean?" Don't read it aloud.
@@ -0,0 +1,173 @@
+#!/usr/bin/env bash
+# scripts/sync_to_gl.sh - copy ~/acdl contents to ~/gl/acdl and push.
+#
+# Copies the ACDL source tree into the GitLab mirror at ~/gl/acdl.
+# Hidden files/dirs are NOT copied EXCEPT for .github (so GitLab CI
+# workflows stay current) and .gitignore. The terraform/ tree is
+# omitted entirely, and .gitignore patterns are honored. The
+# destination's existing .git directory is preserved untouched.
+#
+# After syncing, commits any changes on the current branch with a
+# timestamped message and pushes it to its upstream (origin/main).
+#
+# Run manually:
+#   bash scripts/sync_to_gl.sh             # sync + commit + push
+#   bash scripts/sync_to_gl.sh -v          # verbose (list copied files)
+#   bash scripts/sync_to_gl.sh --no-push   # sync + commit only, no push
+#   bash scripts/sync_to_gl.sh --dry-run   # show what would happen
+#   SRC=~/acdl DST=~/gl/acdl bash scripts/sync_to_gl.sh
+set -euo pipefail
+
+SRC="${SRC:-$HOME/acdl}"
+DST="${DST:-$HOME/gl/acdl}"
+VERBOSE=0
+NO_PUSH=0
+DRY_RUN=0
+
+for arg in "$@"; do
+  case "$arg" in
+    -v|--verbose) VERBOSE=1 ;;
+    --no-push)   NO_PUSH=1 ;;
+    --dry-run)   DRY_RUN=1 ;;
+    -h|--help)
+      sed -n '2,21p' "$0"
+      exit 0
+      ;;
+    *) echo "FAIL: unknown argument: $arg" >&2; exit 1 ;;
+  esac
+done
+
+fail() { echo "FAIL: $*" >&2; exit 1; }
+run() {
+  if [ "$DRY_RUN" = "1" ]; then
+    echo "  [dry-run] $*"
+  else
+    "$@"
+  fi
+}
+
+[ -d "$SRC" ] || fail "source not found: $SRC"
+[ -d "$DST" ] || fail "destination not found: $DST (create it first)"
+[ -d "$DST/.git" ] || fail "destination has no .git: $DST/.git (restore it first)"
+
+echo "=== sync_to_gl ==="
+echo "source:      $SRC"
+echo "destination:  $DST"
+[ "$NO_PUSH"    = "1" ] && echo "mode:        sync + commit (no push)"
+[ "$DRY_RUN"    = "1" ] && echo "mode:        dry-run (no changes made)"
+echo ""
+
+# Sanity: refuse if DST is not inside ~/gl or is the same as SRC.
+case "$DST" in
+  "$HOME"/gl/*) : ;;
+  *) fail "destination must live under ~/gl (got $DST)" ;;
+esac
+[ "$SRC" != "$DST" ] || fail "source and destination are identical"
+
+# --- sync (rsync) -----------------------------------------------------------
+
+# Build rsync exclude list: every hidden entry in SRC except .github
+# and .gitignore.
+EXCLUDES=()
+for hidden in "$SRC"/.*; do
+  name="$(basename "$hidden")"
+  case "$name" in
+    .|...) continue ;;
+    .github|.gitignore) continue ;;   # keep
+  esac
+  EXCLUDES+=("--exclude=/$name")
+done
+
+# Never touch the destination's .git. "protect" makes rsync skip it
+# entirely (neither transfer nor delete) even under --delete; this is
+# stronger than --exclude, which --delete-excluded would wipe out.
+# Drop it from the transfer set too.
+EXCLUDES+=("--exclude=/.git")
+
+# Omit the terraform/ tree entirely.
+EXCLUDES+=("--exclude=/terraform")
+
+# rsync filters: protect .git, then honor per-directory .gitignore
+# via dir-merge (:-) semantics so patterns anchor like git does.
+FILTERS=(
+  "--filter=P .git"
+  "--filter=:- .gitignore"
+)
+
+# Use --delete (prune extras in the synced tree) but NOT --delete-excluded:
+# that would wipe destination paths covered by our --exclude rules, which
+# is exactly what must NOT happen for .git.
+RSYNC_ARGS=(-a --delete)
+[ "$VERBOSE" = "1" ] && RSYNC_ARGS+=(-v)
+
+echo "rsync excludes: ${EXCLUDES[*]}"
+echo "rsync filters:  ${FILTERS[*]}"
+echo ""
+
+if [ "$DRY_RUN" = "1" ]; then
+  echo "[dry-run] rsync would run:"
+  printf '  %q ' rsync "${RSYNC_ARGS[@]}" "${FILTERS[@]}" "${EXCLUDES[@]}" "$SRC/" "$DST/"; echo
+else
+  rsync "${RSYNC_ARGS[@]}" "${FILTERS[@]}" "${EXCLUDES[@]}" "$SRC/" "$DST/"
+  echo "rsync: OK"
+fi
+
+echo ""
+
+# --- git commit + push ------------------------------------------------------
+
+cd "$DST"
+
+# Refuse to run inside a merge/rebase/conflict state.
+git rev-parse --is-inside-work-tree >/dev/null
+git_dir_state() {
+  local f
+  for f in MERGE_HEAD CHERRY_PICK_HEAD REVERT_HEAD BISECT_LOG; do
+    [ -e ".git/$f" ] && return 1
+  done
+  [ -d ".git/rebase-merge" -o -d ".git/rebase-apply" ] && return 1
+  return 0
+}
+git_dir_state || fail "destination .git is mid-operation (merge/rebase/etc); resolve it then re-run"
+
+branch="$(git symbolic-ref --quiet --short HEAD 2>/dev/null || true)"
+[ -n "$branch" ] || fail "HEAD is detached; checkout a branch first (got $(git rev-parse --short HEAD))"
+
+# Stage everything in the working tree (including deletions).
+run git add -A
+
+# Commit only if there is something staged.
+if git diff --cached --quiet; then
+  echo "git: no changes to commit on branch '$branch'"
+else
+  ts="$(date -u +%Y-%m-%d\ %H:%M\ UTC)"
+  msg="chore: sync from source mirror $ts"
+  echo "git: committing on branch '$branch'"
+  [ "$VERBOSE" = "1" ] && git diff --cached --stat
+  run git commit -m "$msg"
+fi
+
+# Push (current branch to its upstream) unless suppressed.
+if [ "$NO_PUSH" = "1" ]; then
+  echo "git: --no-push set, skipping push"
+  PUSHED=0
+else
+  upstream="$(git rev-parse --abbrev-ref --symbolic-full-name '@{u}' 2>/dev/null || true)"
+  if [ -z "$upstream" ]; then
+    fail "no upstream configured for branch '$branch'; set one with: git -C $DST branch --set-upstream-to=origin/$branch $branch"
+  fi
+  if [ "$DRY_RUN" = "1" ]; then
+    echo "  [dry-run] git push to $upstream"
+  else
+    echo "git: pushing '$branch' to $upstream"
+    git push
+    echo "git: push OK"
+  fi
+fi
+
+echo ""
+echo "=== sync_to_gl OK ==="
+echo "copied $SRC -> $DST"
+[ "$DRY_RUN"    = "1" ] && echo "(dry-run: nothing actually written or pushed)"
+[ "$NO_PUSH"    = "1" ] && echo "(no-push: changes committed but not pushed)"
+exit 0
Author	SHA1	Message	Date
Jon Chery	a4481e20de	docs(P51): full presentation rework — scope, story arc, visuals, appendix acdl-ci / Lint (push) Successful in 9s Details acdl-ci / Test (push) Successful in 29s Details acdl-ci / Platform check-only (offline) (push) Successful in 10s Details Major rework of both presentation decks based on leadership feedback. Addresses: story arc, concept clarity, scope clarification, more visuals, appendix for detail-heavy slides, and a complete Road to the North Star. 6 new mermaid diagrams: - platform-works-03-scope-boundary (Upstream → Contract → ACDL → AWS) - developer-experience-01b-scope-boundary (both consumer paths + scope) - platform-works-04-confidence-signal (6 inputs → score → gate → decision) - platform-works-05-attestation-flow (deploy → gate → approver → evidence) - developer-experience-04-promotion-journey (dev → qa → prod → dr) - road-to-north-star (v1.0 demo → v1.9 → v1.10 → v2.0 → North Star) Both Marp decks restructured to 10 main + 6 appendix slides: PW deck (17 slides): 1. Title 2. The Problem & The North Star (anti-goals moved to slide 3) 3. Where ACDL Sits in Your World (NEW — scope boundary, infra only) 4. The Contract-Driven Model (image: removed, infra inputs instead) 5. The End-to-End Flow 6. Zero-Trust by Default 7. Safety is Computed (NEW confidence signal diagram) 8. Security by Construction 9. Accountability & Audit (NEW attestation flow diagram, QA clarification, badge reclassification: dev=Testing, qa/prod/dr=Planned) 10. Testing vs. Planned (summary, full inventory in appendix) 11. The Vision Realized + Appendix: TOC, Platform-Managed Environments, Observability, Road to North Star, Full Inventory, Glossary DX deck (16 slides): 1. Title 2. Where ACDL Sits in Your World (REPLACES Two Consumer Surfaces — scope boundary with both consumer paths) 3. The Contract — The Entire Consumer Surface (image: removed) 4. The Developer Feedback Loop 5. Versioned, Predictable Releases 6. Friendly Onboarding 7. Safe Promotion Path (NEW promotion journey diagram, rising bar annotated: dev=Testing, qa/prod/dr=Planned) 8. Safe Decommission 9. Self-Service Module Catalog 10. The Desired Outcomes + Appendix: TOC, Citizen Developer Experience, No Platform Code, Local Reproducibility, Road to North Star, Glossary Story arc: every slide has an italic 'Story beat' line connecting it to the narrative progression. Scope clarification: ACDL is infrastructure only. Upstream is anything (IDE, agentic SDLC, citizen dev vibe coding). ACDL provisions and governs AWS resources; application deployment is upstream. Contract examples now show infrastructure inputs (cpu, memory, desired_count, port) not image:. QA attestation reclassification: 'Design tested' → 'Planned'. QA attests to infrastructure readiness (contract + Terraform plan + evidence), not application code. Dev is autonomous (Testing); qa/prod/dr are Planned. Road to the North Star: phased timeline (v1.0 → v1.9 → v1.10 → v2.0 → North Star), annotated 'proposed phasing, not formally planned.' Also: scripts/sync_to_gl.sh added (GitLab mirror sync utility). ---ci--- phase: 51 milestone: v1.9 status: complete requirements: covered: [] partial: [] ---/ci---	2026-07-27 14:46:05 +00:00
Jon Chery	00762c1256	verify(P51): code review — 1 P0 auto-fixed, 2 P1+ flagged ---ci--- project: acdl phase: 51 milestone: v1.9.8 status: verify lessons: - P0 fix: removed duplicate reclassification bullets in slide 9 (Dev autonomous / qa-prod-dr attestation were listed twice); consolidated badges inline to match Marp deck ---/ci---	2026-07-27 14:44:12 +00:00
Jon Chery	116f49ecb8	docs(P50): update ROADMAP + PROJECT for v1.9.7 patch release acdl-ci / Lint (push) Successful in 8s Details acdl-ci / Test (push) Successful in 28s Details acdl-ci / Platform check-only (offline) (push) Successful in 9s Details ---ci--- phase: 50 milestone: v1.9 status: complete requirements: covered: [] partial: [] ---/ci---	2026-07-23 15:59:20 +00:00
Jon Chery	016068fd46	docs(P50): add talking points files + update README to 4-step process acdl-ci / Lint (push) Successful in 7s Details acdl-ci / Test (push) Successful in 28s Details acdl-ci / Platform check-only (offline) (push) Successful in 9s Details Create two talking points markdown files — one per deck — distilling the source of truth (speaker notes + content) into presenter-ready cues indexed by the Marp deck's 10-slide structure. Each file has: - One section per Marp slide (## Slide N — Title), matching the Marp deck - 3-6 talking point bullets per slide — punchy, actionable cues distilled from the source markdown's speaker notes - A key takeaway per slide — the one memorable thing the audience should walk away with The talking points are the middle layer between the source of truth (full detail + speaker notes) and the Marp deck (what the audience sees). They give the presenter a cue sheet for delivery without repeating either layer. README updated: - 3-step → 4-step process (added Step 4: talking points) - Process diagram updated with the 4th step - Directory layout updated with the two new files - 'Adding a new presentation' checklist updated with step 6 (distill talking points) - Current decks table updated with a talking points column ---ci--- phase: 50 milestone: v1.9 status: complete requirements: covered: [] partial: [] ---/ci---	2026-07-23 15:58:35 +00:00
Jon Chery	1eeee323c0	docs(P49): update ROADMAP + PROJECT for v1.9.6 patch release acdl-ci / Lint (push) Successful in 7s Details acdl-ci / Test (push) Successful in 27s Details acdl-ci / Platform check-only (offline) (push) Successful in 9s Details ---ci--- phase: 49 milestone: v1.9 status: complete requirements: covered: [] partial: [] ---/ci---	2026-07-23 15:44:36 +00:00