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

Agentic Cloud Delivery Platform — How The Platform Works

+
Internal
+
+
+
Agentic Cloud Delivery Platform — How The Platform Works
+

The Problem We Solve

+

Software delivery scales with the coordination surface around it, not the engineering inside it.

+

Two frictions slow every team:

+
    +
  • Cognitive load — authoring the infrastructure that runs a service correctly. The long tail of services that are difficult to deploy, inconsistent in security and observability posture.
    • +
  • Operational work — moving a merged change from "merged" to "running in production with policy, observability, and security enforced." Manual work that scales with the system, not with the change.
    • +
+

The platform absorbs both frictions.

+
Internal
+
+
+
Agentic Cloud Delivery Platform — How The Platform Works
+

The North Star

+
+

Consumers declare intent; the platform delivers safe production deployment — automatically, safely, and with a complete audit trail.

+
+

Success looks like:

+
    +
  • A merged change progresses through lower environments without a platform engineer joining a thread, approving a ticket, or 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.
    • +
  • Every production change is traceable to a human attestation and an immutable evidence stream.
    • +
+
Internal
+
+
+
Agentic Cloud Delivery Platform — How The Platform Works
+

The Contract-Driven Model

+

One small YAML file is all a consumer writes. The platform owns everything else.

+

+

The contract names three things:

+
    +
  • Which module — a catalog of pre-built, security-reviewed building blocks
    • +
  • Which environment — the platform raises the safety bar automatically as sensitivity rises
    • +
  • Which inputs — the handful of values that vary per deployment
    • +
+
Internal
+
+
+
Agentic Cloud Delivery Platform — How The Platform Works
+

The End-to-End Flow

+

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

+

+
    +
  • Security and policy checks run before any infrastructure is created
    • +
  • Every stage produces a record that feeds the confidence signal and the evidence stream — there is no "unchecked" path
    • +
+
Internal
+
+
+
Agentic Cloud Delivery Platform — How The Platform Works
+

Zero-Trust by Default

+

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

+
    +
  • Authentication — OIDC federation. Each job mints a short-lived token; no credential is stored in the consumer repo or in a runner secret. Available today (GitHub Actions) Planned: all runners
    • +
  • Authorization — 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
      • +
    • Resource tags — every resource is tagged acdl:owner + acdl:contract; the session policy grants access only to matching tags
      • +
    +
    • +
+

The effect: a consumer can only touch the resources it created. Blast radius is contained. One consumer can never affect another.

+
Internal
+
+
+
Agentic Cloud Delivery Platform — How The Platform Works
+

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?"

+
    +
  • Six weighted inputs: policy conformance, validation, freshness, source provenance, history, NFRs
    • +
  • Per-environment thresholds that rise with sensitivity:
    • +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
EnvironmentThresholdAttester
dev≥ 0.50No one — autonomous
qa≥ 0.75QA
prod≥ 0.90SRE
dr≥ 0.95SRE + DR drill
+
    +
  • A single critical finding hard-blocks the deployment — critical findings are not averaged away
    • +
  • When the platform halts, it gives a measured reason — never an opaque debugging exercise
    • +
+
Internal
+
+
+
Agentic Cloud Delivery Platform — How The Platform Works
+

Policy & Security Enforcement

+

Checks run on every deployment, normalized to a single schema regardless of which engine produced them.

+
    +
  • Infrastructure policy (Checkov) — secrets in plaintext, public ingress, IAM wildcards, KMS references, required tagging standards (acdl:owner, acdl:contract, acdl:environment, acdl:cost-center) Available today
    • +
  • Cloud security posture (Wiz adapter) — translates cloud security findings into the same normalized record Adapter ready
    • +
  • Kubernetes-native policy (Kyverno adapter) — ready for the GitOps reconciler Adapter ready
    • +
+

Every check produces a record with severity, rule ID, pass/fail status, and a human-readable message — consumed uniformly by the confidence signal.

+
Internal
+
+
+
Agentic Cloud Delivery Platform — How The Platform Works
+

Secure by Default

+

Security defaults that do not require a team to opt in. Available today

+
    +
  • Encryption on every resource — at-rest encryption on by default for every primitive (S3, RDS, ECR, ECS, and more)
    • +
  • Per-stack customer-managed keys — one key per deployment, 90-day rotation, no shared keys across stacks
    • +
  • Managed-key fallback with a loud warning — silent use of cloud-managed keys is a security gap we refuse to hide
    • +
  • Deletion protection on by default — prevent_destroy on unless a consumer explicitly disables it via a documented flag
    • +
  • Safe decommission — a 2-step pipeline (disable protection → zero counts → destroy) with two SRE attestation gates and a change-request validated against the CMDB
    • +
+
Internal
+
+
+
Agentic Cloud Delivery Platform — How The Platform Works
+

Immutable Audit & Evidence

+

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 Available today
    • +
  • Tiered storage: cold, tamper-proof source of truth (S3 Object Lock, 7-year retention) + a hot query index Outbox shipped Full ledger: planned
    • +
  • 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 — approver identities are the only durable record outside the forge's audit log
    • +
+
Internal
+
+
+
Agentic Cloud Delivery Platform — How The Platform Works
+

Human-in-the-Loop Where It Matters

+

Autonomy and accountability are not in tension — they apply at different environments.

+
    +
  • Dev is fully autonomous. 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 — the QA approver cannot be the prod approver. The platform reads both identities from the outbox and blocks on a match. Design shipped Wiring: planned
    • +
  • Timeout discipline — 1 business day = warn + escalate; 2 business days = auto-freeze + re-submit
    • +
+
Internal
+
+
+
Agentic Cloud Delivery Platform — How The Platform Works
+

Observability Built In

+

Monitoring is a platform default, not a per-team project. Available today

+
    +
  • Uptime monitoring deployed automatically with every stack — a dedicated monitoring instance is provisioned after any module deploy, in a separate state, with a feature flag to disable
    • +
  • Monitored endpoints passed from the deployment's own outputs — no manual endpoint registration
    • +
  • Alert channels: Microsoft Teams webhook, email, SMS, and GitHub issues
    • +
  • The uptime URL is published to the developer via a PR comment — they don't hunt for it
    • +
  • Roadmap: deeper observability bootstrap (dashboards, runbooks, on-call bindings) as first-class contract fields
    • +
+
Internal
+
+
+
Agentic Cloud Delivery Platform — How The Platform Works
+

Platform-Managed Environments

+

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

+

A named environment is a platform-owned bundle of:

+
    +
  • An AWS account (or a scoped partition of one)
    • +
  • A network (VPC + subnets)
    • +
  • A state backend (S3 + DynamoDB for state + locking)
    • +
  • An IAM role surfaced via ABAC, scoped to the consumer's identity and resource tags
    • +
+

The consumer selects an environment by name in their contract. The platform resolves the name to the underlying resources at run time. The consumer never sees raw credentials.

+

Friendly onboarding: the first run detects no environment and emits a guided prompt (not an opaque failure). Available today Self-service: planned

+
Internal
+
+
+
Agentic Cloud Delivery Platform — How The Platform Works
+

Portability & Future-Proofing

+

The platform is opinionated, but not painted into a corner.

+
    +
  • Substrate-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. 1 adapter: Terraform OpenTofu / Pulumi / K8s
    • +
  • Forge-agnostic contract ingestion. The platform Lambda reads a configurable API base for GitHub or Gitea. Available today
    • +
  • Portable contracts. A second forge needs a forge adapter + a workflow translator — no change to modules, contracts, confidence, or audit
    • +
  • Pattern recognition compounds value over time. As the platform observes recurring patterns, it can synthesize reusable modules. Future capability
    • +
+
Internal
+
+
+
Agentic Cloud Delivery Platform — How The Platform Works
+ +

Roadmap: Shipped vs. Planned

+ +

Available today

+
    +
  • 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 ready)
    • +
  • 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
    • +
  • Uptime monitoring deployed automatically with every stack
    • +
  • Platform-managed environments + friendly onboarding
    • +
  • Local reproducibility + forge-agnostic contract ingestion
    • +
+

Planned (on the roadmap)

+
    +
  • 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
    • +
  • Environment self-service provisioning
    • +
  • Dynamic module creation from a contract (agentic citizen-developer flow)
    • +
  • Additional substrate adapters (OpenTofu, Pulumi, Kubernetes CRDs)
    • +
+
Internal
+
+
\ No newline at end of file diff --git a/docs/presentations/the-developer-experience.html b/docs/presentations/the-developer-experience.html new file mode 100644 index 0000000..ae687ca --- /dev/null +++ b/docs/presentations/the-developer-experience.html @@ -0,0 +1,949 @@ +Agentic Cloud Delivery Platform — The Developer Experience
+
Agentic Cloud Delivery Platform — The Developer Experience
+ +

Agentic Cloud Delivery Platform — The Developer Experience

+
Internal
+
+
+
Agentic Cloud Delivery Platform — The Developer Experience
+

Two Consumer Surfaces, One Platform

+

The platform serves two kinds of consumer through two coordinated interfaces — both converge on the same contract, the same policy envelope, and the same evidence stream.

+

+
    +
  • 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
    • +
+

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

+
Internal
+
+
+
Agentic Cloud Delivery Platform — The Developer Experience
+

What a Developer Actually Does

+

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

+

+

The developer does not:

+
    +
  • Write infrastructure modules
    • +
  • Author workflow YAML beyond the one-line uses: wrapper
    • +
  • Clone the platform repo
    • +
  • Hold cloud credentials
    • +
  • Maintain a state backend, a VPC, or a runner
    • +
+
Internal
+
+
+
Agentic Cloud Delivery Platform — The Developer Experience
+

The Citizen Developer Experience

+

A non-technical consumer ships a production deployment by declaring intent — without authoring a workflow, a configuration file, or an infrastructure module.

+
    +
  • The consumer opens an issue describing what they need (e.g. "a web API for the pricing service")
    • +
  • An agent maps the intent to a contract referencing a module from the reviewed skill catalog
    • +
  • The contract enters the same pipeline and must clear the same confidence gate before promotion
    • +
+

Guardrails that make this safe:

+
    +
  • Skills are versioned, signed, and reviewed for sensitive data before release (Infra & Ops owns the review)
    • +
  • Agents are stateless — all state lives in the platform; the platform trusts and always verifies
    • +
  • The agent's trace and submission confidence are captured in the contract for review
    • +
+

Skill catalog + real agent runtime: planned

+
Internal
+
+
+
Agentic Cloud Delivery Platform — The Developer Experience
+

The Contract

+

A 5-line YAML file. This is the entire consumer-facing interface to production.

+
# .acdl/contract.yaml — a static site
+uses: acdl/pipelines/deploy.yaml@v1.6
+module: static-assets
+environment: dev
+inputs:
+  bucket_name: my-static-site-assets
+  region: us-east-1
+
+
# .acdl/contract.yaml — a microservice
+uses: acdl/pipelines/deploy.yaml@v1.6
+module: microservice
+environment: dev
+inputs:
+  image: my-registry/my-microservice:latest
+  port: 8080
+
+

An invalid contract fails fast at validation with a clear error — not an opaque failure three stages in.

+
Internal
+
+
+
Agentic Cloud Delivery Platform — The Developer Experience
+

No Platform Code, No Cloning

+

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

+

+
    +
  • The consumer's CI definition is a thin wrapper — one uses: line
    • +
  • The runner checks out the consumer repo, then checks out the platform repo into the workspace
    • +
  • The platform installs its own runtime dependencies — the consumer installs nothing
    • +
  • When the platform ships a fix, every consumer on a floating tag gets it on their next run
    • +
+
Internal
+
+
+
Agentic Cloud Delivery Platform — The Developer Experience
+

Versioned, Predictable Releases

+

Consumers control when they absorb platform improvements.

+
    +
  • Floating MAJOR + MINOR tags (e.g. @v1.6) — a consumer automatically receives patch updates within the line Available today
    • +
  • Semantic versioning with a clear contract: interface → MAJOR, behavior → MINOR, lifecycle → PATCH
    • +
  • A consumer can pin to an exact version for maximum stability, or float on MAJOR only (@v1) to absorb new features on their own cadence
    • +
  • Unversioned references (@main, bare) are discouraged — the versioned tag is the only immutability lever
    • +
  • Automated release job computes the next semver on merge to main, creates the tag, and updates the floating tags Available today
    • +
+
Internal
+
+
+
Agentic Cloud Delivery Platform — The Developer Experience
+

Instant Feedback

+

Developers see what the platform is doing, in real time, in their own run logs. Available today

+
    +
  • Streamed output by default — the infrastructure plan, policy-check results, and each check record (severity, rule ID, pass/fail) flow to stdout
    • +
  • PR comments after every successful pipeline stage — a developer always knows where they stand without refreshing a dashboard
    • +
  • Clear, explainable halt reasons — a policy violation, an insufficient confidence signal, or a missing attestation. Never an opaque debugging exercise.
    • +
  • A --quiet mode suppresses streaming for log-only contexts
    • +
+
Internal
+
+
+
Agentic Cloud Delivery Platform — The Developer Experience
+

Deploy Outputs That Just Work

+

After a successful deploy, the developer gets their connection information without hunting for it — and without secrets leaking into logs. Available today

+
    +
  • Human-readable connection strings posted as a structured GitHub PR comment / job summary
    • +
  • Runtime-injectable values written to encrypted Parameter Store (SecureString, KMS-encrypted, namespaced /acdl/{env}/{contractId}/{output_name})
    • +
  • No raw secrets in logs — enforced by construction
    • +
  • Errors become GitHub issues, automatically — a failed deploy reports through the platform Lambda, which opens (or comments on) an issue on the platform repo. The consumer's only grant is the onboarding-granted Lambda-invoke permission
    • +
+
Internal
+
+
+
Agentic Cloud Delivery Platform — The Developer Experience
+

Local Reproducibility

+

The entire CI pipeline runs from the shell, not just in CI. Available today

+
    +
  • 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
    • +
+
Internal
+
+
+
Agentic Cloud Delivery Platform — The Developer Experience
+

Friendly Onboarding

+

First impressions of a platform are made when it fails for the first time. The platform fails gracefully. Available today

+

When no environment is bound, the platform emits a user-friendly onboarding prompt instead of failing opaquely:

+
    +
  1. That no environment is bound to their repo yet
    2. +
  2. What the platform will provision on their behalf (account, network, state, role)
    3. +
  3. The expected turnaround for the platform team to grant the environment
    4. +
  4. How to request an environment
    5. +
+

The pipeline then exits without attempting a deployment — no partial state, no confusing errors.

+

Both onboarding paths end in a sandbox dev submission that must pass the confidence gate before the consumer is promoted.

+

Citizen developer onboarding path: planned

+
Internal
+
+
+
Agentic Cloud Delivery Platform — The Developer Experience
+

Safe Promotion Path

+

The contract is environment-agnostic by design. Promotion is a workflow choice, not a contract edit — the platform raises the bar automatically.

+

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.

+
jobs:
+  dev:
+    uses: acdl/.github/workflows/deploy.yml@v1.6
+    with: { contract: .acdl/contract.yaml, environment: dev }
+  qa:
+    needs: dev
+    uses: acdl/.github/workflows/deploy.yml@v1.6
+    with: { contract: .acdl/contract.yaml, environment: qa }
+
+

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

+
jobs:
+  dev:
+    uses: acdl/.github/workflows/deploy.yml@v1.6
+    with: { contract: .acdl/contract-dev.yaml }
+  qa:
+    needs: dev
+    uses: acdl/.github/workflows/deploy.yml@v1.6
+    with: { contract: .acdl/contract-qa.yaml }
+
+
Internal
+
+
+
Agentic Cloud Delivery Platform — The Developer Experience
+

Safe Promotion Path — The Rising Bar

+

Whichever approach a team picks, the platform applies the same rising bar:

+ + + + + + + + + + + + + + + + + + + + + + + + + +
EnvironmentWhat the platform adds
devConfidence ≥ 0.50, fully autonomous
qaQA human attestation + confidence ≥ 0.75
prodSRE human attestation + confidence ≥ 0.90
drSRE human attestation + confidence ≥ 0.95 + DR drill reference
+
    +
  • No staging environment — the design deliberately removes the "staging is basically prod but not really" anti-pattern
    • +
  • Separation of duties is enforced — the QA approver cannot be the prod approver Design shipped Wiring: planned
    • +
  • Timeout discipline — 1 business day = warn + escalate; 2 business days = auto-freeze + re-submit
    • +
+

The DX win: the contract stays stable across environments. The safety win: the platform raises the threshold and attestation bar automatically based on the job's declared environment.

+
Internal
+
+
+
Agentic Cloud Delivery Platform — The Developer Experience
+

Safe Decommission

+

Tearing down a stack is as deliberate as deploying one — and just as gated. Available today

+
uses: acdl/.github/workflows/deploy.yml@v1.8
+with:
+  contract: .acdl/contract.yaml
+  mode: decommission
+  changeRequestId: "CR-2026-001"
+
+

A 2-step pipeline with two SRE human-attestation gates:

+
    +
  1. Validate the change request — the platform queries the CMDB; the CR must be approved and match the consumer repo
    2. +
  2. Disable deletion protection (plan + apply) → SRE approves
    3. +
  3. Zero all counts + destroy (plan + apply) → a second SRE approves
    4. +
  4. Confirmation — the stack is destroyed
    5. +
+

The per-stack encryption key enters a grace window (default 30 days) so encrypted data remains recoverable.

+
Internal
+
+
+
Agentic Cloud Delivery Platform — The Developer Experience
+

Self-Service Module Catalog

+

Developers pick from pre-built, security-reviewed building blocks — they don't author infrastructure from scratch. Available today

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

The Desired Outcomes

+ +
    +
  • Velocity without sacrificing safety. Speed is in the ergonomics (a 5-line contract, a one-line uses:); safety is in the gates the consumer cannot bypass.
    • +
  • Security, observability, and compliance as platform defaults — not per-team effort, not post-hoc remediation. Encryption, deletion protection, uptime monitoring, policy checks, and evidence are on by construction.
    • +
  • Auditability as a byproduct, not a project. Every production change is traceable to a human attestation and a tamper-evident evidence event.
    • +
  • Blast radius contained by design. Zero-trust OIDC + ABAC means a consumer can only touch its own tagged resources.
    • +
  • The bottleneck moves off the platform team's ticket queue. A merged change progresses through lower environments without a platform engineer joining a thread.
    • +
  • A path to the citizen developer. The same safety envelope that serves a senior engineer is the one that will serve a non-technical consumer — expanding who can ship safely without lowering the bar.
    • +
+
Internal
+
+
\ No newline at end of file