# Phase 3: the cloud enclave as code

The third phase moves the program onto a real cloud account, as code,
with the account's own posture held to the same standard as the code's.
This is the public plan, fixed before the work; discoveries during the
build become recorded decisions, not silent amendments.

## The shape

- An AWS Organization: a near-empty management account as billing and
  policy root, hardware-key credentials, no root access keys, root use
  alarmed; organizational units for workloads and sandbox; two service
  control policies to start, denying regions outside the home pair and
  denying root-user actions.
- Accounts persist, stacks are ephemeral: one sandbox member account
  stands, and the enclave inside it is destroyed and reapplied daily
  by script, so recovery is rehearsed by routine. An account-vending
  module exists from the start, because applications get vended
  accounts as the standing pattern.
- Budgets and alarms exist before any resource does.
- A generic platform repository holds the modules (organization,
  baseline, vending, network, deploy federation) with no application's
  name in them; applications consume versioned modules and keep their
  own glue.
- Terraform as the tool, for its adoption; state in versioned S3 with
  native locking; no stored cloud credential anywhere, humans through
  short-lived sessions and pipelines through OIDC federation into
  scoped roles.
- Control Tower declined deliberately: toil chosen over spend, because
  its per-account plumbing bills continuously while doing the
  instructive work invisibly, and the decision entry names what it
  would have provided so adopting it later stays an informed move.
- The cloud's own reviewers enabled as code: Config with a
  conformance baseline as the independent record of what exists,
  Security Hub's foundational standard, the organization access
  analyzer, GuardDuty on the sandbox, and drift detection on a weekly
  schedule, because a plan is a claim and the account is the fact.

## The subphases

1. **Baseline and organization.** The platform baseline document
   written first, every row checked, attested, or accepted; then the
   organization, identity, budgets, guardrails, and the sandbox
   account; a threat model revision for the new surfaces.
2. **The platform repository.** Born fully governed; the foundation
   applied from a short-lived session: state backend, deploy
   federation, the organization trail into a locked bucket, the
   registry, and the reviewers above.
3. **The enclave, ephemeral.** The network module without standing
   cost traps, the vending module proven by vending one account, the
   daily destroy-apply drill scripted and timed, and the pipeline
   pushing the application's image to the registry through
   federation, with no key existing anywhere to steal.
4. **The trail meets the application.** The organization trail
   queryable; creator attribution enters the application's design
   file-first; the sample account generator gains a deterministic
   scale mode, and the inventory gains the pagination that thousands
   of identities require.
5. **Proof.** Rebuild from the documents alone, the first bill against
   the budget, baseline attestations current, findings triaged to
   fixed or accepted, diagrams and documents updated.

## What this phase deliberately does not do

No production traffic, no real identities, no live provider connection
from the application yet, and no managed Kubernetes, which is the next
phase's move of a workload the local cluster already proved.
