docs(P48): vision gaps + badge system + substrate→engine + CR format + agentic tags
9 requirements implemented across presentation decks and project docs: 1. DX closing slide: added 'Infrastructure as a utility, not a craft' bullet to convey the full vision (infrastructure consumed, not maintained; platform compounds value over time). 2. PW Problem slide: 'moving a merged change' → 'promoting a change'. 3. PW Problem slide: added 'Red tape' and 'Scalability without increasing headcount' bullets (4 frictions, not 2). 4. PW Roadmap slide: redesigned with side-by-side HTML table layout (Testing | Planned), 16px font, no overflow. 5. PW deck: added new slide 'What This Platform Is — and Isn't' after North Star (sovereign boundary, infrastructure as utility, 4 anti-goals). PW deck now 16 slides (was 15). 6. Maturity nomenclature: 'Available today'/'shipped' → 'Testing' across both decks + source markdown. New .testing badge (blue/teal #DBEAFE). Roadmap title: 'Testing vs. Planned'. The platform has 0 consumer adoption — 'shipped' was inaccurate. 7. Global: 'substrate' → 'engine' across entire project (88 matches, 30+ files including .ciagent/, docs/, modules/, adapters/, schemas/, code). 8. Presentation files only: 'forge' → 'VCS' / 'version control system' (6 occurrences in 4 files). 'forge' retained in all technical docs and code as the industry-standard term. 9. New .agentic badge (purple/violet #EDE9FE) appended to agentic features in both decks: confidence signal, autonomous dev, pattern recognition, dynamic module creation, citizen developer surface, auto-promotion. Also: Change Request ID format changed from 'CR-2026-001' to 'CHG0678912' across presentation files, consumer guide, and test fixtures. HTML re-rendered. PPTX rendered for release upload. ---ci--- phase: 48 milestone: v1.9 status: complete requirements: covered: [] partial: [] ---/ci---
This commit is contained in:
Jon Chery
@@ -58,8 +58,9 @@ Synthesize the full markdown into a lean Marp deck:
|
||||
- **`<!-- _class: title -->` + `<!-- _paginate: false -->`** on title and
|
||||
closing slides for the dark-background title style.
|
||||
- **Maturity badges** using inline spans:
|
||||
`<span class="badge today">Available today</span>`
|
||||
`<span class="badge testing">Testing</span>`
|
||||
`<span class="badge planned">Planned</span>`
|
||||
`<span class="badge agentic">Agentic</span>`
|
||||
- **Tighter prose** than Step 1 — strip the speaker-note nuance; keep the
|
||||
leadership-relevant selling points.
|
||||
|
||||
@@ -133,15 +134,16 @@ docs/presentations/
|
||||
|
||||
### Maturity framing
|
||||
|
||||
Every capability claim in a deck is tagged with one of two badges:
|
||||
Every capability claim in a deck is tagged with one of three badges:
|
||||
|
||||
| Badge | Meaning |
|
||||
|---|---|
|
||||
| `Available today` | Shipped and verified in the platform |
|
||||
| `Planned` | On the roadmap, not yet shipped |
|
||||
| `Testing` | Works internally, not yet released to consumers (0 adoption) |
|
||||
| `Planned` | On the roadmap, not yet implemented |
|
||||
| `Agentic` | Involves AI agents, autonomous decision-making, or the citizen developer flow |
|
||||
|
||||
This is non-negotiable for a leadership audience: never present a roadmap
|
||||
item as a current capability, and never bury a shipped capability's
|
||||
item as a current capability, and never bury a tested capability's
|
||||
availability. When in doubt, check `.ciagent/ROADMAP.md` and the milestone
|
||||
status in `.ciagent/PROJECT.md`.
|
||||
|
||||
|
||||
@@ -23,8 +23,9 @@ style: |
|
||||
display: inline-block; padding: 2px 8px; border-radius: 4px;
|
||||
font-size: 14px; font-weight: 600;
|
||||
}
|
||||
.today { background: #c6f6d5; color: #22543d; }
|
||||
.testing { background: #DBEAFE; color: #1E3A5F; }
|
||||
.planned { background: #fef3c7; color: #78350f; }
|
||||
.agentic { background: #EDE9FE; color: #4C1D95; }
|
||||
---
|
||||
|
||||
<!-- _class: title -->
|
||||
@@ -45,12 +46,14 @@ section.title h3 { color: #F0F0F0; font-weight: 400; font-size: 22px; margin-top
|
||||
|
||||
Software delivery scales with the **coordination surface around it**, not the engineering inside it.
|
||||
|
||||
Two frictions slow every team:
|
||||
Four 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.**
|
||||
- **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.
|
||||
|
||||
The platform absorbs **both** frictions.
|
||||
The platform absorbs **all four** frictions.
|
||||
|
||||
---
|
||||
|
||||
@@ -66,6 +69,22 @@ Success looks like:
|
||||
|
||||
---
|
||||
|
||||
# What This Platform Is — and Isn't
|
||||
|
||||
**What it is:**
|
||||
|
||||
- **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.
|
||||
|
||||
---
|
||||
|
||||
# The Contract-Driven Model
|
||||
|
||||
One small YAML file is all a consumer writes. The platform owns everything else.
|
||||
@@ -95,7 +114,7 @@ Every deployment runs the same stages, in the same order, with the same checks
|
||||
|
||||
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. <span class="badge today">Available today (GitHub Actions)</span> <span class="badge planned">Planned: all runners</span>
|
||||
- **Authentication — OIDC federation.** Each job mints a short-lived token; no credential is stored in the consumer repo or in a runner secret. <span class="badge testing">Testing (GitHub Actions)</span> <span class="badge planned">Planned: all runners</span>
|
||||
- **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**
|
||||
@@ -106,7 +125,7 @@ Consumer repositories hold **no long-lived cloud credentials.** Ever.
|
||||
|
||||
# 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?"*
|
||||
Every delivery action produces a **measurable, explainable confidence signal** — the platform's certified answer to *"is this safe to proceed?"* <span class="badge agentic">Agentic</span>
|
||||
|
||||
- **Six weighted inputs:** policy conformance, validation, freshness, source provenance, history, NFRs
|
||||
- **Per-environment thresholds** that rise with sensitivity:
|
||||
@@ -127,9 +146,9 @@ Every delivery action produces a **measurable, explainable confidence signal**
|
||||
|
||||
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`) <span class="badge today">Available today</span>
|
||||
- **Cloud security posture** (Wiz adapter) — translates cloud security findings into the same normalized record <span class="badge today">Adapter ready</span>
|
||||
- **Kubernetes-native policy** (Kyverno adapter) — ready for the GitOps reconciler <span class="badge today">Adapter ready</span>
|
||||
- **Infrastructure policy** (Checkov) — secrets in plaintext, public ingress, IAM wildcards, KMS references, **required tagging standards** (`acdl:owner`, `acdl:contract`, `acdl:environment`, `acdl:cost-center`) <span class="badge testing">Testing</span>
|
||||
- **Cloud security posture** (Wiz adapter) — translates cloud security findings into the same normalized record <span class="badge testing">Testing</span>
|
||||
- **Kubernetes-native policy** (Kyverno adapter) — ready for the GitOps reconciler <span class="badge testing">Testing</span>
|
||||
|
||||
Every check produces a record with **severity, rule ID, pass/fail status, and a human-readable message** — consumed uniformly by the confidence signal.
|
||||
|
||||
@@ -137,7 +156,7 @@ Every check produces a record with **severity, rule ID, pass/fail status, and a
|
||||
|
||||
# Secure by Default
|
||||
|
||||
Security defaults that **do not require a team to opt in.** <span class="badge today">Available today</span>
|
||||
Security defaults that **do not require a team to opt in.** <span class="badge testing">Testing</span>
|
||||
|
||||
- **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**
|
||||
@@ -151,10 +170,10 @@ Security defaults that **do not require a team to opt in.** <span class="badge t
|
||||
|
||||
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 <span class="badge today">Available today</span>
|
||||
- **Tiered storage:** cold, tamper-proof source of truth (S3 Object Lock, 7-year retention) + a hot query index <span class="badge today">Outbox shipped</span> <span class="badge planned">Full ledger: planned</span>
|
||||
- **Every deployment writes a hash-chained evidence event** — each event links to the previous via a cryptographic hash; tampering breaks the chain <span class="badge testing">Testing</span>
|
||||
- **Tiered storage:** cold, tamper-proof source of truth (S3 Object Lock, 7-year retention) + a hot query index <span class="badge testing">Outbox tested</span> <span class="badge planned">Full ledger: planned</span>
|
||||
- **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
|
||||
- **Every production change is traceable to a human attestation** — approver identities are the only durable record outside the VCS's audit log
|
||||
|
||||
---
|
||||
|
||||
@@ -162,16 +181,16 @@ Version control is a **coordination tool, not an evidentiary fortress.** True co
|
||||
|
||||
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.
|
||||
- **Dev is fully autonomous.** The confidence signal (≥ 0.50) is the only gate. Queue-based handoffs are eliminated from lower environments. <span class="badge agentic">Agentic</span>
|
||||
- **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.** <span class="badge today">Design shipped</span> <span class="badge planned">Wiring: planned</span>
|
||||
- **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.** <span class="badge testing">Design tested</span> <span class="badge planned">Wiring: planned</span>
|
||||
- **Timeout discipline** — 1 business day = warn + escalate; 2 business days = auto-freeze + re-submit
|
||||
|
||||
---
|
||||
|
||||
# Observability Built In
|
||||
|
||||
Monitoring is **a platform default, not a per-team project.** <span class="badge today">Available today</span>
|
||||
Monitoring is **a platform default, not a per-team project.** <span class="badge testing">Testing</span>
|
||||
|
||||
- **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
|
||||
@@ -194,7 +213,7 @@ A named environment is a platform-owned bundle of:
|
||||
|
||||
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). <span class="badge today">Available today</span> <span class="badge planned">Self-service: planned</span>
|
||||
**Friendly onboarding:** the first run detects no environment and emits a guided prompt (not an opaque failure). <span class="badge testing">Testing</span> <span class="badge planned">Self-service: planned</span>
|
||||
|
||||
---
|
||||
|
||||
@@ -202,42 +221,56 @@ The consumer selects an environment **by name** in their contract. The platform
|
||||
|
||||
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.* <span class="badge today">1 adapter: Terraform</span> <span class="badge planned">OpenTofu / Pulumi / K8s</span>
|
||||
- **Forge-agnostic contract ingestion.** The platform Lambda reads a configurable API base for GitHub or Gitea. <span class="badge today">Available today</span>
|
||||
- **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. <span class="badge planned">Future capability</span>
|
||||
- **Engine-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.* <span class="badge testing">1 adapter: Terraform</span> <span class="badge planned">OpenTofu / Pulumi / K8s</span>
|
||||
- **VCS-agnostic contract ingestion.** The platform Lambda reads a configurable API base for GitHub or Gitea. <span class="badge testing">Testing</span>
|
||||
- **Portable contracts.** A second VCS needs a VCS 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. <span class="badge planned">Future capability</span> <span class="badge agentic">Agentic</span>
|
||||
|
||||
---
|
||||
|
||||
<!-- _class: title -->
|
||||
<!-- _paginate: false -->
|
||||
|
||||
# Roadmap: Shipped vs. Planned
|
||||
# Testing vs. Planned
|
||||
|
||||
<style>
|
||||
section { font-size: 20px; }
|
||||
section { font-size: 16px; }
|
||||
td { font-size: 15px; vertical-align: top; }
|
||||
ul { margin: 0; padding-left: 1.2em; }
|
||||
li { margin-bottom: 2px; }
|
||||
</style>
|
||||
|
||||
**Available today**
|
||||
<table style="width: 100%; border: none;">
|
||||
<tr>
|
||||
<td style="width: 52%; border: none; padding-right: 12px;">
|
||||
|
||||
**Testing** (works internally, not yet released to consumers)
|
||||
|
||||
- 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
|
||||
- Confidence signal (6 inputs, per-env thresholds) gating promotion <span class="badge agentic">Agentic</span>
|
||||
- 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
|
||||
- Local reproducibility + VCS-agnostic contract ingestion
|
||||
|
||||
**Planned (on the roadmap)**
|
||||
</td>
|
||||
<td style="width: 48%; border: none; padding-left: 12px;">
|
||||
|
||||
**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, DORA extension points
|
||||
- Environment self-service provisioning
|
||||
- Dynamic module creation from a contract (agentic citizen-developer flow)
|
||||
- Additional substrate adapters (OpenTofu, Pulumi, Kubernetes CRDs)
|
||||
- Dynamic module creation from a contract (agentic citizen-developer flow) <span class="badge agentic">Agentic</span>
|
||||
- Additional engine adapters (OpenTofu, Pulumi, Kubernetes CRDs)
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
File diff suppressed because one or more lines are too long
@@ -4,7 +4,7 @@
|
||||
> **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."
|
||||
> **Maturity framing:** "Available today" = shipped and verified. "Planned" = on the roadmap, not yet shipped.
|
||||
> **Maturity framing:** "Testing" = shipped and verified. "Planned" = on the roadmap, not yet shipped.
|
||||
|
||||
---
|
||||
|
||||
@@ -15,9 +15,11 @@ Software delivery scales with the **coordination surface around it**, not the en
|
||||
Two frictions slow every team down:
|
||||
|
||||
- **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** — 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.**
|
||||
- **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.
|
||||
|
||||
> **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 both frictions — that is the value proposition in one sentence.
|
||||
> **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.
|
||||
|
||||
---
|
||||
|
||||
@@ -35,7 +37,25 @@ What success looks like:
|
||||
|
||||
---
|
||||
|
||||
## Slide 3 — The Contract-Driven Model
|
||||
## Slide 3 — What This Platform Is — and Isn't
|
||||
|
||||
**What it is:**
|
||||
|
||||
- **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.
|
||||
|
||||
> **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.
|
||||
|
||||
---
|
||||
|
||||
## Slide 4 — The Contract-Driven Model
|
||||
|
||||
One small YAML file is all a consumer writes. The platform owns everything else.
|
||||
|
||||
@@ -86,7 +106,7 @@ Two properties matter to leadership:
|
||||
|
||||
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. *(Available today on GitHub Actions runners; planned for all platform runners.)*
|
||||
- **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.**
|
||||
@@ -136,11 +156,11 @@ Every check produces a record with **severity, rule ID, pass/fail status, and hu
|
||||
|
||||
Security defaults that **do not require a team to opt in.**
|
||||
|
||||
- **Encryption on every resource** — at-rest encryption is on by default for every primitive (S3, RDS, ECR, ECS, and more). *(Available today.)*
|
||||
- **Per-stack customer-managed keys (CMKs)** — one key per deployment, 90-day rotation at creation, **no shared keys across stacks.** *(Available today.)*
|
||||
- **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. *(Available today.)*
|
||||
- **Deletion protection on by default** — every resource has `prevent_destroy` on unless a consumer explicitly disables it via a documented feature flag. *(Available today.)*
|
||||
- **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. *(Available today.)* Encryption keys enter a grace window (default 30 days) so encrypted data remains recoverable during decommission.
|
||||
- **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.)*
|
||||
- **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.
|
||||
|
||||
@@ -150,10 +170,10 @@ Security defaults that **do not require a team to opt in.**
|
||||
|
||||
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. 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 shipped; S3 Object Lock + JWS detached signatures are planned regulatory-ledger build-out.)*
|
||||
- **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 forge's audit log, stored in the outbox keyed by contract.
|
||||
- **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.
|
||||
|
||||
@@ -176,9 +196,9 @@ Autonomy and accountability are **not in tension** — they are applied at diffe
|
||||
|
||||
Monitoring is **a platform default, not a per-team project.**
|
||||
|
||||
- **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. *(Available today.)*
|
||||
- **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. *(Available today.)*
|
||||
- **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.
|
||||
|
||||
@@ -199,7 +219,7 @@ A named environment is a platform-owned bundle of:
|
||||
|
||||
The consumer selects an environment **by name** in their contract (`environment: dev`). The platform resolves the name to the underlying account/network/state/role at run time. **The consumer never sees the raw credentials.**
|
||||
|
||||
**Friendly onboarding:** the first run detects no environment and emits a guided prompt (not an opaque failure) telling the consumer what the platform will provision and how to request it. *(Available today.)* **Self-service environment provisioning is planned.**
|
||||
**Friendly onboarding:** the first run detects no environment and emits a guided prompt (not an opaque failure) telling the consumer what the platform will provision and how to request it. *(Testing.)* **Self-service environment provisioning is planned.**
|
||||
|
||||
> **Speaker notes:** For the Head of Cloud: this is the governance story. The platform team owns the accounts, the network design, the state hygiene. Consumers can't drift into misconfigured state backends or over-permissioned roles because they never touch them. The onboarding prompt matters — first impressions of a platform are made when it fails for the first time.
|
||||
|
||||
@@ -209,18 +229,18 @@ The consumer selects an environment **by name** in their contract (`environment:
|
||||
|
||||
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.* 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. *(Available today.)*
|
||||
- **Portable contracts.** The contract schema, the confidence signal, and the audit stream are substrate- and forge-agnostic. A second forge (e.g. GitLab) needs a forge adapter + a workflow-template translator — **no change to the modules, the contract standard, the confidence model, or the audit stream.**
|
||||
- **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.)*
|
||||
|
||||
> **Speaker notes:** This is the "we won't have to rewrite this in two years" slide. The bet is that the substrate (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:** 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.
|
||||
|
||||
---
|
||||
|
||||
## Slide 14 — Roadmap: Honest Shipped vs. Planned
|
||||
## Slide 14 — Roadmap: Honest Testing vs. Planned
|
||||
|
||||
**Available today:**
|
||||
**Testing:**
|
||||
|
||||
- Contract-driven deploys with a versioned reusable workflow.
|
||||
- Module catalog (primitives + modules) with validated examples.
|
||||
@@ -243,6 +263,6 @@ The platform is **opinionated, but not painted into a corner.**
|
||||
- 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).
|
||||
- Additional engine adapters (OpenTofu, Pulumi, Kubernetes CRDs).
|
||||
|
||||
> **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).
|
||||
@@ -25,8 +25,9 @@ style: |
|
||||
display: inline-block; padding: 2px 8px; border-radius: 4px;
|
||||
font-size: 14px; font-weight: 600;
|
||||
}
|
||||
.today { background: #c6f6d5; color: #22543d; }
|
||||
.testing { background: #DBEAFE; color: #1E3A5F; }
|
||||
.planned { background: #fef3c7; color: #78350f; }
|
||||
.agentic { background: #EDE9FE; color: #4C1D95; }
|
||||
---
|
||||
|
||||
<!-- _class: title -->
|
||||
@@ -50,7 +51,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 AI 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 <span class="badge agentic">Agentic</span>
|
||||
|
||||
The platform is **opinionated in what it accepts, regardless of who is declaring.** There is no "citizen developer mode" with weaker checks.
|
||||
|
||||
@@ -86,7 +87,7 @@ A non-technical consumer ships a production deployment **by declaring intent**
|
||||
- Agents are **stateless** — all state lives in the platform; the platform trusts and **always verifies**
|
||||
- The agent's trace and submission confidence are captured in the contract for review
|
||||
|
||||
<span class="badge planned">Skill catalog + real agent runtime: planned</span>
|
||||
<span class="badge planned">Skill catalog + real agent runtime: planned</span> <span class="badge agentic">Agentic</span>
|
||||
|
||||
---
|
||||
|
||||
@@ -135,17 +136,17 @@ Consumers `uses:` a **versioned** central workflow. The platform fetches itself
|
||||
|
||||
Consumers control **when** they absorb platform improvements.
|
||||
|
||||
- **Floating MAJOR + MINOR tags** (e.g. `@v1.6`) — a consumer automatically receives patch updates within the line <span class="badge today">Available today</span>
|
||||
- **Floating MAJOR + MINOR tags** (e.g. `@v1.6`) — a consumer automatically receives patch updates within the line <span class="badge testing">Testing</span>
|
||||
- **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 <span class="badge today">Available today</span>
|
||||
- **Automated release job** computes the next semver on merge to main, creates the tag, and updates the floating tags <span class="badge testing">Testing</span>
|
||||
|
||||
---
|
||||
|
||||
# Instant Feedback
|
||||
|
||||
Developers see **what the platform is doing**, in real time, in their own run logs. <span class="badge today">Available today</span>
|
||||
Developers see **what the platform is doing**, in real time, in their own run logs. <span class="badge testing">Testing</span>
|
||||
|
||||
- **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
|
||||
@@ -156,7 +157,7 @@ Developers see **what the platform is doing**, in real time, in their own run lo
|
||||
|
||||
# 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. <span class="badge today">Available today</span>
|
||||
After a successful deploy, the developer gets their connection information **without hunting for it** — and without secrets leaking into logs. <span class="badge testing">Testing</span>
|
||||
|
||||
- **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}`)
|
||||
@@ -167,7 +168,7 @@ After a successful deploy, the developer gets their connection information **wit
|
||||
|
||||
# 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>
|
||||
First impressions of a platform are made **when it fails for the first time.** The platform fails gracefully. <span class="badge testing">Testing</span>
|
||||
|
||||
When no environment is bound, the platform emits a **user-friendly onboarding prompt** instead of failing opaquely:
|
||||
|
||||
@@ -240,13 +241,13 @@ Whichever approach a team picks, the platform applies the same rising bar:
|
||||
|
||||
| Environment | What the platform adds |
|
||||
|---|---|
|
||||
| dev | Confidence ≥ 0.50, fully autonomous |
|
||||
| dev | Confidence ≥ 0.50, fully autonomous <span class="badge agentic">Agentic</span> |
|
||||
| qa | QA human attestation + confidence ≥ 0.75 |
|
||||
| prod | SRE human attestation + confidence ≥ 0.90 |
|
||||
| dr | SRE 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 <span class="badge today">Design shipped</span> <span class="badge planned">Wiring: planned</span>
|
||||
- **Separation of duties is enforced** — the QA approver cannot be the prod approver <span class="badge testing">Design tested</span> <span class="badge planned">Wiring: planned</span>
|
||||
- **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.
|
||||
@@ -255,14 +256,14 @@ The DX win: the contract stays stable across environments. The safety win: the p
|
||||
|
||||
# Safe Decommission
|
||||
|
||||
Tearing down a stack is **as deliberate as deploying one** — and just as gated. <span class="badge today">Available today</span>
|
||||
Tearing down a stack is **as deliberate as deploying one** — and just as gated. <span class="badge testing">Testing</span>
|
||||
|
||||
```yaml
|
||||
uses: acdl/.github/workflows/deploy.yml@v1.8
|
||||
with:
|
||||
contract: .acdl/contract.yaml
|
||||
mode: decommission
|
||||
changeRequestId: "CR-2026-001"
|
||||
changeRequestId: "CHG0678912"
|
||||
```
|
||||
|
||||
A 2-step pipeline with **two SRE human-attestation gates**:
|
||||
@@ -278,12 +279,12 @@ The per-stack encryption key enters a **grace window** (default 30 days) so encr
|
||||
|
||||
# Self-Service Module Catalog
|
||||
|
||||
Developers pick from **pre-built, security-reviewed building blocks** — they don't author infrastructure from scratch. <span class="badge today">Available today</span>
|
||||
Developers pick from **pre-built, security-reviewed building blocks** — they don't author infrastructure from scratch. <span class="badge testing">Testing</span>
|
||||
|
||||
- **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 <span class="badge planned">Planned</span>
|
||||
- **Auto-promotion of patterns** — a thin-composition layer is auto-promoted to the catalog after 3 observed usages <span class="badge planned">Planned</span> <span class="badge agentic">Agentic</span>
|
||||
- **Compliance extension points** — each module lists where GDPR, SOX, SOC2, DORA controls will wire in <span class="badge planned">Planned</span>
|
||||
|
||||
---
|
||||
@@ -302,4 +303,5 @@ section { font-size: 22px; }
|
||||
- **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.
|
||||
- **Infrastructure as a utility, not a craft.** The platform abstracts compute, networking, and state. Teams consume infrastructure, they don't maintain it — and the platform compounds value over time by learning from recurring patterns.
|
||||
- **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. <span class="badge agentic">Agentic</span>
|
||||
File diff suppressed because one or more lines are too long
@@ -4,7 +4,7 @@
|
||||
> **Audience:** Senior Leadership, CTO, Head of Cloud, Head of Infrastructure, Head of DevOps
|
||||
> **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.
|
||||
> **Maturity framing:** "Testing" = shipped and verified. "Planned" = on the roadmap, not yet shipped.
|
||||
|
||||
---
|
||||
|
||||
@@ -145,7 +145,7 @@ Consumers control **when** they absorb platform improvements.
|
||||
- **Semantic versioning with a clear contract:** interface changes → MAJOR, behavior changes → MINOR, lifecycle fixes → 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 a consumer has.
|
||||
- **Automated release job** computes the next semver on merge to main, creates the tag, and updates the floating tags. *(Available today.)*
|
||||
- **Automated release job** computes the next semver on merge to main, creates the tag, and updates the floating tags. *(Testing.)*
|
||||
|
||||
> **Speaker notes:** This is the "no surprise upgrades" story. Leadership hears two things: (1) consumers aren't forced to chase the platform, (2) the platform isn't forced to support N forks of every workflow. The versioning discipline is what makes both true.
|
||||
|
||||
@@ -155,8 +155,8 @@ Consumers control **when** they absorb platform improvements.
|
||||
|
||||
Developers see **what the platform is doing**, in real time, in their own run logs.
|
||||
|
||||
- **Streamed output by default** — the infrastructure plan, policy-check results, and each `PolicyCheckResult` record (severity, rule ID, pass/fail) flow to stdout. *(Available today.)*
|
||||
- **PR comments after every successful pipeline stage** — a developer always knows where they stand without refreshing a dashboard. *(Available today.)*
|
||||
- **Streamed output by default** — the infrastructure plan, policy-check results, and each `PolicyCheckResult` record (severity, rule ID, pass/fail) flow to stdout. *(Testing.)*
|
||||
- **PR comments after every successful pipeline stage** — a developer always knows where they stand without refreshing a dashboard. *(Testing.)*
|
||||
- **Clear, explainable halt reasons** — a policy violation, an insufficient confidence signal, or a missing attestation. **Never an opaque, manual-debugging exercise.**
|
||||
- **A `--quiet` mode** suppresses streaming for log-only contexts.
|
||||
|
||||
@@ -168,10 +168,10 @@ Developers see **what the platform is doing**, in real time, in their own run lo
|
||||
|
||||
After a successful deploy, the developer gets their connection information **without hunting for it** — and without secrets leaking into logs.
|
||||
|
||||
- **Human-readable connection strings** posted as a structured GitHub PR comment / job summary. *(Available today.)*
|
||||
- **Runtime-injectable values** written to encrypted Parameter Store (`SecureString`, KMS-encrypted, namespaced `/acdl/{env}/{contractId}/{output_name}`). *(Available today.)*
|
||||
- **Human-readable connection strings** posted as a structured GitHub PR comment / job summary. *(Testing.)*
|
||||
- **Runtime-injectable values** written to encrypted Parameter Store (`SecureString`, KMS-encrypted, namespaced `/acdl/{env}/{contractId}/{output_name}`). *(Testing.)*
|
||||
- **No raw secrets in logs** — the platform enforces this 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 — no separate `issues: write` scope on the consumer side. *(Available today.)*
|
||||
- **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 — no separate `issues: write` scope on the consumer side. *(Testing.)*
|
||||
|
||||
> **Speaker notes:** The "errors become issues" point is a DX win that also helps the platform team — every consumer failure is a tracked, queryable artifact, not a lost log line. The Head of DevOps should hear: the platform closes the feedback loop, it doesn't just push a green/red status.
|
||||
|
||||
@@ -181,7 +181,7 @@ After a successful deploy, the developer gets their connection information **wit
|
||||
|
||||
First impressions of a platform are made **when it fails for the first time.** The platform fails gracefully.
|
||||
|
||||
- When a consumer pipeline runs for the first time and **no environment is bound**, the platform detects this and emits a **user-friendly onboarding prompt** instead of failing opaquely. *(Available today.)*
|
||||
- When a consumer pipeline runs for the first time and **no environment is bound**, the platform detects this and emits a **user-friendly onboarding prompt** instead of failing opaquely. *(Testing.)*
|
||||
- The prompt tells the consumer:
|
||||
1. That no environment is bound to their repo yet.
|
||||
2. What the platform will provision on their behalf (account, network, state, role).
|
||||
@@ -252,7 +252,7 @@ Whichever approach a team picks, the platform applies the same rising bar:
|
||||
| dr | SRE human attestation + confidence ≥ 0.95 + a disaster-recovery drill reference |
|
||||
|
||||
- **No staging environment** — the design deliberately removes the "staging is basically prod but not really" anti-pattern. Dev is the only autonomous environment.
|
||||
- **Separation of duties is enforced** — the QA approver cannot be the prod approver. *(Design shipped; wiring for qa/prod/dr is planned.)*
|
||||
- **Separation of duties is enforced** — the QA approver cannot be the prod approver. *(Design tested; wiring for qa/prod/dr is planned.)*
|
||||
- **Timeout discipline** — 1 business day = warn + escalate; 2 business days = auto-freeze + re-submit.
|
||||
|
||||
> **Speaker notes:** Promotion is a workflow choice, not a contract mutation — this matters because it means a promotion can be reviewed as a *diff in the workflow*, not as a rewritten contract. Approach A (one contract, environment passed by the job) keeps the single source of truth; Approach B (environment-specific contracts) lets teams whose inputs genuinely vary keep that variation explicit and reviewable. For leadership: the DX win is that the contract stays stable across environments; the safety win is that the platform raises the threshold and attestation bar automatically based on the target environment the job declares. The consumer can't bypass the gates — they pick *which* environment to target, and the platform applies the right bar.
|
||||
@@ -269,7 +269,7 @@ uses: acdl/.github/workflows/deploy.yml@v1.8
|
||||
with:
|
||||
contract: .acdl/contract.yaml
|
||||
mode: decommission
|
||||
changeRequestId: "CR-2026-001"
|
||||
changeRequestId: "CHG0678912"
|
||||
```
|
||||
|
||||
A 2-step pipeline with **two SRE human-attestation gates** *(available today)*:
|
||||
@@ -292,9 +292,9 @@ A 2-step pipeline with **two SRE human-attestation gates** *(available today)*:
|
||||
|
||||
Developers pick from **pre-built, security-reviewed building blocks** — they don't author infrastructure from scratch.
|
||||
|
||||
- **Primitives** — single-purpose resources (S3, VPC, ECS cluster, ECS service, IAM role, load balancer, container registry, CloudFront, WAF, RDS). Each has documented inputs, outputs, usage, compliance extension points, and versioning. *(Available today.)*
|
||||
- **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.)*
|
||||
- **Primitives** — single-purpose resources (S3, VPC, ECS cluster, ECS service, IAM role, load balancer, container registry, CloudFront, WAF, RDS). Each has documented inputs, outputs, usage, compliance extension points, and versioning. *(Testing.)*
|
||||
- **Modules** — composed patterns (a static site with CDN + WAF; a microservice with VPC + ECS + load balancer + registry). *(Testing.)*
|
||||
- **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. *(Testing.)*
|
||||
- **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, DORA controls will wire in. *(Compliance milestone is planned.)*
|
||||
|
||||
@@ -311,6 +311,7 @@ What this platform delivers to the organization:
|
||||
- **Auditability as a byproduct, not a project.** Every production change is traceable to a human attestation and a tamper-evident evidence event — captured during the deploy, not reconstructed for the audit.
|
||||
- **Blast radius contained by design.** Zero-trust OIDC + ABAC means a consumer can only touch its own tagged resources. One consumer can never affect another.
|
||||
- **The bottleneck moves off the platform team's ticket queue.** A merged change progresses through lower environments without a platform engineer joining a thread. The platform team invests in the platform, not in per-deployment hand-holding.
|
||||
- **Infrastructure as a utility, not a craft.** The platform abstracts compute, networking, and state. Teams consume infrastructure, they don't maintain it — and the platform compounds value over time by learning from recurring patterns.
|
||||
- **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.
|
||||
|
||||
> **Speaker notes:** Close on the strategic frame. The platform is not "a CI/CD tool" — it is the organizational lever for shipping safely at the pace the business demands, with the security and audit posture the regulators require. Invite questions; the companion deck ("How the Platform Works") covers the internal mechanics in more depth.
|
||||
Reference in New Issue
Block a user