continuous-intelligence/acdl
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 128 Wiki Activity

verify(P51): code review — 1 P0 auto-fixed, 2 P1+ flagged

Browse Source 
---ci---
project: acdl
phase: 51
milestone: v1.9.8
status: verify
lessons:
  - P0 fix: removed duplicate reclassification bullets in slide 9 (Dev autonomous / qa-prod-dr attestation were listed twice); consolidated badges inline to match Marp deck
---/ci---
This commit is contained in:
Jon Chery
2026-07-27 14:44:12 +00:00
parent 116f49ecb8
commit 00762c1256
2 changed files with 253 additions and 127 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/presentations/how-the-platform-works-talking-points.md
+110 -28
View File
@@ -1,6 +1,6 @@
# How The Platform Works — Talking Points
> **Companion to:** `how-the-platform-works-marp.md` (10 slides)
> **Companion to:** `how-the-platform-works-marp.md` (10 main + 6 appendix = 16 slides)
> **Content source:** `how-the-platform-works.md` (full source of truth with speaker notes)
> **Purpose:** Presenter-ready cues — 3-6 talking points per slide + the one key takeaway the audience should remember.
> **Audience:** Senior Leadership — CTO, Head of Cloud, Head of Infrastructure, Head of DevOps
@@ -12,6 +12,7 @@
**Talking points:**
- Brief introduction — this deck explains *how* the platform works internally, not what the developer experience is (that's the companion deck)
- Set the frame: the platform is not a CI/CD tool — it's the organizational lever for shipping safely at the pace the business demands
- The deck has 10 main slides plus a 6-slide appendix for deep-dive questions
**Key takeaway:** This is a platform that computes safety, doesn't assume it.
@@ -24,16 +25,30 @@
- Walk through the 4 frictions quickly: cognitive load, operational work, red tape, scalability. Don't dwell — the North Star is the resolution
- Land the North Star quote: "declare intent → safe production deployment" — this is the entire value proposition in one sentence
- The litmus test: if a platform engineer still has to touch a ticket for a dev→qa promotion, we haven't delivered the vision
- Close with the two anti-goals: "not a general-purpose AI" and "not a permissive delivery highway" — the platform is deliberately scoped, not trying to be everything
- Note: the 2 anti-goals ("not a general-purpose AI" and "not a permissive delivery highway") have moved to slide 3 — they belong with the scope boundary, not the North Star
**Key takeaway:** The platform absorbs all four frictions. Declare intent, not execute operations.
---
## Slide 3 — The Contract-Driven Model
## Slide 3 — Where ACDL Sits in Your World
**Talking points:**
- This is the new scope-boundary slide — it tells leadership where ACDL fits and, just as importantly, where it doesn't
- Upstream is anything — your IDE, an agentic SDLC, or a citizen developer vibe coding on a laptop. ACDL doesn't care how the contract was produced
- ACDL is infrastructure only — it provisions and governs AWS resources. It does not build, test, or deploy your application code. That's upstream
- Land the 2 anti-goals: "not a general-purpose AI" (autonomy is narrow, scoped to delivery, bounded by strict policy) and "not a permissive delivery highway" (no escape hatches to bypass the confidence framework)
- The sovereign boundary means the platform team owns delivery and infrastructure, not the upstream development process
**Key takeaway:** ACDL is the delivery and infrastructure boundary. Upstream is anything; ACDL is infra only.
---
## Slide 4 — The Contract-Driven Model
**Talking points:**
- Emphasize the asymmetry — the consumer's surface is intentionally tiny (module + environment + inputs), the platform's surface is large and opinionated
- Note: the contract examples now show **infrastructure inputs** (cpu, memory, desired_count, port) — not a container image. The image is upstream; the platform governs infrastructure
- The contract is the API — it's deliberately small so it can be reviewed, validated, and audited
- The consumer does not write infrastructure modules, workflow logic, or adapter code — they declare intent; the platform reconciles, provisions, and progresses
- Land the "no AWS account, no VPC, no state backend" point — the platform owns the blast radius. Consumers can't drift into misconfigured state or over-permissioned roles because they never touch them
@@ -42,19 +57,19 @@
---
## Slide 4 — The End-to-End Flow
## Slide 5 — The End-to-End Flow
**Talking points:**
- Walk the flow left to right once — don't dwell on internals. The point is that the flow is fixed, opinionated, and identical for every consumer
- Land beat 1: security and policy checks run *before* any infrastructure is created — not after the fact, not as a post-deployment audit
- Land beat 2: every stage produces a record that feeds the confidence signal and the evidence stream. There is no "unchecked" path
- Tease the confidence signal (next slide) — this is where "safety is computed" lands
- Tease the confidence signal (slide 7) — this is where "safety is computed" lands
**Key takeaway:** The same pipeline, every time. Checks before creation, evidence at every stage.
---
## Slide 5 — Zero-Trust by Default
## Slide 6 — Zero-Trust by Default
**Talking points:**
- This is the slide for the Head of Cloud/Security — the key phrase is "blast radius contained to the consumer's own stack"
@@ -66,20 +81,21 @@
---
## Slide 6 — Safety is Computed, Not Assumed
## Slide 7 — Safety is Computed, Not Assumed
**Talking points:**
- This is the bet that separates this platform from "yet another CI/CD tool" — reliance on operator instinct or tenure is not a substitute for a computed, auditable signal
- Walk the threshold table: dev ≥ 0.50 (autonomous) → qa ≥ 0.75 (QA attests) → prod ≥ 0.90 (SRE attests) → dr ≥ 0.95 (SRE + DR drill). The bar rises automatically with sensitivity
- The new confidence signal diagram makes the six inputs and the per-input breakdown visible — walk it briefly so the audience sees the signal is *not* a black box
- The weights are **manually tuned**, the inputs are **observable**, and the breakdown is **auditable** — if a consumer asks "why 0.62?", the platform answers with a per-input breakdown. This is the "auditable, not magic" point
- Walk the threshold table: dev ≥ 0.50 (autonomous, Testing) → qa ≥ 0.75 (QA, Planned) → prod ≥ 0.90 (SRE, Planned). The bar rises automatically with sensitivity
- A single critical policy finding hard-blocks the deployment — critical findings are not averaged away. This is non-negotiable
- When the platform halts, it gives a measured, explainable reason — never an opaque debugging exercise. Leadership cares because it makes promotion decisions *reviewable*
- The thresholds are tunable by Infra & Ops + SRE jointly, and any override is itself a confidence-event in the audit stream
**Key takeaway:** Safety is a measurable, explainable signal — not a gut feeling. A single critical finding blocks everything.
**Key takeaway:** Safety is a measurable, explainable signal — manually tuned, observable inputs, auditable breakdown. A single critical finding blocks everything.
---
## Slide 7 — Security by Construction
## Slide 8 — Security by Construction
**Talking points:**
- The phrase to land is "secure by default, not secure by effort" — teams don't opt in to security, it's on by construction
@@ -92,29 +108,17 @@
---
## Slide 8 — Accountability & Audit
## Slide 9 — Accountability & Audit
**Talking points:**
- The "lower environments autonomous, higher environments attested" tenet is the resolution to the classic "move fast vs. be safe" false dichotomy
- Be honest: the separation-of-duties *mechanism* is designed and the dev path is wired; the qa/prod/dr wiring is on the roadmap
- The new attestation flow diagram shows the human-in-the-loop path — dev autonomous → qa/prod/dr human attestation → evidence event. Walk it briefly
- Land the QA clarification: **QA attests to infrastructure readiness — the contract, the planned Terraform changes, and the accumulated evidence. QA does not review application code (that's upstream).** This is the scope-boundary point reiterated
- Badge reclassification to be clear about: separation of duties = **Planned** (not "design tested"); dev autonomous = **Testing**; qa/prod/dr attestation = **Planned**
- The audit trail is a byproduct of deployment, not a project — every deployment writes a hash-chained evidence event synchronously (RPO = 0)
- Be honest about the ledger: the outbox + hash chain is testing today; the full regulatory ledger (S3 Object Lock, JWS signatures, daily checkpoints) is planned
- Every production change is traceable to a human attestation — approver identities are the only durable record outside the VCS's audit log
**Key takeaway:** Dev is autonomous. Higher environments are attested. Every change is evidenced. The audit trail is a byproduct, not a project.
---
## Slide 9 — Testing vs. Planned
**Talking points:**
- Close on honesty — the platform delivers real, verifiable value today, and the roadmap is concrete, not aspirational hand-waving
- Walk the left column (Testing) quickly — 11 capabilities that work internally today, from contract-driven deploys to encryption by default to uptime monitoring
- Walk the right column (Planned) — be clear about what's not yet done: HITL wiring, full regulatory ledger, compliance milestone, environment self-service, dynamic module creation, additional engine adapters
- Invite questions on any "planned" item — each has a defined milestone and a clear reason it isn't shipped yet (usually an upstream dependency, not an engineering gap)
- Emphasize: 0 consumer adoption today — "Testing" means it works internally, not that it's released
**Key takeaway:** 11 capabilities testing today. 9 planned items on a concrete roadmap. Zero consumer adoption — yet.
**Key takeaway:** Dev is autonomous. Higher environments are attested. QA attests to infra readiness, not app code. Every change is evidenced.
---
@@ -129,3 +133,81 @@
- The path to the citizen developer — the same safety envelope that serves a senior engineer will serve a non-technical consumer. Expanding who can ship safely without lowering the bar
**Key takeaway:** The investment is in the abstraction, not the tool. Ship safely at the pace the business demands, with the security and audit posture the regulators require.
---
## Appendix TOC — Deep Dives
**Talking points:**
- These slides are for follow-up questions — don't walk them in the main 15-minute talk
- Pull them up when an audience member wants detail on a specific topic: environments, observability, roadmap, full inventory, or glossary terms
- The appendix exists so the main deck stays tight while still having answers ready
**Key takeaway:** The appendix is the backup — detail on demand, not on the critical path.
---
## A1 — Platform-Managed Environments
**Talking points:**
- A consumer provides no AWS account, no VPC, no subnet, no state backend, no runner key — the platform owns the entire blast radius
- A named environment is a platform-owned bundle: an AWS account (or scoped partition), a network, a state backend, and an IAM role surfaced via ABAC
- The consumer selects an environment by name (`environment: dev`) and the platform resolves it at run time — the consumer never sees raw credentials
- Friendly onboarding is testing today: the first run detects no environment and emits a guided prompt, not an opaque failure. Self-service provisioning is planned
- For the Head of Cloud: this is the governance story — the platform team owns accounts, network design, and state hygiene; consumers can't drift because they never touch them
**Key takeaway:** Environments are platform-owned bundles. Consumers pick a name; the platform owns the rest.
---
## A2 — Observability Built In
**Talking points:**
- Monitoring is a platform default, not a per-team project — you don't deploy a service and *then* remember to set up monitoring
- Uptime monitoring (Uptime-kuma on ECS Fargate) is provisioned automatically after any module deploy, in a separate state, with a feature flag to disable
- Monitored endpoints come from the deployment's own outputs — no manual endpoint registration. The platform constructs the synthetic monitoring contract from what was just deployed
- Alert channels: Microsoft Teams webhook, email, SMS, and GitHub issues — all testing today
- The uptime URL is published to the developer via a PR comment so they don't hunt for it
- Roadmap: deeper observability bootstrap (dashboards, runbooks, on-call bindings) as first-class contract fields for prod/dr — planned
**Key takeaway:** Monitoring ships with the deploy, not after it. The feature flag lets teams with existing monitoring opt out cleanly.
---
## A3 — The Road to the North Star
**Talking points:**
- Be explicit up front: this is **proposed phasing, not formally planned** — the phases are sequenced by dependency, not by calendar
- Phase 1 — Testing baseline (current): contract-driven deploys, zero-trust OIDC + ABAC, confidence signal, hash-chained evidence, encryption by default, safe decommission, uptime monitoring, platform-managed environments
- Phase 2 — Production readiness: HITL wiring for qa/prod/dr, all-runner OIDC, full regulatory ledger, environment self-service
- Phase 3 — Compliance & expansion: compliance milestone (GDPR, SOX, SOC2, DORA), additional engine adapters (OpenTofu, Pulumi, Kubernetes CRDs), deeper observability bootstrap
- Phase 4 — Agentic frontier: dynamic module creation from a contract (citizen-developer flow), pattern recognition that compounds value over time
- Each phase's items are gated on the prior phase's maturity — invite questions on any phase boundary
**Key takeaway:** A dependency-sequenced path from testing baseline to agentic frontier — proposed, not formally committed.
---
## A4 — Testing vs. Planned (Full Inventory)
**Talking points:**
- Close on honesty — the platform delivers real, verifiable value today, and the roadmap is concrete, not aspirational hand-waving
- Walk the Testing column (11 capabilities) quickly — from contract-driven deploys to encryption by default to uptime monitoring. These work internally and are dev pilot-ready
- Walk the Planned column (9 capabilities) — be clear about what's not yet done: HITL wiring, full regulatory ledger, compliance milestone, environment self-service, dynamic module creation, additional engine adapters, deeper observability
- Two agentic items are flagged: dynamic module creation and pattern recognition — both involve AI agents or autonomous decision-making
- Invite questions on any "planned" item — each has a defined milestone and a clear reason it isn't shipped yet (usually an upstream dependency, not an engineering gap)
- Emphasize: 0 consumer adoption today — "Testing" means it works internally and is dev pilot-ready, not that it's released
**Key takeaway:** 11 capabilities testing today. 9 planned items on a concrete roadmap. Zero consumer adoption — yet.
---
## A5 — Glossary
**Talking points:**
- This is a reference slide — don't read it aloud, point to it as a takeaway reference for term definitions
- The terms most likely to come up in questions: OIDC (short-lived tokens), ABAC (tag-scoped access), CMK (per-stack encryption keys), RPO = 0 (synchronous evidence write)
- HITL is the human-attestation term for qa/prod/dr; NFR is the non-functional-requirements input to the confidence signal
- IR (Intermediate Representation) is the engine-agnostic stack definition between the contract and Terraform — the abstraction that makes the platform portable
**Key takeaway:** A shared vocabulary — keep it as a reference for follow-up questions.
docs/presentations/how-the-platform-works.md
+142 -98
View File
@@ -2,54 +2,51 @@
> **Subtitle:** Agentic Cloud Delivery Platform
> **Audience:** Senior Leadership, CTO, Head of Cloud, Head of Infrastructure, Head of DevOps
> **Length:** ~15 minutes · 14 slides
> **Length:** ~15 minutes · 10 main + 6 appendix = 16 slides
> **Purpose:** Sell the platform's value to tech leadership — zero-trust, security, observability, auditability, and the shift from "operators guess" to "the platform computes safety."
> **Maturity framing:** "Testing" = shipped and verified. "Planned" = on the roadmap, not yet shipped.
> **Maturity framing:** "Testing" = works internally, dev pilot-ready. "Planned" = on the roadmap, not yet implemented. "Agentic" = involves AI agents or autonomous decision-making.
---
## Slide 1 — The Problem We Solve
## Slide 1 — Title
# How The Platform Works
### Agentic Cloud Delivery Platform
> **Speaker notes:** Brief introduction — this deck explains *how* the platform works internally, not what the developer experience is (that's the companion deck). Set the frame: the platform is not a CI/CD tool — it's the organizational lever for shipping safely at the pace the business demands.
---
## Slide 2 — The Problem & The North Star
Software delivery scales with the **coordination surface around it**, not the engineering inside it. Most teams can write code; far fewer get the infrastructure right.
Two frictions slow every team down:
Four frictions slow every team:
- **Cognitive load** — authoring the infrastructure that runs a service correctly. The long tail of well-meaning services that are difficult to deploy, inconsistent in security and observability posture.
- **Operational work** — promoting a change from "merged" to "running in production with policy, observability, and security enforced." Manual work that **scales with the system, not with the change.**
- **Red tape** — every deployment requires tickets, approvals, and manual handoffs that scale with the organization, not with the change. A merged change waits in a queue for someone to press a button.
- **Scalability without increasing headcount** — the platform allows delivery throughput to scale without linearly scaling platform engineers. Today, every new team adds load to the same ticket queue.
- **Cognitive load** — authoring infrastructure correctly; the long tail of services inconsistent in security and observability.
- **Operational work** — promoting a change from "merged" to "running in production." Manual work that **scales with the system, not the change.**
- **Red tape** — tickets, approvals, and handoffs that scale with the organization. A merged change waits in a queue.
- **Scalability without increasing headcount** — throughput scales without linearly scaling platform engineers.
> **Speaker notes:** Open with the cost of the status quo. Every team that stands up its own pipeline, its own Terraform, its own review checklist is paying a tax that doesn't differentiate the business. The platform absorbs all four frictions — that is the value proposition in one sentence.
> Consumers **declare intent**; the platform delivers **safe production deployment** — automatically, safely, with a complete audit trail.
---
## Slide 2 — The North Star
> Consumers **declare intent**; the platform delivers **safe production deployment** through an agentic stack — automatically, safely, and with a complete audit trail.
What success looks like:
- A merged change progresses through lower environments **end-to-end without a platform engineer joining a thread, approving a ticket, or manually triggering a stage.**
- A **non-technical consumer** ships a production deployment by declaring intent — without authoring a workflow, a configuration file, or an infrastructure module.
- A merged change progresses **without a platform engineer joining a thread or approving a ticket.**
- A **non-technical consumer** ships by declaring intent — no workflow, no config file, no infrastructure module.
- Every production change is **traceable to a human attestation and an immutable evidence stream.**
> **Speaker notes:** This is the litmus test. If a platform engineer still has to touch a ticket for a dev→qa promotion, we haven't delivered the vision. The two consumer surfaces (technical developer + citizen developer) are covered in the companion deck. Here we focus on *how* the platform makes the North Star real.
> **Speaker notes:** Open with the cost of the status quo. Every team that stands up its own pipeline, its own Terraform, its own review checklist is paying a tax that doesn't differentiate the business. The platform absorbs all four frictions — that is the value proposition in one sentence. Land the North Star quote: "declare intent → safe production deployment." The litmus test: if a platform engineer still has to touch a ticket for a dev→qa promotion, we haven't delivered the vision.
---
## Slide 3 — What This Platform Is — and Isn't
## Slide 3 — Where ACDL Sits in Your World
**What it is:**
Now that we know the problem, here's where ACDL fits — and where it doesn't.
- **A sovereign delivery boundary.** The platform governs infrastructure and delivery. It does not penetrate upstream product or software development lifecycles. Integration happens through validated, published contracts.
- **Infrastructure consumed, not maintained.** Compute is abstract, containerized, or serverless. The platform does not manage node, OS, or bare-metal lifecycles. Infrastructure is a utility, not a craft.
**What it isn't:**
- **Not an upstream development platform.** No product backlogs, sprint ceremonies, or IDE workflows.
- **Not a general-purpose AI.** Autonomy is narrow, scoped to delivery and infrastructure reconciliation, bounded by strict policy envelopes.
- **Not a legacy infrastructure bridge.** No VMs, bare metal, or OS lifecycles.
- **Not a permissive delivery highway.** No escape hatches to bypass the confidence framework or human attestation requirements.
- **Upstream is anything** — your IDE, an agentic SDLC, or a citizen developer vibe coding on a laptop. ACDL doesn't care how the contract was produced.
- **ACDL is infrastructure only** — it provisions and governs AWS resources. It does not build, test, or deploy your application code. That's upstream.
- **Not a general-purpose AI** — autonomy is narrow, scoped to delivery, bounded by strict policy envelopes.
- **Not a permissive delivery highway** — no escape hatches to bypass the confidence framework or human attestation requirements.
> **Speaker notes:** This slide gives leadership the framing they need. The platform is deliberately scoped — it is not trying to be everything. The sovereign boundary means the platform team owns delivery and infrastructure, not the upstream development process. The anti-goals are as important as the goals: they tell leadership what not to expect.
@@ -57,7 +54,9 @@ What success looks like:
## Slide 4 — The Contract-Driven Model
One small YAML file is all a consumer writes. The platform owns everything else.
The contract is the boundary between upstream and ACDL. It's all a consumer writes.
A single YAML contract — **module, environment, inputs**. The platform owns everything else.
```mermaid
flowchart LR
@@ -69,15 +68,18 @@ The contract names three things:
- **Which module** — a catalog of pre-built, security-reviewed building blocks (a static site, a microservice, a database, and more).
- **Which environment** — `dev`, `qa`, `prod`, or `dr`. The platform raises the safety bar automatically as the environment gets more sensitive.
- **Which inputs** — the handful of values that vary per deployment (a bucket name, a container image, a port).
- **Which inputs** — infrastructure values that vary per deployment (cpu, memory, port, desired_count).
- The consumer provides **no AWS account, no VPC, no state backend** — the platform owns the blast radius.
The consumer does **not** write infrastructure modules, workflow logic, or adapter code. They declare intent; the platform reconciles, provisions, and progresses.
> **Speaker notes:** Emphasize the asymmetry. The consumer's surface is intentionally tiny — a contract that fits on one screen. The platform's surface is large and opinionated. That asymmetry is what makes "declare intent, not execute operations" concrete.
> **Speaker notes:** Emphasize the asymmetry. The consumer's surface is intentionally tiny — a contract that fits on one screen. The platform's surface is large and opinionated. That asymmetry is what makes "declare intent, not execute operations" concrete. Note that the contract examples now show infrastructure inputs (cpu, memory, desired_count, port) — not a container image. The image is upstream; the platform governs infrastructure.
---
## Slide 4 — The End-to-End Flow
## Slide 5 — The End-to-End Flow
Once the contract is written, here's what the platform does with it — every time.
Every deployment runs the same stages, in the same order, with the same checks — no team-specific pipelines, no tribal runbooks.
@@ -98,16 +100,18 @@ Two properties matter to leadership:
- **Security and policy checks run *before* any infrastructure is created** — not after the fact, not as a post-deployment audit.
- **Every stage produces a record** that feeds the confidence signal and the evidence stream. There is no "unchecked" path.
> **Speaker notes:** Walk left to right once. Don't dwell on internals — the point is that the flow is fixed, opinionated, and identical for every consumer. The two leadership-relevant beats are (1) checks before creation, (2) every stage is evidenced. The confidence signal (Slide 6) is where the "safety is computed" story lands.
> **Speaker notes:** Walk left to right once. Don't dwell on internals — the point is that the flow is fixed, opinionated, and identical for every consumer. The two leadership-relevant beats are (1) checks before creation, (2) every stage is evidenced. The confidence signal (Slide 7) is where the "safety is computed" story lands.
---
## Slide 5 — Zero-Trust by Default
## Slide 6 — Zero-Trust by Default
Before any infrastructure is created, here's how access is scoped.
Consumer repositories hold **no long-lived cloud credentials.** Ever.
- **Authentication** is **OIDC federation** between the platform runners and the cloud provider. Each job mints a short-lived token; no credential is stored in the consumer repo or in a runner secret. *(Testing on GitHub Actions runners; planned for all platform runners.)*
- **Authorization** is **attribute-based (ABAC), not role-based.** Two attribute classes scope every action:
- **Authentication is OIDC federation** between the platform runners and the cloud provider. Each job mints a short-lived token; no credential is stored in the consumer repo or in a runner secret. *(Testing on GitHub Actions runners; planned for all platform runners.)*
- **Authorization is attribute-based (ABAC), not role-based.** Two attribute classes scope every action:
- **Repository identity** — the role's trust policy binds to the exact consumer repo + branch that invoked the workflow.
- **Resource-creation attributes** — every resource is tagged with `acdl:owner=<consumer-repo>` and `acdl:contract=<contract-id>`. The session policy grants view/update/delete **only on resources whose tags match the calling repo.**
@@ -117,96 +121,101 @@ Consumer repositories hold **no long-lived cloud credentials.** Ever.
---
## Slide 6 — Safety is Computed, Not Assumed
## Slide 7 — Safety is Computed, Not Assumed
Every delivery action produces a **measurable, explainable confidence signal** — the platform's certified answer to "is this safe to proceed?"
Now let's look at how the platform decides whether a deployment is safe.
- **Six weighted inputs:** policy conformance, validation, freshness, source provenance, history, and non-functional requirements (NFRs).
Every delivery action produces a **measurable, explainable confidence signal** — a weighted sum of observable facts, not a black box. *(Agentic.)*
- **Six weighted inputs** — policy conformance, validation, freshness, source provenance, history, and non-functional requirements (NFRs). The weights are **manually tuned**, the inputs are **observable**, and the breakdown is **auditable** — if a consumer asks "why 0.62?", the platform answers with a per-input breakdown.
- **Per-environment thresholds** that rise with sensitivity:
| Environment | Threshold | Who must attest |
|---|---|---|
| dev | ≥ 0.50 | No one — fully autonomous |
| qa | ≥ 0.75 | QA |
| prod | ≥ 0.90 | SRE |
| dr | ≥ 0.95 | SRE + a disaster-recovery drill reference |
| dev | ≥ 0.50 | No one — fully autonomous *(Testing)* |
| qa | ≥ 0.75 | QA *(Planned)* |
| prod | ≥ 0.90 | SRE *(Planned)* |
| dr | ≥ 0.95 | SRE + a disaster-recovery drill reference *(Planned)* |
- **A single critical policy finding hard-blocks the deployment**, regardless of every other input. Critical findings are not averaged away.
- **When the platform halts, it gives a measured reason** — a policy violation, an insufficient signal, a missing attestation — never an opaque, manual-debugging exercise.
> **Speaker notes:** This is the bet that separates this platform from "yet another CI/CD tool." Reliance on operator instinct or tenure is not a substitute. The signal is auditable; the thresholds are tunable by Infra & Ops + SRE jointly, and any override is itself a confidence-event in the audit stream. Leadership cares about this because it makes promotion decisions *reviewable*.
> **Speaker notes:** This is the bet that separates this platform from "yet another CI/CD tool." Reliance on operator instinct or tenure is not a substitute. The signal is auditable; the thresholds are tunable by Infra & Ops + SRE jointly, and any override is itself a confidence-event in the audit stream. Leadership cares about this because it makes promotion decisions *reviewable*. The new confidence signal diagram makes the six inputs and the per-input breakdown visible — emphasize that the weights are manually tuned and the breakdown is auditable, not a black box.
---
## Slide 7 — Policy & Security Enforcement
## Slide 8 — Security by Construction
Checks run on **every** deployment, normalized to a single schema regardless of which engine produced them.
Beyond the confidence signal, security defaults are on by construction — not by opt-in.
- **Infrastructure-as-code policy** (Checkov) — secrets in plaintext, public ingress, IAM wildcards, KMS key references, **required tagging standards** (`acdl:owner`, `acdl:contract`, `acdl:environment`, `acdl:cost-center`).
- **Cloud security posture** (Wiz adapter) — translates cloud security findings into the same normalized record. *(Adapter available today; activates when a Wiz tenant is configured.)*
- **Kubernetes-native policy** (Kyverno adapter) — ready for the GitOps reconciler roadmap item. *(Adapter available today; inactive for Terraform-only stacks.)*
Every check produces a record with **severity, rule ID, pass/fail status, and human-readable message** — consumed uniformly by the confidence signal. No engine-specific escapes.
> **Speaker notes:** The selling point is *normalization*. We can add a new security tool without changing the confidence model or the evidence stream. For the Head of Security: tagging standards are enforced, not advisory — a missing `acdl:owner` tag fails the check, not a warning.
---
## Slide 8 — Secure by Default
Security defaults that **do not require a team to opt in.**
Security defaults that **do not require a team to opt in.** Checks run on **every** deployment, normalized to a single schema regardless of which engine produced them. *(Testing.)*
- **Infrastructure-as-code policy** (Checkov) — secrets in plaintext, public ingress, IAM wildcards, KMS key references, **required tagging standards** (`acdl:owner`, `acdl:contract`, `acdl:environment`, `acdl:cost-center`). All run *before* infra is created.
- **Cloud security posture** (Wiz adapter) — translates cloud security findings into the same normalized record. *(Adapter testing; activates when a Wiz tenant is configured.)*
- **Kubernetes-native policy** (Kyverno adapter) — ready for the GitOps reconciler roadmap item. *(Adapter testing; inactive for Terraform-only stacks.)*
- **Encryption on every resource** — at-rest encryption is on by default for every primitive (S3, RDS, ECR, ECS, and more). *(Testing.)*
- **Per-stack customer-managed keys (CMKs)** — one key per deployment, 90-day rotation at creation, **no shared keys across stacks.** *(Testing.)*
- **Managed-key fallback with a loud warning** — standalone primitives fall back to cloud-managed keys only when no CMK is provided, and the platform warns explicitly. Silent use of cloud-managed keys is a security gap we refuse to hide. *(Testing.)*
- **Managed-key fallback with a loud warning** — standalone primitives fall back to cloud-managed keys only when no CMK is provided, and the platform warns explicitly. *(Testing.)*
- **Deletion protection on by default** — every resource has `prevent_destroy` on unless a consumer explicitly disables it via a documented feature flag. *(Testing.)*
- **Safe decommission** — a 2-step pipeline (disable protection → zero counts → destroy) with **two SRE human-attestation gates** and a **change-request validated against the platform CMDB** before any destructive action. *(Testing.)* Encryption keys enter a grace window (default 30 days) so encrypted data remains recoverable during decommission.
> **Speaker notes:** The phrase to land is "secure by default, not secure by effort." The decommission flow is the counter-argument to "deletion protection makes cleanup impossible" — it's a deliberate, gated, two-approval path, not a lock with no key.
> **Speaker notes:** The phrase to land is "secure by default, not secure by effort." The selling point is *normalization* — we can add a new security tool without changing the confidence model or the evidence stream. For the Head of Security: tagging standards are enforced, not advisory — a missing `acdl:owner` tag fails the check, not a warning. The decommission flow is the counter-argument to "deletion protection makes cleanup impossible" — it's a deliberate, gated, two-approval path, not a lock with no key.
---
## Slide 9 — Immutable Audit & Evidence
## Slide 9 — Accountability & Audit
Computed safety handles the gate. But humans still matter — here's how accountability works.
- **Dev is fully autonomous.** The confidence signal (≥ 0.50) is the only gate. Queue-based handoffs are eliminated from lower environments. *(Testing, Agentic.)*
- **qa, prod, and dr require deliberate human attestation** — not rubber stamps, but policy-mandated acts of accountability via protected deployment approvals. The approver reviews the contract, the planned Terraform changes, and the accumulated evidence. *(Planned.)*
- **QA attests to infrastructure readiness — the contract, the planned Terraform changes, and the accumulated evidence. QA does not review application code (that's upstream).**
- **Separation of duties is enforced** *(Planned)* — the person who approved the qa promotion **cannot** be the person who approves the prod promotion. The platform reads both identities from the outbox and **blocks** on a match, emitting a `SEPARATION_OF_DUTIES_VIOLATION` and routing a halt artifact to SRE on-call.
- **Timeout discipline** — 1 business day = warn + escalate; 2 business days = auto-freeze + re-submit. Rejection extends the audit chain; it does not tear it up.
Version control is a **coordination tool, not an evidentiary fortress.** True compliance requires an immutable, externally-stored ledger.
- **Every deployment writes a hash-chained evidence event** — each event links to the previous via a cryptographic hash. Tampering breaks the chain. *(Testing. the DynamoDB outbox.)*
- **Every deployment writes a hash-chained evidence event** — each event links to the previous via a cryptographic hash. Tampering breaks the chain. *(Testing — the DynamoDB outbox.)*
- **Tiered storage design:** cold, tamper-proof source of truth (S3 Object Lock, compliance mode, 7-year retention) + a hot query index for fast lookup. *(Outbox tested; S3 Object Lock + JWS detached signatures are planned regulatory-ledger build-out.)*
- **RPO = 0** — the evidence write is synchronous; a deployment is not acknowledged until the evidence event is durably recorded.
- **Every production change is traceable to a human attestation** — the QA and prod approver identities are the only durable record outside the VCS's audit log, stored in the outbox keyed by contract.
> **Speaker notes:** This is the slide for the Head of Infrastructure and anyone who has been through an audit. "The audit trail is a byproduct of deployment, not a project." Note honestly that the full regulatory ledger (S3 Object Lock, JWS signatures, daily checkpoints) is planned; what ships today is the outbox + hash chain that makes every event tamper-evident and queryable.
> **Speaker notes:** The "lower environments autonomous, higher environments attested" tenet is the resolution to the classic "move fast vs. be safe" false dichotomy. Be honest: the separation-of-duties *mechanism* (CODEOWNERS routing, identity-distinctness check, the 8-concern attestation matrix) is designed and the dev path is wired; the qa/prod/dr wiring is on the roadmap. The new attestation flow diagram makes the human-in-the-loop path visible. Note the QA clarification: QA attests to infrastructure readiness — the contract, the plan, and the evidence — not application code. The audit trail is a byproduct of deployment, not a project. Note honestly that the full regulatory ledger (S3 Object Lock, JWS signatures, daily checkpoints) is planned; what ships today is the outbox + hash chain that makes every event tamper-evident and queryable. Badge reclassification: separation of duties = Planned (not "design tested"), dev autonomous = Testing, qa/prod/dr attestation = Planned.
---
## Slide 10 — Human-in-the-Loop Where It Matters
## Slide 10 — The Vision Realized
Autonomy and accountability are **not in tension** — they are applied at different environments.
Here's what success looks like when the North Star is reached.
- **Dev is fully autonomous.** No human gate. The confidence signal (≥ 0.50) is the only gate. Queue-based handoffs are eliminated from lower environments.
- **qa, prod, and dr require deliberate human attestation** — not rubber stamps, but policy-mandated acts of accountability via protected deployment approvals.
- **Separation of duties is enforced** *(design shipped; wiring for qa/prod/dr is planned)* — the person who approved the qa promotion **cannot** be the person who approves the prod promotion. The platform reads both identities from the outbox and **blocks** on a match, emitting a `SEPARATION_OF_DUTIES_VIOLATION` and routing a halt artifact to SRE on-call.
- **Timeout discipline** — 1 business day = warn + escalate; 2 business days = auto-freeze + re-submit. Rejection extends the audit chain; it does not tear it up.
- **Velocity without sacrificing safety.** Speed is in the ergonomics (a simple contract, a one-line `uses:`); safety is in the gates the consumer cannot bypass.
- **Security, observability, and compliance as platform defaults** — not per-team effort, not post-hoc remediation.
- **Auditability as a byproduct, not a project.** Every production change is traceable to a human attestation and a tamper-evident evidence event.
- **Blast radius contained by design.** Zero-trust OIDC + ABAC means a consumer can only touch its own tagged resources.
- **Infrastructure as a utility, not a craft.** Teams consume infrastructure, they don't maintain it.
- **A path to the citizen developer.** The same safety envelope that serves a senior engineer will serve a non-technical consumer. *(Agentic.)*
> **Speaker notes:** The "Lower environments autonomous, higher environments attested" tenet is the resolution to the classic "move fast vs. be safe" false dichotomy. Be honest: the *mechanism* (CODEOWNERS routing, identity-distinctness check, the 8-concern attestation matrix) is designed and the dev path is wired; the qa/prod/dr wiring is on the roadmap.
> **Speaker notes:** Close on the strategic frame. The platform is not "a CI/CD tool," it's the organizational lever for shipping safely at the pace the business demands. The investment is in the abstraction, not the tool. Ship safely at the pace the business demands, with the security and audit posture the regulators require.
---
## Slide 11 — Observability Built In
## Appendix — Table of Contents
Monitoring is **a platform default, not a per-team project.**
For deep dives — these slides cover details omitted from the main 10.
- **Uptime monitoring deployed automatically with every stack** — a dedicated monitoring instance (Uptime-kuma on ECS Fargate) is provisioned after any module deploy, in a separate state, with a feature flag to disable. *(Testing.)*
- **Monitored endpoints passed from the deployment's own outputs** — the platform constructs a synthetic monitoring contract from what was just deployed. No manual endpoint registration.
- **Alert channels:** Microsoft Teams webhook, email, SMS, and GitHub issues. *(Testing.)*
- **The uptime URL is published to the developer** via a PR comment — they don't hunt for it.
- **Roadmap:** deeper observability bootstrap (dashboards, runbooks, on-call bindings) as first-class contract fields for prod/dr.
**Contents:**
> **Speaker notes:** The Head of DevOps cares about this. The framing: "you don't deploy a service and *then* remember to set up monitoring — the platform does it as part of the deploy." The feature flag means teams with existing monitoring (e.g. Datadog) can opt out cleanly.
1. Platform-Managed Environments (detail)
2. Observability Built In (detail)
3. The Road to the North Star (phased roadmap)
4. Testing vs. Planned (full inventory)
5. Glossary
> **Speaker notes:** These are deep-dive slides for follow-up questions. Don't walk them in the main 15-minute talk — pull them up when an audience member wants detail on a specific topic.
---
## Slide 12 — Platform-Managed Environments
## A1 — Platform-Managed Environments
A consumer provides **no AWS account, no VPC, no subnet, no state backend, no runner key.** The platform owns the blast radius.
@@ -225,44 +234,79 @@ The consumer selects an environment **by name** in their contract (`environment:
---
## Slide 13 — Portability & Future-Proofing
## A2 — Observability Built In
The platform is **opinionated, but not painted into a corner.**
Monitoring is **a platform default, not a per-team project.** *(Testing.)*
- **Angine-agnostic core.** The contract, the resolved stack, the policy results, the confidence signal, and the evidence stream are all defined *without reference to any specific infrastructure tool.* Today there is one adapter (Terraform). *(OpenTofu, Pulumi, Kubernetes CRDs are future adapters — no architectural change required.)*
- **Forge-agnostic contract ingestion.** The platform Lambda reads a configurable API base for GitHub or Gitea. *(Testing.)*
- **Portable contracts.** The contract schema, the confidence signal, and the audit stream are engine- and VCS-agnostic. A second VCS (e.g. GitLab) needs a VCS adapter + a workflow-template translator — **no change to the modules, the contract standard, the confidence model, or the audit stream.**
- **Pattern recognition compounds value over time.** As the platform observes recurring contract patterns, it can synthesize and offer reusable modules. *(Future capability, not a current commitment — but the design allows it.)*
- **Uptime monitoring deployed automatically with every stack** — a dedicated monitoring instance (Uptime-kuma on ECS Fargate) is provisioned after any module deploy, in a separate state, with a feature flag to disable.
- **Monitored endpoints passed from the deployment's own outputs** — the platform constructs a synthetic monitoring contract from what was just deployed. No manual endpoint registration.
- **Alert channels:** Microsoft Teams webhook, email, SMS, and GitHub issues. *(Testing.)*
- **The uptime URL is published to the developer** via a PR comment — they don't hunt for it.
- **Roadmap:** deeper observability bootstrap (dashboards, runbooks, on-call bindings) as first-class contract fields for prod/dr. *(Planned.)*
> **Speaker notes:** This is the "we won't have to rewrite this in two years" slide. The bet is that the engine (Terraform today) will change, but the contract + confidence + audit model won't. Leadership should hear: the investment is in the abstraction, not the tool.
> **Speaker notes:** The Head of DevOps cares about this. The framing: "you don't deploy a service and *then* remember to set up monitoring — the platform does it as part of the deploy." The feature flag means teams with existing monitoring (e.g. Datadog) can opt out cleanly.
---
## Slide 14 — Roadmap: Honest Testing vs. Planned
## A3 — The Road to the North Star
**Testing:**
*Proposed phasing — not formally planned.*
A phased roadmap from the current Testing baseline to the full North Star:
- **Phase 1 — Testing baseline (current):** contract-driven deploys, zero-trust OIDC + ABAC on GitHub Actions, confidence signal gating, hash-chained evidence, encryption by default, deletion protection + safe decommission, uptime monitoring, platform-managed environments.
- **Phase 2 — Production readiness:** HITL wiring for qa/prod/dr, all-runner OIDC, full regulatory ledger (S3 Object Lock + JWS signatures + daily checkpoints), environment self-service.
- **Phase 3 — Compliance & expansion:** compliance milestone (GDPR, SOX, SOC2, DORA extension points), additional engine adapters (OpenTofu, Pulumi, Kubernetes CRDs), deeper observability bootstrap.
- **Phase 4 — Agentic frontier:** dynamic module creation from a contract (the agentic citizen-developer composition mechanism), pattern recognition that compounds value over time.
> **Speaker notes:** Be clear with leadership: this is a proposed phasing, not a formally committed plan. The phases are sequenced by dependency, not by calendar — each phase's items are gated on the prior phase's maturity. Invite questions on any phase boundary.
---
## A4 — Testing vs. Planned (Full Inventory)
**Testing** (works internally, dev pilot-ready) — 11 capabilities:
- Contract-driven deploys with a versioned reusable workflow.
- Module catalog (primitives + modules) with validated examples.
- Zero-trust OIDC + ABAC on GitHub Actions runners.
- Security + policy checks before infra creation (Checkov; Wiz + Kyverno adapters ready).
- Confidence signal (6 inputs, per-env thresholds) gating promotion.
- Confidence signal (6 inputs, per-env thresholds) gating promotion. *(Agentic.)*
- Hash-chained, tamper-evident evidence outbox (RPO = 0).
- Encryption by default + per-stack customer-managed keys.
- Deletion protection by default + safe decommission with SRE gates + CMDB validation.
- Uptime monitoring deployed automatically with every stack.
- Platform-managed environments + friendly onboarding.
- Local reproducibility (`run_ci.sh` mirrors the CI pipeline).
- Forge-agnostic contract ingestion (GitHub + Gitea).
- Engine-agnostic core (1 adapter: Terraform) + VCS-agnostic ingestion (GitHub + Gitea).
**Planned (on the roadmap, not yet shipped):**
**Planned** (on the roadmap, not yet implemented) — 9 capabilities:
- Real OIDC federation on all platform runners (Gitea Actions OIDC pending an upstream merge).
- HITL wiring for qa / prod / dr environments (design shipped; wiring is next).
- Full regulatory ledger: S3 Object Lock (7-yr compliance mode) + JWS detached signatures + daily checkpoints.
- Compliance milestone: per-module extension points for GDPR, SOX, SOC2, DORA.
- Environment self-service (a consumer-facing flow to request and provision a new environment).
- Dynamic module creation from a contract (the agentic "citizen developer" composition mechanism).
- Dynamic module creation from a contract (the agentic "citizen developer" composition mechanism). *(Agentic.)*
- Pattern recognition compounds value over time. *(Agentic.)*
- Additional engine adapters (OpenTofu, Pulumi, Kubernetes CRDs).
- Deeper observability bootstrap (dashboards, runbooks, on-call bindings).
> **Speaker notes:** Close on honesty. The platform delivers real, verifiable value today — and the roadmap is concrete, not aspirational hand-waving. Invite questions on any "planned" item; each has a defined milestone and a clear reason it isn't shipped yet (usually an upstream dependency, not an engineering gap).
> **Speaker notes:** Close on honesty. The platform delivers real, verifiable value today — 11 capabilities that work internally. The roadmap is concrete, not aspirational hand-waving — 9 planned items, each with a defined milestone and a clear reason it isn't shipped yet (usually an upstream dependency, not an engineering gap). Emphasize: 0 consumer adoption today — "Testing" means it works internally and is dev pilot-ready, not that it's released.
---
## A5 — Glossary
| Term | Meaning |
|---|---|
| **OIDC** | OpenID Connect — federation protocol for short-lived tokens, no long-lived credentials |
| **ABAC** | Attribute-Based Access Control — access scoped by resource tags + repo identity, not roles |
| **CMK** | Customer-Managed Key — per-stack encryption key, 90-day rotation, no shared keys |
| **CMDB** | Configuration Management Database — validates change requests for decommission |
| **RPO** | Recovery Point Objective — RPO = 0 means evidence is written synchronously, no data loss |
| **HITL** | Human-in-the-Loop — deliberate human attestation required for qa/prod/dr environments |
| **VCS** | Version Control System — the git hosting platform (GitHub, Gitea, GitLab) |
| **NFR** | Non-Functional Requirement — encryption, tagging, observability standards |
| **IR** | Intermediate Representation — the engine-agnostic stack definition between contract and Terraform |
> **Speaker notes:** Use this slide as a reference when the audience asks for term definitions. Don't read it aloud — point to it as a takeaway reference.