diff --git a/docs/presentations/README.md b/docs/presentations/README.md index e17c6bc..06b6074 100644 --- a/docs/presentations/README.md +++ b/docs/presentations/README.md @@ -115,7 +115,7 @@ Distill the source of truth (Step 1) into presenter-ready cues, indexed by the Marp deck (Step 2) slide structure: - **One section per Marp slide** — `## Slide N — Title`, matching the Marp - deck's 10 main + 6 appendix slide structure exactly. The Marp deck + deck's 10 main + 7 appendix slide structure exactly. The Marp deck provides the indexing and context (what the audience sees); the source markdown provides the content (the speaker notes, the detail, the nuance). - **3-6 talking point bullets per slide** — punchy, actionable cues distilled @@ -145,11 +145,11 @@ and re-distill. 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 (10 main + 6 appendix) +├── how-the-platform-works-marp.md ← Step 2: Marp deck (10 main + 7 appendix) ├── how-the-platform-works.html ← Step 3: rendered HTML (committed) ├── how-the-platform-works-talking-points.md ← Step 4: presenter cues (16 sections) ├── the-developer-experience.md ← Step 1: full source of truth -├── the-developer-experience-marp.md ← Step 2: Marp deck (10 main + 6 appendix) +├── the-developer-experience-marp.md ← Step 2: Marp deck (10 main + 7 appendix) ├── the-developer-experience.html ← Step 3: rendered HTML (committed) ├── the-developer-experience-talking-points.md ← Step 4: presenter cues (16 sections) └── assets/ @@ -183,7 +183,7 @@ docs/presentations/ ### Appendix structure -Each Marp deck has **10 main slides + 6 appendix slides** (16 total). The +Each Marp deck has **10 main slides + 6 appendix slides** (17 total). The main 10 are the presentation; the appendix is for deep dives and Q&A backup. - **Main slides** (1-10): the story arc, high-impact, minimal text, @@ -331,5 +331,5 @@ attachments to the Gitea release. | Deck | Source of truth (Step 1) | Marp deck (Step 2) | Rendered HTML (Step 3) | Talking points (Step 4) | Slides | Audience | |---|---|---|---|---|---|---| -| How the Platform Works | `how-the-platform-works.md` | `how-the-platform-works-marp.md` | `how-the-platform-works.html` | `how-the-platform-works-talking-points.md` | 10 main + 6 appendix | 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` | `the-developer-experience-talking-points.md` | 10 main + 6 appendix | CTO, Head of Cloud, Head of Infra, Head of DevOps | \ No newline at end of file +| How the Platform Works | `how-the-platform-works.md` | `how-the-platform-works-marp.md` | `how-the-platform-works.html` | `how-the-platform-works-talking-points.md` | 10 main + 7 appendix | 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` | `the-developer-experience-talking-points.md` | 10 main + 7 appendix | 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-marp.md b/docs/presentations/how-the-platform-works-marp.md index ce98255..726e666 100644 --- a/docs/presentations/how-the-platform-works-marp.md +++ b/docs/presentations/how-the-platform-works-marp.md @@ -177,7 +177,7 @@ Security defaults that **do not require a team to opt in.** Checks run on **ever section { font-size: 20px; } -**11 capabilities testing today** (dev pilot-ready): +**22/22 Verified** via lifecycle pipeline + regression gate: - Contract-driven deploys · Module catalog · Zero-trust OIDC + ABAC - Security + policy checks before infra creation · Confidence signal gating @@ -192,8 +192,7 @@ section { font-size: 20px; } - Dynamic module creation Agentic · Pattern recognition Agentic - Additional engine adapters · Deeper observability bootstrap -**Verification Coverage** — 6 cloud capabilities are design-verified + locally emulated, deploy-unverified (IAM drift): -DynamoDB contracts table · Lambda contract-ingestor · ECS service live · CloudFront prod stack · uptime-kuma · OIDC role +**22/22 Verified** — the v1.11 lifecycle pipeline ran apply→modify→destroy against live AWS, then tore down to zero-cost (D-096). The v1.10 "6 deploy-unverified (IAM drift)" status is closed. *Full inventory + phased roadmap in the appendix.* @@ -230,6 +229,7 @@ DynamoDB contracts table · Lambda contract-ingestor · ECS service live · Clou 4. Testing vs. Planned (full inventory) 5. Glossary 6. Operating Model & Cost +7. Verified by Construction --- @@ -285,11 +285,13 @@ ul { margin: 0; padding-left: 1.2em; } li { margin-bottom: 2px; } +**22/22 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). +
-**Testing** (works internally, dev pilot-ready) +**Testing** (22/22 Verified — works internally, dev pilot-ready) - Contract-driven deploys with a versioned reusable workflow - Module catalog (primitives + modules) with validated examples @@ -342,11 +344,43 @@ li { margin-bottom: 2px; } # A6 — Operating Model & Cost -ACDL runs at **zero cloud cost** for day-to-day development. + -- **Local emulators are the primary tier** — the full pipeline (contract → resolver → adapter → local ECS → flat-file outbox → local Lambda) runs in-process, no AWS credentials, no Checkov, no DynamoDB. Testing -- **Live-AWS is a one-off spike per milestone** — `terraform init/validate/plan` against the real account verifies the adapter emits valid Terraform. No BAU cloud spend. -- **No running infrastructure between milestones** — state is in S3 (one bucket), the outbox is in DynamoDB (one table), both are query-only between spikes. -- **Cost drivers** are spike-scoped: Terraform plan reads (free), S3 state storage (cents), DynamoDB outbox (cents). No ECS, no CloudFront, no Lambda running persistently. +ACDL runs at **zero cloud cost** for day-to-day development. AWS spend was measured via Cost Explorer (`COST.md`, 2026-07-28): -**The operating model:** local-first development, milestone-scoped verification, zero BAU cloud spend. \ No newline at end of file +| Metric | Value | +|--------|-------| +| Total spend (8 days) | **$0.001883** | +| Daily average | $0.000235 | +| Projected monthly | ~$0.007 | +| Peak day | 2026-07-27 ($0.000867) | + +- **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 (D-096). The pipeline now **defaults to plan-only** on every PR; `ACDL_LIFECYCLE_MODE=full` overrides to 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 spike > $1/day is an anomaly. + +**Pre-mortem (`PRE_MORTEM.md`):** failure modes were pre-mortemed before the leadership pitch. The v1.10 decay incident (diff-scoped VERIFY missed 7 adapter defects) is the root pattern: *a claim outruns the verification that backs it.* Four forward failure modes + structural mitigations (regression-tested IAM baseline, mandatory teardown, verified-only deck claims, honest scope). + +--- + + + + +# A7 — Verified by Construction + +The v1.11 architecture makes "Verified" a structural property, not a claim. + + + +Two architectural pillars: + +- **The stateless adapter (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. Each L1 module ships a real `terraform/` module dir owning its shape, nested blocks, and defaults. The adapter reads the registry and emits `module "x" { source = ... }` blocks. A new module is a new terraform dir, not a code change. *(The v1.12 P67 fix closed a dedup defect for multi-resource L1s — ecs-service, alb; CAP-013 now Verified.)* +- **Pipeline-driven lifecycle testing.** A `modules-lifecycle` pipeline matrix-runs each L1 and L2 module's `examples/{simple,complex}.yml` contracts through apply→modify→destroy against live AWS. **The "test" = the pipeline cell going green.** Defaults to **plan-only** on every PR (fast, no AWS mutation, no cost); `ACDL_LIFECYCLE_MODE=full` overrides to 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. + +The v1.10 lesson is the negative space: a 918-line adapter with type-specific branches decayed silently. The ~80-line stateless adapter + the milestone regression gate are the structural fix. \ No newline at end of file diff --git a/docs/presentations/how-the-platform-works-talking-points.md b/docs/presentations/how-the-platform-works-talking-points.md index d77d220..845c440 100644 --- a/docs/presentations/how-the-platform-works-talking-points.md +++ b/docs/presentations/how-the-platform-works-talking-points.md @@ -1,6 +1,6 @@ # How The Platform Works — Talking Points -> **Companion to:** `how-the-platform-works-marp.md` (10 main + 6 appendix = 16 slides) +> **Companion to:** `how-the-platform-works-marp.md` (10 main + 7 appendix = 17 slides) > **Content source:** `how-the-platform-works.md` (full source of truth with speaker notes) > **Purpose:** Presenter-ready cues — 3-6 talking points per slide + the one key takeaway the audience should remember. > **Audience:** Senior Leadership — CTO, Head of Cloud, Head of Infrastructure, Head of DevOps @@ -12,7 +12,8 @@ **Talking points:** - Brief introduction — this deck explains *how* the platform works internally, not what the developer experience is (that's the companion deck) - Set the frame: the platform is not a CI/CD tool — it's the organizational lever for shipping safely at the pace the business demands -- The deck has 10 main slides plus a 6-slide appendix for deep-dive questions +- The deck has 10 main slides plus a 7-slide appendix for deep-dive questions +- v1.12 re-verification: every "Testing" claim in this deck is now Verified — 22/22 capabilities via the v1.11 lifecycle pipeline (see A7) **Key takeaway:** This is a platform that computes safety, doesn't assume it. @@ -34,7 +35,7 @@ ## Slide 3 — Where ACDL Sits in Your World **Talking points:** -- This is the new scope-boundary slide — it tells leadership where ACDL fits and, just as importantly, where it doesn't +- This is the scope-boundary slide — it tells leadership where ACDL fits and, just as importantly, where it doesn't - Upstream is anything — your IDE, an agentic SDLC, or a citizen developer vibe coding on a laptop. ACDL doesn't care how the contract was produced - ACDL is infrastructure only — it provisions and governs AWS resources. It does not build, test, or deploy your application code. That's upstream - Land the 2 anti-goals: "not a general-purpose AI" (autonomy is narrow, scoped to delivery, bounded by strict policy) and "not a permissive delivery highway" (no escape hatches to bypass the confidence framework) @@ -85,7 +86,7 @@ **Talking points:** - This is the bet that separates this platform from "yet another CI/CD tool" — reliance on operator instinct or tenure is not a substitute for a computed, auditable signal -- The new confidence signal diagram makes the six inputs and the per-input breakdown visible — walk it briefly so the audience sees the signal is *not* a black box +- The confidence signal diagram makes the six inputs and the per-input breakdown visible — walk it briefly so the audience sees the signal is *not* a black box - The weights are **manually tuned**, the inputs are **observable**, and the breakdown is **auditable** — if a consumer asks "why 0.62?", the platform answers with a per-input breakdown. This is the "auditable, not magic" point - Walk the threshold table: dev ≥ 0.50 (autonomous, Testing) → qa ≥ 0.75 (QA, Planned) → prod ≥ 0.90 (SRE, Planned). The bar rises automatically with sensitivity - A single critical policy finding hard-blocks the deployment — critical findings are not averaged away. This is non-negotiable @@ -112,7 +113,7 @@ **Talking points:** - The "lower environments autonomous, higher environments attested" tenet is the resolution to the classic "move fast vs. be safe" false dichotomy -- The new attestation flow diagram shows the human-in-the-loop path — dev autonomous → qa/prod/dr human attestation → evidence event. Walk it briefly +- The attestation flow diagram shows the human-in-the-loop path — dev autonomous → qa/prod/dr human attestation → evidence event. Walk it briefly - Land the QA clarification: **QA attests to infrastructure readiness — the contract, the planned Terraform changes, and the accumulated evidence. QA does not review application code (that's upstream).** This is the scope-boundary point reiterated - Badge reclassification to be clear about: separation of duties = **Planned** (not "design tested"); dev autonomous = **Testing**; qa/prod/dr attestation = **Planned** - The audit trail is a byproduct of deployment, not a project — every deployment writes a hash-chained evidence event synchronously (RPO = 0) @@ -140,7 +141,8 @@ **Talking points:** - These slides are for follow-up questions — don't walk them in the main 15-minute talk -- Pull them up when an audience member wants detail on a specific topic: environments, observability, roadmap, full inventory, or glossary terms +- Pull them up when an audience member wants detail on a specific topic: environments, observability, roadmap, full inventory, glossary, cost, or the v1.11 architecture +- The appendix now has 7 slides (A1–A7), including two new ones: A6 (Operating Model & Cost with real AWS figures + pre-mortem) and A7 (Verified by Construction — the v1.11 architecture) - The appendix exists so the main deck stays tight while still having answers ready **Key takeaway:** The appendix is the backup — detail on demand, not on the critical path. @@ -178,13 +180,13 @@ **Talking points:** - Be explicit up front: this is **proposed phasing, not formally planned** — the phases are sequenced by dependency, not by calendar -- Phase 1 — Testing baseline (current): contract-driven deploys, zero-trust OIDC + ABAC, confidence signal, hash-chained evidence, encryption by default, safe decommission, uptime monitoring, platform-managed environments -- Phase 2 — Production readiness: HITL wiring for qa/prod/dr, all-runner OIDC, full regulatory ledger, environment self-service +- Phase 1 — Testing baseline (current, v1.12): contract-driven deploys, zero-trust OIDC + ABAC, confidence signal, hash-chained evidence, encryption by default, 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 A7) +- 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), additional engine adapters (OpenTofu, Pulumi, Kubernetes CRDs), deeper observability bootstrap - Phase 4 — Agentic frontier: dynamic module creation from a contract (citizen-developer flow), pattern recognition that compounds value over time - Each phase's items are gated on the prior phase's maturity — invite questions on any phase boundary -**Key takeaway:** A dependency-sequenced path from testing baseline to agentic frontier — proposed, not formally committed. +**Key takeaway:** A dependency-sequenced path from testing baseline to agentic frontier — proposed, not formally committed. Phase 1 is now Verified (22/22), not aspirational. --- @@ -192,13 +194,14 @@ **Talking points:** - Close on honesty — the platform delivers real, verifiable value today, and the roadmap is concrete, not aspirational hand-waving -- Walk the Testing column (11 capabilities) quickly — from contract-driven deploys to encryption by default to uptime monitoring. These work internally and are dev pilot-ready +- **22/22 capabilities Verified** via the v1.11 lifecycle pipeline (apply→modify→destroy against live AWS for every L1 + L2 module) + the D-091 regression gate. The v1.10 "6 deploy-unverified (IAM drift)" status is closed (CAP-013 fixed in P67) +- Walk the Testing column (22 capabilities) — from contract-driven deploys to encryption by default to uptime monitoring. These work internally and are dev pilot-ready - Walk the Planned column (9 capabilities) — be clear about what's not yet done: HITL wiring, full regulatory ledger, compliance milestone, environment self-service, dynamic module creation, additional engine adapters, deeper observability - Two agentic items are flagged: dynamic module creation and pattern recognition — both involve AI agents or autonomous decision-making -- Invite questions on any "planned" item — each has a defined milestone and a clear reason it isn't shipped yet (usually an upstream dependency, not an engineering gap) - Emphasize: 0 consumer adoption today — "Testing" means it works internally and is dev pilot-ready, not that it's released +- The lifecycle pipeline defaults to **plan-only** on every PR (fast, no AWS mutation, no cost); `ACDL_LIFECYCLE_MODE=full` overrides to apply→destroy for milestone verification (REQ-134, v1.12) -**Key takeaway:** 11 capabilities testing today. 9 planned items on a concrete roadmap. Zero consumer adoption — yet. +**Key takeaway:** 22/22 capabilities Verified via lifecycle pipeline + regression gate. 9 planned items on a concrete roadmap. Zero consumer adoption — yet. --- @@ -210,4 +213,32 @@ - HITL is the human-attestation term for qa/prod/dr; NFR is the non-functional-requirements input to the confidence signal - IR (Intermediate Representation) is the engine-agnostic stack definition between the contract and Terraform — the abstraction that makes the platform portable -**Key takeaway:** A shared vocabulary — keep it as a reference for follow-up questions. \ No newline at end of file +**Key takeaway:** A shared vocabulary — keep it as a reference for follow-up questions. + +--- + +## A6 — Operating Model & Cost + +**Talking points:** +- This is the slide for the Head of Cloud / Finance — the headline: less than one cent ($0.001883) over 8 days of active development; zero BAU cloud spend +- Walk the cost table: total $0.001883 / 8 days, daily average $0.000235, projected monthly ~$0.007, peak day 2026-07-27 at $0.000867 (a v1.10 regression + verify run) +- S3 dominates the spend (98.8%, the terraform state bucket) — no compute (ECS/Lambda) ran because v1.0→v1.10 was plan-only for IAM-gated capabilities +- 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 (D-096 — teardown mandatory before milestone COMPLETE) +- The lifecycle pipeline now defaults to **plan-only** on every PR (fast, no AWS mutation, no cost); `ACDL_LIFECYCLE_MODE=full` overrides to apply→destroy for milestone verification (REQ-134, v1.12) +- The pre-mortem (`PRE_MORTEM.md`) is the credibility slide — we already asked "how does this fail?" The v1.10 decay incident (diff-scoped VERIFY missed 7 adapter defects) is the root pattern: *a claim outruns the verification that backs it.* Four forward failure modes + structural mitigations (regression-tested IAM baseline, mandatory teardown, verified-only deck claims, honest scope) + +**Key takeaway:** Less than one cent over 8 days. Zero BAU cloud spend. The pre-mortem + plan-only default make cost a non-issue and verification structural. + +--- + +## A7 — Verified by Construction + +**Talking points:** +- This is the deep-dive slide for the Head of Engineering / Architecture — the two pillars answer "how do you keep the decks honest?" +- Pillar 1 — the **stateless adapter** (918 → ~80 lines): the old adapter was a monolith with 3 constant tables and 39 type-specific branches. The new adapter is a stateless assembler that owns no module content — each L1 module ships a real `terraform/` module dir owning its shape, nested blocks, and defaults. A new module is a new terraform dir, not a code change +- The v1.12 P67 fix closed a dedup defect for multi-resource L1s (ecs-service, alb) — CAP-013 is now Verified +- Pillar 2 — **pipeline-driven lifecycle testing**: a `modules-lifecycle` pipeline matrix-runs each L1 and L2 module's contracts through apply→modify→destroy against live AWS. The "test" = the pipeline cell going green. No per-module Python +- The pipeline defaults to plan-only on every PR (zero cost); `ACDL_LIFECYCLE_MODE=full` runs the real apply→destroy for milestone verification. The regression gate (D-091) re-runs all 22 capabilities at milestone completion — 22/22 Verified as of v1.12 +- 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 + +**Key takeaway:** "Verified" is a structural property, not a claim — a stateless ~80-line adapter + a lifecycle pipeline that defaults to plan-only and goes green on every PR. \ No newline at end of file diff --git a/docs/presentations/how-the-platform-works.html b/docs/presentations/how-the-platform-works.html index ac1f29b..fe7d3b6 100644 --- a/docs/presentations/how-the-platform-works.html +++ b/docs/presentations/how-the-platform-works.html @@ -1,4 +1,4 @@ -How The Platform Works
+;" data-marpit-pagination-total="19">
How The Platform Works

The Problem & The North Star

Here's the problem we're solving and where we're going.

@@ -162,7 +162,7 @@ em.story { color: #6B7280; font-size: 16px; font-style: italic; } .testing { background: #DBEAFE; color: #1E3A5F; } .planned { background: #fef3c7; color: #78350f; } .agentic { background: #EDE9FE; color: #4C1D95; } -;" data-marpit-pagination-total="18"> +;" data-marpit-pagination-total="19">
How The Platform Works

Where ACDL Sits in Your World

Now that we know the problem, here's where ACDL fits — and where it doesn't.

@@ -217,7 +217,7 @@ em.story { color: #6B7280; font-size: 16px; font-style: italic; } .testing { background: #DBEAFE; color: #1E3A5F; } .planned { background: #fef3c7; color: #78350f; } .agentic { background: #EDE9FE; color: #4C1D95; } -;" data-marpit-pagination-total="18"> +;" data-marpit-pagination-total="19">
How The Platform Works

The Contract-Driven Model

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

@@ -273,7 +273,7 @@ em.story { color: #6B7280; font-size: 16px; font-style: italic; } .testing { background: #DBEAFE; color: #1E3A5F; } .planned { background: #fef3c7; color: #78350f; } .agentic { background: #EDE9FE; color: #4C1D95; } -;" data-marpit-pagination-total="18"> +;" data-marpit-pagination-total="19">
How The Platform Works

The End-to-End Flow

Once the contract is written, here's what the platform does with it — every time.

@@ -327,7 +327,7 @@ em.story { color: #6B7280; font-size: 16px; font-style: italic; } .testing { background: #DBEAFE; color: #1E3A5F; } .planned { background: #fef3c7; color: #78350f; } .agentic { background: #EDE9FE; color: #4C1D95; } -;" data-marpit-pagination-total="18"> +;" data-marpit-pagination-total="19">
How The Platform Works

Zero-Trust by Default

Before any infrastructure is created, here's how access is scoped.

@@ -386,7 +386,7 @@ em.story { color: #6B7280; font-size: 16px; font-style: italic; } .testing { background: #DBEAFE; color: #1E3A5F; } .planned { background: #fef3c7; color: #78350f; } .agentic { background: #EDE9FE; color: #4C1D95; } -;" data-marpit-pagination-total="18"> +;" data-marpit-pagination-total="19">
How The Platform Works

Safety is Computed, Not Assumed

Now let's look at how the platform decides whether a deployment is safe.

@@ -469,7 +469,7 @@ em.story { color: #6B7280; font-size: 16px; font-style: italic; } .testing { background: #DBEAFE; color: #1E3A5F; } .planned { background: #fef3c7; color: #78350f; } .agentic { background: #EDE9FE; color: #4C1D95; } -;" data-marpit-pagination-total="18"> +;" data-marpit-pagination-total="19">
How The Platform Works

Security by Construction

Beyond the confidence signal, security defaults are on by construction — not by opt-in.

@@ -524,7 +524,7 @@ em.story { color: #6B7280; font-size: 16px; font-style: italic; } .testing { background: #DBEAFE; color: #1E3A5F; } .planned { background: #fef3c7; color: #78350f; } .agentic { background: #EDE9FE; color: #4C1D95; } -;" data-marpit-pagination-total="18"> +;" data-marpit-pagination-total="19">
How The Platform Works

Accountability & Audit

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

@@ -586,7 +586,7 @@ em.story { color: #6B7280; font-size: 16px; font-style: italic; }

Testing vs. Planned

Let's be honest about what works today and what's on the roadmap.

-

11 capabilities testing today (dev pilot-ready):

+

22/22 Verified via lifecycle pipeline + regression gate:

  • Contract-driven deploys · Module catalog · Zero-trust OIDC + ABAC
  • Security + policy checks before infra creation · Confidence signal gating
    • @@ -601,8 +601,7 @@ em.story { color: #6B7280; font-size: 16px; font-style: italic; }
  • Dynamic module creation Agentic · Pattern recognition Agentic
  • Additional engine adapters · Deeper observability bootstrap
-

Verification Coverage — 6 cloud capabilities are design-verified + locally emulated, deploy-unverified (IAM drift):
-DynamoDB contracts table · Lambda contract-ingestor · ECS service live · CloudFront prod stack · uptime-kuma · OIDC role

+

22/22 Verified — the v1.11 lifecycle pipeline ran apply→modify→destroy against live AWS, then tore down to zero-cost (D-096). The v1.10 "6 deploy-unverified (IAM drift)" status is closed.

Full inventory + phased roadmap in the appendix.

Internal
@@ -718,6 +717,7 @@ em.story { color: #6B7280; font-size: 16px; font-style: italic; }
  • Testing vs. Planned (full inventory)
  • Glossary
  • Operating Model & Cost
    • +
  • Verified by Construction
    • Internal
    @@ -763,7 +763,7 @@ em.story { color: #6B7280; font-size: 16px; font-style: italic; } .testing { background: #DBEAFE; color: #1E3A5F; } .planned { background: #fef3c7; color: #78350f; } .agentic { background: #EDE9FE; color: #4C1D95; } -;" data-marpit-pagination-total="18"> +;" data-marpit-pagination-total="19">
    How The Platform Works

    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.

    @@ -820,7 +820,7 @@ em.story { color: #6B7280; font-size: 16px; font-style: italic; } .testing { background: #DBEAFE; color: #1E3A5F; } .planned { background: #fef3c7; color: #78350f; } .agentic { background: #EDE9FE; color: #4C1D95; } -;" data-marpit-pagination-total="18"> +;" data-marpit-pagination-total="19">
    How The Platform Works

    A2 — Observability Built In

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

    @@ -929,10 +929,12 @@ em.story { color: #6B7280; font-size: 16px; font-style: italic; }
    How The Platform Works

    A4 — Testing vs. Planned (Full Inventory)

    + +

    22/22 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).

    -

    Testing (works internally, dev pilot-ready)

    +

    Testing (22/22 Verified — works internally, dev pilot-ready)

    • Contract-driven deploys with a versioned reusable workflow
    • Module catalog (primitives + modules) with validated examples
      • @@ -1007,7 +1009,7 @@ em.story { color: #6B7280; font-size: 16px; font-style: italic; } .testing { background: #DBEAFE; color: #1E3A5F; } .planned { background: #fef3c7; color: #78350f; } .agentic { background: #EDE9FE; color: #4C1D95; } -;" data-marpit-pagination-total="18"> +;" data-marpit-pagination-total="19">
      How The Platform Works

      A5 — Glossary

      @@ -1100,17 +1102,100 @@ em.story { color: #6B7280; font-size: 16px; font-style: italic; } .testing { background: #DBEAFE; color: #1E3A5F; } .planned { background: #fef3c7; color: #78350f; } .agentic { background: #EDE9FE; color: #4C1D95; } -;" data-marpit-pagination-total="18"> +;" data-marpit-pagination-total="19">
      How The Platform Works

      A6 — Operating Model & Cost

      -

      ACDL runs at zero cloud cost for day-to-day development.

      + +

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

      +
      + + + + + + + + + + + + + + + + + + + + + + + + +
      MetricValue
      Total spend (8 days)$0.001883
      Daily average$0.000235
      Projected monthly~$0.007
      Peak day2026-07-27 ($0.000867)
        -
      • Local emulators are the primary tier — the full pipeline (contract → resolver → adapter → local ECS → flat-file outbox → local Lambda) runs in-process, no AWS credentials, no Checkov, no DynamoDB. Testing
        • -
      • Live-AWS is a one-off spike per milestone — terraform init/validate/plan against the real account verifies the adapter emits valid Terraform. No BAU cloud spend.
        • -
      • No running infrastructure between milestones — state is in S3 (one bucket), the outbox is in DynamoDB (one table), both are query-only between spikes.
        • -
      • Cost drivers are spike-scoped: Terraform plan reads (free), S3 state storage (cents), DynamoDB outbox (cents). No ECS, no CloudFront, no Lambda running persistently.
        • +
      • 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 (D-096). The pipeline now defaults to plan-only on every PR; ACDL_LIFECYCLE_MODE=full overrides to 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 spike > $1/day is an anomaly.
      -

      The operating model: local-first development, milestone-scoped verification, zero BAU cloud spend.

      +

      Pre-mortem (PRE_MORTEM.md): failure modes were pre-mortemed before the leadership pitch. The v1.10 decay incident (diff-scoped VERIFY missed 7 adapter defects) is the root pattern: a claim outruns the verification that backs it. Four forward failure modes + structural mitigations (regression-tested IAM baseline, mandatory teardown, verified-only deck claims, honest scope).

      +
      Internal
      + +
      +
      How The Platform Works
      + +

      A7 — Verified by Construction

      +

      The v1.11 architecture makes "Verified" a structural property, not a claim.

      + +

      Two architectural pillars:

      +
        +
      • The stateless adapter (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. Each L1 module ships a real terraform/ module dir owning its shape, nested blocks, and defaults. The adapter reads the registry and emits module "x" { source = ... } blocks. A new module is a new terraform dir, not a code change. (The v1.12 P67 fix closed a dedup defect for multi-resource L1s — ecs-service, alb; CAP-013 now Verified.)
        • +
      • Pipeline-driven lifecycle testing. A modules-lifecycle pipeline matrix-runs each L1 and L2 module's examples/{simple,complex}.yml contracts through apply→modify→destroy against live AWS. The "test" = the pipeline cell going green. Defaults to plan-only on every PR (fast, no AWS mutation, no cost); ACDL_LIFECYCLE_MODE=full overrides to 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.
        • +
      +

      The v1.10 lesson is the negative space: a 918-line adapter with type-specific branches decayed silently. The ~80-line stateless adapter + the milestone regression gate are the structural fix.

      Internal