docs(P71b): presentation badge cleanup + platform architecture diagram (v1.13.2)
Remove all testing/agentic maturity badges from both leadership decks across all 4 pipeline layers (source .md, Marp -marp.md, rendered .html, talking-points). Only the planned badges are retained where relevant. Marp inline CSS dropped the .testing/.agentic rules (kept .planned). README maturity-framing updated to describe only the Planned badge. Add a new Slide 3 'The platform at a glance' to both decks with a shared high-level logical architecture diagram (assets/mmd/platform-architecture.mmd -> assets/png/platform-architecture.png). The diagram shows the full topology: consumer surfaces (technical dev + citizen dev) -> contract schema -> central pipeline (8 fixed stages) -> cross-cutting components (module catalog, stateless engine adapter, platform-managed environments, HITL gates, hash-chained evidence stream) -> downstream AWS resources. Subsequent slides renumbered 4-11; talking points + README directory layout + slide counts (10->11 main, 19->20 / 18->19 total) synced. Both HTML decks re-rendered. Docs-only NFR patch (no code changes). ---ci--- project: acdl phase: 71b milestone: v1.13 status: complete ---/ci---
This commit is contained in:
Jon Chery
@@ -26,6 +26,7 @@
|
||||
- **v1.12 (complete, tag `v1.12.0`):** Presentation Refinement — the leadership decks synced to the v1.11-verified reality (22/22 Verified, stateless adapter, lifecycle pipeline, cost figures, pre-mortem). Includes the CAP-013 adapter dedup fix + 2 probe fixes (required to make the deck claims true) + the ACDL_LIFECYCLE_MODE CI flag (lifecycle tests default to plan-only, full on override). 6 phases (P66–P70). See the v1.12 section below.
|
||||
- **v1.13 (complete, tag `v1.13.0`):** Presentation Polish — both leadership decks polished across all 4 pipeline layers (source .md → -marp.md → .html → -talking-points.md). Action headlines replace category names; story-arc restructure (Intro ~10% / Body ~80% / Conclusion ~10%); removed all transition story lines; bullets ≤12 words, 3–4 per main slide; larger fonts (body 26px, h1 40px, h2 32px); 6 new mermaid diagrams (frictions 2×2, north-star before/after, zero-trust flow, catalog primitives→modules, decommission gates, semver timeline). Code review: 0 P0, 2 P1 auto-fixed (slide-count metadata + README directory layout). 522 tests pass. Docs-only NFR patch. 1 phase (P71). See the v1.13 section below.
|
||||
- **v1.13.1 (complete, tag `v1.13.1`):** config.json schema migration — regenerate `.ciagent/config.json` to the updated CIAgent v2 config structure (drop removed fields, migrate `gitea`→`release.gitea`, add `secrets`/`ship`/`backend`/`ideation`/`personas`/`logging`/`telemetry` sections). Code review: 0 P0, 2 P1/P2 auto-fixed. Docs-only NFR patch (no code changes). Gitea release id 253.
|
||||
- **v1.13.2 (complete, tag `v1.13.2`):** presentation badge cleanup + platform architecture diagram — removed all `testing`/`agentic` maturity badges from both decks (only `planned` retained); added a new Slide 3 "The platform at a glance" with a shared high-level logical architecture diagram (consumer surfaces → contract → central pipeline → cross-cutting components → AWS) to both decks; renumbered subsequent slides 4–11; synced talking points + README. Docs-only NFR patch (no code changes).
|
||||
- **v1.0 demo URL:** https://git.cloudinit.dev/continuous-intelligence/acdl-evidence/raw/branch/main/index.html
|
||||
|
||||
---
|
||||
@@ -1033,3 +1034,29 @@ sections). The new config conforms to `CIAgentConfig` (config.ts:156) and passes
|
||||
Multi-persona code review: 0 P0, 2 P1/P2 auto-fixed (`.ciagent/logs/` gitignored,
|
||||
trailing newline restored). Gitea release id 253. Docs-only NFR patch (no code
|
||||
changes).
|
||||
|
||||
### v1.13.2 (complete, tag `v1.13.2`): presentation badge cleanup + platform architecture diagram
|
||||
|
||||
NFR patch (docs-only). Two presentation changes across both leadership decks
|
||||
(`how-the-platform-works` + `the-developer-experience`):
|
||||
|
||||
1. **Badge cleanup** — removed all `testing` and `agentic` maturity badges from
|
||||
every deck layer (source `.md`, Marp `-marp.md`, rendered `.html`,
|
||||
talking-points). Only the `planned` badges are retained where relevant. The
|
||||
Marp inline `style:` CSS dropped the `.testing` / `.agentic` rules (kept
|
||||
`.planned`). The README maturity-framing section updated to describe only the
|
||||
`Planned` badge. Empty table cells (dev environment Maturity row) normalized
|
||||
to `—`.
|
||||
2. **Platform architecture diagram** — added a new Slide 3 "The platform at a
|
||||
glance" to both decks, right after the problem statement. A shared mermaid
|
||||
source (`assets/mmd/platform-architecture.mmd`) renders to
|
||||
`assets/png/platform-architecture.png` and is embedded in both Marp decks.
|
||||
The diagram shows the full logical topology: consumer surfaces (technical dev
|
||||
+ citizen dev) → contract schema → central pipeline (8 fixed stages) →
|
||||
cross-cutting components (module catalog, stateless engine adapter,
|
||||
platform-managed environments, HITL gates, hash-chained evidence stream) →
|
||||
downstream AWS resources. All subsequent slides renumbered 4–11; talking
|
||||
points + README directory layout + slide counts (10→11 main, 19→20 / 18→19
|
||||
total) synced. Both HTML decks re-rendered via Marp.
|
||||
|
||||
Docs-only NFR patch (no code changes).
|
||||
|
||||
@@ -61,9 +61,7 @@ Synthesize the full markdown into a lean Marp deck:
|
||||
- **`<!-- _class: title -->` + `<!-- _paginate: false -->`** on title and
|
||||
closing slides for the dark-background title style.
|
||||
- **Maturity badges** using inline spans:
|
||||
`<span class="badge testing">Testing</span>`
|
||||
`<span class="badge planned">Planned</span>`
|
||||
`<span class="badge agentic">Agentic</span>`
|
||||
- **Tighter prose** than Step 1 — strip the speaker-note nuance; keep the
|
||||
leadership-relevant selling points.
|
||||
|
||||
@@ -115,7 +113,7 @@ 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 + Appendix TOC + appendix slide structure exactly. The Marp deck
|
||||
deck's 11 main + Appendix TOC + 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
|
||||
@@ -145,13 +143,13 @@ and re-distill.
|
||||
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 (10 main + TOC + 8 appendix = 19)
|
||||
├── how-the-platform-works-marp.md ← Step 2: Marp deck (11 main + TOC + 8 appendix = 20)
|
||||
├── how-the-platform-works.html ← Step 3: rendered HTML (committed)
|
||||
├── how-the-platform-works-talking-points.md ← Step 4: presenter cues (19 sections)
|
||||
├── how-the-platform-works-talking-points.md ← Step 4: presenter cues (20 sections)
|
||||
├── the-developer-experience.md ← Step 1: full source of truth
|
||||
├── the-developer-experience-marp.md ← Step 2: Marp deck (10 main + TOC + 7 appendix = 18)
|
||||
├── the-developer-experience-marp.md ← Step 2: Marp deck (11 main + TOC + 7 appendix = 19)
|
||||
├── the-developer-experience.html ← Step 3: rendered HTML (committed)
|
||||
├── the-developer-experience-talking-points.md ← Step 4: presenter cues (18 sections)
|
||||
├── the-developer-experience-talking-points.md ← Step 4: presenter cues (19 sections)
|
||||
└── assets/
|
||||
├── puppeteer-config.json ← no-sandbox config for mmdc
|
||||
├── mmd/ ← mermaid source files (Step 2 input)
|
||||
@@ -171,6 +169,7 @@ docs/presentations/
|
||||
│ ├── developer-experience-05-catalog.mmd
|
||||
│ ├── developer-experience-07-decommission.mmd
|
||||
│ ├── developer-experience-08-semver.mmd
|
||||
│ ├── platform-architecture.mmd ← shared high-level logical architecture (both decks)
|
||||
│ └── road-to-north-star.mmd
|
||||
└── png/ ← rendered PNGs (embedded in Marp)
|
||||
├── platform-works-01-contract-driven.png
|
||||
@@ -188,6 +187,7 @@ docs/presentations/
|
||||
├── developer-experience-05-catalog.png
|
||||
├── developer-experience-07-decommission.png
|
||||
├── developer-experience-08-semver.png
|
||||
├── platform-architecture.png ← shared high-level logical architecture (both decks)
|
||||
└── road-to-north-star.png
|
||||
```
|
||||
|
||||
@@ -195,12 +195,12 @@ docs/presentations/
|
||||
|
||||
### Appendix structure
|
||||
|
||||
Each Marp deck has **10 main slides + an Appendix TOC + appendix slides**. The
|
||||
main 10 are the presentation; the appendix is for deep dives and Q&A backup.
|
||||
Each Marp deck has **11 main slides + an Appendix TOC + appendix slides**. The
|
||||
main 11 are the presentation; the appendix is for deep dives and Q&A backup.
|
||||
The platform-works deck has 8 appendix slides (A1–A8); the developer-experience
|
||||
deck has 7 appendix slides (A1–A7). Both include an Appendix TOC slide.
|
||||
|
||||
- **Main slides** (1-10): the story arc, high-impact, minimal text,
|
||||
- **Main slides** (1-11): the story arc, high-impact, minimal text,
|
||||
visual-heavy. These are what the audience sees during the talk.
|
||||
- **Appendix slides** (TOC + A1..An): detail-heavy slides moved out of the
|
||||
main 10 to preserve the narrative flow. The appendix starts with a TOC
|
||||
@@ -213,13 +213,11 @@ deck has 7 appendix slides (A1–A7). Both include an Appendix TOC slide.
|
||||
|
||||
### Maturity framing
|
||||
|
||||
Every capability claim in a deck is tagged with one of three badges:
|
||||
Every capability claim in a deck is tagged with a `Planned` badge when the item is on the roadmap but not yet implemented:
|
||||
|
||||
| Badge | Meaning |
|
||||
|---|---|
|
||||
| `Testing` | Works internally, not yet released to consumers (0 adoption) |
|
||||
| `Planned` | On the roadmap, not yet implemented |
|
||||
| `Agentic` | Involves AI agents, autonomous decision-making, or the citizen developer flow |
|
||||
|
||||
This is non-negotiable for a leadership audience: never present a roadmap
|
||||
item as a current capability, and never bury a tested capability's
|
||||
@@ -345,5 +343,5 @@ attachments to the Gitea release.
|
||||
|
||||
| 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 + TOC + 8 appendix (19) | 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 + TOC + 7 appendix (18) | CTO, Head of Cloud, Head of Infra, Head of DevOps |
|
||||
| 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` | 11 main + TOC + 8 appendix (20) | 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` | 11 main + TOC + 7 appendix (19) | CTO, Head of Cloud, Head of Infra, Head of DevOps |
|
||||
@@ -0,0 +1,47 @@
|
||||
%%{init: {"theme": "base", "themeVariables": {"primaryColor": "#1B1B1B", "primaryBorderColor": "#D6002A", "primaryTextColor": "#fff", "secondaryColor": "#fff", "secondaryBorderColor": "#D6002A", "secondaryTextColor": "#1B1B1B", "tertiaryColor": "#F0F0F0", "clusterBkg": "#F0F0F0", "lineColor": "#1B1B1B", "fontFamily": "\"Akkurat Pro\", \"Helvetica Neue\", \"Arial\", sans-serif"}}}%%
|
||||
|
||||
flowchart TD
|
||||
subgraph UP ["Consumer surfaces — upstream"]
|
||||
direction LR
|
||||
U1["Technical dev\napp code + contract"]
|
||||
U2["Citizen dev\nintent → AI agent → contract"]
|
||||
end
|
||||
|
||||
subgraph ACDL ["ACDL — infrastructure only"]
|
||||
direction TB
|
||||
CS["Contract schema\n(validate + fail-fast)"]
|
||||
subgraph PIPE ["Central pipeline — fixed stages, every deployment"]
|
||||
direction LR
|
||||
P1["Validate"] --> P2["Resolve\ntarget stack"] --> P3["Security\nchecks"] --> P4["Infra plan"] --> P5["Policy\nchecks"] --> P6["Confidence\nsignal"] --> P7["Evidence\nevent"] --> P8["Infra apply"]
|
||||
end
|
||||
CAT["Module catalog\nprimitives + modules\n(security-reviewed)"]
|
||||
ADAPT["Engine adapter\n(stateless → Terraform)"]
|
||||
ENV["Platform-managed\nenvironments\naccount · VPC · state · IAM"]
|
||||
HITL["HITL gates\nqa · prod · dr"]
|
||||
EVID["Evidence stream\nhash-chained outbox\n(RPO = 0)"]
|
||||
CS --> PIPE
|
||||
CAT --> P2
|
||||
ADAPT --> P4
|
||||
ADAPT --> P8
|
||||
ENV --> P8
|
||||
P6 --> HITL
|
||||
HITL --> P8
|
||||
P7 --> EVID
|
||||
end
|
||||
|
||||
subgraph DOWN ["Downstream"]
|
||||
direction LR
|
||||
D1["AWS resources\nrunning\n(tagged, encrypted)"]
|
||||
D2["Consumer pipeline\ndeploys image"]
|
||||
end
|
||||
|
||||
U1 --> CS
|
||||
U2 --> CS
|
||||
P8 --> D1
|
||||
D1 --> D2
|
||||
|
||||
classDef accent fill:#1B1B1B,color:#fff,stroke:#D6002A,stroke-width:2px
|
||||
classDef supporting fill:#fff,color:#1B1B1B,stroke:#D6002A,stroke-width:1px
|
||||
classDef clusterTitle fill:#F0F0F0,color:#1B1B1B,stroke:#D6002A,stroke-width:1px
|
||||
class CS,P6,P7,EVID,ADAPT,ENV accent
|
||||
class U1,U2,P1,P2,P3,P4,P5,P8,CAT,HITL,D1,D2 supporting
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 76 KiB |
@@ -23,9 +23,7 @@ style: |
|
||||
display: inline-block; padding: 2px 8px; border-radius: 4px;
|
||||
font-size: 16px; font-weight: 600;
|
||||
}
|
||||
.testing { background: #DBEAFE; color: #1E3A5F; }
|
||||
.planned { background: #fef3c7; color: #78350f; }
|
||||
.agentic { background: #EDE9FE; color: #4C1D95; }
|
||||
---
|
||||
|
||||
<!-- _class: title -->
|
||||
@@ -53,6 +51,17 @@ section.title h3 { color: #F0F0F0; font-weight: 400; font-size: 22px; margin-top
|
||||
|
||||
---
|
||||
|
||||
# The platform at a glance
|
||||
|
||||
|
||||
|
||||
- **Consumer surfaces** — technical dev or citizen dev; both produce a contract
|
||||
- **Central pipeline** — fixed stages, identical for every deployment: validate → resolve → security → plan → policy → confidence → evidence → apply
|
||||
- **Module catalog + engine adapter** — security-reviewed blocks; the adapter is the only engine-specific code (Terraform today)
|
||||
- **HITL gates + evidence stream** — human attestation for qa/prod/dr; every deployment writes a hash-chained event (RPO = 0)
|
||||
|
||||
---
|
||||
|
||||
# Declare intent; the platform delivers safe production
|
||||
|
||||
|
||||
@@ -98,7 +107,7 @@ section.title h3 { color: #F0F0F0; font-weight: 400; font-size: 22px; margin-top
|
||||
|
||||
|
||||
|
||||
- **OIDC federation** — short-lived token per job, no stored credential <span class="badge testing">Testing (GitHub Actions)</span> <span class="badge planned">Planned: all runners</span>
|
||||
- **OIDC federation** — short-lived token per job, no stored credential <span class="badge planned">Planned: all runners</span>
|
||||
- **ABAC, not role-based** — repo identity + resource tags scope every action
|
||||
- **A consumer can only touch its own tagged resources.** One consumer can never affect another.
|
||||
|
||||
@@ -108,11 +117,11 @@ section.title h3 { color: #F0F0F0; font-weight: 400; font-size: 22px; margin-top
|
||||
|
||||
|
||||
|
||||
- **Six weighted inputs** — manually tuned, auditable per-input breakdown <span class="badge agentic">Agentic</span>
|
||||
- **Six weighted inputs** — manually tuned, auditable per-input breakdown
|
||||
|
||||
| Environment | Threshold | Attester |
|
||||
|---|---|---|
|
||||
| dev | ≥ 0.50 | No one — autonomous <span class="badge testing">Testing</span> |
|
||||
| dev | ≥ 0.50 | No one — autonomous |
|
||||
| qa | ≥ 0.75 | QA <span class="badge planned">Planned</span> |
|
||||
| prod | ≥ 0.90 | SRE <span class="badge planned">Planned</span> |
|
||||
|
||||
@@ -124,10 +133,10 @@ section.title h3 { color: #F0F0F0; font-weight: 400; font-size: 22px; margin-top
|
||||
|
||||
|
||||
|
||||
- **Dev is fully autonomous** — confidence signal is the only gate <span class="badge testing">Testing</span> <span class="badge agentic">Agentic</span>
|
||||
- **Dev is fully autonomous** — confidence signal is the only gate
|
||||
- **qa, prod, dr require human attestation** — contract + plan + evidence <span class="badge planned">Planned</span>
|
||||
- **Separation of duties** — QA approver ≠ prod approver; platform **blocks on a match** <span class="badge planned">Planned</span>
|
||||
- **Hash-chained evidence event** — tampering breaks the chain. **RPO = 0** <span class="badge testing">Testing</span>
|
||||
- **Hash-chained evidence event** — tampering breaks the chain. **RPO = 0**
|
||||
|
||||
---
|
||||
|
||||
@@ -141,7 +150,7 @@ section.title h3 { color: #F0F0F0; font-weight: 400; font-size: 22px; margin-top
|
||||
- **Auditability as a byproduct, not a project** — every change traceable to a human attestation
|
||||
- **Blast radius contained by design** — OIDC + ABAC, only your own tagged resources
|
||||
- **Infrastructure as a utility, not a craft** — consume, don't maintain
|
||||
- **A path to the citizen developer** — same envelope, senior engineer or non-technical <span class="badge agentic">Agentic</span>
|
||||
- **A path to the citizen developer** — same envelope, senior engineer or non-technical
|
||||
|
||||
---
|
||||
|
||||
@@ -176,13 +185,13 @@ A named environment is a platform-owned bundle of:
|
||||
|
||||
The consumer selects an environment **by name** in their contract. The platform resolves it 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>
|
||||
**Friendly onboarding:** the first run detects no environment and emits a guided prompt (not an opaque failure). <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>
|
||||
Monitoring is **a platform default, not a per-team project.**
|
||||
|
||||
- **Uptime monitoring deployed automatically with every stack** — separate state, feature flag to disable
|
||||
- **Monitored endpoints passed from the deployment's own outputs** — no manual endpoint registration
|
||||
@@ -194,7 +203,7 @@ Monitoring is **a platform default, not a per-team project.** <span class="badge
|
||||
|
||||
# A3 — Security by Construction
|
||||
|
||||
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>
|
||||
Security defaults that **do not require a team to opt in.** Checks run on **every** deployment, normalized to a single schema.
|
||||
|
||||
- **Policy checks** (Checkov, Wiz, Kyverno) — secrets, public ingress, IAM wildcards, **required tagging** — all run *before* infra is created
|
||||
- **Encryption on every resource** — at-rest on by default; per-stack CMKs with 90-day rotation, **no shared keys across stacks**
|
||||
@@ -238,7 +247,7 @@ li { margin-bottom: 2px; }
|
||||
- Module catalog (primitives + modules) with validated examples
|
||||
- Zero-trust OIDC + ABAC on GitHub Actions runners
|
||||
- Security + policy checks before infra creation (Checkov; Wiz + Kyverno ready)
|
||||
- Confidence signal (6 inputs, per-env thresholds) gating promotion <span class="badge agentic">Agentic</span>
|
||||
- Confidence signal (6 inputs, per-env thresholds) gating promotion
|
||||
- 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
|
||||
@@ -256,8 +265,8 @@ li { margin-bottom: 2px; }
|
||||
- Full regulatory ledger: S3 Object Lock + JWS signatures + daily checkpoints
|
||||
- Compliance milestone: GDPR, SOX, SOC2, DORA extension points
|
||||
- Environment self-service provisioning
|
||||
- Dynamic module creation from a contract (agentic citizen-developer flow) <span class="badge agentic">Agentic</span>
|
||||
- Pattern recognition compounds value over time <span class="badge agentic">Agentic</span>
|
||||
- Dynamic module creation from a contract (agentic citizen-developer flow)
|
||||
- Pattern recognition compounds value over time
|
||||
- Additional engine adapters (OpenTofu, Pulumi, Kubernetes CRDs)
|
||||
- Deeper observability bootstrap (dashboards, runbooks, on-call)
|
||||
|
||||
@@ -300,7 +309,7 @@ ACDL runs at **zero cloud cost** for day-to-day development. AWS spend was measu
|
||||
| Peak day | 2026-07-27 ($0.000867) |
|
||||
|
||||
- **S3 dominates** (98.8%, terraform state bucket) — no compute ran because v1.0→v1.10 was plan-only for IAM-gated capabilities
|
||||
- **Local emulators are the primary tier** — the full pipeline runs in-process, no AWS credentials <span class="badge testing">Testing</span>
|
||||
- **Local emulators are the primary tier** — the full pipeline runs in-process, no AWS credentials
|
||||
- **Live-AWS verification is milestone-scoped, then torn down.** The pipeline now **defaults to plan-only** on every PR; `ACDL_LIFECYCLE_MODE=full` overrides to apply→destroy for milestone verification (REQ-134, v1.12).
|
||||
- **Cost drivers** are spike-scoped: Terraform plan reads (free), S3 state storage (cents), DynamoDB outbox (cents). Any spike > $1/day is an anomaly.
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# How The Platform Works — Talking Points
|
||||
|
||||
> **Companion to:** `how-the-platform-works-marp.md` (10 main + Appendix TOC + 8 appendix = 19 slides)
|
||||
> **Companion to:** `how-the-platform-works-marp.md` (11 main + Appendix TOC + 8 appendix = 20 slides)
|
||||
> **Content source:** `how-the-platform-works.md` (full source of truth with speaker notes)
|
||||
> **Purpose:** Presenter-ready cues — 3-6 talking points per slide + the one key takeaway the audience should remember.
|
||||
> **Audience:** Senior Leadership — CTO, Head of Cloud, Head of Infrastructure, Head of DevOps
|
||||
@@ -30,7 +30,19 @@
|
||||
|
||||
---
|
||||
|
||||
## Slide 3 — Declare intent; the platform delivers safe production
|
||||
## Slide 3 — The platform at a glance
|
||||
|
||||
**Talking points:**
|
||||
- One-slide map of the whole platform — use it to orient the audience before diving into any single component
|
||||
- The leadership-relevant beats: (1) two surfaces, one pipeline, one evidence stream — the convergence is the design; (2) the pipeline stages are fixed and identical for every consumer; (3) the engine adapter is the only engine-specific code, which makes the catalog and confidence model portable
|
||||
- Don't walk every node — point to the boundaries and say "the rest of this deck zooms into each of these"
|
||||
- The contract schema is the boundary between upstream and ACDL; everything left of it is the consumer's, everything right of it is the platform's
|
||||
|
||||
**Key takeaway:** Two surfaces, one pipeline, one evidence stream. The rest of the deck zooms in.
|
||||
|
||||
---
|
||||
|
||||
## Slide 4 — Declare intent; the platform delivers safe production
|
||||
|
||||
**Talking points:**
|
||||
- Land the before/after contrast: today's queue vs. ACDL's autonomous flow
|
||||
@@ -42,7 +54,7 @@
|
||||
|
||||
---
|
||||
|
||||
## Slide 4 — ACDL owns infrastructure, not your app
|
||||
## Slide 5 — ACDL owns infrastructure, not your app
|
||||
|
||||
**Talking points:**
|
||||
- The platform is deliberately scoped — it is not trying to be everything
|
||||
@@ -54,7 +66,7 @@
|
||||
|
||||
---
|
||||
|
||||
## Slide 5 — One YAML file. The platform owns everything else.
|
||||
## Slide 6 — One YAML file. The platform owns everything else.
|
||||
|
||||
**Talking points:**
|
||||
- Hold this slide — emphasize the asymmetry. The consumer's surface is intentionally tiny; the platform's surface is large and opinionated
|
||||
@@ -66,19 +78,19 @@
|
||||
|
||||
---
|
||||
|
||||
## Slide 6 — Same stages, same checks, every deployment
|
||||
## Slide 7 — Same stages, same checks, every deployment
|
||||
|
||||
**Talking points:**
|
||||
- Walk left to right once — don't dwell on internals; the point is the flow is fixed, opinionated, and identical for every consumer
|
||||
- The two leadership-relevant beats: (1) checks before creation, (2) every stage is evidenced
|
||||
- No team-specific pipelines, no tribal runbooks — the flow is the contract
|
||||
- The confidence signal (Slide 8) is where the "safety is computed" story lands
|
||||
- The confidence signal (Slide 9) is where the "safety is computed" story lands
|
||||
|
||||
**Key takeaway:** Same stages, same checks, every deployment. No "unchecked" path.
|
||||
|
||||
---
|
||||
|
||||
## Slide 7 — No long-lived credentials. Blast radius contained.
|
||||
## Slide 8 — No long-lived credentials. Blast radius contained.
|
||||
|
||||
**Talking points:**
|
||||
- This is the slide for the Head of Cloud/Security — the key phrase is "blast radius contained to the consumer's own stack"
|
||||
@@ -91,7 +103,7 @@
|
||||
|
||||
---
|
||||
|
||||
## Slide 8 — Safety is a measurable signal, not a black box
|
||||
## Slide 9 — Safety is a measurable signal, not a black box
|
||||
|
||||
**Talking points:**
|
||||
- This is the bet that separates this platform from "yet another CI/CD tool" — reliance on operator instinct or tenure is not a substitute
|
||||
@@ -104,7 +116,7 @@
|
||||
|
||||
---
|
||||
|
||||
## Slide 9 — Every change traceable to a human attestation
|
||||
## Slide 10 — Every change traceable to a human attestation
|
||||
|
||||
**Talking points:**
|
||||
- The "lower environments autonomous, higher environments attested" tenet resolves the classic "move fast vs. be safe" false dichotomy
|
||||
@@ -117,7 +129,7 @@
|
||||
|
||||
---
|
||||
|
||||
## Slide 10 — The vision realized
|
||||
## Slide 11 — The vision realized
|
||||
|
||||
**Talking points:**
|
||||
- Close on the strategic frame — the platform is not "a CI/CD tool," it's the organizational lever for shipping safely at the pace the business demands
|
||||
|
||||
File diff suppressed because one or more lines are too long
@@ -2,7 +2,7 @@
|
||||
|
||||
> **Subtitle:** Agentic Cloud Delivery Platform
|
||||
> **Audience:** Senior Leadership, CTO, Head of Cloud, Head of Infrastructure, Head of DevOps
|
||||
> **Length:** ~15 minutes · 10 main + Appendix TOC + 8 appendix = 19 slides
|
||||
> **Length:** ~16 minutes · 11 main + Appendix TOC + 8 appendix = 20 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" = works internally, dev pilot-ready. "Planned" = on the roadmap, not yet implemented. "Agentic" = involves AI agents or autonomous decision-making.
|
||||
> **Re-verification (2026-07-29):** Every "Testing" claim in this deck was re-verified in v1.10 Phase 54 (D-093) and again in v1.11 via the pipeline-driven lifecycle tests (P59–P62). The headline E2E (contract → resolver → adapter → terraform init/validate/plan) passes against the live AWS account; the local emulating tier (Phase 53) runs the full E2E with no cloud credentials. **22/22 auto-verifiable capabilities Verified** (CAP-013 fixed in v1.12 P67 — the adapter's multi-resource L1 dedup defect is closed; CAP-017/018 probe bugs fixed). The v1.11 lifecycle pipeline ran apply→modify→destroy against live AWS and was then torn down to zero-cost (D-096). See `.ciagent/CAPABILITY_INVENTORY.md` and `.ciagent/PRE_MORTEM.md`.
|
||||
@@ -50,7 +50,66 @@ flowchart LR
|
||||
|
||||
---
|
||||
|
||||
## Slide 3 — Declare intent; the platform delivers safe production
|
||||
## Slide 3 — The platform at a glance
|
||||
|
||||
One picture of the whole platform — the components, how they connect, and where the boundaries are. The rest of this deck zooms into each piece.
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
subgraph UP ["Consumer surfaces — upstream"]
|
||||
direction LR
|
||||
U1["Technical dev\napp code + contract"]
|
||||
U2["Citizen dev\nintent → AI agent → contract"]
|
||||
end
|
||||
|
||||
subgraph ACDL ["ACDL — infrastructure only"]
|
||||
direction TB
|
||||
CS["Contract schema\n(validate + fail-fast)"]
|
||||
subgraph PIPE ["Central pipeline — fixed stages, every deployment"]
|
||||
direction LR
|
||||
P1["Validate"] --> P2["Resolve\ntarget stack"] --> P3["Security\nchecks"] --> P4["Infra plan"] --> P5["Policy\nchecks"] --> P6["Confidence\nsignal"] --> P7["Evidence\nevent"] --> P8["Infra apply"]
|
||||
end
|
||||
CAT["Module catalog\nprimitives + modules\n(security-reviewed)"]
|
||||
ADAPT["Engine adapter\n(stateless → Terraform)"]
|
||||
ENV["Platform-managed\nenvironments\naccount · VPC · state · IAM"]
|
||||
HITL["HITL gates\nqa · prod · dr"]
|
||||
EVID["Evidence stream\nhash-chained outbox\n(RPO = 0)"]
|
||||
CS --> PIPE
|
||||
CAT --> P2
|
||||
ADAPT --> P4
|
||||
ADAPT --> P8
|
||||
ENV --> P8
|
||||
P6 --> HITL
|
||||
HITL --> P8
|
||||
P7 --> EVID
|
||||
end
|
||||
|
||||
subgraph DOWN ["Downstream"]
|
||||
direction LR
|
||||
D1["AWS resources\nrunning\n(tagged, encrypted)"]
|
||||
D2["Consumer pipeline\ndeploys image"]
|
||||
end
|
||||
|
||||
U1 --> CS
|
||||
U2 --> CS
|
||||
P8 --> D1
|
||||
D1 --> D2
|
||||
```
|
||||
|
||||
- **Consumer surfaces** — technical dev or citizen dev; both produce a contract. Upstream is anything.
|
||||
- **Contract schema** — the boundary between upstream and ACDL; validated fail-fast.
|
||||
- **Central pipeline** — fixed stages, identical for every deployment: validate → resolve → security → plan → policy → confidence → evidence → apply.
|
||||
- **Module catalog** — security-reviewed primitives + modules the resolver expands against.
|
||||
- **Engine adapter** — stateless; the only engine-specific code (Terraform today).
|
||||
- **Platform-managed environments** — account, VPC, state, IAM role; the platform owns the blast radius.
|
||||
- **HITL gates** — human attestation for qa/prod/dr; dev is autonomous.
|
||||
- **Evidence stream** — hash-chained outbox, RPO = 0, written by every deployment.
|
||||
|
||||
> **Speaker notes:** This is the one-slide map of the platform. Use it to orient the audience before diving into any single component. The leadership-relevant beats: (1) two surfaces, one pipeline, one evidence stream — the convergence is the design; (2) the pipeline stages are fixed and identical for every consumer — no team-specific pipelines; (3) the engine adapter is the only engine-specific code, which is what makes the catalog and confidence model portable. Don't walk every node; point to the boundaries and say "the rest of this deck zooms into each of these."
|
||||
|
||||
---
|
||||
|
||||
## Slide 4 — Declare intent; the platform delivers safe production
|
||||
|
||||
Consumers **declare intent**; the platform delivers **safe production deployment** — automatically, safely, with a complete audit trail.
|
||||
|
||||
@@ -82,7 +141,7 @@ flowchart LR
|
||||
|
||||
---
|
||||
|
||||
## Slide 4 — ACDL owns infrastructure, not your app
|
||||
## Slide 5 — ACDL owns infrastructure, not your app
|
||||
|
||||
The platform is deliberately scoped — it is not trying to be everything.
|
||||
|
||||
@@ -123,7 +182,7 @@ flowchart LR
|
||||
|
||||
---
|
||||
|
||||
## Slide 5 — One YAML file. The platform owns everything else.
|
||||
## Slide 6 — One YAML file. The platform owns everything else.
|
||||
|
||||
The contract is the boundary between upstream and ACDL. It's all a consumer writes.
|
||||
|
||||
@@ -142,7 +201,7 @@ flowchart LR
|
||||
|
||||
---
|
||||
|
||||
## Slide 6 — Same stages, same checks, every deployment
|
||||
## Slide 7 — Same stages, same checks, every deployment
|
||||
|
||||
Every deployment runs the same stages, in the same order, with the same checks — no team-specific pipelines, no tribal runbooks.
|
||||
|
||||
@@ -161,11 +220,11 @@ flowchart TD
|
||||
- **Security and policy checks run *before* any infrastructure is created** — not as a post-deployment audit.
|
||||
- **Every stage produces a record** that feeds the confidence signal and the evidence stream. 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: (1) checks before creation, (2) every stage is evidenced. The confidence signal (Slide 8) 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: (1) checks before creation, (2) every stage is evidenced. The confidence signal (Slide 9) is where the "safety is computed" story lands.
|
||||
|
||||
---
|
||||
|
||||
## Slide 7 — No long-lived credentials. Blast radius contained.
|
||||
## Slide 8 — No long-lived credentials. Blast radius contained.
|
||||
|
||||
Consumer repositories hold **no long-lived cloud credentials.** Ever.
|
||||
|
||||
@@ -178,7 +237,7 @@ flowchart LR
|
||||
A --> B --> C --> D
|
||||
```
|
||||
|
||||
- **Authentication — OIDC federation.** Each job mints a short-lived token; no credential stored in the consumer repo or runner secret. <span class="badge testing">Testing (GitHub Actions)</span> <span class="badge planned">Planned: all runners</span>
|
||||
- **Authentication — OIDC federation.** Each job mints a short-lived token; no credential stored in the consumer repo or runner secret. <span class="badge planned">Planned: all runners</span>
|
||||
- **Authorization — attribute-based (ABAC), not role-based.** Two attribute classes scope every action:
|
||||
- **Repository identity** — trust policy binds to the exact consumer repo + branch.
|
||||
- **Resource tags** — every resource tagged `acdl:owner` + `acdl:contract`; session policy grants access **only to matching tags.**
|
||||
@@ -188,9 +247,9 @@ flowchart LR
|
||||
|
||||
---
|
||||
|
||||
## Slide 8 — Safety is a measurable signal, not a black box
|
||||
## Slide 9 — Safety is a measurable signal, not a black box
|
||||
|
||||
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>
|
||||
Every delivery action produces a **measurable, explainable confidence signal** — a weighted sum of observable facts, not a black box.
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
@@ -208,7 +267,7 @@ flowchart LR
|
||||
|
||||
| Environment | Threshold | Attester |
|
||||
|---|---|---|
|
||||
| dev | ≥ 0.50 | No one — autonomous <span class="badge testing">Testing</span> |
|
||||
| dev | ≥ 0.50 | No one — autonomous |
|
||||
| qa | ≥ 0.75 | QA <span class="badge planned">Planned</span> |
|
||||
| prod | ≥ 0.90 | SRE <span class="badge planned">Planned</span> |
|
||||
|
||||
@@ -218,7 +277,7 @@ flowchart LR
|
||||
|
||||
---
|
||||
|
||||
## Slide 9 — Every change traceable to a human attestation
|
||||
## Slide 10 — Every change traceable to a human attestation
|
||||
|
||||
Computed safety handles the gate. Humans still matter — here's how accountability works.
|
||||
|
||||
@@ -237,23 +296,23 @@ flowchart LR
|
||||
GATED --> OUT
|
||||
```
|
||||
|
||||
- **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>
|
||||
- **Dev is fully autonomous.** The confidence signal (≥ 0.50) is the only gate.
|
||||
- **qa, prod, dr require human attestation** — the approver reviews contract, planned Terraform, and accumulated evidence. <span class="badge planned">Planned</span>
|
||||
- **Separation of duties is enforced** — 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>
|
||||
- **Every deployment writes a hash-chained evidence event** — tampering breaks the chain. **RPO = 0.**
|
||||
|
||||
> **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* is designed and the dev path is wired; qa/prod/dr wiring is on the roadmap. The audit trail is a byproduct of deployment, not a project. 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.
|
||||
|
||||
---
|
||||
|
||||
## Slide 10 — The vision realized
|
||||
## Slide 11 — The vision realized
|
||||
|
||||
- **Velocity without sacrificing safety.** Speed is in the ergonomics; 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 serves a senior engineer and a non-technical consumer. <span class="badge agentic">Agentic</span>
|
||||
- **A path to the citizen developer.** The same safety envelope serves a senior engineer and a non-technical consumer.
|
||||
|
||||
> **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, with the security and audit posture the regulators require. The investment is in the abstraction, not the tool.
|
||||
|
||||
|
||||
@@ -25,9 +25,7 @@ style: |
|
||||
display: inline-block; padding: 2px 8px; border-radius: 4px;
|
||||
font-size: 16px; font-weight: 600;
|
||||
}
|
||||
.testing { background: #DBEAFE; color: #1E3A5F; }
|
||||
.planned { background: #fef3c7; color: #78350f; }
|
||||
.agentic { background: #EDE9FE; color: #4C1D95; }
|
||||
---
|
||||
|
||||
<!-- _class: title -->
|
||||
@@ -49,12 +47,23 @@ section.title h3 { color: #F0F0F0; font-weight: 400; font-size: 22px; margin-top
|
||||
|
||||
|
||||
- **Technical developer** — owns app code + a contract + a thin CI definition
|
||||
- **Citizen developer** — declares intent; an AI agent produces a contract that passes the **same** safety envelope <span class="badge agentic">Agentic</span>
|
||||
- **Citizen developer** — declares intent; an AI agent produces a contract that passes the **same** safety envelope
|
||||
- **Upstream is anything** — IDE, agentic SDLC, or vibe coding. ACDL doesn't care how the contract was produced
|
||||
- **ACDL is infrastructure only** — provisions and governs AWS resources. Application deployment is upstream
|
||||
|
||||
---
|
||||
|
||||
# The platform at a glance
|
||||
|
||||
|
||||
|
||||
- **You own the left edge** — app code and a contract. That is the entire consumer surface
|
||||
- **The platform owns the middle** — pipeline, catalog, adapter, environments, gates, evidence
|
||||
- **Two surfaces, one pipeline, one evidence stream** — senior engineer and citizen dev converge on the same safety envelope
|
||||
- **The bar rises automatically** — confidence signal + HITL gates scale with the target environment, not a ticket
|
||||
|
||||
---
|
||||
|
||||
# Three things. The entire consumer surface.
|
||||
|
||||
<img src="assets/png/developer-experience-02-what-dev-does.png" style="float: right; width: 38%; margin-left: 20px; margin-bottom: 10px;" />
|
||||
@@ -87,7 +96,7 @@ infrastructure:
|
||||
- **PR comments after every successful pipeline stage** — always know where you stand
|
||||
- **Clear, explainable halt reasons** — a policy violation, an insufficient signal, or a missing attestation. **Never opaque.**
|
||||
- **Connection strings posted as PR comments** — human-readable, no hunting. Runtime secrets go to encrypted Parameter Store, never to logs
|
||||
- **Errors become GitHub issues, automatically** — a failed deploy opens an issue on the platform repo <span class="badge testing">Testing</span>
|
||||
- **Errors become GitHub issues, automatically** — a failed deploy opens an issue on the platform repo
|
||||
|
||||
---
|
||||
|
||||
@@ -98,7 +107,7 @@ infrastructure:
|
||||
- **Primitives** — single-purpose resources (S3, VPC, ECS, IAM, ALB, ECR, CloudFront, WAF, RDS)
|
||||
- **Modules** — composed patterns (static site with CDN + WAF; microservice with VPC + ECS + ALB + ECR)
|
||||
- **Validated examples per module** — `simple.yaml` + `complex.yaml`, validated against the contract schema in CI
|
||||
- **Auto-promotion of patterns** — after 3 observed usages <span class="badge planned">Planned</span> <span class="badge agentic">Agentic</span>
|
||||
- **Auto-promotion of patterns** — after 3 observed usages <span class="badge planned">Planned</span>
|
||||
|
||||
---
|
||||
|
||||
@@ -108,7 +117,7 @@ infrastructure:
|
||||
|
||||
| Environment | What the platform adds | Maturity |
|
||||
|---|---|---|
|
||||
| dev | Confidence ≥ 0.50, fully autonomous | <span class="badge testing">Testing</span> |
|
||||
| dev | Confidence ≥ 0.50, fully autonomous | — |
|
||||
| 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 + DR drill | <span class="badge planned">Planned</span> |
|
||||
@@ -138,7 +147,7 @@ with:
|
||||
|
||||
- **Validate the change request** — platform queries the CMDB; CR must be `approved` and match the consumer repo
|
||||
- **Two SRE human-attestation gates** — disable protection → SRE approves → zero counts + destroy → second SRE approves
|
||||
- **Per-stack encryption key enters a grace window** (default 30 days) so encrypted data remains recoverable <span class="badge testing">Testing</span>
|
||||
- **Per-stack encryption key enters a grace window** (default 30 days) so encrypted data remains recoverable
|
||||
|
||||
---
|
||||
|
||||
@@ -150,13 +159,13 @@ with:
|
||||
- **Semantic versioning with a clear contract:** interface → MAJOR, behavior → MINOR, lifecycle → PATCH
|
||||
- **Pin to an exact version** for stability, or float on MAJOR only (`@v1`) to absorb new features on your own cadence
|
||||
- **Unversioned references (`@main`, bare) are discouraged** — the versioned tag is the only immutability lever
|
||||
- **Automated release job** computes the next semver on merge to main, creates the tag, and updates floating tags <span class="badge testing">Testing</span>
|
||||
- **Automated release job** computes the next semver on merge to main, creates the tag, and updates floating tags
|
||||
|
||||
---
|
||||
|
||||
# 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>
|
||||
First impressions of a platform are made **when it fails for the first time.** The platform fails gracefully.
|
||||
|
||||
When no environment is bound, the platform emits a **user-friendly onboarding prompt** instead of failing opaquely:
|
||||
|
||||
@@ -182,7 +191,7 @@ The pipeline then **exits without attempting a deployment** — no partial state
|
||||
- **Blast radius contained by design** — OIDC + ABAC, only your own tagged resources
|
||||
- **The bottleneck moves off the platform team's ticket queue** — a merged change progresses without a platform engineer joining a thread
|
||||
- **Infrastructure as a utility, not a craft** — consume, don't maintain
|
||||
- **A path to the citizen developer** — same envelope, senior engineer or non-technical <span class="badge agentic">Agentic</span>
|
||||
- **A path to the citizen developer** — same envelope, senior engineer or non-technical
|
||||
|
||||
---
|
||||
|
||||
@@ -217,7 +226,7 @@ A non-technical consumer ships a production deployment **by declaring intent**
|
||||
- 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>
|
||||
<span class="badge planned">Skill catalog + real agent runtime: planned</span>
|
||||
|
||||
---
|
||||
|
||||
@@ -236,7 +245,7 @@ Consumers `uses:` a **versioned** central workflow. The platform fetches itself
|
||||
|
||||
# A3 — Local Reproducibility
|
||||
|
||||
The entire CI pipeline runs **from the shell**, not just in CI. <span class="badge testing">Testing</span>
|
||||
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
|
||||
- `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
|
||||
@@ -287,7 +296,7 @@ ACDL runs at **zero cloud cost** for day-to-day development. AWS spend was measu
|
||||
| Projected monthly | ~$0.007 |
|
||||
| Peak day | 2026-07-27 ($0.000867) |
|
||||
|
||||
- **Local emulators are the primary tier** — the full pipeline runs in-process, no AWS credentials <span class="badge testing">Testing</span>
|
||||
- **Local emulators are the primary tier** — the full pipeline runs in-process, no AWS credentials
|
||||
- **Live-AWS verification is milestone-scoped, then torn down.** The pipeline now **defaults to plan-only** on every PR; `ACDL_LIFECYCLE_MODE=full` overrides to apply→destroy for milestone verification (REQ-134, v1.12).
|
||||
- **Cost drivers** are spike-scoped: Terraform plan reads (free), S3 state storage (cents), DynamoDB outbox (cents). No running infrastructure between milestones.
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# The Developer Experience — Talking Points
|
||||
|
||||
> **Companion to:** `the-developer-experience-marp.md` (10 main + Appendix TOC + 7 appendix = 18 slides)
|
||||
> **Companion to:** `the-developer-experience-marp.md` (11 main + Appendix TOC + 7 appendix = 19 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
|
||||
@@ -31,7 +31,19 @@
|
||||
|
||||
---
|
||||
|
||||
## Slide 3 — Three things. The entire consumer surface.
|
||||
## Slide 3 — The platform at a glance
|
||||
|
||||
**Talking points:**
|
||||
- One-slide map — frame it from the left edge: "this is what you touch, this is what the platform owns for you"
|
||||
- The leadership beat: the convergence — two surfaces, one pipeline, one evidence stream — is the design point that lets us expand who can ship safely without lowering the bar
|
||||
- Don't walk every node — point to the contract boundary and say "the rest of this deck zooms into the developer-facing pieces"
|
||||
- The bar rises automatically — the confidence signal and HITL gates scale with the target environment, not with a ticket
|
||||
|
||||
**Key takeaway:** You own the left edge (app + contract). The platform owns everything else, end to end.
|
||||
|
||||
---
|
||||
|
||||
## Slide 4 — Three things. 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
|
||||
@@ -44,7 +56,7 @@
|
||||
|
||||
---
|
||||
|
||||
## Slide 4 — See what the platform does, in real time
|
||||
## Slide 5 — See what the platform does, in real time
|
||||
|
||||
**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
|
||||
@@ -58,7 +70,7 @@
|
||||
|
||||
---
|
||||
|
||||
## Slide 5 — Pick from pre-built, security-reviewed blocks
|
||||
## Slide 6 — Pick from pre-built, security-reviewed blocks
|
||||
|
||||
**Talking points:**
|
||||
- The catalog is what makes "declare intent" practical — you can only declare a module that exists
|
||||
@@ -72,7 +84,7 @@
|
||||
|
||||
---
|
||||
|
||||
## Slide 6 — The bar rises automatically with sensitivity
|
||||
## Slide 7 — The bar rises automatically with sensitivity
|
||||
|
||||
**Talking points:**
|
||||
- Promotion is a workflow choice, not a contract edit — a promotion can be reviewed as a *diff in the workflow*, not as a rewritten contract
|
||||
@@ -86,7 +98,7 @@
|
||||
|
||||
---
|
||||
|
||||
## Slide 7 — Tearing down is as gated as deploying
|
||||
## Slide 8 — Tearing down is as gated as deploying
|
||||
|
||||
**Talking points:**
|
||||
- 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`
|
||||
@@ -99,7 +111,7 @@
|
||||
|
||||
---
|
||||
|
||||
## Slide 8 — You control when you absorb improvements
|
||||
## Slide 9 — You control when you absorb improvements
|
||||
|
||||
**Talking points:**
|
||||
- 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
|
||||
@@ -113,7 +125,7 @@
|
||||
|
||||
---
|
||||
|
||||
## Slide 9 — Fails gracefully, not opaquely
|
||||
## Slide 10 — Fails gracefully, not opaquely
|
||||
|
||||
**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"
|
||||
@@ -127,7 +139,7 @@
|
||||
|
||||
---
|
||||
|
||||
## Slide 10 — The desired outcomes
|
||||
## Slide 11 — The desired outcomes
|
||||
|
||||
**Talking points:**
|
||||
- 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
|
||||
|
||||
File diff suppressed because one or more lines are too long
@@ -2,7 +2,7 @@
|
||||
|
||||
> **Subtitle:** Agentic Cloud Delivery Platform
|
||||
> **Audience:** Senior Leadership, CTO, Head of Cloud, Head of Infrastructure, Head of DevOps
|
||||
> **Length:** ~15 minutes · 10 main + Appendix TOC + 7 appendix = 18 slides
|
||||
> **Length:** ~16 minutes · 11 main + Appendix TOC + 7 appendix = 19 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" = works internally, dev pilot-ready. "Planned" = on the roadmap. "Agentic" = involves AI agents or autonomous decision-making.
|
||||
> **Re-verification (2026-07-29):** Every "Testing" claim in this deck was re-verified in v1.10 Phase 54 (D-093) and again in v1.11 via the pipeline-driven lifecycle tests (P59–P62). The headline E2E (contract → resolver → adapter → terraform init/validate/plan) passes against the live AWS account; the local emulating tier (Phase 53) runs the full E2E with no cloud credentials. **22/22 auto-verifiable capabilities Verified** (CAP-013 fixed in v1.12 P67 — the adapter's multi-resource L1 dedup defect is closed). The v1.11 lifecycle pipeline ran apply→modify→destroy against live AWS and was then torn down to zero-cost (D-096). See `.ciagent/CAPABILITY_INVENTORY.md` and `.ciagent/PRE_MORTEM.md`.
|
||||
@@ -46,7 +46,7 @@ flowchart LR
|
||||
```
|
||||
|
||||
- **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>
|
||||
- **Citizen developer** — declares intent in plain language; an AI agent produces a contract that passes the **same** safety envelope.
|
||||
- **Upstream is anything** — IDE, agentic SDLC, or vibe coding. ACDL doesn't care how the contract was produced.
|
||||
- **ACDL is infrastructure only** — it provisions and governs AWS resources. Application deployment is upstream.
|
||||
|
||||
@@ -54,7 +54,62 @@ flowchart LR
|
||||
|
||||
---
|
||||
|
||||
## Slide 3 — Three things. The entire consumer surface.
|
||||
## Slide 3 — The platform at a glance
|
||||
|
||||
One picture of the whole platform — what you touch, what the platform owns, and where the safety lives. The rest of this deck zooms into the developer-facing pieces.
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
subgraph UP ["Consumer surfaces — upstream"]
|
||||
direction LR
|
||||
U1["Technical dev\napp code + contract"]
|
||||
U2["Citizen dev\nintent → AI agent → contract"]
|
||||
end
|
||||
|
||||
subgraph ACDL ["ACDL — infrastructure only"]
|
||||
direction TB
|
||||
CS["Contract schema\n(validate + fail-fast)"]
|
||||
subgraph PIPE ["Central pipeline — fixed stages, every deployment"]
|
||||
direction LR
|
||||
P1["Validate"] --> P2["Resolve\ntarget stack"] --> P3["Security\nchecks"] --> P4["Infra plan"] --> P5["Policy\nchecks"] --> P6["Confidence\nsignal"] --> P7["Evidence\nevent"] --> P8["Infra apply"]
|
||||
end
|
||||
CAT["Module catalog\nprimitives + modules\n(security-reviewed)"]
|
||||
ADAPT["Engine adapter\n(stateless → Terraform)"]
|
||||
ENV["Platform-managed\nenvironments\naccount · VPC · state · IAM"]
|
||||
HITL["HITL gates\nqa · prod · dr"]
|
||||
EVID["Evidence stream\nhash-chained outbox\n(RPO = 0)"]
|
||||
CS --> PIPE
|
||||
CAT --> P2
|
||||
ADAPT --> P4
|
||||
ADAPT --> P8
|
||||
ENV --> P8
|
||||
P6 --> HITL
|
||||
HITL --> P8
|
||||
P7 --> EVID
|
||||
end
|
||||
|
||||
subgraph DOWN ["Downstream"]
|
||||
direction LR
|
||||
D1["AWS resources\nrunning\n(tagged, encrypted)"]
|
||||
D2["Consumer pipeline\ndeploys image"]
|
||||
end
|
||||
|
||||
U1 --> CS
|
||||
U2 --> CS
|
||||
P8 --> D1
|
||||
D1 --> D2
|
||||
```
|
||||
|
||||
- **You own the left edge** — app code and a contract. That is the entire consumer surface.
|
||||
- **The platform owns everything in the middle** — the pipeline, the catalog, the adapter, the environments, the gates, the evidence.
|
||||
- **Two surfaces, one pipeline, one evidence stream** — a senior engineer and a citizen developer converge on the same safety envelope.
|
||||
- **The bar rises automatically** — the confidence signal and HITL gates scale with the target environment, not with a ticket.
|
||||
|
||||
> **Speaker notes:** This is the one-slide map. For a developer-experience audience, frame it from the left edge: "this is what you touch, this is what the platform owns for you." The leadership beat: the convergence — two surfaces, one pipeline, one evidence stream — is the design point that lets us expand who can ship safely without lowering the bar. Don't walk every node; point to the contract boundary and say "the rest of this deck zooms into the developer-facing pieces."
|
||||
|
||||
---
|
||||
|
||||
## Slide 4 — Three things. The entire consumer surface.
|
||||
|
||||
Three things. That is the entire consumer-side surface.
|
||||
|
||||
@@ -82,9 +137,9 @@ The developer does **not**: write infrastructure modules, clone the platform rep
|
||||
|
||||
---
|
||||
|
||||
## Slide 4 — See what the platform does, in real time
|
||||
## Slide 5 — See what the platform does, in real time
|
||||
|
||||
Developers see **what the platform is doing**, in real time. <span class="badge testing">Testing</span>
|
||||
Developers see **what the platform is doing**, in real time.
|
||||
|
||||
- **Streamed output by default** — the 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.
|
||||
@@ -96,9 +151,9 @@ Developers see **what the platform is doing**, in real time. <span class="badge
|
||||
|
||||
---
|
||||
|
||||
## Slide 5 — Pick from pre-built, security-reviewed blocks
|
||||
## Slide 6 — Pick from pre-built, security-reviewed blocks
|
||||
|
||||
Developers pick from **pre-built, security-reviewed building blocks.** <span class="badge testing">Testing</span>
|
||||
Developers pick from **pre-built, security-reviewed building blocks.**
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
@@ -125,14 +180,14 @@ flowchart LR
|
||||
- **Primitives** — single-purpose resources (S3, VPC, ECS, IAM, ALB, ECR, CloudFront, WAF, RDS), each with documented inputs/outputs and versioning.
|
||||
- **Modules** — composed patterns (a static site with CDN + WAF; a microservice with VPC + ECS + ALB + ECR).
|
||||
- **Validated examples per module** — `simple.yaml` + `complex.yaml`, 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>
|
||||
- **Auto-promotion of patterns** — 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, 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 6 — The bar rises automatically with sensitivity
|
||||
## Slide 7 — The bar rises automatically with sensitivity
|
||||
|
||||
The contract is environment-agnostic. The platform raises the bar automatically.
|
||||
|
||||
@@ -145,7 +200,7 @@ flowchart LR
|
||||
|
||||
| Environment | What the platform adds | Maturity |
|
||||
|---|---|---|
|
||||
| dev | Confidence ≥ 0.50, fully autonomous | <span class="badge testing">Testing</span> |
|
||||
| dev | Confidence ≥ 0.50, fully autonomous | — |
|
||||
| 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 + DR drill reference | <span class="badge planned">Planned</span> |
|
||||
@@ -158,9 +213,9 @@ flowchart LR
|
||||
|
||||
---
|
||||
|
||||
## Slide 7 — Tearing down is as gated as deploying
|
||||
## Slide 8 — Tearing down is as gated as deploying
|
||||
|
||||
Tearing down a stack is **as deliberate as deploying one.** <span class="badge testing">Testing</span>
|
||||
Tearing down a stack is **as deliberate as deploying one.**
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
@@ -192,9 +247,9 @@ The per-stack encryption key enters a **grace window** (default 30 days) so encr
|
||||
|
||||
---
|
||||
|
||||
## Slide 8 — You control when you absorb improvements
|
||||
## Slide 9 — You control when you absorb improvements
|
||||
|
||||
Consumers control **when** they absorb platform improvements. <span class="badge testing">Testing</span>
|
||||
Consumers control **when** they absorb platform improvements.
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
@@ -231,9 +286,9 @@ flowchart LR
|
||||
|
||||
---
|
||||
|
||||
## Slide 9 — Fails gracefully, not opaquely
|
||||
## Slide 10 — 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>
|
||||
First impressions of a platform are made **when it fails for the first time.** The platform fails gracefully.
|
||||
|
||||
When no environment is bound, the platform emits a **user-friendly onboarding prompt** instead of failing opaquely. The prompt tells the consumer:
|
||||
|
||||
@@ -250,7 +305,7 @@ The pipeline then **exits without attempting a deployment** — no partial state
|
||||
|
||||
---
|
||||
|
||||
## Slide 10 — The desired outcomes
|
||||
## Slide 11 — The desired outcomes
|
||||
|
||||
- **Velocity without sacrificing safety.** Speed is in the ergonomics; safety is in the gates the consumer cannot bypass.
|
||||
- **Security, observability, and compliance as platform defaults** — not per-team effort, not post-hoc remediation.
|
||||
@@ -258,7 +313,7 @@ The pipeline then **exits without attempting a deployment** — no partial state
|
||||
- **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.** Teams consume infrastructure, they don't maintain it.
|
||||
- **A path to the citizen developer.** The same safety envelope serves a senior engineer and a non-technical consumer. <span class="badge agentic">Agentic</span>
|
||||
- **A path to the citizen developer.** The same safety envelope serves a senior engineer and a non-technical consumer.
|
||||
|
||||
> **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.
|
||||
|
||||
@@ -285,7 +340,7 @@ For deep dives — these slides cover details omitted from the main 10.
|
||||
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.** <span class="badge agentic">Agentic</span>
|
||||
- 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:**
|
||||
@@ -295,7 +350,7 @@ A non-technical consumer ships a production deployment **by declaring intent**
|
||||
- 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.
|
||||
|
||||
<span class="badge planned">Skill catalog + real agent runtime: planned</span> <span class="badge agentic">Agentic</span>
|
||||
<span class="badge planned">Skill catalog + real agent runtime: planned</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.
|
||||
|
||||
@@ -326,7 +381,7 @@ flowchart LR
|
||||
|
||||
## A3 — Local Reproducibility
|
||||
|
||||
The entire CI pipeline runs **from the shell**, not just in CI. <span class="badge testing">Testing</span>
|
||||
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.
|
||||
- `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.
|
||||
@@ -380,7 +435,7 @@ ACDL runs at **zero cloud cost** for day-to-day development. The v1.0→v1.10 AW
|
||||
| Projected monthly | ~$0.007 |
|
||||
| Peak day | 2026-07-27 ($0.000867 — v1.10 regression + verify run) |
|
||||
|
||||
- **Local emulators are the primary tier** — the full pipeline runs in-process, no AWS credentials, no Checkov, no DynamoDB. <span class="badge testing">Testing</span>
|
||||
- **Local emulators are the primary tier** — the full pipeline runs in-process, no AWS credentials, no Checkov, no DynamoDB.
|
||||
- **Live-AWS verification is milestone-scoped, then torn down.** The v1.11 lifecycle pipeline ran apply→modify→destroy for every module, then tore down to zero-cost steady state (D-096 — teardown mandatory before milestone COMPLETE). The lifecycle pipeline now **defaults to plan-only** on every PR (fast, no AWS mutation, no cost); a CI variable (`ACDL_LIFECYCLE_MODE=full`) overrides to the real apply→destroy for milestone verification (REQ-134, v1.12).
|
||||
- **Cost drivers** are spike-scoped: Terraform plan reads (free), S3 state storage (cents), DynamoDB outbox (cents). No running infrastructure between milestones.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user