docs(P47): presentation slide updates + HIPAA removal from all docs

Presentation changes (both Marp decks + source markdown):
1. Title slide: deck title as H1 (slightly bigger), 'Agentic Cloud Delivery
   Platform' as H3 subtitle — cleaner title hierarchy
2. DX deck: removed Local Reproducibility slide (not beneficial for DX)
3. DX deck: Safe Promotion Path slide redesigned with side-by-side layout
   for Approaches A and B (HTML table, two columns)
4. DX deck: 'an agent' → 'an AI agent' (slide 2 + Citizen Developer slide)
5. DX deck: What a Developer Does — diagram floated to the right side
6. Header simplified to just the deck name (subtitle now on title slide)

HIPAA removal (25 files):
- Completely removed all HIPAA references from all markdown documentation,
  presentation source files, module READMEs, and rendered HTML
- Removed HIPAA from compliance milestone lists (GDPR, SOX, SOC2, DORA remain)
- Removed HIPAA section references (§164.xxx) from compliance annotations
- Cleaned up empty parentheses and broken commas left by removal
- Re-rendered both HTML decks from updated Marp source

---ci---
phase: 47
milestone: v1.9
status: complete
requirements:
  covered: []
  partial: []
---/ci---

.ciagent/PROJECT.md

@@ -364,6 +364,44 @@ historical gap (no git-history rewrite).
 Milestone COMPLETE gate: review → ship `v1.9.0` (feature milestone, next
 minor per run.md — v1.8 shipped `v1.8.0`) → audit.
 
+## Patch v1.9.1 (complete, tag `v1.9.1`)
+
+Docs-only NFR patch on the v1.9 line. Two leadership-facing presentation
+decks (How the Platform Works + The Developer Experience) for senior
+leadership (CTO, Head of Cloud, Head of Infrastructure, Head of DevOps).
+Each deck has a full markdown source of truth (with speaker notes + mermaid
+diagrams) and a lean Marp deck (no speaker notes, embedded PNG diagrams). A
+README documents the 3-step slide creation process (full markdown → Marp
+synthesis → PPTX export) with conventions, build commands, and maturity
+framing rules. No code changes; 494 tests pass; `run_ci.sh` +
+`run_platform.sh --check-only` green.
+
+## Patch v1.9.2 (complete, tag `v1.9.2`)
+
+Docs-only NFR patch on the v1.9 line. Applies the S&P Global Energy brand
+visual identity to both Marp presentation decks. Brand colors extracted
+from the live spglobal.com compiled Tailwind CSS and SVG logo: red-core
+`#D6002A`, grey-90 `#1B1B1B`, grey-80 `#2E2E2E`, grey-5 `#F0F0F0`, Akkurat
+Pro corporate typeface. Title headers changed to full platform name.
+Footer changed from 'Confidential · For Senior Leadership' to 'Internal'.
+Title slide subtitle removed. Last DX slide renamed from 'The Outcome for
+Leadership' to 'The Desired Outcomes'. Marp `theme: default` kept as base.
+No code changes; 494 tests pass; `run_ci.sh` + `run_platform.sh --check-only`
+green.
+
+## Patch v1.9.3 (complete, tag `v1.9.3`)
+
+Docs-only NFR patch on the v1.9 line. Renders both Marp presentation decks
+to self-contained HTML (committed to `docs/presentations/`, base64-embedded
+images, full S&P Global Energy brand theme) and PPTX (uploaded to the Gitea
+release as downloadable attachments). The HTML files are viewable in any
+browser and on the git forge — they render the red accent bar, dark
+title-slide background, red H1 headings, and Akkurat Pro font stack. README
+updated to document HTML as committed artifacts (re-render when Marp source
+changes) and PPTX as release attachments (binary, not committed to git).
+No code changes; 494 tests pass; `run_ci.sh` + `run_platform.sh --check-only`
+green.
+
 ## Requirements
 
 ### v1.0 (Prior milestone — the demo)

.ciagent/ROADMAP.md

@@ -11,6 +11,9 @@
 - **v1.6 (complete, tag `v1.6.0`):** consumer-facing docs restructure + terminology normalization + environments concept. `docs/` becomes a Jekyll-style GitHub Pages site. `acdl_platform/` is renamed to `core/`. L2 → "modules", L1 → "primitives", "composition" → "pattern" in prose. README restructured: Features + Roadmap (no internal status), repository roles restated (consumer = app code + contracts + CI definitions), mermaid fixed (visible text, security-checks + infrastructure-apply stages, no tool names), credentials section minus go-gitea/waivers. Platform-managed environments concept + a minimal onboarding scaffold. `.ciagent/` + `.gitea/` references removed from all consumer-facing docs.
 - **v1.7 (complete, tag `v1.7.0`):** production platform + contract ingestion + pipeline maturation. Rename `static-assets` → `static-assets` (D-048 — incl. `.ciagent/` historical narrative). Author `cloudfront` + `waf` primitives; augment `static-assets` to a production-ready S3 + CloudFront (OAC) + WAF stack (D-049). Tagging-standard enforcement (Checkov custom rule, D-043 closure, D-054). Wiz adapter stub (D-052) + Kyverno K8s-native adapter (D-053). Platform Lambda + DynamoDB `acdl-contracts` table for contract ingestion (D-051) + cross-account IAM. Deploy outputs via SSM SecureString + GitHub PR comment (D-050). Uniform error reporting via the Lambda `report_error` action → GitHub issue on the platform repo (D-055); Gitea excluded. Stage comments after every successful pipeline stage. Three platform pipelines (platform-test unit+integration, primitives-plan, patterns-plan). Release job with semver + MAJOR.MINOR/MAJOR tag maintenance (D-057). `uses:`/`ref:` bumped to `@v1.6`; floating `v1.6` + `v1` tags created in Phase 22. Remove the legacy consumer-repos directory (a v1.2 artifact, removed in v1.7); add validated per-module examples (`modules/<name>/examples/`, D-058) including a new RDS primitive demonstrating multi-engine variation (D-059).
 - **v1.8 (complete, tag `v1.8.0`):** P1 remediation + uptime monitoring + engineering standards + encryption/deletion-protection by default + decommission alias + path documentation. Clears 8 pending P1 issues (P1-3..P1-9 + S1). Adds per-stack CMK + encryption-by-default for all primitives. Adds deletion-protection-by-default + L2 feature flag. Adds uptime-kuma primitive (ECS Fargate, deployed by default after L2, separate state, feature flag, alert channels). Adds decommission mode (2-step pipeline with HITL SRE gates + CMDB-validated change request). Adds `modules/STANDARDS.md` (L1+L2 authoring + review standards). Adds `schemas/README.md`, `pipelines/README.md`, `adapters/README.md`.
+- **v1.9.1 (complete, tag `v1.9.1`):** leadership presentation decks. Two leadership-facing presentation decks (How the Platform Works + The Developer Experience) for senior leadership (CTO, Head of Cloud, Head of Infrastructure, Head of DevOps). Each deck has a full markdown source of truth (with speaker notes + mermaid diagrams) and a lean Marp deck (no speaker notes, embedded PNG diagrams). A README documents the 3-step slide creation process (full markdown → Marp synthesis → PPTX export). Docs-only NFR patch.
+- **v1.9.2 (complete, tag `v1.9.2`):** S&P Global Energy theme for presentation decks. Applies the S&P Global Energy brand visual identity (red-core #D6002A, grey-90 #1B1B1B, Akkurat Pro font) to both Marp decks. Title headers changed to full platform name. Footer 'Confidential' → 'Internal'. Title slide subtitle removed. Last DX slide renamed to 'The Desired Outcomes'. Docs-only NFR patch.
+- **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.0 demo URL:** https://git.cloudinit.dev/continuous-intelligence/acdl-evidence/raw/branch/main/index.html
 
 ---

README.md

@@ -76,7 +76,7 @@ Planned future features (no dates; tracked in the internal roadmap):
   consumer creates a module directly from the contract file (the
   "composition" mechanism, redesigned).
 - **Compliance milestone** — per-module compliance extension points (GDPR,
-  SOX, SOC2, HIPAA, DORA) wired into the pipeline.
+  SOX, SOC2, DORA) wired into the pipeline.
 - **Additional substrate adapters** — beyond the Terraform adapter.
 - **Environment self-service** — a consumer-facing flow to request and
   provision a new platform-managed environment (today it is a platform-team

docs/consumer-guide.md

@@ -292,7 +292,7 @@ for the full table.
 ## Step 9 — Compliance extensions
 
 Each module lists compliance extension points for the future compliance
-milestone (GDPR, SOX, SOC2, HIPAA, DORA). See each module's README under
+milestone (GDPR, SOX, SOC2, DORA). See each module's README under
 `modules/l1/<name>/README.md` or `modules/l2/<name>/README.md` for the
 per-module extension points. Common examples:
 

docs/index.md

@@ -63,7 +63,7 @@ Planned future features (no dates; tracked in the internal roadmap):
   consumer creates a module directly from the contract file (the "composition"
   mechanism, redesigned).
 - **Compliance milestone** — per-module compliance extension points (GDPR,
-  SOX, SOC2, HIPAA, DORA) wired into the pipeline.
+  SOX, SOC2, DORA) wired into the pipeline.
 - **Additional substrate adapters** — beyond the Terraform adapter.
 - **Environment self-service** — a consumer-facing flow to request and
   provision a new platform-managed environment.

docs/presentations/README.md

@@ -63,9 +63,32 @@ Synthesize the full markdown into a lean Marp deck:
 - **Tighter prose** than Step 1 — strip the speaker-note nuance; keep the
   leadership-relevant selling points.
 
-### Step 3 — PPTX export
+### Step 3 — Render to HTML and PPTX
 
-Export the Marp deck to PPTX for stakeholders who want a slide file:
+Both formats are derived from the Marp deck. **HTML is committed to the repo**
+(viewable in any browser, self-contained with base64-embedded images). **PPTX
+is uploaded to the Gitea release** as a downloadable attachment (binary, not
+committed to git).
+
+#### HTML export (committed to repo)
+
+```bash
+CHROME_PATH=/root/.cache/ms-playwright/chromium-1217/chrome-linux64/chrome \
+  npx --yes @marp-team/marp-cli@latest --allow-local-files \
+  docs/presentations/<deck-name>-marp.md \
+  -o docs/presentations/<deck-name>.html
+```
+
+HTML export inlines images as base64 data URIs — no `--allow-local-files`
+needed for self-contained output, but it's required when the Marp deck
+references local PNG assets. The resulting HTML is a single self-contained
+file that renders the full deck with the S&P Global Energy theme.
+
+**Re-render the HTML whenever the Marp source changes.** The HTML files are
+committed artifacts, not generated on-the-fly — they must be re-rendered and
+re-committed when the Marp deck is updated.
+
+#### PPTX export (uploaded to Gitea release)
 
 ```bash
 CHROME_PATH=/root/.cache/ms-playwright/chromium-1217/chrome-linux64/chrome \
@@ -75,7 +98,9 @@ CHROME_PATH=/root/.cache/ms-playwright/chromium-1217/chrome-linux64/chrome \
 ```
 
 The `--allow-local-files` flag is **required** for PPTX export so the local
-PNG diagrams are embedded in the file.
+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.
 
 ## Directory layout
 
@@ -84,8 +109,10 @@ 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.html                  ← Step 3: rendered HTML (committed)
 ├── the-developer-experience.md                 ← Step 1: full source of truth
 ├── the-developer-experience-marp.md            ← Step 2: Marp deck
+├── the-developer-experience.html               ← Step 3: rendered HTML (committed)
 └── assets/
     ├── puppeteer-config.json                   ← no-sandbox config for mmdc
     ├── mmd/                                     ← mermaid source files (Step 2 input)
@@ -170,19 +197,23 @@ done
 The `puppeteer-config.json` passes `--no-sandbox` to the headless browser
 (required when running as root in this environment).
 
-### Export a Marp deck to HTML (for browser preview)
+### Export a Marp deck to HTML (committed to repo)
 
 ```bash
 CHROME_PATH=/root/.cache/ms-playwright/chromium-1217/chrome-linux64/chrome \
-  npx --yes @marp-team/marp-cli@latest \
+  npx --yes @marp-team/marp-cli@latest --allow-local-files \
   docs/presentations/<deck-name>-marp.md \
-  -o <output-path>.html
+  -o docs/presentations/<deck-name>.html
 ```
 
-HTML export inlines images as base64 data URIs — no `--allow-local-files`
-needed.
+HTML export inlines images as base64 data URIs. The `--allow-local-files`
+flag is needed when the Marp deck references local PNG assets (like the
+diagram images in `assets/png/`). The resulting HTML is self-contained.
 
-### Export a Marp deck to PPTX (for stakeholders)
+**The HTML files are committed artifacts** — re-render and re-commit whenever
+the Marp source changes.
+
+### Export a Marp deck to PPTX (uploaded to Gitea release)
 
 ```bash
 CHROME_PATH=/root/.cache/ms-playwright/chromium-1217/chrome-linux64/chrome \
@@ -192,7 +223,8 @@ CHROME_PATH=/root/.cache/ms-playwright/chromium-1217/chrome-linux64/chrome \
 ```
 
 `--allow-local-files` is **required** for PPTX so local PNG diagrams are
-embedded in the file.
+embedded in the file. PPTX files are not committed to git — upload them as
+attachments to the Gitea release.
 
 ## Adding a new presentation
 
@@ -203,8 +235,11 @@ embedded in the file.
    and render them to `assets/png/` (command above).
 3. **Synthesize the Marp deck** as `<deck-name>-marp.md` with frontmatter,
    no speaker notes, embedded PNGs, and maturity badges.
-4. **Export to PPTX** with `--allow-local-files`.
-5. **Verify** the PPTX slide count and that media files are embedded:
+4. **Render to HTML** with `--allow-local-files` and commit the HTML to
+   `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:
    ```bash
    python3 -c "
    import zipfile, re
@@ -217,7 +252,7 @@ embedded in the file.
 
 ## Current decks
 
-| Deck | Source of truth (Step 1) | Marp deck (Step 2) | Audience |
-|---|---|---|---|
-| How the Platform Works | `how-the-platform-works.md` | `how-the-platform-works-marp.md` | CTO, Head of Cloud, Head of Infra, Head of DevOps |
-| The Developer Experience | `the-developer-experience.md` | `the-developer-experience-marp.md` | CTO, Head of Cloud, Head of Infra, Head of DevOps |
+| 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 |

docs/presentations/how-the-platform-works-marp.md

@@ -3,20 +3,21 @@ marp: true
 theme: default
 paginate: true
 size: 16x9
-header: "ACDL — How the Platform Works"
-footer: "Confidential · For Senior Leadership"
+header: "How The Platform Works"
+footer: "Internal"
 style: |
   section {
-    font-family: "Inter", "Segoe UI", "Helvetica Neue", sans-serif;
+    font-family: "Akkurat Pro", "Helvetica Neue", "Arial", sans-serif;
     font-size: 22px;
+    color: #1B1B1B;
   }
-  h1 { color: #1a365d; font-size: 34px; margin-bottom: 0.3em; }
-  h2 { color: #1a365d; font-size: 26px; margin-bottom: 0.2em; }
-  section.title { background: #1a365d; color: #fff; }
+  h1 { color: #D6002A; font-size: 34px; margin-bottom: 0.3em; }
+  h2 { color: #D6002A; font-size: 26px; margin-bottom: 0.2em; }
+  section.title { background: #1B1B1B; color: #fff; border-top: 8px solid #D6002A; }
   section.title h1 { color: #fff; }
   table { font-size: 18px; width: 100%; }
-  th { background: #edf2f7; }
-  blockquote { border-left: 4px solid #3182ce; color: #2d3748; font-size: 20px; }
+  th { background: #F0F0F0; }
+  blockquote { border-left: 4px solid #D6002A; color: #2E2E2E; font-size: 20px; }
   img { display: block; margin: 0 auto; max-height: 320px; }
   .badge {
     display: inline-block; padding: 2px 8px; border-radius: 4px;
@@ -29,14 +30,13 @@ style: |
 <!-- _class: title -->
 <!-- _paginate: false -->
 
-# How the Platform Works
+# How The Platform Works
 
-**ACDL — Agentic Cloud Delivery Platform**
-
-Senior Leadership Briefing
+### Agentic Cloud Delivery Platform
 
 <style>
-section.title h1 { font-size: 42px; }
+section.title h1 { font-size: 44px; margin-bottom: 0.1em; }
+section.title h3 { color: #F0F0F0; font-weight: 400; font-size: 22px; margin-top: 0; }
 </style>
 
 ---
@@ -237,7 +237,7 @@ section { font-size: 20px; }
 - Real OIDC federation on all platform runners
 - HITL wiring for qa / prod / dr environments
 - Full regulatory ledger: S3 Object Lock + JWS signatures + daily checkpoints
-- Compliance milestone: GDPR, SOX, SOC2, HIPAA, DORA extension points
+- Compliance milestone: GDPR, SOX, SOC2, DORA extension points
 - Environment self-service provisioning
 - Dynamic module creation from a contract (agentic citizen-developer flow)
 - Additional substrate adapters (OpenTofu, Pulumi, Kubernetes CRDs)

docs/presentations/how-the-platform-works.md

@@ -1,5 +1,6 @@
-# How the Platform Works
+# How The Platform Works
 
+> **Subtitle:** Agentic Cloud Delivery Platform
 > **Audience:** Senior Leadership, CTO, Head of Cloud, Head of Infrastructure, Head of DevOps
 > **Length:** ~15 minutes · 14 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."
@@ -239,7 +240,7 @@ The platform is **opinionated, but not painted into a corner.**
 - 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, HIPAA, DORA.
+- 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).
 - Additional substrate adapters (OpenTofu, Pulumi, Kubernetes CRDs).

docs/presentations/the-developer-experience-marp.md

@@ -3,20 +3,21 @@ marp: true
 theme: default
 paginate: true
 size: 16x9
-header: "ACDL — The Developer Experience"
-footer: "Confidential · For Senior Leadership"
+header: "The Developer Experience"
+footer: "Internal"
 style: |
   section {
-    font-family: "Inter", "Segoe UI", "Helvetica Neue", sans-serif;
+    font-family: "Akkurat Pro", "Helvetica Neue", "Arial", sans-serif;
     font-size: 22px;
+    color: #1B1B1B;
   }
-  h1 { color: #1a365d; font-size: 34px; margin-bottom: 0.3em; }
-  h2 { color: #1a365d; font-size: 26px; margin-bottom: 0.2em; }
-  section.title { background: #1a365d; color: #fff; }
+  h1 { color: #D6002A; font-size: 34px; margin-bottom: 0.3em; }
+  h2 { color: #D6002A; font-size: 26px; margin-bottom: 0.2em; }
+  section.title { background: #1B1B1B; color: #fff; border-top: 8px solid #D6002A; }
   section.title h1 { color: #fff; }
   table { font-size: 18px; width: 100%; }
-  th { background: #edf2f7; }
-  blockquote { border-left: 4px solid #3182ce; color: #2d3748; font-size: 20px; }
+  th { background: #F0F0F0; }
+  blockquote { border-left: 4px solid #D6002A; color: #2E2E2E; font-size: 20px; }
   pre { font-size: 16px; line-height: 1.3; }
   code { font-size: 16px; }
   img { display: block; margin: 0 auto; max-height: 300px; }
@@ -33,12 +34,11 @@ style: |
 
 # The Developer Experience
 
-**ACDL — Agentic Cloud Delivery Platform**
-
-Senior Leadership Briefing
+### Agentic Cloud Delivery Platform
 
 <style>
-section.title h1 { font-size: 42px; }
+section.title h1 { font-size: 44px; margin-bottom: 0.1em; }
+section.title h3 { color: #F0F0F0; font-weight: 400; font-size: 22px; margin-top: 0; }
 </style>
 
 ---
@@ -50,7 +50,7 @@ The platform serves **two kinds of consumer** through two coordinated interfaces
 ![w:1000](assets/png/developer-experience-01-two-surfaces.png)
 
 - **Technical developer** — owns app code + a contract + a thin CI definition
-- **Citizen developer** — declares intent in plain language; an agent produces a contract that passes the **same** safety envelope
+- **Citizen developer** — declares intent in plain language; an AI agent produces a contract that passes the **same** safety envelope
 
 The platform is **opinionated in what it accepts, regardless of who is declaring.** There is no "citizen developer mode" with weaker checks.
 
@@ -60,7 +60,7 @@ The platform is **opinionated in what it accepts, regardless of who is declaring
 
 Three things. That is the entire consumer-side surface.
 
-![w:900](assets/png/developer-experience-02-what-dev-does.png)
+<img src="assets/png/developer-experience-02-what-dev-does.png" style="float: right; width: 45%; margin-left: 20px; margin-bottom: 10px;" />
 
 The developer does **not**:
 
@@ -77,7 +77,7 @@ The developer does **not**:
 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 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**
 - The contract enters the **same pipeline** and must clear the **same confidence gate** before promotion
 
 **Guardrails that make this safe:**
@@ -165,17 +165,6 @@ After a successful deploy, the developer gets their connection information **wit
 
 ---
 
-# Local Reproducibility
-
-The entire CI pipeline runs **from the shell**, not just in CI. <span class="badge today">Available today</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. A test asserts conformance
-
----
-
 # Friendly Onboarding
 
 First impressions of a platform are made **when it fails for the first time.** The platform fails gracefully. <span class="badge today">Available today</span>
@@ -199,7 +188,11 @@ Both onboarding paths end in a **sandbox dev submission that must pass the confi
 
 The contract is environment-agnostic by design. Promotion is **a workflow choice, not a contract edit** — the platform raises the bar automatically.
 
-**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 never changes.
+<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. The contract never changes.
 
 ```yaml
 jobs:
@@ -212,7 +205,10 @@ jobs:
     with: { contract: .acdl/contract.yaml, environment: qa }
 ```
 
-**Approach B — One job per environment, environment-specific contracts.** When inputs genuinely differ per environment, each job points at its own contract file.
+</td>
+<td style="width: 50%; vertical-align: top; border: none; padding-left: 12px;">
+
+**Approach B — Environment-specific contracts.** When inputs genuinely differ per environment, each job points at its own contract file.
 
 ```yaml
 jobs:
@@ -225,10 +221,15 @@ jobs:
     with: { contract: .acdl/contract-qa.yaml }
 ```
 
+</td>
+</tr>
+</table>
+
 <style>
-section { font-size: 19px; }
-pre { font-size: 13px; }
-code { font-size: 13px; }
+section { font-size: 18px; }
+pre { font-size: 11px; line-height: 1.2; }
+code { font-size: 11px; }
+td { font-size: 16px; }
 </style>
 
 ---
@@ -283,14 +284,14 @@ Developers pick from **pre-built, security-reviewed building blocks** — they d
 - **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>
-- **Compliance extension points** — each module lists where GDPR, SOX, SOC2, HIPAA, DORA controls will wire in <span class="badge planned">Planned</span>
+- **Compliance extension points** — each module lists where GDPR, SOX, SOC2, DORA controls will wire in <span class="badge planned">Planned</span>
 
 ---
 
 <!-- _class: title -->
 <!-- _paginate: false -->
 
-# The Outcome for Leadership
+# The Desired Outcomes
 
 <style>
 section { font-size: 22px; }

docs/presentations/the-developer-experience.md

@@ -1,7 +1,8 @@
 # The Developer Experience
 
+> **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 · 13 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:** "Available today" = shipped and verified. "Planned" = on the roadmap, not yet shipped.
 
@@ -22,7 +23,7 @@ flowchart TD
 ```
 
 - **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 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.
 
 The platform is **opinionated in what it accepts, regardless of who is declaring.** There is no "citizen developer mode" with weaker checks.
 
@@ -59,7 +60,7 @@ The developer does **not**:
 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 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.**
 - The contract enters the **same pipeline** and must clear the **same confidence gate** before promotion.
 
 **Guardrails that make this safe:**
@@ -176,20 +177,7 @@ After a successful deploy, the developer gets their connection information **wit
 
 ---
 
-## Slide 9 — Local Reproducibility
-
-The entire CI pipeline runs **from the shell**, not just in CI.
-
-- `scripts/run_ci.sh` mirrors the CI pipeline locally — the same three stages (lint → test → check-only) in sequence. Exits 0 with "CI PIPELINE OK." *(Available today.)*
-- `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. *(Available today.)*
-- `--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 the GitHub and Gitea workflows implement. A test asserts conformance.
-
-> **Speaker notes:** This is the "no 'works on my machine' for CI" slide. A developer can reproduce the exact CI behavior locally before pushing. For the Head of Engineering: this shrinks the PR-cycle time because failures are caught pre-push, and it makes the pipeline itself a reviewable artifact (the YAML contract), not tribal workflow code.
-
----
-
-## Slide 10 — Friendly Onboarding
+## Slide 9 — Friendly Onboarding
 
 First impressions of a platform are made **when it fails for the first time.** The platform fails gracefully.
 
@@ -308,7 +296,7 @@ Developers pick from **pre-built, security-reviewed building blocks** — they d
 - **Modules** — composed patterns (a static site with CDN + WAF; a microservice with VPC + ECS + load balancer + registry). *(Available today.)*
 - **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. *(Available today.)*
 - **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, HIPAA, DORA controls will wire in. *(Compliance milestone is 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.
 

modules/README-TEMPLATE.md

@@ -50,7 +50,7 @@ L1 primitive MUST declare `deletion_protection` and `encryption_enabled`
 ## Compliance extension points
 
 Resources this module could be extended with for the future compliance
-milestone (GDPR, SOX, SOC2, HIPAA, DORA). Not implemented yet — listed
+milestone (GDPR, SOX, SOC2, DORA). Not implemented yet — listed
 so the redesign can plan for them.
 
 - **<area>** — <what could be added, e.g. KMS key for encryption>

modules/STANDARDS.md

@@ -431,7 +431,7 @@ Every module README MUST follow the structure of
 7. `## Usage` — a concrete snippet showing how a consumer references
    the module in a contract.
 8. `## Compliance extension points` — resources or behaviors that could
-   be added for the future compliance milestone (GDPR, SOX, SOC2, HIPAA,
+   be added for the future compliance milestone (GDPR, SOX, SOC2,
    DORA). Not implemented yet; listed so the redesign can plan for them.
 9. `## Examples` — links to `examples/simple.yaml` and
    `examples/complex.yaml` with a one-line description of each.

modules/l1/alb/README.md

@@ -57,7 +57,7 @@ The `target_group_arn` output is referenced by `ecs-service` as its
 
 ## Compliance extension points
 
-- **TLS / HTTPS listener** — add `aws_acm_certificate` + `ssl_policy` + `certificate_arn` for encryption in transit (SOC2 CC6.1, PCI-DSS 4.1, HIPAA §164.312(e)(1), GDPR Art.32).
+- **TLS / HTTPS listener** — add `aws_acm_certificate` + `ssl_policy` + `certificate_arn` for encryption in transit (SOC2 CC6.1, PCI-DSS 4.1, GDPR Art.32).
 - **Access logs** — add `access_logs { bucket = ..., prefix = ... }` to the load balancer (SOX, SOC2 CC7.2, DORA ICT audit trail).
 - **Security group rules** — add ingress/egress rules restricting traffic to known sources (SOC2 CC6.6, PCI-DSS 1.2).
 - **Health check** — add a `health_check` block to the target group (SOC2 CC7.3 monitoring, DORA operational resilience).

modules/l1/cloudfront/README.md

@@ -69,7 +69,7 @@ inside a module composition (see `modules/l2/static-assets`).
 - **Logging** — CloudFront access logs to an S3 bucket for auditability
   (SOC2 CC7.2, DORA audit trail).
 - **Field-level encryption** — add field-level encryption for PII fields
-  in POST bodies (HIPAA §164.312(a)(2)(iv), GDPR Art.32).
+  in POST bodies (GDPR Art.32).
 
 ## Examples
 

modules/l1/ecr/README.md

@@ -45,11 +45,11 @@ The `repository_url` output is used to build the `image` input for
 
 ## Compliance extension points
 
-- **Image scanning** — add `image_scanning_configuration { scan_on_push = true }` for vulnerability scanning (SOC2 CC7.6, DORA ICT risk testing, HIPAA security monitoring).
-- **Encryption** — add `encryption_configuration { encryption_type = "KMS", kms_key = ... }` with a customer-managed key (SOC2 CC6.1, HIPAA §164.312(a)(2)(iv), GDPR Art.32).
+- **Image scanning** — add `image_scanning_configuration { scan_on_push = true }` for vulnerability scanning (SOC2 CC7.6, DORA ICT risk testing, security monitoring).
+- **Encryption** — add `encryption_configuration { encryption_type = "KMS", kms_key = ... }` with a customer-managed key (SOC2 CC6.1, GDPR Art.32).
 - **Image tag immutability** — add `image_tag_mutability = "IMMUTABLE"` to prevent tag overwriting (SOX §802, SOC2 CC6.1 integrity, DORA audit integrity).
 - **Lifecycle policy** — add `aws_ecr_lifecycle_policy` to enforce image retention / cleanup (GDPR Art.5(2) data minimization, SOC2 CC5.2).
-- **Access policy** — add a repository policy restricting pull/push to known roles (SOC2 CC6.1, HIPAA §164.308(a)(4)).
+- **Access policy** — add a repository policy restricting pull/push to known roles (SOC2 CC6.1.
 
 ## Examples
 

modules/l1/ecs-cluster/README.md

@@ -46,8 +46,8 @@ The `cluster_arn` output is referenced by `ecs-service` as its
 ## Compliance extension points
 
 - **Container Insights** — add `configuration { container_insights = "enabled" }` for observability (SOC2 CC7.3, DORA ICT risk monitoring).
-- **CloudWatch Logs** — add a log group with retention policy for cluster-level audit logs (SOX, SOC2 CC7.2, HIPAA §164.312(b)).
-- **Encryption** — add `settings { name = "containerInsights", value = "enabled" }` and KMS-based encryption for container data (HIPAA §164.312(a)(2)(iv), GDPR Art.32).
+- **CloudWatch Logs** — add a log group with retention policy for cluster-level audit logs (SOX, SOC2 CC7.2.
+- **Encryption** — add `settings { name = "containerInsights", value = "enabled" }` and KMS-based encryption for container data (GDPR Art.32).
 
 ## Examples
 

modules/l1/ecs-service/README.md

@@ -64,9 +64,9 @@ provided.
 
 ## Compliance extension points
 
-- **CloudWatch Logs** — add `logConfiguration` to the container definition with a log group + retention policy (SOX, SOC2 CC7.2, HIPAA §164.312(b), DORA ICT incident logging).
+- **CloudWatch Logs** — add `logConfiguration` to the container definition with a log group + retention policy (SOX, SOC2 CC7.2, DORA ICT incident logging).
 - **Task execution role separation** — add a separate `aws_iam_role` for execution vs. the task role (SOC2 CC6.3 segregation of duties at runtime).
-- **Secrets injection** — add `secrets` block referencing AWS Secrets Manager / SSM Parameter Store with KMS encryption (SOC2 CC6.1, HIPAA §164.312(a)(2)(iv)).
+- **Secrets injection** — add `secrets` block referencing AWS Secrets Manager / SSM Parameter Store with KMS encryption (SOC2 CC6.1.
 - **Execute command** — add `enable_execute_command` with KMS encryption for session audit (SOC2 CC7.2).
 - **Deployment circuit breaker** — add `deployment_circuit_breaker` block for resilience (SOC2 CC9.1, DORA operational resilience).
 - **Health check** — add a `health_check` block to the target group (currently missing despite the contract schema having a healthcheck field).

modules/l1/iam-role/README.md

@@ -51,8 +51,8 @@ into the Terraform `assume_role_policy` argument. The
 ## Compliance extension points
 
 - **Permissions boundary** — add `permissions_boundary` to enforce least-privilege guardrails (SOC2 CC6.1, SOX ITGC, DORA ICT access control).
-- **Inline policy** — add `aws_iam_role_policy` for fine-grained least-privilege instead of broad managed policies (SOC2 CC6.1, HIPAA §164.308(a)(4)).
-- **MFA conditions** — add `condition` blocks requiring MFA for assume-role (SOC2 CC6.1, HIPAA §164.312(d)).
+- **Inline policy** — add `aws_iam_role_policy` for fine-grained least-privilege instead of broad managed policies (SOC2 CC6.1.
+- **MFA conditions** — add `condition` blocks requiring MFA for assume-role (SOC2 CC6.1.
 - **Source IP / region conditions** — add `aws:SourceIp` / `aws:RequestedRegion` conditions for data residency enforcement (GDPR Art.44-49, DORA ICT third-party risk).
 - **Access Analyzer** — add `aws_accessanalyzer_analyzer` to verify least-privilege (SOC2 CC6.1, GDPR Art.32).
 - **Role separation** — add a separate task role vs. execution role (SOC2 CC6.3 segregation of duties).

modules/l1/kms-key/README.md

@@ -53,7 +53,7 @@ pipeline as the regression baseline).
 
 ## Compliance extension points
 
-- **Key rotation** — automatic key rotation enabled by default (SOC2 CC6.1, HIPAA §164.312(a)(2)(iv), GDPR Art.32).
+- **Key rotation** — automatic key rotation enabled by default (SOC2 CC6.1, GDPR Art.32).
 - **Deletion protection** — pending deletion window prevents accidental destruction (SOC2 CC7.2).
 - **Key policy** — restrict key usage to the stack's IAM roles (SOC2 CC6.1, GDPR Art.32).
 - **Audit logging** — CloudTrail logs all KMS API calls (SOC2 CC7.2, DORA audit trail).

modules/l1/rds/README.md

@@ -72,18 +72,17 @@ as the regression baseline).
 ## Compliance extension points
 
 - **KMS encryption** — add a customer-managed KMS key for storage
-  encryption (`kms_key_id` argument) (SOC2 CC6.1, HIPAA §164.312(a)(2)(iv),
+  encryption (`kms_key_id` argument) (SOC2 CC6.1,
   GDPR Art.32).
 - **Automated backups** — the `backup_retention_period` NFR controls
   automated backup retention; extend with backup windows + copy tags to
   another region for DR (SOX ITGC, DORA operational resilience).
 - **Audit logging via CloudTrail** — RDS does not emit CloudTrail events
   for data-plane access; add `aws_db_instance_automated_backups_replication`
-  + CloudWatch Logs for database audit (SOX, SOC2 CC7.2, HIPAA
-  §164.312(b)).
+  + CloudWatch Logs for database audit (SOX, SOC2 CC7.2).
 - **IAM database authentication** — add `iam_database_authentication_enabled
   = true` so IAM users/roles can authenticate to the database without
-  long-lived passwords (SOC2 CC6.1, HIPAA §164.308(a)(4)).
+  long-lived passwords (SOC2 CC6.1).
 - **Read replicas** — add `aws_db_instance` with `replicate_source_db` for
   read scaling and DR failover (SOC2 CC9.1, DORA operational resilience).
 

modules/l1/s3/README.md

@@ -50,11 +50,11 @@ pipeline as the regression baseline).
 
 ## Compliance extension points
 
-- **Encryption at rest** — add `aws_s3_bucket_server_side_encryption_configuration` with a customer-managed KMS key (SOC2 CC6.1, HIPAA §164.312(a)(2)(iv), GDPR Art.32).
+- **Encryption at rest** — add `aws_s3_bucket_server_side_encryption_configuration` with a customer-managed KMS key (SOC2 CC6.1, GDPR Art.32).
 - **Object Lock** — add `aws_s3_bucket_object_lock_configuration` in compliance mode with 7-year retention for immutable evidence (SOX §802, DORA audit trail).
 - **Access logging** — add `aws_s3_bucket_logging` to a target logging bucket (SOC2 CC7.2).
 - **Public access block** — add `aws_s3_bucket_public_access_block` to prevent data exfiltration (SOC2 CC6.1, GDPR Art.32).
-- **Lifecycle policy** — add `aws_s3_bucket_lifecycle_configuration` for retention enforcement (GDPR Art.5(2), HIPAA §164.530(j)).
+- **Lifecycle policy** — add `aws_s3_bucket_lifecycle_configuration` for retention enforcement (GDPR Art.5(2).
 
 ## Examples
 

modules/l1/uptime/README.md

@@ -72,7 +72,7 @@ pipeline as the regression baseline).
 
 ## Compliance extension points
 
-- **KMS encryption for EFS** — encrypt the EFS volume that persists uptime-kuma state with a customer-managed KMS key (SOC2 CC6.1, HIPAA §164.312(a)(2)(iv), GDPR Art.32).
+- **KMS encryption for EFS** — encrypt the EFS volume that persists uptime-kuma state with a customer-managed KMS key (SOC2 CC6.1, GDPR Art.32).
 - **HTTPS/TLS for the ALB** — attach an ACM certificate and HTTPS listener to the ALB so the dashboard is served over TLS (SOC2 CC6.1, GDPR Art.32).
 - **WAF in front of uptime dashboard** — place a WAF web ACL in front of the ALB to protect the dashboard from common exploits (SOC2 CC7.2).
 - **Secrets Manager for alert webhook URLs** — store Teams webhook URLs and other credentials in AWS Secrets Manager rather than plaintext inputs (SOC2 CC6.1, GDPR Art.32).

modules/l1/vpc/README.md

@@ -54,8 +54,8 @@ modules reference `subnet_ids` for their network placement.
 
 ## Compliance extension points
 
-- **VPC Flow Logs** — add `aws_flow_log` + CloudWatch Logs group / S3 destination (SOX ITGC, SOC2 CC7.2, HIPAA §164.312(b), DORA ICT risk logging).
-- **Private subnets + NAT gateway** — add private subnets with a NAT gateway so ECS tasks don't need public IPs (SOC2 CC6.6, PCI-DSS 1.3, HIPAA network isolation).
+- **VPC Flow Logs** — add `aws_flow_log` + CloudWatch Logs group / S3 destination (SOX ITGC, SOC2 CC7.2, DORA ICT risk logging).
+- **Private subnets + NAT gateway** — add private subnets with a NAT gateway so ECS tasks don't need public IPs (SOC2 CC6.6, PCI-DSS 1.3, network isolation).
 - **VPC endpoints** — add S3, ECR, KMS, DynamoDB, CloudWatch interface/gateway endpoints to keep traffic off the public internet (SOC2 CC6.7, GDPR Art.32(1)(a), DORA ICT third-party risk).
 - **Security groups** — add `aws_security_group` as a first-class sub-resource (currently missing; needed for all regulated deployments) (SOC2 CC6.6, PCI-DSS 1.2).
 - **Network ACLs** — add `aws_network_acl` for subnet-level segmentation (PCI-DSS 1.3).

modules/l2/microservice/README.md

@@ -53,7 +53,7 @@ inputs:
 ## Compliance extension points
 
 The pattern can wire compliance resources across primitives when the
-compliance milestone (GDPR, SOX, SOC2, HIPAA, DORA) lands:
+compliance milestone (GDPR, SOX, SOC2, DORA) lands:
 
 - **KMS key** — shared encryption key referenced by S3, ECR, CloudWatch Logs, and Secrets Manager.
 - **CloudTrail** — management-plane audit trail for the entire stack.

modules/l2/static-assets/README.md

@@ -75,7 +75,7 @@ READMEs for the underlying primitives.
 ## Compliance extension points
 
 The pattern can wire compliance resources when the compliance
-milestone (GDPR, SOX, SOC2, HIPAA, DORA) lands:
+milestone (GDPR, SOX, SOC2, DORA) lands:
 
 - **KMS key** — shared encryption key for S3 SSE.
 - **S3 access logs** — access logging to a separate audit bucket.