The Problem & The North Star

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

Four frictions slow every team:

• Cognitive load — authoring infrastructure correctly; the long tail of services inconsistent in security and observability
• Operational work — promoting a change from "merged" to "running in production." Manual work that scales with the system, not the change
• Red tape — tickets, approvals, and handoffs that scale with the organization. A merged change waits in a queue
• Scalability without increasing headcount — throughput scales without linearly scaling platform engineers

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

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

Where ACDL Sits in Your World

Now that we know the problem, here's where ACDL fits — and 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.
• Not a general-purpose AI — autonomy is narrow, scoped to delivery, bounded by strict policy
• Not a permissive delivery highway — no escape hatches to bypass the confidence framework

The Contract-Driven Model

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

A single YAML contract — module, environment, inputs. The platform owns everything else.

• Which module — a catalog of pre-built, security-reviewed building blocks
• Which environment — the platform raises the safety bar automatically as sensitivity rises
• Which inputs — infrastructure values that vary per deployment (cpu, memory, port, desired_count)
• The consumer provides no AWS account, no VPC, no state backend — the platform owns the blast radius

The End-to-End Flow

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

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

• Security and policy checks run before any infrastructure is created
• Every stage produces a record that feeds the confidence signal and the evidence stream — there is no "unchecked" path

Zero-Trust by Default

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

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

• Authentication — OIDC federation. Each job mints a short-lived token; no credential is stored in the consumer repo or in a runner secret. Testing (GitHub Actions) Planned: all runners
• Authorization — attribute-based (ABAC), not role-based. Two attribute classes scope every action:
  • Repository identity — the role's trust policy binds to the exact consumer repo + branch
  • Resource tags — every resource is tagged acdl:owner + acdl:contract; the session policy grants access only to matching tags

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

Safety is Computed, Not Assumed

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

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

• Six weighted inputs — 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:

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

Security by Construction

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

Security defaults that do not require a team to opt in. Checks run on every deployment, normalized to a single schema. Testing

• Policy checks (Checkov, Wiz, Kyverno) — secrets in plaintext, public ingress, IAM wildcards, required tagging standards — all run before infra is created
• Encryption on every resource — at-rest encryption on by default; per-stack customer-managed keys with 90-day rotation, no shared keys across stacks
• Deletion protection on by default — prevent_destroy on unless explicitly disabled via a documented flag
• Safe decommission — a 2-step pipeline with two SRE attestation gates and a change-request validated against the CMDB

Accountability & Audit

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

• Dev is fully autonomous. The confidence signal (≥ 0.50) is the only gate. Testing Agentic
• qa, prod, dr require human attestation — the approver reviews the contract, the planned Terraform changes, and the accumulated evidence Planned
• QA attests to infrastructure readiness, not application code — the contract, the plan, and the evidence. Application code review is upstream
• Separation of duties — 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 Testing

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

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

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

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 is provisioned after any module deploy, in a separate state, with a feature flag to disable
• Monitored endpoints passed from the deployment's own outputs — no manual endpoint registration
• Alert channels: Microsoft Teams webhook, email, SMS, and GitHub issues
• The uptime URL is published to the developer via a PR comment — they don't hunt for it
• Roadmap: deeper observability bootstrap (dashboards, runbooks, on-call bindings) as first-class contract fields Planned

A5 — Glossary

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.

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