Release 1 delivery-readiness architecture

Reviewers can trace approved design, C4 boundaries, rendering, tooling, physics, source anchors, and channel acknowledgements from the Release 1 human review reference.

Current verdict

The approved Release 1 architecture boundary is coherent, but the release is not ready for implementation admission or promotion. Execution history and governance approval are separate:

• all 49 Release 1 FR/NFR records remain Proposed;
• all 49 have links to Done or ToBeReleased Tasks;
• 40 requirements link only to historical Done Tasks;
• nine requirements (FR-0002, FR-0009, FR-0019, FR-0021, FR-0023, FR-0024, FR-0054, FR-0055, FR-0058) include current ToBeReleased work;
• Task execution never approves a Feature, accepts a requirement, proves current runtime use, or authorizes release acceptance.

AEROSIM-FT-44 and FR-0051 are the clearest example. Socket.IO contract, gateway, client, and tests exist as historical implementation evidence, but the active Web flight path does not instantiate that client and the API has no production command forwarder. The route remains authenticated, exposed, and fail-closed scaffolding.

The Release 1 UI/UX and NFR alignment ledger separately proves current bidirectional Task/design-package links, exposes each applicable NFR without changing its status, and preserves deferred accessibility as proposal-only scope.

Requirement disposition prepared after Scope

The complete Option A decision-ready draft expands this disposition into exact Feature, requirement, Task, C4, interface, risk, allocation, and implementation-decision inputs. It is preparation only and creates no approval.

If Scope selects the recommended disposition, Architecture can record this exact follow-up without redesign:

1. approve 47 unchanged Release 1 requirements as solution requirements, without inferring implementation or release acceptance;
2. narrow FR-0040 with AEROSIM-FT-33 to governed free-flight and resumable-state persistence, excluding guided-training progression;
3. defer FR-0051 with AEROSIM-FT-44 from the active Release 1 flight path;
4. retain NFR-0007 for the remaining engineering Features while removing deferred AEROSIM-FT-44 from its active Release 1 allocation;
5. keep candidate evidence, authenticated UAT, promotion, Task closure, and product acceptance as independent gates.

No requirement status changes until the exact Scope decision is attributable.

Corrective control Feature required

Appending late remediation Tasks directly to AEROSIM-FT-43 would retroactively change dependency semantics for already completed work. Combining data, recovery, and operability into the one remaining AEROSIM-FT-53 Task slot would be unreviewable. The shortest sound model is one new Scope-owned corrective Feature:

Proposed AEROSIM-FT-56 — Establish Release 1 production resilience controls

Parent: AEROSIM-EP-1

State: proposal only; Scope approval required

Target: Release 1 corrective candidate; Releases assigns the immutable identity

Proposed outcomes:

1. every Release 1 pilot-data class has an attributable lifecycle policy and subject-scoped export, deletion, retention, expiry, hold, and audit behavior;
2. PostgreSQL uses approved least-privilege identities and transport security, and an encrypted backup restores into isolation within approved RTO/RPO;
3. the immutable candidate is qualified against approved service objectives, capacity, dependency-aware readiness, observability, incident objectives, and failure-domain evidence.

Architecture task packages

The identifiers below are proposed and become canonical only after Scope creates and approves AEROSIM-FT-56 and the repository allocator confirms they remain available.

Proposed TASK-0168 — Define and enforce the pilot-data lifecycle contract

• KDD: KDD-R1-04
• Depends on: TASK-0020
• Inputs requiring decisions: data classes, owners, classification, numeric retention, export/deletion obligations, holds, audit retention, and backup-expiry treatment.
• Outputs: machine-testable lifecycle matrix; subject-scoped export, deletion, expiry, and non-sensitive audit evidence.
• Verification: disposable-PostgreSQL tests for completeness, cross-pilot denial, idempotency, rollback, expiry, holds, and log redaction.
• Fail closed: no guessed policy values and no claim of completion after partial export or deletion.

Proposed TASK-0169 — Harden PostgreSQL access, transport, backup, and recovery

• KDD: KDD-R1-04
• Depends on: proposed TASK-0168
• Inputs requiring decisions: owner/migrator/backup/runtime privilege model, TLS or bounded residual-risk decision, rotation, backup cadence/storage/encryption/retention, RTO, and RPO.
• Outputs: least-privilege database access; approved transport boundary; encrypted backup and isolated restore path.
• Verification: negative SQL privileges; TLS rejection cases; identified backup restored into isolation with schema, integrity, pilot-isolation, API-readiness, and timed RTO/RPO evidence.
• Fail closed: PVC durability, pod restart, migrations, or an untested backup are not recovery evidence.

Proposed TASK-0170 — Establish and prove production service objectives and operability

• KDD: KDD-R1-05
• Depends on: TASK-0052, TASK-0130, and proposed TASK-0169
• Inputs requiring decisions: availability, latency, error-rate, capacity, saturation, detection, acknowledgement, containment, restoration, escalation, telemetry retention, and failure-domain posture.
• Outputs: SLI/SLO catalogue, bounded-cardinality telemetry, dashboards, alerts, responders, runbooks, capacity evidence, dependency-aware release gate, and game-day evidence.
• Verification: authenticated load tests; PostgreSQL-loss readiness test; approved failure matrix; timed game day; immutable-tuple readback.
• Fail closed: logs alone are not observability, Synced/Healthy is not an SLO, and mixed-tuple evidence is rejected.

Handover chain

Destination	State	Exact next action
Scope	Decision requested	Select the 33-Feature disposition and whether to create proposed AEROSIM-FT-56.
Architecture	Prepared	After Scope, record the 49-requirement disposition and final canonical Task identities.
Kanban	Blocked for new admission	RootAtSkic admits exact Tasks only after Feature solution, implementation approval, requirements, dependencies, and release allocation exist.
Delivery	Not directly dispatchable	Delivery receives only exact READY_FOR_DELIVERY Tasks from Kanban.
UAT	Blocked	Delivery must provide one frozen development tuple and exact journey set.
Releases	Blocked	Requires authenticated UAT_PASSED, a new immutable identity, exact promotion request, and exact desired-state approval.

TASK-0149 through TASK-0157 remain TO_BE_RELEASED; they are not silently closed or returned to Delivery by this architecture package.