4Substrate Completion

1. Why this step exists

Steps 0-3 deployed the substrate's foundations: human identity (SSO), state backend + permission boundary (bootstrap), KMS CMKs + tier roles (identity), and the network surface (VPC + NFW + endpoints). After Step 3 the substrate existed but the platform layer the vibe apps need was still empty: no audit storage, no observability, no guardrails, no Lambda execution roles, no AgentCore Memory or Gateway scaffolding.

Step 4 closes that gap. Six modules go in, each filling a specific Phase 1 plan deliverable. After this step, vibe apps have somewhere to write audit records, somewhere to read observability data from, guardrails enforced platform-wide, and execution roles ready to host Lambda functions.

2. What this step creates (6 modules)

module/platform/data

module/platform/observability

module/platform/guardrails

module/platform/memory

module/platform/gateway

module/platform/lambda-tools

3. Cost breakdown

4. How it was applied

Step 4 is the first multi-PR substrate change to go entirely through CI (the wired path from Step 3a). Five PRs landed across one session:

1. PR #2 — Six new modules + composition wiring + MODULES.md. Plan: 36 add, 62 change (tag enrichments), 0 destroy. Applied; hit three errors mid-flight.
2. PR #3 — Three fixes: PROMPT_ATTACK strength (AWS validation), GuardDuty S3 export deferred (requires audit CMK policy update), CloudTrail/data depends_on (bucket policy race).
3. PR #4 — Defer CloudTrail event_selectors (permission boundary denies cloudtrail:PutEventSelectors). Trail uses default management-events selectors for Phase 1.
4. PR #5 — Bootstrap permission boundary update: split DenyCloudTrailTampering into DenyCloudTrailHardTampering (StopLogging + DeleteTrail + RemoveTags on all trails) and DenyCloudTrailConfigTamperingOnNonProjectTrails (UpdateTrail + PutEventSelectors only on trails NOT matching ai-sandbox-*). Applied via laptop SSO admin — the boundary itself is a bootstrap-level concern by design.
5. Final apply — CI dispatched, succeeded: 0 added, 3 changed, 0 destroyed. Substrate complete.

Total elapsed time: ~1 hour of apply attempts + boundary update. Plan and review time excluded.

5. Verification (the 7 checks that passed)

# 1. CloudTrail logging
AWS_PROFILE=ai-sandbox aws cloudtrail get-trail-status \
  --name ai-sandbox-trail \
  --query '{IsLogging:IsLogging,LatestDeliveryTime:LatestDeliveryTime}'
# Expected: IsLogging=true, recent LatestDeliveryTime

# 2. GuardDuty detector active
AWS_PROFILE=ai-sandbox aws guardduty list-detectors
# Expected: array with one detector ID

# 3. Bedrock invocation logging
AWS_PROFILE=ai-sandbox aws bedrock get-model-invocation-logging-configuration \
  --query 'loggingConfig.cloudWatchConfig.logGroupName'
# Expected: "/aws/bedrock/invocations/ai-sandbox"

# 4. Bedrock guardrail READY
AWS_PROFILE=ai-sandbox aws bedrock list-guardrails \
  --query 'guardrails[?name==`ai-sandbox-default`].{Name:name,Status:status}'
# Expected: Status=READY

# 5. Audit S3 Object Lock
AWS_PROFILE=ai-sandbox aws s3api get-object-lock-configuration \
  --bucket ai-sandbox-audit-959228203854 \
  --query 'ObjectLockConfiguration.Rule.DefaultRetention'
# Expected: Mode=COMPLIANCE, Days=2555

# 6. Lockbox DDB
AWS_PROFILE=ai-sandbox aws dynamodb describe-table \
  --table-name ai-sandbox-lockbox-tokens \
  --query 'Table.{Status:TableStatus,SSE:SSEDescription.Status,Stream:StreamSpecification.StreamEnabled}'
# Expected: Status=ACTIVE, SSE=ENABLED, Stream=true

# 7. CloudWatch dashboards
AWS_PROFILE=ai-sandbox aws cloudwatch list-dashboards \
  --dashboard-name-prefix ai-sandbox
# Expected: 3 entries (operators, exec, audit)

6. How to view the work in AWS Console

7. Doctrine implications

The permission boundary defended itself

Four of the five PRs in this step exist because the bootstrap permission boundary refused operations that look reasonable but compromise audit guarantees. cloudtrail:PutEventSelectors denied. cloudtrail:DeleteTrail denied. guardduty publishing destinations require additional principal grants. Each refusal was the doctrine working as designed.

The boundary update in PR #5 wasn't a relaxation — it was a scope refinement. Hard tampering (StopLogging, DeleteTrail, RemoveTags) stays globally denied. Configuration tampering (PutEventSelectors, UpdateTrail) is now denied only on trails this project does not own. The deploy role can manage ai-sandbox-* trails as IaC requires; cannot touch other trails.

The substrate is now structurally watching itself

From this step forward, every API call is in CloudTrail (encrypted, 7-year Object Lock). Every Bedrock invocation is in CloudWatch (encrypted, 90-day retention). Every threat-class finding is in GuardDuty. Every workload that uses Bedrock goes through the guardrail. The substrate's "I know what I did" property is no longer aspirational.

Phase 1 / Phase 2 boundary is structural, not aspirational

The lockbox DDB table, the reveal Lambda execution role, the lockbox CMK, and the per-zone lockbox secrets are all provisioned. Phase 1 apps don't exercise them. When a Phase 2 PII workflow needs them, no substrate migration is required: the resources exist, the IAM patterns exist, the doctrine is documented. Phase 2 is feature work, not infrastructure work.

8. What actually happened during apply (5-PR saga)

One session, four apply failures, five PRs, one bootstrap update. Recorded honestly because the failures are themselves substrate validation.

9. What comes next

Substrate complete. Two things next, in this order:

1. Step 4.5 — Observability vibe app. Static HTML/JS on S3+CloudFront + Lambda backend + Cognito auth (manual enrollment with TOTP 2FA + future Identity Center federation as a parallel path). Reads from the CloudWatch dashboards and log groups deployed in this step. Three audience tabs: operators, exec, audit. The first real test that vibe apps can be built on the substrate.
2. Step 5 — NFW enforcement flip. nfw_enforcement_mode = "drop", dns_firewall_action = "BLOCK". Doctrine originally said "after 24-48h of real workload observation"; with no workloads yet, the SoR allowlist is design-correct rather than observation-tuned. Flipping now means future workloads deploy against the right enforcement floor instead of having to live through a transition. The obs app from Step 4.5 will let us watch the flip happen.

At Day 28 end (today), Phase 1 of the 60-day plan is structurally complete. Phase 2 (module library) is ~50% in the form of MODULES.md doctrine + vibecode SDK API surface defined. Phase 3 (three POCs) is 0%, but two are now identified (observability vibe app + Sales monthly reports). Phase 4 (observability pipeline) is ~70% — audit stream end-to-end live; dashboards exist but the polished exec-facing front end is what Step 4.5 delivers.