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---
This commit is contained in:
Jon Chery
@@ -3,7 +3,7 @@ marp: true
|
||||
theme: default
|
||||
paginate: true
|
||||
size: 16x9
|
||||
header: "Agentic Cloud Delivery Platform — How The Platform Works"
|
||||
header: "How The Platform Works"
|
||||
footer: "Internal"
|
||||
style: |
|
||||
section {
|
||||
@@ -30,10 +30,13 @@ style: |
|
||||
<!-- _class: title -->
|
||||
<!-- _paginate: false -->
|
||||
|
||||
# Agentic Cloud Delivery Platform — How The Platform Works
|
||||
# How The Platform Works
|
||||
|
||||
### Agentic Cloud Delivery Platform
|
||||
|
||||
<style>
|
||||
section.title h1 { font-size: 36px; }
|
||||
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>
|
||||
|
||||
---
|
||||
@@ -234,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)
|
||||
File diff suppressed because one or more lines are too long
@@ -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).
|
||||
|
||||
@@ -3,7 +3,7 @@ marp: true
|
||||
theme: default
|
||||
paginate: true
|
||||
size: 16x9
|
||||
header: "Agentic Cloud Delivery Platform — The Developer Experience"
|
||||
header: "The Developer Experience"
|
||||
footer: "Internal"
|
||||
style: |
|
||||
section {
|
||||
@@ -32,10 +32,13 @@ style: |
|
||||
<!-- _class: title -->
|
||||
<!-- _paginate: false -->
|
||||
|
||||
# Agentic Cloud Delivery Platform — The Developer Experience
|
||||
# The Developer Experience
|
||||
|
||||
### Agentic Cloud Delivery Platform
|
||||
|
||||
<style>
|
||||
section.title h1 { font-size: 36px; }
|
||||
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>
|
||||
|
||||
---
|
||||
@@ -47,7 +50,7 @@ The platform serves **two kinds of consumer** through two coordinated interfaces
|
||||
|
||||
|
||||
- **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.
|
||||
|
||||
@@ -57,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.
|
||||
|
||||
|
||||
<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**:
|
||||
|
||||
@@ -74,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:**
|
||||
@@ -162,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>
|
||||
@@ -196,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:
|
||||
@@ -209,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:
|
||||
@@ -222,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>
|
||||
|
||||
---
|
||||
@@ -280,7 +284,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)
|
||||
- **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>
|
||||
|
||||
---
|
||||
|
||||
|
||||
File diff suppressed because one or more lines are too long
@@ -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.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user