From 807b17d04b5b151fc005029aeb1f4b087e097e82 Mon Sep 17 00:00:00 2001 From: Jon Chery Date: Thu, 23 Jul 2026 15:43:49 +0000 Subject: [PATCH] docs(P49): consolidate both Marp decks to 10 high-impact slides MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit How The Platform Works: 16 → 10 slides - Merged Problem + North Star + What It Is/Isn't → 1 slide (4 frictions → North Star → 3 success criteria → 2 anti-goals) - Merged Policy & Security + Secure by Default → 'Security by Construction' - Merged Immutable Audit + Human-in-the-Loop → 'Accountability & Audit' - Folded Observability, Platform-Managed Environments, Portability into existing slides as bullets (Roadmap, Contract-Driven) - Added 'The Vision Realized' closing slide - Removed '5-line YAML' claim (credibility — complex stacks are more) The Developer Experience: 15 → 10 slides - Merged What Dev Does + Contract + No Platform Code → 'The Contract — The Entire Consumer Surface' - Merged Instant Feedback + Deploy Outputs → 'The Developer Feedback Loop' - Merged Safe Promotion Path + Rising Bar → 1 slide with side-by-side approaches + threshold table - Cut Citizen Developer Experience as standalone (mentioned on slide 2 and slide 10 Outcomes) - Kept Versioned Releases, Friendly Onboarding, Safe Decommission as standalone (per user request) - Removed '5-line YAML' claim Source markdown files unchanged (remain complete reference with speaker notes for all original slides). ---ci--- phase: 49 milestone: v1.9 status: complete requirements: covered: [] partial: [] ---/ci--- --- .../how-the-platform-works-marp.md | 160 ++--- .../presentations/how-the-platform-works.html | 550 ++++-------------- .../the-developer-experience-marp.md | 145 +---- .../the-developer-experience.html | 501 ++++------------ 4 files changed, 298 insertions(+), 1058 deletions(-) diff --git a/docs/presentations/how-the-platform-works-marp.md b/docs/presentations/how-the-platform-works-marp.md index e0f843e..be73e79 100644 --- a/docs/presentations/how-the-platform-works-marp.md +++ b/docs/presentations/how-the-platform-works-marp.md @@ -42,60 +42,35 @@ section.title h3 { color: #F0F0F0; font-weight: 400; font-size: 22px; margin-top --- -# The Problem We Solve - -Software delivery scales with the **coordination surface around it**, not the engineering inside it. +# The Problem & The North Star 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** — 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. +- **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 -The platform absorbs **all four** frictions. +> Consumers **declare intent**; the platform delivers **safe production deployment** — automatically, safely, with a complete audit trail. ---- - -# The North Star - -> Consumers **declare intent**; the platform delivers **safe production deployment** — automatically, safely, and with a complete audit trail. - -Success looks like: - -- A merged change progresses through lower environments **without a platform engineer joining a thread, approving a ticket, or triggering a stage.** -- A **non-technical consumer** ships a production deployment by declaring intent — without authoring a workflow, a configuration file, or an infrastructure module. -- Every production change is **traceable to a human attestation and an immutable evidence stream.** - ---- - -# 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. +- 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** +- **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 -One small YAML file is all a consumer writes. The platform owns everything else. +A single YAML contract is all a consumer writes — **module, environment, inputs**. The platform owns everything else. -![w:900](assets/png/platform-works-01-contract-driven.png) - -The contract names three things: +![w:850](assets/png/platform-works-01-contract-driven.png) - **Which module** — a catalog of pre-built, security-reviewed building blocks - **Which environment** — the platform raises the safety bar automatically as sensitivity rises - **Which inputs** — the handful of values that vary per deployment +- The consumer provides **no AWS account, no VPC, no state backend, no runner key** — the platform owns the blast radius --- @@ -142,89 +117,26 @@ Every delivery action produces a **measurable, explainable confidence signal** --- -# Policy & Security Enforcement +# Security by Construction -Checks run on **every** deployment, normalized to a single schema regardless of which engine produced them. +Security defaults that **do not require a team to opt in.** Checks run on **every** deployment, normalized to a single schema. Testing -- **Infrastructure policy** (Checkov) — secrets in plaintext, public ingress, IAM wildcards, KMS references, **required tagging standards** (`acdl:owner`, `acdl:contract`, `acdl:environment`, `acdl:cost-center`) Testing -- **Cloud security posture** (Wiz adapter) — translates cloud security findings into the same normalized record Testing -- **Kubernetes-native policy** (Kyverno adapter) — ready for the GitOps reconciler Testing - -Every check produces a record with **severity, rule ID, pass/fail status, and a human-readable message** — consumed uniformly by the confidence signal. +- **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** --- -# Secure by Default - -Security defaults that **do not require a team to opt in.** Testing - -- **Encryption on every resource** — at-rest encryption on by default for every primitive (S3, RDS, ECR, ECS, and more) -- **Per-stack customer-managed keys** — one key per deployment, 90-day rotation, **no shared keys across stacks** -- **Managed-key fallback with a loud warning** — silent use of cloud-managed keys is a security gap we refuse to hide -- **Deletion protection on by default** — `prevent_destroy` on unless a consumer explicitly disables it via a documented flag -- **Safe decommission** — a 2-step pipeline (disable protection → zero counts → destroy) with **two SRE attestation gates** and a **change-request validated against the CMDB** - ---- - -# Immutable Audit & Evidence - -Version control is a **coordination tool, not an evidentiary fortress.** True compliance requires an immutable, externally-stored ledger. - -- **Every deployment writes a hash-chained evidence event** — each event links to the previous via a cryptographic hash; tampering breaks the chain Testing -- **Tiered storage:** cold, tamper-proof source of truth (S3 Object Lock, 7-year retention) + a hot query index Outbox tested Full ledger: planned -- **RPO = 0** — the evidence write is synchronous; a deployment is not acknowledged until the evidence event is durably recorded -- **Every production change is traceable to a human attestation** — approver identities are the only durable record outside the VCS's audit log - ---- - -# Human-in-the-Loop Where It Matters +# Accountability & Audit 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. Agentic -- **qa, prod, and dr require deliberate human attestation** — not rubber stamps, but policy-mandated acts of accountability via protected deployment approvals. -- **Separation of duties is enforced** — the QA approver **cannot** be the prod approver. The platform reads both identities from the outbox and **blocks on a match.** Design tested Wiring: planned -- **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.** 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 - ---- - -# 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 - ---- - -# Portability & Future-Proofing - -The platform is **opinionated, but not painted into a corner.** - -- **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.* 1 adapter: Terraform OpenTofu / Pulumi / K8s -- **VCS-agnostic contract ingestion.** The platform Lambda reads a configurable API base for GitHub or Gitea. Testing -- **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. Future capability Agentic +- **Dev is fully autonomous.** The confidence signal (≥ 0.50) is the only gate. Queue-based handoffs are eliminated. Agentic +- **qa, prod, dr require deliberate human attestation** — policy-mandated acts of accountability, not rubber stamps +- **Separation of duties is enforced** — the QA approver **cannot** be the prod approver. The platform **blocks on a match.** Design tested Wiring: planned +- **Every deployment writes a hash-chained evidence event** — tampering breaks the chain. **RPO = 0** — the evidence write is synchronous Testing +- **Every production change is traceable to a human attestation** — the only durable record outside the VCS's audit log --- @@ -256,7 +168,7 @@ li { margin-bottom: 2px; } - Deletion protection by default + safe decommission with SRE gates - Uptime monitoring deployed automatically with every stack - Platform-managed environments + friendly onboarding -- Local reproducibility + VCS-agnostic contract ingestion +- Engine-agnostic core (1 adapter: Terraform) + VCS-agnostic ingestion @@ -269,8 +181,24 @@ li { margin-bottom: 2px; } - Compliance milestone: GDPR, SOX, SOC2, DORA extension points - Environment self-service provisioning - Dynamic module creation from a contract (agentic citizen-developer flow) Agentic +- Pattern recognition compounds value over time Agentic - Additional engine adapters (OpenTofu, Pulumi, Kubernetes CRDs) +- Deeper observability bootstrap (dashboards, runbooks, on-call) - \ No newline at end of file + + +--- + + + + +# The Vision Realized + +- **Velocity without sacrificing safety.** Speed is in the ergonomics (a simple contract, a one-line `uses:`); safety is in the gates the consumer cannot bypass. +- **Security, observability, and compliance as platform defaults** — not per-team effort, not post-hoc remediation. Encryption, deletion protection, uptime monitoring, policy checks, and evidence are on by construction. +- **Auditability as a byproduct, not a project.** Every production change is traceable to a human attestation and a tamper-evident evidence event. +- **Blast radius contained by design.** Zero-trust OIDC + ABAC means a consumer can only touch its own tagged resources. +- **Infrastructure as a utility, not a craft.** The platform abstracts compute, networking, and state. Teams consume infrastructure, they don't maintain it. +- **A path to the citizen developer.** The same safety envelope that serves a senior engineer will serve a non-technical consumer — expanding who can ship safely without lowering the bar. Agentic \ 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 e552eba..9a3c21f 100644 --- a/docs/presentations/how-the-platform-works.html +++ b/docs/presentations/how-the-platform-works.html @@ -95,18 +95,26 @@ img { display: block; margin: 0 auto; max-height: 320px; } .testing { background: #DBEAFE; color: #1E3A5F; } .planned { background: #fef3c7; color: #78350f; } .agentic { background: #EDE9FE; color: #4C1D95; } -;" data-marpit-pagination-total="16"> +;" data-marpit-pagination-total="10">
How The Platform Works
-

The Problem We Solve

-

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

+

The Problem & The North Star

Four frictions slow every team:

+
+

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

+
+ -

The platform absorbs all four frictions.

+;" data-marpit-pagination-total="10">
How The Platform Works
-

The North Star

-
-

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

-
-

Success looks like:

+

The Contract-Driven Model

+

A single YAML contract is all a consumer writes — module, environment, inputs. The platform owns everything else.

+

    -
  • A merged change progresses through lower environments without a platform engineer joining a thread, approving a ticket, or triggering a stage.
    • -
  • A non-technical consumer ships a production deployment by declaring intent — without authoring a workflow, a configuration file, or an infrastructure module.
    • -
  • Every production change is traceable to a human attestation and an immutable evidence stream.
    • +
  • Which module — a catalog of pre-built, security-reviewed building blocks
    • +
  • Which environment — the platform raises the safety bar automatically as sensitivity rises
    • +
  • Which inputs — the handful of values that vary per deployment
    • +
  • The consumer provides no AWS account, no VPC, no state backend, no runner key — the platform owns the blast radius
Internal
@@ -203,20 +210,14 @@ img { display: block; margin: 0 auto; max-height: 320px; } .testing { background: #DBEAFE; color: #1E3A5F; } .planned { background: #fef3c7; color: #78350f; } .agentic { background: #EDE9FE; color: #4C1D95; } -;" data-marpit-pagination-total="16"> +;" data-marpit-pagination-total="10">
How The Platform Works
-

What This Platform Is — and Isn't

-

What it is:

+

The End-to-End Flow

+

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

+

    -
  • 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.
    • +
  • Security and policy checks run before any infrastructure is created
    • +
  • Every stage produces a record that feeds the confidence signal and the evidence stream — there is no "unchecked" path
Internal
@@ -260,17 +261,20 @@ img { display: block; margin: 0 auto; max-height: 320px; } .testing { background: #DBEAFE; color: #1E3A5F; } .planned { background: #fef3c7; color: #78350f; } .agentic { background: #EDE9FE; color: #4C1D95; } -;" data-marpit-pagination-total="16"> +;" data-marpit-pagination-total="10">
How The Platform Works
-

The Contract-Driven Model

-

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

-

-

The contract names three things:

+

Zero-Trust by Default

+

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

    -
  • Which module — a catalog of pre-built, security-reviewed building blocks
    • -
  • Which environment — the platform raises the safety bar automatically as sensitivity rises
    • -
  • Which inputs — the handful of values that vary per deployment
    • +
  • 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.

Internal
-
How The Platform Works
-

The End-to-End Flow

-

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

-

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

Zero-Trust by Default

-

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

-
    -
  • Authentication — OIDC federation. Each job mints a short-lived token; no credential is stored in the consumer repo or in a runner secret. 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.

-
Internal
-
-
+;" data-marpit-pagination-total="10">
How The Platform Works

Safety is Computed, Not Assumed

Every delivery action produces a measurable, explainable confidence signal — the platform's certified answer to "is this safe to proceed?" Agentic

@@ -465,7 +362,7 @@ img { display: block; margin: 0 auto; max-height: 320px; }
Internal
-
+;" data-marpit-pagination-total="10">
How The Platform Works
-

Policy & Security Enforcement

-

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

+

Security by Construction

+

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

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

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

-
Internal
-
-
-
How The Platform Works
-

Secure by Default

-

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

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

Immutable Audit & Evidence

-

Version control is a coordination tool, not an evidentiary fortress. True compliance requires an immutable, externally-stored ledger.

-
    -
  • Every deployment writes a hash-chained evidence event — each event links to the previous via a cryptographic hash; tampering breaks the chain Testing
    • -
  • Tiered storage: cold, tamper-proof source of truth (S3 Object Lock, 7-year retention) + a hot query index Outbox tested Full ledger: planned
    • -
  • RPO = 0 — the evidence write is synchronous; a deployment is not acknowledged until the evidence event is durably recorded
    • -
  • Every production change is traceable to a human attestation — approver identities are the only durable record outside the VCS's audit log
    • -
-
Internal
-
-
-
How The Platform Works
-

Human-in-the-Loop Where It Matters

+

Accountability & Audit

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. Agentic
    • -
  • qa, prod, and dr require deliberate human attestation — not rubber stamps, but policy-mandated acts of accountability via protected deployment approvals.
    • -
  • Separation of duties is enforced — the QA approver cannot be the prod approver. The platform reads both identities from the outbox and blocks on a match. Design tested Wiring: planned
    • -
  • Timeout discipline — 1 business day = warn + escalate; 2 business days = auto-freeze + re-submit
    • +
  • Dev is fully autonomous. The confidence signal (≥ 0.50) is the only gate. Queue-based handoffs are eliminated. Agentic
    • +
  • qa, prod, dr require deliberate human attestation — policy-mandated acts of accountability, not rubber stamps
    • +
  • Separation of duties is enforced — the QA approver cannot be the prod approver. The platform blocks on a match. Design tested Wiring: planned
    • +
  • Every deployment writes a hash-chained evidence event — tampering breaks the chain. RPO = 0 — the evidence write is synchronous Testing
    • +
  • Every production change is traceable to a human attestation — the only durable record outside the VCS's audit log
Internal
-
-
How The Platform Works
-

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
    • -
-
Internal
-
-
-
How The Platform Works
-

Platform-Managed Environments

-

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

-

A named environment is a platform-owned bundle of:

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

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

-

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

-
Internal
-
-
-
How The Platform Works
-

Portability & Future-Proofing

-

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

-
    -
  • 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. 1 adapter: Terraform OpenTofu / Pulumi / K8s
    • -
  • VCS-agnostic contract ingestion. The platform Lambda reads a configurable API base for GitHub or Gitea. Testing
    • -
  • 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. Future capability Agentic
    • -
-
Internal
-
-
Agentic +
  • Pattern recognition compounds value over time Agentic
  • Additional engine adapters (OpenTofu, Pulumi, Kubernetes CRDs)
    • +
  • Deeper observability bootstrap (dashboards, runbooks, on-call)
    • -
    Internal
    + +
    Internal
    +
    +
    +
    How The Platform Works
    + +

    The Vision Realized

    +
      +
    • Velocity without sacrificing safety. Speed is in the ergonomics (a simple contract, a one-line uses:); safety is in the gates the consumer cannot bypass.
      • +
    • Security, observability, and compliance as platform defaults — not per-team effort, not post-hoc remediation. Encryption, deletion protection, uptime monitoring, policy checks, and evidence are on by construction.
      • +
    • Auditability as a byproduct, not a project. Every production change is traceable to a human attestation and a tamper-evident evidence event.
      • +
    • Blast radius contained by design. Zero-trust OIDC + ABAC means a consumer can only touch its own tagged resources.
      • +
    • Infrastructure as a utility, not a craft. The platform abstracts compute, networking, and state. Teams consume infrastructure, they don't maintain it.
      • +
    • A path to the citizen developer. The same safety envelope that serves a senior engineer will serve a non-technical consumer — expanding who can ship safely without lowering the bar. Agentic
      • +
    +
    Internal