acdl/docs/architecture-v1.0.md

# Architecture Document v1.0

> **Snapshot status:** v1.0 — taken in ACDL Phase 07 (milestone v1.1).
> All 11 open decisions in §13 are **resolved** — see `PROJECT.md`
> "Open-decision resolutions" table + decisions D-034..D-046.
> The body §§1-12 is copied verbatim from the upstream
> `docs/architecture.md` v0.2; only the header status line, the resolution
> session log, §13, §14, and the new §15 are Phase 07 additions. The
> `act_runner` → `gitea-runner` rename (D-046, 2026-04 in gitea/runner#850)
> is applied; `act_runner` appears only in a "formerly" note.

# Agentic Cloud Delivery Platform — Architecture Document

Status: **v1.0** (snapshot taken in ACDL Phase 07, milestone v1.1). All 11
open decisions in §13 are resolved — see `PROJECT.md` "Open-decision
resolutions" table + decisions D-034..D-046.

Companion to: Agentic Cloud Delivery Vision [1].

Authoring principle: The vision is the source of truth for why [1]; this document is the source of truth for how. Where the two conflict, the vision wins.

Resolution session log (v1.0 snapshot — see PROJECT.md for full text):

| ID | Question | Resolution (one-line — see PROJECT.md for rationale) |
|---|---|---|
| W1.A | AI-refinement trigger | ✅ RESOLVED — joint condition: N ≥ 50 consecutive zero-rollback changes AND no L1/L2 incident in 6 months AND Infra & Ops unilateral override. |
| W1.B | Multi-stack edge case rule | ✅ RESOLVED — permitted only for (a) DR-region mirror, (b) time-boxed experimental stack TTL ≤ 30d, (c) explicit Infra & Ops approval with `multiStack.justification`. |
| W2.A | Tag mutability for prod | ✅ RESOLVED — Path B: tag for dev/qa, SHA for prod; platform CLI resolves tag→SHA. |
| W3.D | L1/L2 standard versioning | ✅ RESOLVED — semver (interface→MAJOR, behavior→MINOR, lifecycle→PATCH); L2 pins L1 by `name@semver`; MAJOR bump = new registry entry + 12-month deprecation. |
| W3.E | Schema mandatory vs. optional inputs | ✅ RESOLVED — dev: stack+environment; qa adds validation.e2eSuite+loadTest; prod adds runbook+dashboard+oncall; dr adds drDrillRef; `inputs` always optional; `profile: agentic` fields optional everywhere (naturalLanguageIntent required when profile is agentic). |
| BA.A | Initial L3B skill catalog | ✅ RESOLVED — 5 skills: web API, worker, scheduled job, static asset, basic observability bootstrap; addition criteria: (a) sensitive-data reviewable, (b) single contract submission, (c) documented use case. |
| BA.B | Confidence threshold tuning | ✅ RESOLVED — thresholds frozen for v1; tuning begins v1.2 (quarterly FP/FN tracking; override = Infra & Ops + SRE joint sign-off, itself a confidence-event). |
| BA.C | On-call / operational ownership | ✅ RESOLVED — platform on-call = Infra & Ops; L3A/L3B halt → platform on-call (Sev2); consumer-visible outage → consumer on-call (Sev1) + platform support. |
| BA.D | Cost / capacity governance | ✅ RESOLVED — FinOps owns cloud cost; per-contract monthly reporting; runaway spend hard-halts at 120% of declared budget via the confidence signal; override = FinOps + SRE joint sign-off. |
| BA.E | Consumer onboarding | ✅ RESOLVED — developer (L3A): `getting-started` → contract schema + central pipeline template; citizen (L3B): scoped agent + skill catalog, no workflow authoring; both end in a sandbox dev submission that must pass the confidence gate. |
| BA.F | Cross-platform evolution | ✅ RESOLVED — contract schema, stack, PolicyCheckResult, confidence signal, audit stream are portable (forge-agnostic); forge-specific code = workflow YAML, OIDC trust, CODEOWNERS, Environments; a second forge needs a forge adapter + workflow-template translator, no change to L1/L2/stack/confidence/audit. |
| Q1.3 | OpenTofu timing | ✅ RESOLVED (deferred) — not in v1 or v1.1; the substrate abstraction (§12) makes OpenTofu a future adapter, not an architecture change; revisit when an OpenTofu adapter is requested. |

---

## 0. Purpose

This document encodes the architectural commitments that realize the vision [1]. The resolution session has closed eight open items; the document is now at v0.2 with eleven open items remaining, listed in Section 13. Every locked commitment is grounded in either a vision tenet or a specific decision made during resolution.

The structure remains: four layers (L1 primitives, L2 composed stacks, L3A developer surface, L3B agentic surface) plus five cross-cutting concerns (central pipeline, contract schema, confidence signal, audit stream, HITL mechanics), with one addition: the substrate abstraction layer (Section 12) is now a first-class architectural concern, not an implementation detail.

## 1. Architectural Overview

The platform remains four layers and five cross-cutting concerns. The substrate abstraction is added as a sixth cross-cutting concern in Section 12 because it is the binding constraint for the L1/L2 model, the central pipeline, and the policy toolchain.

The vision's "Two Consumer Surfaces, One Platform" tenet [1] remains the constraint that binds all concerns: L3A and L3B converge on the same contract schema, the same policy envelope, and the same evidence stream.

Locked additions this revision:

- The environment model is dev (autonomous) → qa (QA HITL) → prod (SRE HITL) → dr (SRE HITL). Staging does not exist.

- L1/L2 are substrate-agnostic in shape; substrate adapters are the only substrate-specific component.

## 2. Layer 1 — Foundational Primitives

Purpose. Single-purpose, substrate-agnostic primitive modules representing the smallest reusable infrastructure pieces. L1 modules do not compose with other L1 modules; L1 takes its environment as input.

Locked commitments (unchanged from v0.1):

- No inter-L1 references. L1 may call Terraform data sources.

- Semver with three triggers (interface → MAJOR, behavior → MINOR, lifecycle → PATCH).

- Immutability on publication.

- 12-month deprecation window.

- AI refinement is a flag.

✅ RESOLVED (see PROJECT.md W1.A): AI-refinement operational trigger — joint condition: N ≥ 50 consecutive changes with zero rollbacks AND no L1/L2 incident in last 6 months AND Infra & Ops holds a unilateral override.

✅ RESOLVED (sub-decision): The L1 module's interface field is defined against the Target Stack, not against Terraform's variable block directly. In v1, the stack is shaped to round-trip cleanly to Terraform, but the schema is substrate-agnostic. Pending v1 implementation details in Section 12.

## 3. Layer 2 — Composed Stacks

Purpose. Combine L1 primitives into deployable infrastructure shapes. Each codebase maps to one canonical L2 stack; the stack is either a parameterized module (Shape X) or a thin-composition layer (Shape Y).

Locked commitments (unchanged from v0.1):

- 1 codebase = 1 L2 stack (default), with multiStack: true for exceptions.

- Shape X or Shape Y.

- Hierarchical composition, max depth 5, only registered L1s.

- Pipeline quality checks: secrets-in-plaintext, public ingress, IAM wildcard, KMS key reference, tag compliance, naming convention.

- Restricted from thin-composition: IAM principal creation, network boundary creation, key/secret creation, external data transfer.

- Auto-promote after 3 observed usages.

✅ RESOLVED (see PROJECT.md W1.B): Multi-stack edge case rule — permitted only for (a) DR-region mirror, (b) time-boxed experimental stack with TTL ≤ 30 days, (c) explicit Infra & Ops approval for a documented reason captured in multiStack.justification.

✅ RESOLVED (sub-decision): The L2 composition tree's wires field is defined against the stack's relationship type, not against a Terraform module block. The stack → Terraform translation is the Terraform adapter's job (Section 12). The composition pipeline itself is substrate-agnostic.

## 4. Layer 3A — Developer Consumer Surface

Locked commitments (unchanged from v0.1):

- Tag-based reference to the central pipeline template.

- Developer-owned workflow file, no platform auto-sync.

- L3A and L3B are parallel paths, not a progression.

✅ RESOLVED (see PROJECT.md W2.A): Tag mutability for production-bound references — Path B (tag for dev/qa, SHA for prod). The platform provides a CLI command that resolves the current tag to its SHA for prod-bound workflows.

## 5. Layer 3B — Agentic Consumer Surface

Locked commitments (unchanged from v0.1):

- Hybrid runtime, skill as markdown, agent as executor.

- Trust model: trust and always verify on the platform side.

- Skill envelope (4 dimensions).

- Stateless agents, all state in the platform.

Environment progression — locked (this revision):

| Environment | Autonomy | Attester | Gate |
|---|---|---|---|
| dev | Full autonomy (no HITL) | — | Confidence signal ≥ 0.50, all six inputs present |
| qa | Held for attestation | QA | GitHub Deployment approval + full QA matrix (see §10) |
| prod | Held for attestation | SRE | GitHub Deployment approval + full SRE matrix (see §10) |
| dr | Held for attestation | SRE | GitHub Deployment approval + dr-drill evidence (see §10) |

Staging is removed. Dev is the only autonomous environment and absorbs integration, contract, security smoke, and performance smoke validation. The CDLC reference document's environment model is a doc-sync item flagged at the top of this document.

Profile marker: profile: agentic unlocks L3B-specific fields naturalLanguageIntent, confidenceAtSubmission, agentTrace).

✅ RESOLVED (see PROJECT.md BA.A): Skill catalog — initial set: web API, worker, scheduled job, static asset, basic observability bootstrap. Addition criteria: (a) reviewable for sensitive data, (b) expressible as a single contract submission, (c) documented use case.

## 6. Cross-Cutting — Central Pipeline Template

Locked commitments (unchanged from v0.1):

- JSON Schema (draft 2020-12) with thin domain-specific wrapper.

- Central repo + generated client libraries.

- Multi-stage validation pipeline (schema → policy → NFR → confidence).

- Distributed enrichment.

- GitOps reconciler + Terraform execution layer.

Locked additions this revision:

- The GitOps reconciler is the platform's K8s API. The cdlc-gitops repository's state materializes into K8s CRDs (ArgoCD Applications or Flux Kustomizations) that the reconciler watches. This is the platform's internal state surface.

- The pipeline emits a PolicyCheckResult record per policy rule evaluated. The confidence signal consumes these as one normalized input (Section 8).

✅ RESOLVED (see PROJECT.md W3.D): L1/L2 standard versioning details — semver (interface→MAJOR, behavior→MINOR, lifecycle→PATCH); L2 contracts pin L1 by `name@semver`; the resolver picks the highest compatible; MAJOR bumps require a new registry entry (immutable publication); old entry enters a 12-month deprecation window.

✅ RESOLVED (see PROJECT.md W3.E): Schema mandatory vs. optional inputs — dev requires stack+environment; qa adds validation.e2eSuite + validation.loadTest; prod adds runbook + dashboard + oncall; dr adds drDrillRef; `inputs` always optional; `profile: agentic` fields optional everywhere (naturalLanguageIntent required when profile is agentic).

## 7. Cross-Cutting — Contract Schema

Locked commitments (unchanged from v0.1):

- Central repo + generated client libraries.

- Strict fail-fast at schema stage, multi-stage validation pipeline with reason codes from a published vocabulary.

✅ RESOLVED (see PROJECT.md W3.E): Schema mandatory vs. optional inputs. The CDLC reference contract example [1] is illustrative; the v1 contract schema has explicit per-field mandatory/optional declarations per environment.

## 8. Cross-Cutting — Confidence Signal

Locked commitments (unchanged from v0.1):

- Six canonical inputs.

- Weighted sum with per-input breakdown.

- Per-environment thresholds: dev ≥ 0.50, qa ≥ 0.75, prod ≥ 0.90, dr ≥ 0.95.

- Structured output { score, band, perInput, reasonCodes }.

- 1-year storage, no algorithm retraining in v1.

- Halt with explicit reason on missing input.

Locked additions this revision:

- The policy check results input is a list of PolicyCheckResult records from the normalized schema (Section 9, 12). The signal does not know which engine produced which result.

- Severity → score penalty mapping: critical → hard override to mandatory block, high → -0.2, medium → -0.05, low → -0.01, info → 0.0. One critical finding hard-overrides the score regardless of all other inputs.

✅ RESOLVED (see PROJECT.md BA.B): Threshold tuning policy. Thresholds frozen for v1. Tuning begins v1.2: quarterly FP/FN tracking per environment; override authority = Infra & Ops + SRE joint sign-off; any override is itself a confidence-event in the audit stream.

## 9. Cross-Cutting — Audit and Evidence Stream

Locked commitments (unchanged from v0.1):

- Tiered audit ledger: S3 with Object Lock in compliance mode (cold, source of truth, 7-year retention) + GitHub audit repo (hot, query index, not part of the chain).

- Daily checkpoints.

- Event schema: JWS detached signature, prev_event_hash chain, controlled-vocabulary event_type.

- Outbox pattern with local durable outbox + async worker.

- Linkage via workflow run ID or agent invocation ID.

Locked additions this revision:

- The outbox database is DynamoDB. RPO is zero (synchronous write to local outbox before contract submission ack); RTO is the async worker's recovery from the dead-letter queue. Single-region in v1; multi-region is a v2 concern.

- The outbox also stores the per-contract QA and prod approver identities (Section 10). The platform-internal identity-distinctness check reads from this outbox. This is the only durable record of the approver identities outside GitHub's audit log.

## 10. Cross-Cutting — Human-in-the-Loop Mechanics

Purpose. The human gates at higher environments. The vision's "Lower Environments are Autonomous; Higher Environments are Attested" tenet [1] and the "deliberate human attestation — not as a rubber stamp" requirement [1] are the binding constraints.

### 10.1 Gate model

Pre-execution gates. The contract is held in a "validated but not applied" state until the human attests. qa, prod, and dr are PR-based attestation gates backed by GitHub Environments with required reviewers.

For qa and prod, there is no partial deployment to roll back on rejection. For dr, the same model — promotion to the DR environment is a separate GitHub Deployment, gated by SRE, against a separate cluster/region. The canary/deployment-rollback model is explicitly not in scope for v1.

### 10.2 Reviewer routing

GitHub CODEOWNERS + GitHub Environment required reviewers. qa → QA team; prod → SRE team; dr → SRE team. CODEOWNERS is the routing layer; it does not enforce identity distinctness.

### 10.3 Separation of duties — identity distinctness

Mechanism is platform-internal, not GitHub-native, not Kyverno (in v1).

Sequence:

1. On promotion dev → qa, the platform reads the QA approver's GitHub identity from the GitHub Deployment approval event and writes it to the DynamoDB outbox keyed by contractId.

2. On promotion qa → prod, the platform reads the stored QA approver identity from the outbox and the new SRE approver identity from the GitHub Deployment approval event.

3. If qaApprover == prodApprover, the platform blocks the prod promotion, writes a SEPARATION_OF_DUTIES_VIOLATION event to the evidence stream, and routes a halt artifact to the SRE on-call.

4. The check is implemented in the central pipeline repo, not as an external policy. The platform is the only writer to the outbox; the check is in the same process that has authority to block the promotion.

### 10.4 Full HITL attestation matrix

| Env | Concern | Evidence artifact | Freshness | Source | Attester |
|---|---|---|---|---|---|
| qa | Functional correctness | Last successful run of contract-declared validation.e2eSuite with pass rate ≥ 99% | Last 24h | Test runner declared in contract | QA |
| qa | Performance baseline | Load test report (k6 / Gatling / Locust) showing p99 latency < declared NFR and throughput > declared minimum | Last 7d | Load test runner declared in contract | QA |
| qa | Security posture | Vulnerability scan (Trivy, Snyk, or contract-declared equivalent) with no criticals/highs, signed by Security on-call | Last 24h | Security scanner + Security team signature | QA |
| qa | Contract NFRs | Platform-generated report: schema valid, NFR assertions (latency, throughput, error rate) within declared bounds | At submission | Platform contract validator | QA |
| prod | Operational readiness | Runbook published, dashboard exists, on-call rotation assigned, alerts configured | At submission, validated against last 30d history | Platform + SRE | SRE |
| prod | Incident response | Sev-1 runbook tabletop or live drill completed | Last 90d | SRE drill record | SRE |
| prod | Capacity / cost | FinOps forecast for next 30d within budget envelope, cost anomaly baseline stored, budget alert configured | Forecast valid for next 30d | FinOps + SRE | SRE |
| prod | Resilience | DR drill, chaos engineering report, backup verified | DR: 180d; chaos: 90d; backup: 30d | SRE + Platform | SRE |
| dr | dr-region deploy with the most recent prod-bound dr drill as canary evidence | dr drill report | Last 180d | SRE | SRE |

### 10.5 Timeout behavior

| Time | State | Action |
|---|---|---|
| Submission | PENDING_ATTESTATION | Notify responsible team |
| 1 business day | PENDING_ATTESTATION_WARNING | Notify team + platform on-call (elevated path); emit PENDING_ATTESTATION_TIMEOUT_WARNING event |
| 2 business days | PENDING_ATTESTATION_AUTO_FREEZE | Auto-freeze; require re-submission; emit PENDING_ATTESTATION_AUTO_FREEZE event; new submission linked via supersedes |

### 10.6 Rejection and rollback

Rejection returns the contract to a HELD state with the rejection reason captured as a PROMOTION_REJECTED event. The consumer fixes the cause and re-submits; the new submission is linked to the rejected one via supersedes. The audit chain is extended, not torn up — matching the resolution session's answer.

There is no partial deployment to roll back at any v1 gate.

## 11. Cross-Cutting — Agentic Stack

Locked commitments (unchanged from v0.1):

- Hybrid runtime, platform-managed control plane + consumer-owned agent.

- Versioned, signed skill catalog over MCP.

- Skill envelope enforced on invocation and result submission.

- Consumer-owned skill execution environment. Platform does not run the skill.

- Stateless agents, all state in the platform.

Locked additions this revision:

- Skills are reviewed for sensitive data before release. Secrets, customer data, internal IPs, and other sensitive payloads are forbidden in skill markdown. The review is owned by Infra & Ops and is the mandatory release gate for any new skill. This is the trade-off for accepting the L3B runtime threat model (skill content is consumer-readable, so the platform must not put anything sensitive in it).

✅ RESOLVED (see PROJECT.md BA.A): Skill catalog — initial set, addition process, deprecation process per the resolution.

## 12. Cross-Cutting — L1/L2 Substrate Execution

Purpose. The technical execution layer for the L1/L2 substrate, including the substrate abstraction that protects v1 from polyglot mess while leaving v2+ room to grow.

### 12.1 Substrate abstraction (locked this revision)

L1/L2 are substrate-agnostic in shape. The architecture defines a Target Stack — a substrate-neutral description of:

- Resources with typed input contracts, typed output contracts, and declared NFRs.

- Relationships (single parent per child, with a shared keyword for multi-relationship dependencies).

- Composition (a tree of resources with max depth 5).

- Policy hooks (the points in the composition where policy checks attach).

The L1 registry, the L2 thin-composition tree, the YML standard, and the policy check result schema are all defined against the stack schema. None of them is defined against any specific substrate.

Substrate adapters are the only substrate-specific code. An adapter compiles the stack into a substrate execution plan. v1 ships exactly one adapter: the Terraform adapter. v2+ may add additional adapters (OpenTofu, Pulumi, K8s CRDs) without architectural change.

v1 implementation reality: the stack is shaped to round-trip cleanly to Terraform because there is no other adapter to differentiate from. The stack and the Terraform output are nearly isomorphic in v1. As additional adapters appear in v2+, the stack gets more expressive (e.g., substrate-specific output types) and the adapters gain translation logic, but the L1 module content, the YML standard, and the composition tree do not change. This is the design that prevents the polyglot mess.

Why not build the abstraction earlier? Building a substrate-agnostic stack before there is a second adapter to test against is speculative generality. The v1 commitment is: (1) the L1 module interface is defined against the stack schema even though the only adapter is Terraform, and (2) the central pipeline, registry, and policy schema consume the stack-typed contracts. The adapter is the only place where substrate terminology appears in v1.

### 12.2 Terraform adapter (v1)

The Terraform adapter:

- Translates the stack-typed L1 module interface to a Terraform variable block and a Terraform output block.

- Translates the stack-typed L2 composition tree to a Terraform root module that calls the L1 modules.

- Translates the stack-typed relationships to Terraform module references.

- Emits a Terraform plan from the stack.

The adapter is a thin layer. It does not own L1/L2 content; it only translates.

### 12.3 State storage

Locked: S3 (state files) + DynamoDB (state locking), cloud-managed. Single-region in v1.

### 12.4 Policy toolchain

Locked:

- Checkov for Terraform plan policy (the four L2 thin-composition checks: secrets-in-plaintext, public ingress, IAM wildcard, KMS key reference, plus tag and naming convention). Checkov is open-source, has a broad rule catalog, and is GitOps-friendly.

- Kyverno for K8s-native policy (platform-internal state in the GitOps reconciler, separation-of-dues-adjacent checks if any are added in v2, future CRD validation).

- OPA/Rego is reserved for cross-resource policy and is explicitly last resort due to Rego complexity.

### 12.5 Execution layer

Locked: GitHub Actions. terraform plan and terraform apply run in the central pipeline repo's GitHub Actions workflow. State locking via DynamoDB. AWS credentials via OIDC federation (long-lived credentials are forbidden). The platform does not run terraform apply against a developer's workstation; all execution is in the central pipeline.

> **ACDL Phase 07 note (D-039):** Gitea Actions (the ACDL forge) does not
> support `id-token: write` / OIDC token issuance as of Gitea 1.27.x /
> gitea-runner v2.1.0 (formerly `act_runner`, renamed 2026-04 in
> gitea/runner#850). The v1.1 spike uses a per-run-rotated long-lived key
> waiver; real OIDC federation is a v1.2 deliverable, blocked on
> go-gitea/gitea#36988. The §12.5 "long-lived credentials are forbidden"
> commitment is the locked target; the waiver is a time-boxed spike
> exception.

### 12.6 Policy result normalization (locked this revision)

The confidence signal does not consume raw Checkov or Kyverno output. It consumes a normalized PolicyCheckResult schema produced by substrate-specific adapters.

Schema (canonical form, lives in the central pipeline repo):

```json
{
  "contractId": "uuid",
  "evaluatedAt": "ISO-8601",
  "engine": "checkov | kyverno | opa",
  "ruleId": "CKV_AWS_24 | KYVERNO_NO_PRIVILEGED | ...",
  "severity": "critical | high | medium | low | info",
  "result": "pass | fail | skipped | error",
  "message": "human-readable",
  "evidence": { "...engine-specific payload, opaque to the signal..." },
  "resourceRef": "stack-typed resource identifier"
}
```

The Checkov adapter runs in the same GitHub Actions step as Checkov itself and translates Checkov JSON to PolicyCheckResult records. The Kyverno adapter runs as a controller in the platform's K8s cluster and translates Kyverno PolicyReport CRDs to PolicyCheckResult records. The confidence signal's policy input component is the union of all PolicyCheckResult records, regardless of engine. The signal does not know which engine produced which result — substrate-agnostic over its inputs, matching the L1/L2 model's substrate-agnostic over its outputs.

### 12.7 Registry maintenance

Locked: L1 module publication updates the L1 registry in the same PR as the module. Registry and module land together. The registry is the stack-typed contract, not a Terraform-specific variable schema. The L1 registry, the central pipeline, and the policy schema all consume the same stack-typed contract — there is one source of truth for the L1 interface, not multiple substrate-specific copies.

### 12.8 Contract-schema-to-stack resolution

The contract schema declares the consumer's intent in stack-typed terms. The central pipeline resolves the contract to a target stack (a list of L1 module instances with their inputs and the relationships between them). The Terraform adapter compiles the target stack to a Terraform execution plan. This resolution is substrate-agnostic — the target stack is in the stack schema.

## 13. Consolidated Open Design Decisions

✅ **All 11 decisions are RESOLVED (see PROJECT.md).** The §13 subsections
below preserve the upstream structure with the `🟡 OPEN` markers replaced
by `✅ RESOLVED (see PROJECT.md)`.

### From Wave 1 (L1/L2 Substrate)

- (W1.A) AI-refinement trigger. ✅ RESOLVED (see PROJECT.md) — joint condition: N ≥ 50 consecutive zero-rollback changes AND no L1/L2 incident in 6 months AND Infra & Ops unilateral override.

- (W1.B) Multi-stack edge case rule. ✅ RESOLVED (see PROJECT.md) — permitted only for (a) DR-region mirror, (b) time-boxed experimental stack TTL ≤ 30d, (c) explicit Infra & Ops approval with `multiStack.justification`.

### From Wave 2 (L3A/L3B)

- (W2.A) Tag mutability for production-bound references. ✅ RESOLVED (see PROJECT.md) — Path B (tag for dev/qa, SHA for prod) with platform-provided CLI to resolve tag → SHA.

### From Wave 3 (Technical Execution)

- (W3.D) L1/L2 standard versioning details. ✅ RESOLVED (see PROJECT.md) — semver (interface→MAJOR, behavior→MINOR, lifecycle→PATCH); L2 pins L1 by `name@semver`; MAJOR bump = new registry entry + 12-month deprecation.

- (W3.E) Schema mandatory vs. optional inputs. ✅ RESOLVED (see PROJECT.md) — per-env mandatory table (dev: stack+environment; qa adds validation.e2eSuite+loadTest; prod adds runbook+dashboard+oncall; dr adds drDrillRef); `inputs` always optional; `profile: agentic` fields optional everywhere.

### From Beyond Architecture

- (BA.A) Skill catalog. ✅ RESOLVED (see PROJECT.md) — 5 skills (web API, worker, scheduled job, static asset, basic observability bootstrap); addition criteria locked.

- (BA.B) Confidence signal threshold tuning. ✅ RESOLVED (see PROJECT.md) — frozen for v1; tuning begins v1.2 (quarterly FP/FN; override = Infra & Ops + SRE joint sign-off).

- (BA.C) On-call and operational ownership. ✅ RESOLVED (see PROJECT.md) — platform on-call = Infra & Ops; L3A/L3B halt → Sev2; consumer outage → Sev1.

- (BA.D) Cost and capacity governance. ✅ RESOLVED (see PROJECT.md) — FinOps owns; per-contract monthly reporting; hard halt at 120% of declared budget via the confidence signal; override = FinOps + SRE joint sign-off.

- (BA.E) Consumer onboarding. ✅ RESOLVED (see PROJECT.md) — developer (L3A): getting-started → contract schema + central pipeline template; citizen (L3B): scoped agent + skill catalog; both end in a sandbox dev submission that must pass the confidence gate.

- (BA.F) Cross-platform evolution. ✅ RESOLVED (see PROJECT.md) — contract schema, stack, PolicyCheckResult, confidence signal, audit stream are portable; forge-specific code = workflow YAML, OIDC trust, CODEOWNERS, Environments; a second forge needs a forge adapter + workflow-template translator.

- (Q1.3) OpenTofu timing. ✅ RESOLVED (deferred — see PROJECT.md) — not in v1 or v1.1; the substrate abstraction makes OpenTofu a future adapter, not an architecture change.

## 14. Document Status and Next Steps

Status: **v1.0**. All 11 open items in §13 are resolved. The architecture is
internally consistent; the v1.1 implementation spike (ACDL Phases 08-10)
validates the locked substrate abstraction + contract→stack→adapter path
against real AWS via a per-run-rotated key (D-039; OIDC deferred to v1.2).
The v1.2 build-out (S3 Object Lock, JWS, HITL wiring, L3B skill catalog,
Kyverno/OPA, real OIDC federation, multi-region) is design-authored in
Phase 07 and implemented post-spike.

Doc-sync items (out of scope of this document but flagged for the same change set):

- The CDLC reference document's environment model assumes staging exists. Path A invalidates that. The CDLC contract example's targetEnvironments: [staging, production] must be revised to [dev, qa, prod, dr].

## 15. Phase 07 authored artifacts

The 11 resolutions are recorded in `PROJECT.md` (decisions D-034..D-046 +
the "Open-decision resolutions" table). Phase 07 formalizes the locked
commitments into these schema/design files (landed in Waves 2-4 of
Phase 07):

| REQ | File | Owner persona |
|-----|------|--------------|
| REQ-17 | `schemas/stack.schema.json` | platform-engineer |
| REQ-18 | `schemas/policy_check_result.schema.json` + `adapters/terraform/policy/checkov_adapter.py` | security-engineer |
| REQ-19 | `platform/confidence_signal.py` | backend-engineer + security-engineer (co-authored) |
| REQ-20 | `platform/audit_ledger_design.md` | security-engineer |
| REQ-21 | `platform/hitl_matrix_design.md` + `platform/separation_of_duties.py` | security-engineer |
| REQ-22 | `schemas/contract.schema.json` | backend-engineer |

The spike scope (D-041, D-043) vs v1.2 build-out boundary for each design
is documented in the respective file.