How The Platform Works

How The Platform Works

Agentic Cloud Delivery Platform

Internal
How The Platform Works

The Problem We Solve

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

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.

The platform absorbs all four frictions.

Internal
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:

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

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

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

  • Six weighted inputs: policy conformance, validation, freshness, source provenance, history, NFRs
  • Per-environment thresholds that rise with sensitivity:
Environment Threshold Attester
dev ≥ 0.50 No one — autonomous
qa ≥ 0.75 QA
prod ≥ 0.90 SRE
dr ≥ 0.95 SRE + DR drill
  • A single critical finding hard-blocks the deployment — critical findings are not averaged away
  • When the platform halts, it gives a measured reason — never an opaque debugging exercise
Internal
How The Platform Works

Policy & Security Enforcement

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

  • Infrastructure policy (Checkov) — secrets in plaintext, public ingress, IAM wildcards, KMS references, required tagging standards (acdl:owner, acdl:contract, acdl:environment, acdl:cost-center) 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 defaultprevent_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
Internal
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

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

Testing vs. Planned

Testing (works internally, not yet released to consumers)

  • Contract-driven deploys with a versioned reusable workflow
  • Module catalog (primitives + modules) with validated examples
  • Zero-trust OIDC + ABAC on GitHub Actions runners
  • Security + policy checks before infra creation (Checkov; Wiz + Kyverno ready)
  • Confidence signal (6 inputs, per-env thresholds) gating promotion 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
  • Uptime monitoring deployed automatically with every stack
  • Platform-managed environments + friendly onboarding
  • Local reproducibility + VCS-agnostic contract ingestion

Planned (on the roadmap)

  • Real OIDC federation on all platform runners
  • HITL wiring for qa / prod / dr environments
  • Full regulatory ledger: S3 Object Lock + JWS signatures + daily checkpoints
  • Compliance milestone: GDPR, SOX, SOC2, DORA extension points
  • Environment self-service provisioning
  • Dynamic module creation from a contract (agentic citizen-developer flow) Agentic
  • Additional engine adapters (OpenTofu, Pulumi, Kubernetes CRDs)
Internal