acdl/docs/presentations/how-the-platform-works.md

How The Platform Works

Subtitle: Agentic Cloud Delivery Platform Audience: Senior Leadership, CTO, Head of Cloud, Head of Infrastructure, Head of DevOps Length: ~16 minutes · 11 main + Appendix TOC + 8 appendix = 20 slides Purpose: Sell the platform's value to tech leadership — zero-trust, security, observability, auditability, and the shift from "operators guess" to "the platform computes safety." Maturity framing: "Testing" = works internally, dev pilot-ready. "Planned" = on the roadmap, not yet implemented. "Agentic" = involves AI agents or autonomous decision-making. Re-verification (2026-07-29): Every "Testing" claim in this deck was re-verified in v1.10 Phase 54 (D-093) and again in v1.11 via the pipeline-driven lifecycle tests (P59–P62). The headline E2E (contract → resolver → adapter → terraform init/validate/plan) passes against the live AWS account; the local emulating tier (Phase 53) runs the full E2E with no cloud credentials. 22/22 auto-verifiable capabilities Verified (CAP-013 fixed in v1.12 P67 — the adapter's multi-resource L1 dedup defect is closed; CAP-017/018 probe bugs fixed). The v1.11 lifecycle pipeline ran apply→modify→destroy against live AWS and was then torn down to zero-cost (D-096). See .ciagent/CAPABILITY_INVENTORY.md and .ciagent/PRE_MORTEM.md.

---

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 — Four frictions slow every team

Most teams can write code; far fewer get the infrastructure right. Delivery scales with the coordination surface around it, not the engineering inside it.

flowchart LR
    subgraph ROW1 [" "]
        direction LR
        A["Cognitive load\nauthoring infra correctly"]
        B["Operational work\nmerged → running"]
    end
    subgraph ROW2 [" "]
        direction LR
        C["Red tape\ntickets, approvals, handoffs"]
        D["Scalability\nthroughput without headcount"]
    end
    A ~~~ B
    C ~~~ D
    A ~~~ C
    B ~~~ D

• Cognitive load — the long tail of services, inconsistent in security and observability.
• Operational work — manual promotion that scales with the system, not the change.
• Red tape — tickets and handoffs that scale with the organization.
• Scalability — throughput 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.

---

Slide 3 — The platform at a glance

One picture of the whole platform — the components, how they connect, and where the boundaries are. The rest of this deck zooms into each piece.

flowchart TD
    subgraph UP ["Consumer surfaces — upstream"]
        direction LR
        U1["Technical dev\napp code + contract"]
        U2["Citizen dev\nintent → AI agent → contract"]
    end

    subgraph ACDL ["ACDL — infrastructure only"]
        direction TB
        CS["Contract schema\n(validate + fail-fast)"]
        subgraph PIPE ["Central pipeline — fixed stages, every deployment"]
            direction LR
            P1["Validate"] --> P2["Resolve\ntarget stack"] --> P3["Security\nchecks"] --> P4["Infra plan"] --> P5["Policy\nchecks"] --> P6["Confidence\nsignal"] --> P7["Evidence\nevent"] --> P8["Infra apply"]
        end
        CAT["Module catalog\nprimitives + modules\n(security-reviewed)"]
        ADAPT["Engine adapter\n(stateless → Terraform)"]
        ENV["Platform-managed\nenvironments\naccount · VPC · state · IAM"]
        HITL["HITL gates\nqa · prod · dr"]
        EVID["Evidence stream\nhash-chained outbox\n(RPO = 0)"]
        CS --> PIPE
        CAT --> P2
        ADAPT --> P4
        ADAPT --> P8
        ENV --> P8
        P6 --> HITL
        HITL --> P8
        P7 --> EVID
    end

    subgraph DOWN ["Downstream"]
        direction LR
        D1["AWS resources\nrunning\n(tagged, encrypted)"]
        D2["Consumer pipeline\ndeploys image"]
    end

    U1 --> CS
    U2 --> CS
    P8 --> D1
    D1 --> D2

• Consumer surfaces — technical dev or citizen dev; both produce a contract. Upstream is anything.
• Contract schema — the boundary between upstream and ACDL; validated fail-fast.
• Central pipeline — fixed stages, identical for every deployment: validate → resolve → security → plan → policy → confidence → evidence → apply.
• Module catalog — security-reviewed primitives + modules the resolver expands against.
• Engine adapter — stateless; the only engine-specific code (Terraform today).
• Platform-managed environments — account, VPC, state, IAM role; the platform owns the blast radius.
• HITL gates — human attestation for qa/prod/dr; dev is autonomous.
• Evidence stream — hash-chained outbox, RPO = 0, written by every deployment.

Speaker notes: This is the one-slide map of the platform. Use it to orient the audience before diving into any single component. The leadership-relevant beats: (1) two surfaces, one pipeline, one evidence stream — the convergence is the design; (2) the pipeline stages are fixed and identical for every consumer — no team-specific pipelines; (3) the engine adapter is the only engine-specific code, which is what makes the catalog and confidence model portable. Don't walk every node; point to the boundaries and say "the rest of this deck zooms into each of these."

---

Slide 4 — Declare intent; the platform delivers safe production

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

flowchart LR
    subgraph TODAY ["Today"]
        direction TB
        A["Merged change"]
        B["Waits in queue"]
        C["Ticket + approvals"]
        D["Manual promotion"]
        A --> B --> C --> D
    end
    subgraph ACDL ["With ACDL"]
        direction TB
        E["Declare intent\n(one YAML contract)"]
        F["Platform delivers\nsafely, autonomously"]
        G["Traceable to\nhuman attestation"]
        E --> F --> G
    end
    TODAY -.before.-> ACDL

• A merged change progresses without a platform engineer joining a thread.
• A non-technical consumer ships by declaring intent — no workflow, no config file, no module.
• Every production change is traceable to a human attestation and an immutable evidence stream.

Speaker notes: Land the before/after contrast: today's queue vs. ACDL's autonomous flow. 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 North Star is "declare intent → safe production deployment."

---

Slide 5 — ACDL owns infrastructure, not your app

The platform is deliberately scoped — it is not trying to be everything.

flowchart LR
    subgraph UP ["Upstream — anything"]
        direction TB
        A["IDE / IDE + AI\n(dev writes contract)"]
        B["Agentic SDLC\n(agent writes contract)"]
        C["Citizen dev\n(vibe codes → AI agent\n→ contract)"]
    end
    subgraph ACDL ["ACDL — infrastructure only"]
        D["Contract\nvalidated"]
        E["Resolve → Plan\nSecurity + Policy checks\nConfidence signal"]
        F["Provision\nAWS resources"]
        G["Evidence\nhash-chained"]
    end
    subgraph DOWN ["Downstream"]
        H["AWS resources\nrunning"]
        I["Consumer pipeline\ndeploys image"]
    end
    A --> D
    B --> D
    C --> D
    D --> E
    E --> F
    E --> G
    F --> H
    H --> I

• Upstream is anything — IDE, agentic SDLC, or vibe coding. ACDL doesn't care how the contract was produced.
• ACDL is infrastructure only — it provisions and governs AWS resources. App build/test/deploy is upstream.
• Not a general-purpose AI — autonomy is narrow, scoped to delivery, bounded by strict policy.
• Not a permissive highway — no escape hatches to bypass the confidence framework.

Speaker notes: 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 6 — One YAML file. The platform owns everything else.

The contract is the boundary between upstream and ACDL. It's all a consumer writes.

flowchart LR
    A["Consumer<br/>writes a contract"] --> B["Platform resolves,<br/>compiles, checks,<br/>deploys, records"]
    B --> C["Resources running in AWS<br/>+ tamper-evident evidence"]

• Which module — a catalog of pre-built, security-reviewed building blocks.
• Which environment — dev, qa, prod, or dr. The bar rises automatically with sensitivity.
• 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.

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. The contract examples show infrastructure inputs (cpu, memory, desired_count, port) — not a container image. The image is upstream; the platform governs infrastructure.

---

Slide 7 — Same stages, same checks, every deployment

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

flowchart TD
    A["Consumer contract<br/>(module + environment + inputs)"] --> B["Validate contract<br/>against the schema"]
    B --> C["Resolve to a target stack<br/>(expand the module's pattern)"]
    C --> D["Security checks<br/>(before any infra is created)"]
    D --> E["Infrastructure plan<br/>(platform compiles the stack)"]
    E --> F["Policy checks<br/>(normalized results)"]
    F --> G["Confidence signal<br/>(6 inputs → score + band)"]
    G --> H["Evidence event<br/>(hash-chained, tamper-evident)"]
    H --> I["Infrastructure apply<br/>(dev only — higher envs hold for attestation)"]

• Security and policy checks run before any infrastructure is created — not as a post-deployment audit.
• Every stage produces a record that feeds the confidence signal and the evidence stream. No "unchecked" path.

Speaker notes: Walk left to right once. Don't dwell on internals — the point is that the flow is fixed, opinionated, and identical for every consumer. The two leadership-relevant beats: (1) checks before creation, (2) every stage is evidenced. The confidence signal (Slide 9) is where the "safety is computed" story lands.

---

Slide 8 — No long-lived credentials. Blast radius contained.

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

flowchart LR
    A["Consumer repo\n(no credentials)"]
    B["OIDC federation\nshort-lived token"]
    C["ABAC session policy\nrepo identity + tags"]
    D["Tagged resources\nonly"]
    A --> B --> C --> D

• Authentication — OIDC federation. Each job mints a short-lived token; no credential stored in the consumer repo or runner secret. Planned: all runners
• Authorization — attribute-based (ABAC), not role-based. Two attribute classes scope every action:
  • Repository identity — trust policy binds to the exact consumer repo + branch.
  • Resource tags — every resource tagged acdl:owner + acdl:contract; session policy grants access only to matching tags.
• The effect: a consumer can only touch the resources it created. One consumer can never affect another.

Speaker notes: This is the slide for the Head of Cloud/Security. The key phrase is "blast radius contained to the consumer's own stack." Contrast with the common failure mode of shared CI roles that can touch any account resource. The static-key override exists for edge cases but is rotated daily on platform runners; it is never the default.

---

Slide 9 — Safety is a measurable signal, not a black box

Every delivery action produces a measurable, explainable confidence signal — a weighted sum of observable facts, not a black box.

flowchart LR
    P["Policy"] --> S["Score"]
    V["Validation"] --> S
    F["Freshness"] --> S
    Pr["Provenance"] --> S
    H["History"] --> S
    N["NFRs"] --> S
    S --> B["Band + threshold"]

• Six weighted inputs — policy, validation, freshness, provenance, history, NFRs. Manually tuned, 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	Attester
dev	≥ 0.50	No one — autonomous
qa	≥ 0.75	QA Planned
prod	≥ 0.90	SRE Planned

• A single critical finding hard-blocks — critical findings are not averaged away.

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 because it makes promotion decisions reviewable.

---

Slide 10 — Every change traceable to a human attestation

Computed safety handles the gate. Humans still matter — here's how accountability works.

flowchart LR
    subgraph DEV ["dev — autonomous"]
        D1["Confidence ≥ 0.50\n→ apply"]
    end
    subgraph GATED ["qa / prod / dr — gated"]
        G1["Confidence ≥ threshold"]
        G2["Human attestation\nreviews contract\n+ plan + evidence"]
        G3["Separation of duties\nQA ≠ prod approver"]
        G1 --> G2 --> G3
    end
    DEV --> OUT["Hash-chained\nevidence event\n(RPO = 0)"]
    GATED --> OUT

• Dev is fully autonomous. The confidence signal (≥ 0.50) is the only gate.
• qa, prod, dr require human attestation — the approver reviews contract, planned Terraform, and accumulated evidence. Planned
• Separation of duties is enforced — the QA approver cannot be the prod approver. The platform blocks on a match. Planned
• Every deployment writes a hash-chained evidence event — tampering breaks the chain. RPO = 0.

Speaker notes: The "lower environments autonomous, higher environments attested" tenet is the resolution to the classic "move fast vs. be safe" false dichotomy. Be honest: the separation-of-duties mechanism is designed and the dev path is wired; qa/prod/dr wiring is on the roadmap. The audit trail is a byproduct of deployment, not a project. The full regulatory ledger (S3 Object Lock, JWS signatures, daily checkpoints) is planned; what ships today is the outbox + hash chain that makes every event tamper-evident and queryable.

---

Slide 11 — The vision realized

• Velocity without sacrificing safety. Speed is in the ergonomics; safety is in the gates the consumer cannot bypass.
• Security, observability, and compliance as platform defaults — not per-team effort, not post-hoc remediation.
• Auditability as a byproduct, not a project. Every production change is traceable to a human attestation and a tamper-evident evidence event.
• Blast radius contained by design. Zero-trust OIDC + ABAC means a consumer can only touch its own tagged resources.
• Infrastructure as a utility, not a craft. Teams consume infrastructure, they don't maintain it.
• A path to the citizen developer. The same safety envelope serves a senior engineer and a non-technical consumer.

Speaker notes: Close on the strategic frame. The platform is not "a CI/CD tool" — it's the organizational lever for shipping safely at the pace the business demands, with the security and audit posture the regulators require. The investment is in the abstraction, not the tool.

---

Appendix — Table of Contents

For deep dives — these slides cover details omitted from the main 10.

Contents:

1. Platform-Managed Environments (detail)
2. Observability Built In (detail)
3. Security by Construction (the full defaults inventory)
4. The Road to the North Star (phased roadmap)
5. Testing vs. Planned (full inventory)
6. Glossary
7. Operating Model & Cost (real AWS spend + pre-mortem)
8. Verified by Construction (the v1.11 architecture)

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.

---

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.

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 infrastructure state + locking).
• An IAM role surfaced to the consumer via ABAC, scoped to the consumer's repository identity and resource tags.

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. (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.

---

A2 — Observability Built In

Monitoring is a platform default, not a per-team project. (Testing.)

• 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: 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.

---

A3 — Security by Construction

Security defaults that do not require a team to opt in. Checks run on every deployment, normalized to a single schema 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. (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 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.

---

A4 — The Road to the North Star

Proposed phasing — not formally planned.

A phased roadmap from the current Testing baseline to the full North Star:

• Phase 1 — Testing baseline (current, v1.12): 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. 22/22 capabilities Verified via the v1.11 lifecycle pipeline (apply→modify→destroy against live AWS, then torn down to zero-cost). The stateless adapter + lifecycle pipeline are the structural verification (see A8).
• 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. Phase 1 is now fully Verified (22/22) and torn down to zero-cost — it is no longer aspirational. Invite questions on any phase boundary.

---

A5 — Testing vs. Planned (Full Inventory)

Verification status (v1.12, 2026-07-29): 22/22 auto-verifiable capabilities Verified — the v1.11 lifecycle pipeline ran apply→modify→destroy against live AWS for every L1 + L2 module, then tore down to zero-cost (D-096). The v1.10 "6 deploy-unverified (IAM drift)" status is closed (CAP-013 fixed in P67). See CAPABILITY_INVENTORY.md.

Testing (works internally, dev pilot-ready — 22/22 Verified via lifecycle pipeline + regression gate):

• 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. (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.
• Engine-agnostic core (1 adapter: Terraform) + VCS-agnostic ingestion (GitHub + Gitea).

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). (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 — 22/22 auto-verifiable capabilities are Verified via the v1.11 lifecycle pipeline (apply→modify→destroy against live AWS) + the D-091 regression gate. 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. The lifecycle pipeline defaults to plan-only on every PR (fast, no AWS mutation, no cost); a CI variable (ACDL_LIFECYCLE_MODE=full) overrides to the real apply→destroy for milestone verification (REQ-134, v1.12).

---

A6 — 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.

---

A7 — Operating Model & Cost (real AWS spend + pre-mortem)

ACDL runs at zero cloud cost for day-to-day development. The v1.0→v1.10 AWS spend was measured directly via Cost Explorer (COST.md, 2026-07-28):

Metric	Value
Total spend (8 days)	$0.001883
Daily average	$0.000235
Projected monthly	~$0.007
Peak day	2026-07-27 ($0.000867 — v1.10 regression + verify run)

• S3 dominates (98.8%, terraform state bucket) — no compute (ECS/Lambda) ran because v1.0→v1.10 was plan-only for IAM-gated capabilities.
• Local emulators are the primary tier — the full pipeline runs in-process, no AWS credentials, no Checkov, no DynamoDB. (Testing.)
• Live-AWS verification is milestone-scoped, then torn down. The v1.11 lifecycle pipeline ran apply→modify→destroy for every module, then tore down to zero-cost steady state (D-096 — teardown mandatory before milestone COMPLETE; no merge to main until terraform show confirms no resources). The lifecycle pipeline now defaults to plan-only on every PR (fast, no AWS mutation, no cost); a CI variable (ACDL_LIFECYCLE_MODE=full) overrides to the real apply→destroy for milestone verification (REQ-134, v1.12).
• Cost drivers are spike-scoped: Terraform plan reads (free), S3 state storage (cents), DynamoDB outbox (cents). Any cost spike > $1/day is an anomaly.

Pre-mortem (PRE_MORTEM.md): the project's failure modes were pre-mortemed before the leadership pitch. The v1.10 decay incident (diff-scoped VERIFY missed 7 adapter defects across 8 NFR-patch phases — decks advertised capability that wasn't reproducible) is the root pattern: a claim outruns the verification that backs it. Four forward failure modes + structural mitigations: (FM-1) IAM-drift recurrence → IAM policy baseline is regression-tested; (FM-2) cost spike from un-torn-down stacks → D-096 mandatory teardown; (FM-3) deck overstates capability → verified-only claims + decks unfrozen only after re-verification; (FM-4) pilot contract gap → honest scope (microservice + static-assets today; the L2 pattern is extensible). All mitigations are structural, not procedural.

Speaker notes: This is the slide for the Head of Cloud / Finance. The headline: less than one cent over 8 days of active development; zero BAU cloud spend; the lifecycle pipeline defaults to plan-only so the PR-time cost is zero. The pre-mortem is the credibility slide — we have already asked "how does this fail?" and the mitigations are structural (regression-tested baselines, mandatory teardown, verified-only deck claims). The v1.10 decay incident is disclosed honestly, not hidden — that disclosure IS the mitigation.

---

A8 — Verified by Construction (the v1.11 architecture)

v1.11 rebuilt the platform on two architectural pillars that make "Verified" a structural property, not a claim:

• The stateless adapter (REQ-123, 918 → ~80 lines). The Terraform adapter was a 918-line monolith with 3 constant tables and 39 type-specific branches. It is now a ~80-line stateless assembler: it owns no module content — no resource shape, no nested HCL blocks, no defaults, no type-specific logic. Each L1 module ships a real terraform/ module dir owning its resource shape, nested blocks, and defaults (centralized in locals.tf). The adapter reads the registry and emits module "x" { source = ... } blocks. No type-specific logic in the adapter means a new module is a new terraform dir, not a code change. (The v1.12 P67 fix closed a dedup defect where multi-resource L1s — ecs-service, alb — produced invalid Terraform; CAP-013 now Verified.)
• Pipeline-driven lifecycle testing (REQ-127/128). A modules-lifecycle pipeline matrix-runs each L1 and L2 module's examples/{simple,complex}.yml contracts through apply→modify→destroy against live AWS. No per-module Python. The "test" = the pipeline cell going green. Defaults to plan-only on every PR (fast, no AWS mutation, no cost); ACDL_LIFECYCLE_MODE=full runs the real apply→destroy for milestone verification (REQ-134, v1.12). The regression gate (D-091) re-runs all 22 capabilities at milestone completion — 22/22 Verified as of v1.12.

Speaker notes: This is the deep-dive slide for the Head of Engineering / Architecture. The two pillars are the answer to "how do you keep the decks honest?" The adapter is simple enough to reason about (a stateless assembler), and the lifecycle pipeline is the automated verification that backs every "Testing" claim. The v1.10 lesson is the negative space: a 918-line adapter with type-specific branches decayed silently because the VERIFY gate was diff-scoped. The ~80-line stateless adapter + the milestone regression gate are the structural fix. The plan-only default (v1.12) means this verification runs on every PR at zero cost, with the full apply→destroy gated behind a CI variable override.