Audit and architectural governance package

Release 1.0.0 — Enterprise Architecture Board Report

BOARD REVIEW REQUIRED

Item-level architecture, decision, stakeholder, sign-off, delivery, and audit evidence for every Release 1 Feature and all 162 child Tasks.

Release	AEROSIM-REL-1.0.0 · AeroSim 1.0.0
Scope	6 Epics · 34 Features · 162 Tasks · 49 requirements
Architecture decisions	3 Feature-linked ADRs: 3 Accepted, 0 not accepted
Canonical source	0faea543943f893601fdc90c9a64f0b566cd0d80
Document purpose	Board decision support and audit evidence; this report does not itself approve scope, architecture, release, or acceptance.

Critical governance truth

33 of 34 Release 1 Features remain canonically Proposed even though technical delivery evidence exists. CI, deployment, and agent actions do not substitute for Board or authorized-human sign-off.

1 · Control

Document control and evidence rules

Report version	1.0.0 — Board review draft
Evidence freeze	2026-09-25; repository commit 0faea543943f893601fdc90c9a64f0b566cd0d80
Generated from	Canonical Release, Epic, Feature, Task, requirement, ADR, and design-package records in the documentation repository
Interpretation rule	Observed implementation, validated evidence, deployment, acceptance, and release approval are separate states.
No-assumption rule	Missing option analysis, owners, decisions, signatures, or acceptance evidence are shown as explicit gaps. They are never inferred.
Board action	Review each Feature profile, the KDD register, stakeholder/sign-off matrix, and unresolved-decision register.

Evidence precedence

Current runtime observation for deployed state.
Current remote default branch and exact-head CI for integrated source state.
Canonical governed records for lifecycle and authority.
Human-attributable Discord or repository evidence for approval.
Local or agent-generated analysis only when explicitly labelled analysis.

Report completeness contract

Exactly 34 Release 1 Feature profiles are present.
Exactly 162 Release 1 child Tasks are listed under their owning Feature.
All 49 linked FR/NFR records are mapped.
All 3 Feature-linked ADRs receive individual KDD treatment.
Pros and benefits come from canonical value/outcome records; drawbacks come from canonical risks/failure boundaries unless labelled Board analysis.
Sign-offs name actor, date, status, and evidence when recorded; otherwise they state Not evidenced.

2 · Decision

Board decision request and present verdict

Present verdict

The Architecture owner conditionally accepted KDD-R1-01 through KDD-R1-03 and accepted ADR-0001 and ADR-0002. KDD-R1-04 and KDD-R1-05 were returned; KDD-R1-06 remains open. Scope, residual operational risk, UAT, promotion, release and product acceptance remain separate gates.

What the Board can acknowledge

Complete enumerated scope trace from Release → Epic → Feature → Task.
Current C4 documentation and implementation evidence exist.
UI/UX baseline revision 6608 has attributable human approval.
3 Feature-linked ADRs are Accepted with human evidence.
Technical delivery evidence is extensive and mostly terminal at Task level.

What remains unapproved

33 Features remain Proposed.
0 Feature-linked ADRs remain Proposed.
Authenticated UAT lacks a durable UAT_PASSED handoff for the current tuple.
Rejected release identity 1.0.0.2 cannot be reused for corrective images.
Human post-release/product acceptance remains pending.

Requested Board dispositions

Decision	Requested disposition	Required authority
Scope baseline	Approve, conditionally approve, or return each Proposed Feature; do not bulk-infer approval.	Enterprise Architecture Board + recorded Scope authority
ADR-0001 / ADR-0002	Accepted with exact Architecture-owner conditions and attributable evidence.	Architecture owner
Release architecture	Acknowledge immutable tuple, UAT, rollback, and promotion controls.	Architecture + Releases + UAT
Production release	Not authorized by this document.	RootAtSkic / Releases authority

Decision

Requested disposition

Required authority

Scope baseline

Approve, conditionally approve, or return each Proposed Feature; do not bulk-infer approval.

Enterprise Architecture Board + recorded Scope authority

ADR-0001 / ADR-0002

Accepted with exact Architecture-owner conditions and attributable evidence.

Architecture owner

Release architecture

Acknowledge immutable tuple, UAT, rollback, and promotion controls.

Architecture + Releases + UAT

Production release

Not authorized by this document.

RootAtSkic / Releases authority

3 · Scope

Release 1 scope structure

Epic	Title	Features	Feature lifecycle
AEROSIM-EP-1	Establish the AeroSim Engineering Foundation	11	Proposed: 11
AEROSIM-EP-2	Maintain My Pilot Profile and Progress	5	Proposed: 5
AEROSIM-EP-3	Believable Aircraft and World Behaviour	5	Proposed: 5
AEROSIM-EP-4	Complete a Free-Flight Session	6	Proposed: 6
AEROSIM-EP-5	Configure and Launch a Flight	6	Proposed: 6
AEROSIM-EP-9	Release AeroSim 1.0.0	1	Approved for Solution: 1

Epic

Title

Features

Feature lifecycle

AEROSIM-EP-1

Establish the AeroSim Engineering Foundation

Proposed: 11

AEROSIM-EP-2

Maintain My Pilot Profile and Progress

Proposed: 5

AEROSIM-EP-3

Believable Aircraft and World Behaviour

Proposed: 5

AEROSIM-EP-4

Complete a Free-Flight Session

Proposed: 6

AEROSIM-EP-5

Configure and Launch a Flight

Proposed: 6

AEROSIM-EP-9

Release AeroSim 1.0.0

Approved for Solution: 1

Canonical totals

34Features

162Tasks

49FR/NFR

3Feature-linked ADRs

Task lifecycle

State	Count	Meaning
Done	161	Canonical release completion evidence exists.
ToBeReleased	1	Technical delivery exists; release closure remains gated.

State

Count

Meaning

Done

161

Canonical release completion evidence exists.

ToBeReleased

Technical delivery exists; release closure remains gated.

Scope-governance discontinuity

The Release record allocates 34 Features, but 33 remain Proposed. The Board must decide whether this is intentional historical modelling or an approval defect. The report does not silently normalize it.

4 · Architecture

Architecture boundary and principal flows

Player browser
React / Three.js / Rapier

HTTPS / WSS

Osgiliath
public TLS boundary

HTTP

Kubernetes Ingress

HTTP / Socket.IO

Web + API

SQL

PostgreSQL

Principal responsibilities

Element	Responsibility	Governance concern
Web application	OIDC session, flight setup, 60 Hz authoritative browser physics, world bootstrap, outcome and recovery.	ADR-0001 accepts the browser-local authority boundary under explicit residual conditions.
API service	Typed HTTP and Socket.IO boundaries, pilot/profile/progress persistence.	Identity, authorization, validation, transaction and failure semantics.
PostgreSQL	Governed pilot and progress records via Prisma migrations.	Isolation, migration, backup and recovery evidence.
Keycloak	External identity provider; browser initiates Authorization Code + PKCE.	Session lifetime, callback, logout, failure and testability.
Gondor platform	Ingress, Argo CD, Kubernetes runtime, Harbor, external secrets.	Deployment authority, immutable evidence, rollback and trust boundaries.

Element

Responsibility

Governance concern

Web application

OIDC session, flight setup, 60 Hz authoritative browser physics, world bootstrap, outcome and recovery.

ADR-0001 accepts the browser-local authority boundary under explicit residual conditions.

API service

Typed HTTP and Socket.IO boundaries, pilot/profile/progress persistence.

Identity, authorization, validation, transaction and failure semantics.

PostgreSQL

Governed pilot and progress records via Prisma migrations.

Isolation, migration, backup and recovery evidence.

Keycloak

External identity provider; browser initiates Authorization Code + PKCE.

Session lifetime, callback, logout, failure and testability.

Gondor platform

Ingress, Argo CD, Kubernetes runtime, Harbor, external secrets.

Deployment authority, immutable evidence, rollback and trust boundaries.

Decision-grade integration contract index

Boundary	Contract / ordering / error semantics	Owner / open decision
HTTP health	GET /health/live → 200 {status: ok}; GET /health/ready → 200 ready or 503 not-ready with database dependency; no credentials/stacks/SQL.	API / Operations · readiness timeout and SLO acceptance open
Typed HTTP input	POST /contract-fixture; strict JSON schema; RFC 9457-style application/problem+json {type,title,status,detail,requestId}; 400 invalid body, 415 media type, 500 without internals.	API Architecture · compatibility/versioning policy open
Socket.IO command/state	FlightCommand {commandId,sequence,axes}; CommandAck; ordered flight:state; ProblemEvent; protocol-version validation; AUTH_REQUIRED, TOKEN_INVALID, INVALID_PAYLOAD, OUT_OF_ORDER.	API + Web · ADR-0001 authority boundary open
Reconnect/dedup	Maximum 3 reconnect attempts; terminal-error after exhaustion; duplicate/decreasing/wrong-protocol state dropped; acknowledged command not replayed.	Web / API · retry/backpressure and availability targets open
Identity propagation	OIDC PKCE session → same Keycloak subject for protected HTTPS and Socket.IO; invalid/expired/wrong issuer/audience/JWKS rejected.	Identity / API · lifecycle and privileged-policy acceptance open
Pilot persistence	Unique Keycloak subject → one pilot profile; transactional idempotent create/read; caller-selected subject denied; cross-pilot disclosure fails.	API / Data owner · retention/deletion/recovery open
Catalogue/launch binding	Catalogue and launch configuration revisions are validated; stale or changed catalogue requires reconfirmation; unsupported combinations fail closed.	Architecture · ADR-0002 accepted with release-coupled catalogue conditions

Boundary

Contract / ordering / error semantics

Owner / open decision

HTTP health

GET /health/live → 200 {status: ok}; GET /health/ready → 200 ready or 503 not-ready with database dependency; no credentials/stacks/SQL.

API / Operations · readiness timeout and SLO acceptance open

Typed HTTP input

POST /contract-fixture; strict JSON schema; RFC 9457-style application/problem+json {type,title,status,detail,requestId}; 400 invalid body, 415 media type, 500 without internals.

API Architecture · compatibility/versioning policy open

Socket.IO command/state

FlightCommand {commandId,sequence,axes}; CommandAck; ordered flight:state; ProblemEvent; protocol-version validation; AUTH_REQUIRED, TOKEN_INVALID, INVALID_PAYLOAD, OUT_OF_ORDER.

API + Web · ADR-0001 authority boundary open

Reconnect/dedup

Maximum 3 reconnect attempts; terminal-error after exhaustion; duplicate/decreasing/wrong-protocol state dropped; acknowledged command not replayed.

Web / API · retry/backpressure and availability targets open

Identity propagation

OIDC PKCE session → same Keycloak subject for protected HTTPS and Socket.IO; invalid/expired/wrong issuer/audience/JWKS rejected.

Identity / API · lifecycle and privileged-policy acceptance open

Pilot persistence

Unique Keycloak subject → one pilot profile; transactional idempotent create/read; caller-selected subject denied; cross-pilot disclosure fails.

API / Data owner · retention/deletion/recovery open

Catalogue/launch binding

Catalogue and launch configuration revisions are validated; stale or changed catalogue requires reconfirmation; unsupported combinations fail closed.

Architecture · ADR-0002 accepted with release-coupled catalogue conditions

Evidence-backed flow boundaries

Configuration: browser catalogue/selection → validated flight configuration → world and aircraft bootstrap.
Flight: browser input → authoritative physics step → rendering/HUD/cameras/warnings from the same frame.
Persistence: authenticated outcome/progress write; saved debrief/progress withheld when persistence fails.
Delivery: application revision → immutable Harbor digests → rendered GitOps revision → Argo reconciliation → runtime/UAT evidence.

5 · Assurance

Security, privacy, identity and data controls

Identity control record

ID	Control	Current evidence	Owner	Unresolved decision
IAM-01	OIDC flow	Authorization Code + PKCE initiated by the browser session client.	AeroSim Architecture / Identity platform	Issuer, audience, scopes, redirect URIs and production client ownership require Board confirmation.
IAM-02	Subject binding	Protected HTTP and Socket.IO boundaries derive one Keycloak subject; pilot data is subject-scoped and cross-pilot access is rejected.	AeroSim Architecture / API	Fine-grained authorization policy and administrator/service identities require explicit acceptance.
IAM-03	Session and tokens	Application session is held in browser memory; invalid/expired/wrong-issuer tokens are rejected.	AeroSim Architecture / Web	Token/session lifetimes, cookie protections, revocation, logout and signing-key rollover are not recorded as accepted KDDs.
IAM-04	Identity lifecycle	Keycloak provides authentication; local credential fallback is excluded.	Identity platform / Product authority	Joiner/mover/leaver, deprovisioning, MFA, federation, recovery and privileged administration are outside the current accepted evidence.
IAM-05	Authenticated UAT	Two unauthenticated journeys pass; storageState cannot restore the in-memory OIDC session for the authenticated journey.	AeroSim UAT / Delivery	Repair ordinary SSO fixture and produce a durable UAT_PASSED handoff for one exact development tuple.

Control

Current evidence

Owner

Unresolved decision

IAM-01

OIDC flow

Authorization Code + PKCE initiated by the browser session client.

AeroSim Architecture / Identity platform

Issuer, audience, scopes, redirect URIs and production client ownership require Board confirmation.

IAM-02

Subject binding

Protected HTTP and Socket.IO boundaries derive one Keycloak subject; pilot data is subject-scoped and cross-pilot access is rejected.

AeroSim Architecture / API

Fine-grained authorization policy and administrator/service identities require explicit acceptance.

IAM-03

Session and tokens

Application session is held in browser memory; invalid/expired/wrong-issuer tokens are rejected.

AeroSim Architecture / Web

Token/session lifetimes, cookie protections, revocation, logout and signing-key rollover are not recorded as accepted KDDs.

IAM-04

Identity lifecycle

Keycloak provides authentication; local credential fallback is excluded.

Identity platform / Product authority

Joiner/mover/leaver, deprovisioning, MFA, federation, recovery and privileged administration are outside the current accepted evidence.

IAM-05

Authenticated UAT

Two unauthenticated journeys pass; storageState cannot restore the in-memory OIDC session for the authenticated journey.

AeroSim UAT / Delivery

Repair ordinary SSO fixture and produce a durable UAT_PASSED handoff for one exact development tuple.

Data lifecycle register

Data	Store	Owner	Purpose	Retention	Deletion / failure	Evidence gap
Pilot identity	Keycloak subject	Identity platform / API	Authentication and pilot ownership	Realm-defined / not documented in report source	Deprovisioning/erasure not evidenced	Audit event evidence required
Pilot profile and preferences	PostgreSQL via Prisma	AeroSim API / Product data owner	Personalization and controls	Not recorded	Deletion/export not recorded	Cross-pilot isolation tests exist
Progress / resumable activity	PostgreSQL via Prisma	AeroSim API / Product data owner	Continuity and resume	Not recorded	Invalidation exists; retention/deletion not recorded	Transactional and ownership evidence exists
Flight outcome / debrief	PostgreSQL via Prisma	AeroSim API / Product data owner	Outcome and progression	Not recorded	Failed persistence withholds saved debrief/progress	Persistence and failure tests exist
Operational logs / diagnostics	Runtime/CI artifacts	Delivery / Operations	Troubleshooting and release evidence	Not recorded	Disposal not recorded	Must avoid secrets and personal data

Data

Store

Owner

Purpose

Retention

Deletion / failure

Evidence gap

Pilot identity

Keycloak subject

Identity platform / API

Authentication and pilot ownership

Realm-defined / not documented in report source

Deprovisioning/erasure not evidenced

Audit event evidence required

Pilot profile and preferences

PostgreSQL via Prisma

AeroSim API / Product data owner

Personalization and controls

Not recorded

Deletion/export not recorded

Cross-pilot isolation tests exist

Progress / resumable activity

PostgreSQL via Prisma

AeroSim API / Product data owner

Continuity and resume

Not recorded

Invalidation exists; retention/deletion not recorded

Transactional and ownership evidence exists

Flight outcome / debrief

PostgreSQL via Prisma

AeroSim API / Product data owner

Outcome and progression

Not recorded

Failed persistence withholds saved debrief/progress

Persistence and failure tests exist

Operational logs / diagnostics

Runtime/CI artifacts

Delivery / Operations

Troubleshooting and release evidence

Not recorded

Disposal not recorded

Must avoid secrets and personal data

Security and trust-boundary decisions

Area	Current control	Residual / Board action
Transport	ADR-0004: public HTTPS/WSS at Osgiliath; optional chart TLS; internal hop HTTP.	Confirm residual internal-HTTP risk or require re-encryption.
Secrets	Bitwarden-backed External Secrets; no browser receipt of administrative secrets.	Record rotation cadence, compromise response, privileged-owner and test evidence.
Authorization	JWT issuer/audience/expiry validation and subject-scoped pilot records.	Accept fine-grained policy, privileged identities and deprovisioning model.

Area

Current control

Residual / Board action

Transport

ADR-0004: public HTTPS/WSS at Osgiliath; optional chart TLS; internal hop HTTP.

Confirm residual internal-HTTP risk or require re-encryption.

Secrets

Bitwarden-backed External Secrets; no browser receipt of administrative secrets.

Record rotation cadence, compromise response, privileged-owner and test evidence.

Authorization

JWT issuer/audience/expiry validation and subject-scoped pilot records.

Accept fine-grained policy, privileged identities and deprovisioning model.

No implied security approval

5 security/data-linked requirements exist, but requirement status and technical tests do not replace an accepted identity, data-lifecycle, secrets, recovery or residual-risk decision.

6 · NFRs

Quality attributes, reliability and operations

NFR	Attribute	Measurable target	Metric decision	Verification	Status / evidence
NFR-0001	Performance	Maintain responsive rendering and simulation.	No numeric threshold: Board decision required.	Measure frame and step timing.	Proposed no acceptance evidence
NFR-0002	Determinism	Reproduce defined simulation and restart results.	No numeric threshold: Board decision required.	Compare repeated state traces.	Proposed no acceptance evidence
NFR-0003	Responsiveness	Present control and state feedback within a measurable budget.	No numeric threshold: Board decision required.	Measure input-to-state and input-to-render latency.	Proposed no acceptance evidence
NFR-0005	Resource governance	Keep browser and deployed workload consumption within explicit budgets.	No numeric threshold: Board decision required.	Measure browser and namespace resources.	Proposed no acceptance evidence
NFR-0006	Compatibility	Support the declared browser and input compatibility matrix.	No numeric threshold: Board decision required.	Run the exact compatibility matrix.	Proposed no acceptance evidence
NFR-0007	Reproducibility and integrity	Repeated validation from the same immutable inputs produces equivalent artifacts and rejects unlicensed, untraceab…	No numeric threshold: Board decision required.	Run clean-build, migration, contract, asset-provenance, image, chart, and exact-head delivery checks.	Proposed no acceptance evidence
NFR-0008	Security and privacy	Every authenticated operation resolves only the active Keycloak subject’s pilot data; AeroSim stores no local pass…	No numeric threshold: Board decision required.	Run authentication-boundary, authorization-isolation, session-expiry, cross-pilot access, and persisted-data integrity tests.	Proposed no acceptance evidence
NFR-0009	Reliability and determinism	Equivalent initial state and timed inputs remain within declared motion and world-state tolerances, and every inva…	No numeric threshold: Board decision required.	Compare repeated state traces and run supported boundary, crash, recovery, and invalid-state scenarios.	Proposed no acceptance evidence
NFR-0010	Responsiveness	Supported input-to-state and state-to-render paths meet the declared latency budget across ordinary flight, bounde…	No numeric threshold: Board decision required.	Measure input-to-state and state-to-render latency across ordinary flight, bounded heavy scenes, camera changes, pause, outc…	Proposed no acceptance evidence
NFR-0011	Configuration integrity	Every launch establishes one session whose canonical configuration equals the reviewed pre-flight summary.	No numeric threshold: Board decision required.	Run configuration-round-trip, invalid-control, and single-launch tests.	Proposed no acceptance evidence

NFR

Attribute

Measurable target

Metric decision

Verification

Status / evidence

NFR-0001

Performance

Maintain responsive rendering and simulation.

No numeric threshold: Board decision required.

Measure frame and step timing.

Proposed no acceptance evidence

NFR-0002

Determinism

Reproduce defined simulation and restart results.

No numeric threshold: Board decision required.

Compare repeated state traces.

Proposed no acceptance evidence

NFR-0003

Responsiveness

Present control and state feedback within a measurable budget.

No numeric threshold: Board decision required.

Measure input-to-state and input-to-render latency.

Proposed no acceptance evidence

NFR-0005

Resource governance

Keep browser and deployed workload consumption within explicit budgets.

No numeric threshold: Board decision required.

Measure browser and namespace resources.

Proposed no acceptance evidence

NFR-0006

Compatibility

Support the declared browser and input compatibility matrix.

No numeric threshold: Board decision required.

Run the exact compatibility matrix.

Proposed no acceptance evidence

NFR-0007

Reproducibility and integrity

Repeated validation from the same immutable inputs produces equivalent artifacts and rejects unlicensed, untraceab…

No numeric threshold: Board decision required.

Run clean-build, migration, contract, asset-provenance, image, chart, and exact-head delivery checks.

Proposed no acceptance evidence

NFR-0008

Security and privacy

Every authenticated operation resolves only the active Keycloak subject’s pilot data; AeroSim stores no local pass…

No numeric threshold: Board decision required.

Run authentication-boundary, authorization-isolation, session-expiry, cross-pilot access, and persisted-data integrity tests.

Proposed no acceptance evidence

NFR-0009

Reliability and determinism

Equivalent initial state and timed inputs remain within declared motion and world-state tolerances, and every inva…

No numeric threshold: Board decision required.

Compare repeated state traces and run supported boundary, crash, recovery, and invalid-state scenarios.

Proposed no acceptance evidence

NFR-0010

Responsiveness

Supported input-to-state and state-to-render paths meet the declared latency budget across ordinary flight, bounde…

No numeric threshold: Board decision required.

Measure input-to-state and state-to-render latency across ordinary flight, bounded heavy scenes, camera changes, pause, outc…

Proposed no acceptance evidence

NFR-0011

Configuration integrity

Every launch establishes one session whose canonical configuration equals the reviewed pre-flight summary.

No numeric threshold: Board decision required.

Run configuration-round-trip, invalid-control, and single-launch tests.

Proposed no acceptance evidence

Operations and evidence-freshness decisions

Control	Current evidence	Required decision / acceptance
Observability	Visible/machine-readable runtime failures, CI results, Argo health and route probes exist.	Approve telemetry ownership, metric names, dashboards, alerts, severity, escalation and retention.
Capacity/performance	60 Hz deterministic physics and selected browser checks exist.	Approve device/browser class, workload, percentile, sampling window, capacity limits and failure rule.
Availability/recovery	Rollback records and healthy deployment evidence exist; database recovery is excluded from migration Tasks.	Approve SLO, RTO, RPO, backup/PITR and restore-test evidence.
Evidence freshness	Current tuple is dated 2026-09-24; historical 1.0.0.0/1.0.0.1/1.0.0.2 evidence remains preserved.	Runtime evidence expires when any application, image, chart, GitOps revision, environment or acceptance journey changes.
Release gate	Two unauthenticated UAT journeys pass; authenticated UAT is incomplete.	Only a complete UAT_PASSED handoff for one unchanged tuple can unblock promotion.

Control

Current evidence

Required decision / acceptance

Observability

Visible/machine-readable runtime failures, CI results, Argo health and route probes exist.

Approve telemetry ownership, metric names, dashboards, alerts, severity, escalation and retention.

Capacity/performance

60 Hz deterministic physics and selected browser checks exist.

Approve device/browser class, workload, percentile, sampling window, capacity limits and failure rule.

Availability/recovery

Rollback records and healthy deployment evidence exist; database recovery is excluded from migration Tasks.

Approve SLO, RTO, RPO, backup/PITR and restore-test evidence.

Evidence freshness

Current tuple is dated 2026-09-24; historical 1.0.0.0/1.0.0.1/1.0.0.2 evidence remains preserved.

Runtime evidence expires when any application, image, chart, GitOps revision, environment or acceptance journey changes.

Release gate

Two unauthenticated UAT journeys pass; authenticated UAT is incomplete.

Only a complete UAT_PASSED handoff for one unchanged tuple can unblock promotion.

Reliability approval remains open

All Release 1 NFR records remain Proposed. The report exposes targets and missing values but does not relabel them approved.

7 · Governance

Stakeholders and decision rights

Role	Accountability	Consulted / informed	Cannot be inferred
Enterprise Architecture Board	Architecture fit, material KDDs, risks, exceptions and conditions.	Architecture, Security, Data, Operations, Product, Delivery, UAT, Releases.	Approval from CI, merge, deployment or agent review.
AeroSim Architecture	C4, interfaces, NFR allocation, ADR quality and technical boundary decisions.	Scope, UI/UX, Delivery, Gondor platform.	Product/release acceptance.
AeroSim Scope	Feature purpose, outcomes, dependencies and release allocation.	Architecture, Product authority, Delivery.	Architecture acceptance.
AeroSim UI/UX	Editable journey baseline and interaction/state evidence.	Scope, Architecture, UAT.	Runtime or release acceptance.
AeroSim Delivery	Implementation, tests, exact-head CI and handoff evidence.	Architecture, UI/UX, UAT, Releases.	Production promotion approval.
AeroSim UAT	Exact-deployment journey evidence and UAT verdict.	Delivery, Releases, Product authority.	Product acceptance when journeys fail or are incomplete.
AeroSim Releases	Immutable candidate, GitOps PR, promotion, rollback and lifecycle closure.	UAT, Delivery, Architecture, Gondor platform.	RootAtSkic approval or product acceptance.
Task accountability	Canonical Tasks name domain-group owners; no individual accountable owner, acceptance owner or reviewer is recorded per Task.	Board should require named accountable individuals for the nine ToBeReleased Tasks and final acceptance.	Group ownership must not be represented as individual sign-off.
RootAtSkic	Recorded product/release authority and backup domain ownership where documented.	All project domains.	Board review unless explicitly acting with that authority.

Role

Accountability

Consulted / informed

Cannot be inferred

Enterprise Architecture Board

Architecture fit, material KDDs, risks, exceptions and conditions.

Architecture, Security, Data, Operations, Product, Delivery, UAT, Releases.

Approval from CI, merge, deployment or agent review.

AeroSim Architecture

C4, interfaces, NFR allocation, ADR quality and technical boundary decisions.

Scope, UI/UX, Delivery, Gondor platform.

Product/release acceptance.

AeroSim Scope

Feature purpose, outcomes, dependencies and release allocation.

Architecture, Product authority, Delivery.

Architecture acceptance.

AeroSim UI/UX

Editable journey baseline and interaction/state evidence.

Scope, Architecture, UAT.

Runtime or release acceptance.

AeroSim Delivery

Implementation, tests, exact-head CI and handoff evidence.

Architecture, UI/UX, UAT, Releases.

Production promotion approval.

AeroSim UAT

Exact-deployment journey evidence and UAT verdict.

Delivery, Releases, Product authority.

Product acceptance when journeys fail or are incomplete.

AeroSim Releases

Immutable candidate, GitOps PR, promotion, rollback and lifecycle closure.

UAT, Delivery, Architecture, Gondor platform.

RootAtSkic approval or product acceptance.

Task accountability

Canonical Tasks name domain-group owners; no individual accountable owner, acceptance owner or reviewer is recorded per Task.

Board should require named accountable individuals for the nine ToBeReleased Tasks and final acceptance.

Group ownership must not be represented as individual sign-off.

RootAtSkic

Recorded product/release authority and backup domain ownership where documented.

All project domains.

Board review unless explicitly acting with that authority.

8 · Sign-offs

Sign-off truth and approval gaps

Artifact / gate	Current state	Recorded sign-off	Board interpretation
Release allocation	CURRENT	Human source evidence	Allocation exists; not equivalent to final architecture or release approval.
Feature scope	33 Proposed / 34	Per-Feature human proposal events; FT-53 has solution/implementation approval.	Board must dispose Proposed Features individually or by an explicit governed decision.
UI/UX baseline	Approved	RootAtSkic · rev 6608	Approved design baseline; does not approve architecture or release.
Architecture decisions	3 Accepted / 3	ADR-0004 has attributable human acceptance; ADR-0001/0002 do not.	Open KDDs are explicit Board gaps.
Technical delivery	Done 161 / ToBeReleased 1	Task-level PR/CI/runtime evidence in canonical records.	Nine ToBeReleased Tasks remain outside terminal closure.
Authenticated UAT	PENDING	No durable UAT_PASSED handoff for the current tuple.	Hard release gate.
Production promotion	NOT AUTHORIZED	Requires RootAtSkic / Releases exact-tuple approval.	This report does not authorize promotion.
Post-release acceptance	PENDING	No final human product acceptance for the corrective candidate.	Hard closure gate.

Artifact / gate

Current state

Recorded sign-off

Board interpretation

Release allocation

CURRENT

Human source evidence

Allocation exists; not equivalent to final architecture or release approval.

Feature scope

33 Proposed / 34

Per-Feature human proposal events; FT-53 has solution/implementation approval.

Board must dispose Proposed Features individually or by an explicit governed decision.

UI/UX baseline

Approved

RootAtSkic · rev 6608

Approved design baseline; does not approve architecture or release.

Architecture decisions

3 Accepted / 3

ADR-0004 has attributable human acceptance; ADR-0001/0002 do not.

Open KDDs are explicit Board gaps.

Technical delivery

Done 161 / ToBeReleased 1

Task-level PR/CI/runtime evidence in canonical records.

Nine ToBeReleased Tasks remain outside terminal closure.

Authenticated UAT

PENDING

No durable UAT_PASSED handoff for the current tuple.

Hard release gate.

Production promotion

NOT AUTHORIZED

Requires RootAtSkic / Releases exact-tuple approval.

This report does not authorize promotion.

Post-release acceptance

PENDING

No final human product acceptance for the corrective candidate.

Hard closure gate.

9 · Release assurance

Current source, development and production evidence

Evidence dimension	Integrated source / development	Production
Application/source	test@7e7d557291c9b15a8b97e8ef587e3faa91c5bf03	dbba4a186a02cb4567c64f1c3400d38556aa1a25
GitOps revision	fb5469900a93a607c2767342912d9b95cd09bc98	5a440bbe62b4d284b8b8ce81c2afeb79a974f762
Argo CD	Synced / Healthy	Synced / Healthy
Declared identity	development-7e7d557	rejected 1.0.0.2
Chart	1.0.0+build.3 · sha256:dceace9ffa94054c…a5a5437f	1.0.0+build.3 · sha256:dceace9ffa94054c…a5a5437f
Rendered template	cd49b100f346ada0 / tree e82bc376… / development answers	6b247bc205512f53 / tree 74cdc073… / production answers
Nebula image	sha256:1748ac900cd9af52…82124401	sha256:d6204a4615e6963…31acf53e9
Singularity image	sha256:4f903ebcfbd06c6…8529a3e2	sha256:36bd6e5ef71e34cb…27f68ec6

Evidence dimension

Integrated source / development

Production

Application/source

test@7e7d557291c9b15a8b97e8ef587e3faa91c5bf03

dbba4a186a02cb4567c64f1c3400d38556aa1a25

GitOps revision

fb5469900a93a607c2767342912d9b95cd09bc98

5a440bbe62b4d284b8b8ce81c2afeb79a974f762

Argo CD

Synced / Healthy

Declared identity

development-7e7d557

rejected 1.0.0.2

Chart

1.0.0+build.3 · sha256:dceace9ffa94054c…a5a5437f

Rendered template

cd49b100f346ada0 / tree e82bc376… / development answers

6b247bc205512f53 / tree 74cdc073… / production answers

Nebula image

sha256:1748ac900cd9af52…82124401

sha256:d6204a4615e6963…31acf53e9

Singularity image

sha256:4f903ebcfbd06c6…8529a3e2

sha256:36bd6e5ef71e34cb…27f68ec6

Environment divergence

Development has advanced beyond the deployed production corrective source. No UAT result for the older development tuple may be reused. Before release review, classify the 7e7d557 changes against Release 1 scope and freeze one unchanged development tuple for complete authenticated UAT.

Material release risks

Risk	Consequence	Required control / owner
Development advanced beyond production	UAT or release evidence can be accidentally bound to a different source and image set.	Freeze exact development tuple and invalidate prior journey evidence · UAT/Releases
Rejected identity 1.0.0.2 reused with different images	Breaks immutable audit meaning and can misstate what was reviewed.	New release/chart identity · Releases + RootAtSkic
Authenticated UAT fixture incompatible with in-memory OIDC session	No complete UAT_PASSED evidence for a frozen current tuple.	Runtime-compatible ordinary SSO fixture · UAT/Delivery
Nine Tasks remain ToBeReleased	Release lifecycle is not terminal.	Promote accepted tuple, verify, then append Done evidence · Releases
Feature/ADR proposal states	Architecture and scope governance trail is incomplete.	Board/authorized owners record explicit dispositions.
Human acceptance pending	Technical operation could be mistaken for product acceptance.	Explicit post-release acceptance · Product authority

Risk

Consequence

Required control / owner

Development advanced beyond production

UAT or release evidence can be accidentally bound to a different source and image set.

Freeze exact development tuple and invalidate prior journey evidence · UAT/Releases

Rejected identity 1.0.0.2 reused with different images

Breaks immutable audit meaning and can misstate what was reviewed.

New release/chart identity · Releases + RootAtSkic

Authenticated UAT fixture incompatible with in-memory OIDC session

No complete UAT_PASSED evidence for a frozen current tuple.

Runtime-compatible ordinary SSO fixture · UAT/Delivery

Nine Tasks remain ToBeReleased

Release lifecycle is not terminal.

Promote accepted tuple, verify, then append Done evidence · Releases

Feature/ADR proposal states

Architecture and scope governance trail is incomplete.

Board/authorized owners record explicit dispositions.

Human acceptance pending

Technical operation could be mistaken for product acceptance.

Explicit post-release acceptance · Product authority

AEROSIM-EP-1 · Establish the AeroSim Engineering Foundation · Feature profile

AEROSIM-FT-41 · Introduce the Nebula Frontend Foundation

Proposed 4 Tasks 2 FR/NFR 1 design-linked · 3 non-visual

Actor / owner / stakeholders	The AeroSim delivery team · AeroSim Scope · AeroSim Architecture and Delivery · AeroSim UI/UX, Architecture and Delivery · AeroSim Architecture
Purpose and value	The capability becomes an explicit, testable project boundary.
Scope boundary	Establish React, Vite, TypeScript, and Stardust
Dependencies / questions	No Feature dependencies · Q-0016
Repositories / C4	corp-v1-aerosim/corp-v1-aerosim · Web application, API Service, Documentation site
UI/UX evidence	1/4 Tasks link to approved package AEROSIM-UIUX-REL-1.0.0 revision 6608; 3 Tasks are explicitly non-visual; refs: UIUX-100-BASELINE

Benefits / intended outcomes

The capability becomes an explicit, testable project boundary.
Nebula builds a production React/Vite application with strict TypeScript and shared Stardust primitives.
A representative routed screen renders through the adopted foundation in automated component and production-build checks.

Drawbacks, constraints and failure exposure

Partial introduction could leave an ungoverned or duplicated technical boundary.
Fail the build when a required VITE_* URL is absent or not an absolute URL.
Fail type checking on implicit any, unchecked index access, or browser/server type leakage; do not emit a production bundle after a TypeScript error.

Lifecycle mismatch — no acceptance inference

Linked Done or ToBeReleased Tasks are immutable implementation history only. They do not approve the Feature, accept any Proposed requirement, prove current runtime use, or authorize release acceptance.

Requirements

ID	Type	Governance status	Requirement / target	Interpretation
FR-0048	FR	Proposed	The system shall establish React, Vite, TypeScript, and Stardust.	Not accepted; linked Task states are implementation history only.
NFR-0007	NFR	Proposed	Keep foundation builds, schemas, contracts, assets, validation, images, and deployment artifacts reproducible and traceable to governed inputs.	Not accepted; linked Task states are implementation history only.

Type

Governance status

Requirement / target

Interpretation

FR-0048

Proposed

The system shall establish React, Vite, TypeScript, and Stardust.

Not accepted; linked Task states are implementation history only.

NFR-0007

NFR

Proposed

Keep foundation builds, schemas, contracts, assets, validation, images, and deployment artifacts reproducible and traceable to governed inputs.

Not accepted; linked Task states are implementation history only.

All release Tasks

Task	Execution status	Outcome / component	Trace links — not acceptance	Execution evidence
AEROSIM-TS-11	Done	Nebula has a production-buildable React application with Vite entry points and strict TypeScript configuration.	FR-0048, NFR-0007 · outcomes 0 · mapping does not establish requirement acceptance	task flow/evidence
AEROSIM-TS-12	Done	Nebula exposes a single typed Stardust primitive layer that application screens can reuse without duplicating foundation componen…	FR-0048, NFR-0007 · outcomes 0 · mapping does not establish requirement acceptance	task flow/evidence
AEROSIM-TS-13	Done	A representative route renders through the Nebula application shell and shared primitives in component tests and a clean producti…	FR-0048, NFR-0007 · outcomes 1 · mapping does not establish requirement acceptance	task flow/evidence
AEROSIM-TS-117	Done	Delivery workers can resolve one immutable Penpot baseline and deterministic design references before changing the application.	FR-0048, NFR-0007 · outcomes 0, 1 · mapping does not establish requirement acceptance	task flow/evidence

Task

Execution status

Outcome / component

Trace links — not acceptance

Execution evidence

AEROSIM-TS-11

Done

Nebula has a production-buildable React application with Vite entry points and strict TypeScript configuration.

FR-0048, NFR-0007 · outcomes 0 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-12

Done

Nebula exposes a single typed Stardust primitive layer that application screens can reuse without duplicating foundation componen…

FR-0048, NFR-0007 · outcomes 0 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-13

Done

A representative route renders through the Nebula application shell and shared primitives in component tests and a clean producti…

FR-0048, NFR-0007 · outcomes 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-117

Done

Delivery workers can resolve one immutable Penpot baseline and deterministic design references before changing the application.

FR-0048, NFR-0007 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

KDD / advisory disposition

No feature-specific ADR recorded

Board disposition required: canonical Feature remains Proposed.

Simulated-panel recommendation: RETURN for exact-item human scope and architecture disposition; retain technical evidence without inferring approval.

Recorded sign-off

RootAtSkic · 2026-08-28T06:00:47.327Z · Proposed evidence

Task states: Done 4

AEROSIM-EP-1 · Establish the AeroSim Engineering Foundation · Feature profile

AEROSIM-FT-42 · Introduce the Singularity Backend Foundation

Proposed 3 Tasks 2 FR/NFR 0 design-linked · 3 non-visual

Actor / owner / stakeholders	The AeroSim delivery team · AeroSim Scope · AeroSim Architecture and Delivery · AeroSim Architecture
Purpose and value	The capability becomes an explicit, testable project boundary.
Scope boundary	Establish Fastify and TypeScript for APIs and business logic
Dependencies / questions	No Feature dependencies · No linked questions
Repositories / C4	corp-v1-aerosim/corp-v1-aerosim · API Service, Web application, Documentation site
UI/UX evidence	3/3 Tasks are explicitly non-visual and make no approved-package conformance claim.

Benefits / intended outcomes

The capability becomes an explicit, testable project boundary.
Singularity starts a Fastify service with typed request and response boundaries.
Automated tests verify the service health route and rejection of invalid input.

Drawbacks, constraints and failure exposure

Partial introduction could leave an ungoverned or duplicated technical boundary.
Abort startup before listen when API_PORT is outside 1..65535, LOG_LEVEL is unknown, or DATABASE_URL is invalid.
Map unexpected handler exceptions to status 500 without returning stack traces or environment values.

Lifecycle mismatch — no acceptance inference

Requirements

ID	Type	Governance status	Requirement / target	Interpretation
FR-0049	FR	Proposed	The system shall establish Fastify and TypeScript for APIs and business logic.	Not accepted; linked Task states are implementation history only.
NFR-0007	NFR	Proposed	Keep foundation builds, schemas, contracts, assets, validation, images, and deployment artifacts reproducible and traceable to governed inputs.	Not accepted; linked Task states are implementation history only.

Type

Governance status

Requirement / target

Interpretation

FR-0049

Proposed

The system shall establish Fastify and TypeScript for APIs and business logic.

Not accepted; linked Task states are implementation history only.

NFR-0007

NFR

Proposed

Keep foundation builds, schemas, contracts, assets, validation, images, and deployment artifacts reproducible and traceable to governed inputs.

Not accepted; linked Task states are implementation history only.

All release Tasks

Task	Execution status	Outcome / component	Trace links — not acceptance	Execution evidence
AEROSIM-TS-14	Done	Singularity starts as a production-buildable Fastify service with strict TypeScript and typed request, response, and error bounda…	FR-0049, NFR-0007 · outcomes 0 · mapping does not establish requirement acceptance	task flow/evidence
AEROSIM-TS-15	Done	The API exposes non-sensitive typed liveness and readiness endpoints suitable for Gondor probes.	FR-0049, NFR-0007 · outcomes 1 · mapping does not establish requirement acceptance	task flow/evidence
AEROSIM-TS-16	Done	Automated API tests prove valid typed requests succeed and malformed or unsupported input is rejected through the normalized erro…	FR-0049, NFR-0007 · outcomes 0, 1 · mapping does not establish requirement acceptance	task flow/evidence

Task

Execution status

Outcome / component

Trace links — not acceptance

Execution evidence

AEROSIM-TS-14

Done

Singularity starts as a production-buildable Fastify service with strict TypeScript and typed request, response, and error bounda…

FR-0049, NFR-0007 · outcomes 0 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-15

Done

The API exposes non-sensitive typed liveness and readiness endpoints suitable for Gondor probes.

FR-0049, NFR-0007 · outcomes 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-16

Done

Automated API tests prove valid typed requests succeed and malformed or unsupported input is rejected through the normalized erro…

FR-0049, NFR-0007 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

KDD / advisory disposition

No feature-specific ADR recorded

Board disposition required: canonical Feature remains Proposed.

Simulated-panel recommendation: RETURN for exact-item human scope and architecture disposition; retain technical evidence without inferring approval.

Recorded sign-off

RootAtSkic · 2026-08-28T06:00:47.327Z · Proposed evidence

Task states: Done 3

AEROSIM-EP-1 · Establish the AeroSim Engineering Foundation · Feature profile

AEROSIM-FT-43 · Introduce Persistent Data Management

Proposed 4 Tasks 2 FR/NFR 0 design-linked · 4 non-visual

Actor / owner / stakeholders	The AeroSim delivery team · AeroSim Scope · AeroSim Architecture and Delivery · AeroSim Architecture
Purpose and value	The capability becomes an explicit, testable project boundary.
Scope boundary	Establish PostgreSQL and Prisma for governed persistent records
Dependencies / questions	AEROSIM-FT-42 · No linked questions
Repositories / C4	corp-v1-aerosim/corp-v1-aerosim · API Service, Web application, Documentation site
UI/UX evidence	4/4 Tasks are explicitly non-visual and make no approved-package conformance claim.

Benefits / intended outcomes

The capability becomes an explicit, testable project boundary.
A clean PostgreSQL database can apply all committed Prisma migrations reproducibly.
Integration tests verify one governed transactional write and read without leaking data across pilots.

Drawbacks, constraints and failure exposure

Partial introduction could leave an ungoverned or duplicated technical boundary.
Prisma validation rejects a missing ownerSubject, clientRequestId, or payload before SQL execution.
The compound unique key rejects a duplicate clientRequestId only within the same ownerSubject.

Lifecycle mismatch — no acceptance inference

Requirements

ID	Type	Governance status	Requirement / target	Interpretation
FR-0050	FR	Proposed	The system shall establish PostgreSQL and Prisma for governed persistent records.	Not accepted; linked Task states are implementation history only.
NFR-0007	NFR	Proposed	Keep foundation builds, schemas, contracts, assets, validation, images, and deployment artifacts reproducible and traceable to governed inputs.	Not accepted; linked Task states are implementation history only.

Type

Governance status

Requirement / target

Interpretation

FR-0050

Proposed

The system shall establish PostgreSQL and Prisma for governed persistent records.

Not accepted; linked Task states are implementation history only.

NFR-0007

NFR

Proposed

Keep foundation builds, schemas, contracts, assets, validation, images, and deployment artifacts reproducible and traceable to governed inputs.

Not accepted; linked Task states are implementation history only.

All release Tasks

Task	Execution status	Outcome / component	Trace links — not acceptance	Execution evidence
AEROSIM-TS-17	Done	A minimal Prisma schema defines governed pilot identity linkage and one representative pilot-owned transactional record.	FR-0050, NFR-0007 · outcomes 0 · mapping does not establish requirement acceptance	task flow/evidence
AEROSIM-TS-18	Done	All committed Prisma migrations apply successfully to a clean PostgreSQL database and reproduce the expected schema.	FR-0050, NFR-0007 · outcomes 0 · mapping does not establish requirement acceptance	task flow/evidence
AEROSIM-TS-19	Done	The API can perform one governed transactional write and read while enforcing authenticated pilot ownership.	FR-0050, NFR-0007 · outcomes 1 · mapping does not establish requirement acceptance	task flow/evidence
AEROSIM-TS-20	Done	Real PostgreSQL integration tests prove committed transactions survive reads, failed transactions roll back, duplicate commands d…	FR-0050, NFR-0007 · outcomes 0, 1 · mapping does not establish requirement acceptance	task flow/evidence

Task

Execution status

Outcome / component

Trace links — not acceptance

Execution evidence

AEROSIM-TS-17

Done

A minimal Prisma schema defines governed pilot identity linkage and one representative pilot-owned transactional record.

FR-0050, NFR-0007 · outcomes 0 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-18

Done

All committed Prisma migrations apply successfully to a clean PostgreSQL database and reproduce the expected schema.

FR-0050, NFR-0007 · outcomes 0 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-19

Done

The API can perform one governed transactional write and read while enforcing authenticated pilot ownership.

FR-0050, NFR-0007 · outcomes 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-20

Done

Real PostgreSQL integration tests prove committed transactions survive reads, failed transactions roll back, duplicate commands d…

FR-0050, NFR-0007 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

KDD / advisory disposition

No feature-specific ADR recorded

Board disposition required: canonical Feature remains Proposed.

Simulated-panel recommendation: RETURN for exact-item human scope and architecture disposition; retain technical evidence without inferring approval.

Recorded sign-off

RootAtSkic · 2026-08-28T06:00:47.327Z · Proposed evidence

Task states: Done 4

AEROSIM-EP-1 · Establish the AeroSim Engineering Foundation · Feature profile

AEROSIM-FT-44 · Introduce Real-Time Communication

Proposed 4 Tasks 2 FR/NFR 0 design-linked · 4 non-visual

Actor / owner / stakeholders	The AeroSim delivery team · AeroSim Scope · AeroSim Architecture and Delivery · AeroSim Architecture
Purpose and value	The capability becomes an explicit, testable project boundary.
Scope boundary	Establish Socket.IO with shared typed contracts
Dependencies / questions	AEROSIM-FT-41, AEROSIM-FT-42 · No linked questions
Repositories / C4	corp-v1-aerosim/corp-v1-aerosim · Web application, API Service, Documentation site
UI/UX evidence	4/4 Tasks are explicitly non-visual and make no approved-package conformance claim.

Benefits / intended outcomes

The capability becomes an explicit, testable project boundary.
Nebula and Singularity consume one shared typed Socket.IO event contract.
Tests cover connection, authorization, reconnect, ordering, and invalid-event behavior.

Drawbacks, constraints and failure exposure

Partial introduction could leave an ungoverned or duplicated technical boundary.
Reject non-finite axis values, throttle outside 0..1, missing commandId, and protocolVersion mismatch.
Fail compile-time contract tests if Web or API declares a same-named event with a divergent payload.

Lifecycle mismatch — no acceptance inference

Release 1 runtime boundary

Socket.IO contract, gateway, client and test artifacts exist, but the current Web flight path does not instantiate the Socket client and the API has no production command forwarder. FR-0051 remains unaccepted and FT-44 remains outside the active Release 1 flight path.

Requirements

ID	Type	Governance status	Requirement / target	Interpretation
FR-0051	FR	Proposed	The system shall establish Socket.IO with shared typed contracts.	Not accepted; linked Task states are implementation history only.
NFR-0007	NFR	Proposed	Keep foundation builds, schemas, contracts, assets, validation, images, and deployment artifacts reproducible and traceable to governed inputs.	Not accepted; linked Task states are implementation history only.

Type

Governance status

Requirement / target

Interpretation

FR-0051

Proposed

The system shall establish Socket.IO with shared typed contracts.

Not accepted; linked Task states are implementation history only.

NFR-0007

NFR

Proposed

Keep foundation builds, schemas, contracts, assets, validation, images, and deployment artifacts reproducible and traceable to governed inputs.

Not accepted; linked Task states are implementation history only.

All release Tasks

Task	Execution status	Outcome / component	Trace links — not acceptance	Execution evidence
AEROSIM-TS-21	Done	Nebula and Singularity compile against one versioned event map with explicit payload, acknowledgement, ordering, and error contra…	FR-0051, NFR-0007 · outcomes 0 · mapping does not establish requirement acceptance	task flow/evidence
AEROSIM-TS-22	Done	Singularity accepts authorized typed Socket.IO connections, rejects invalid identities and events, and preserves declared event o…	FR-0051, NFR-0007 · outcomes 0, 1 · mapping does not establish requirement acceptance	task flow/evidence
AEROSIM-TS-23	Done	Nebula connects through the shared contract, reconnects with bounded behavior, and surfaces terminal connection failures without…	FR-0051, NFR-0007 · outcomes 0, 1 · mapping does not establish requirement acceptance	task flow/evidence
AEROSIM-TS-24	Done	Integration tests cover connection, authorization rejection, reconnect, ordered delivery, invalid events, and disconnect cleanup…	FR-0051, NFR-0007 · outcomes 1 · mapping does not establish requirement acceptance	task flow/evidence

Task

Execution status

Outcome / component

Trace links — not acceptance

Execution evidence

AEROSIM-TS-21

Done

Nebula and Singularity compile against one versioned event map with explicit payload, acknowledgement, ordering, and error contra…

FR-0051, NFR-0007 · outcomes 0 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-22

Done

Singularity accepts authorized typed Socket.IO connections, rejects invalid identities and events, and preserves declared event o…

FR-0051, NFR-0007 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-23

Done

Nebula connects through the shared contract, reconnects with bounded behavior, and surfaces terminal connection failures without…

FR-0051, NFR-0007 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-24

Done

Integration tests cover connection, authorization rejection, reconnect, ordered delivery, invalid events, and disconnect cleanup…

FR-0051, NFR-0007 · outcomes 1 · mapping does not establish requirement acceptance

task flow/evidence

KDD / advisory disposition

No feature-specific ADR recorded

Board disposition required: canonical Feature remains Proposed.

Simulated-panel recommendation: RETURN for exact-item human scope and architecture disposition; retain technical evidence without inferring approval.

Recorded sign-off

RootAtSkic · 2026-08-28T06:00:47.327Z · Proposed evidence

Task states: Done 4

AEROSIM-EP-1 · Establish the AeroSim Engineering Foundation · Feature profile

AEROSIM-FT-45 · Introduce the 3D Rendering Runtime

Proposed 4 Tasks 2 FR/NFR 1 design-linked · 3 non-visual

Actor / owner / stakeholders	The AeroSim delivery team · AeroSim Scope · AeroSim Architecture and Delivery · AeroSim Architecture
Purpose and value	The capability becomes an explicit, testable project boundary.
Scope boundary	Establish Three.js and React Three Fiber for browser flight rendering
Dependencies / questions	AEROSIM-FT-41 · Q-0015, Q-0016
Repositories / C4	corp-v1-aerosim/corp-v1-aerosim · Web application, API Service, Documentation site
UI/UX evidence	1/4 Tasks link to approved package AEROSIM-UIUX-REL-1.0.0 revision 6608; 3 Tasks are explicitly non-visual; refs: UIUX-100-CHASE

Benefits / intended outcomes

The capability becomes an explicit, testable project boundary.
A representative aircraft, terrain, environment, and camera scene renders through React Three Fiber.
Scene lifecycle and low-level Three.js ownership are explicit and production build emits no browser-runtime errors.

Drawbacks, constraints and failure exposure

Partial introduction could leave an ungoverned or duplicated technical boundary.
Render FlightRenderError when WebGL context creation fails; do not start a frame subscription.
Treat a zero-sized container as suspended rendering and avoid invalid camera aspect or renderer size.

Lifecycle mismatch — no acceptance inference

Requirements

ID	Type	Governance status	Requirement / target	Interpretation
FR-0052	FR	Proposed	The system shall establish Three.js and React Three Fiber for browser flight rendering.	Not accepted; linked Task states are implementation history only.
NFR-0007	NFR	Proposed	Keep foundation builds, schemas, contracts, assets, validation, images, and deployment artifacts reproducible and traceable to governed inputs.	Not accepted; linked Task states are implementation history only.

Type

Governance status

Requirement / target

Interpretation

FR-0052

Proposed

The system shall establish Three.js and React Three Fiber for browser flight rendering.

Not accepted; linked Task states are implementation history only.

NFR-0007

NFR

Proposed

Keep foundation builds, schemas, contracts, assets, validation, images, and deployment artifacts reproducible and traceable to governed inputs.

Not accepted; linked Task states are implementation history only.

All release Tasks

Task	Execution status	Outcome / component	Trace links — not acceptance	Execution evidence
AEROSIM-TS-25	Done	The Web Application owns one explicit React Three Fiber canvas and scene lifecycle with isolated low-level Three.js access.	FR-0052, NFR-0007 · outcomes 1 · mapping does not establish requirement acceptance	task flow/evidence
AEROSIM-TS-26	Done	A representative aircraft, terrain surface, environment, primary camera, and secondary camera render through React Three Fiber.	FR-0052, NFR-0007 · outcomes 0 · mapping does not establish requirement acceptance	task flow/evidence
AEROSIM-TS-27	Done	Automated rendering and browser smoke tests prove the representative scene mounts, updates, switches cameras, disposes resources,…	FR-0052, NFR-0007 · outcomes 0, 1 · mapping does not establish requirement acceptance	task flow/evidence
AEROSIM-TS-139	Done	Training Airfield, Coastal Range, and Mountain Valley each render the user-selected scene source as a visibly distinct, governed…	FR-0052 · outcomes 0, 1 · mapping does not establish requirement acceptance	task flow/evidence

Task

Execution status

Outcome / component

Trace links — not acceptance

Execution evidence

AEROSIM-TS-25

Done

The Web Application owns one explicit React Three Fiber canvas and scene lifecycle with isolated low-level Three.js access.

FR-0052, NFR-0007 · outcomes 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-26

Done

A representative aircraft, terrain surface, environment, primary camera, and secondary camera render through React Three Fiber.

FR-0052, NFR-0007 · outcomes 0 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-27

Done

Automated rendering and browser smoke tests prove the representative scene mounts, updates, switches cameras, disposes resources,…

FR-0052, NFR-0007 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-139

Done

Training Airfield, Coastal Range, and Mountain Valley each render the user-selected scene source as a visibly distinct, governed…

FR-0052 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

KDD / advisory disposition

No feature-specific ADR recorded

Board disposition required: canonical Feature remains Proposed.

Simulated-panel recommendation: RETURN for exact-item human scope and architecture disposition; retain technical evidence without inferring approval.

Recorded sign-off

RootAtSkic · 2026-08-28T06:00:47.327Z · Proposed evidence

Task states: Done 4

AEROSIM-EP-1 · Establish the AeroSim Engineering Foundation · Feature profile

AEROSIM-FT-46 · Introduce the Flight Physics Runtime

Proposed 3 Tasks 2 FR/NFR 0 design-linked · 3 non-visual

Actor / owner / stakeholders	The AeroSim delivery team · AeroSim Scope · AeroSim Architecture and Delivery · AeroSim Architecture
Purpose and value	The capability becomes an explicit, testable project boundary.
Scope boundary	Establish Rapier and @react-three/rapier for deterministic physics
Dependencies / questions	AEROSIM-FT-45 · No linked questions
Repositories / C4	corp-v1-aerosim/corp-v1-aerosim · Web application, API Service, Documentation site
UI/UX evidence	3/3 Tasks are explicitly non-visual and make no approved-package conformance claim.

Benefits / intended outcomes

The capability becomes an explicit, testable project boundary.
Rapier advances aircraft and collision state through the documented deterministic simulation step.
Repeated fixed inputs and initial state pass motion and collision regression tests.

Drawbacks, constraints and failure exposure

Partial introduction could leave an ungoverned or duplicated technical boundary.
Reject negative or non-finite elapsed time and non-finite initial state before advancing.
Clamp accumulated elapsed time to five steps and report droppedTimeSeconds rather than running an unbounded catch-up loop.

Lifecycle mismatch — no acceptance inference

Requirements

ID	Type	Governance status	Requirement / target	Interpretation
FR-0053	FR	Proposed	The system shall establish Rapier and @react-three/rapier for deterministic physics.	Not accepted; linked Task states are implementation history only.
NFR-0007	NFR	Proposed	Keep foundation builds, schemas, contracts, assets, validation, images, and deployment artifacts reproducible and traceable to governed inputs.	Not accepted; linked Task states are implementation history only.

Type

Governance status

Requirement / target

Interpretation

FR-0053

Proposed

The system shall establish Rapier and @react-three/rapier for deterministic physics.

Not accepted; linked Task states are implementation history only.

NFR-0007

NFR

Proposed

Keep foundation builds, schemas, contracts, assets, validation, images, and deployment artifacts reproducible and traceable to governed inputs.

Not accepted; linked Task states are implementation history only.

All release Tasks

Task	Execution status	Outcome / component	Trace links — not acceptance	Execution evidence
AEROSIM-TS-28	Done	The browser flight runtime advances simulation through one documented fixed-step clock with explicit input, initial-state, and ou…	FR-0053, NFR-0007 · outcomes 0 · mapping does not establish requirement acceptance	task flow/evidence
AEROSIM-TS-29	Done	Rapier and @react-three/rapier advance representative aircraft motion and collision state through the fixed-step boundary.	FR-0053, NFR-0007 · outcomes 0 · mapping does not establish requirement acceptance	task flow/evidence
AEROSIM-TS-30	Done	Repeated runs from identical initial state and fixed inputs produce equivalent motion and collision results within declared toler…	FR-0053, NFR-0007 · outcomes 1 · mapping does not establish requirement acceptance	task flow/evidence

Task

Execution status

Outcome / component

Trace links — not acceptance

Execution evidence

AEROSIM-TS-28

Done

The browser flight runtime advances simulation through one documented fixed-step clock with explicit input, initial-state, and ou…

FR-0053, NFR-0007 · outcomes 0 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-29

Done

Rapier and @react-three/rapier advance representative aircraft motion and collision state through the fixed-step boundary.

FR-0053, NFR-0007 · outcomes 0 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-30

Done

Repeated runs from identical initial state and fixed inputs produce equivalent motion and collision results within declared toler…

FR-0053, NFR-0007 · outcomes 1 · mapping does not establish requirement acceptance

task flow/evidence

KDD / advisory disposition

No feature-specific ADR recorded

Board disposition required: canonical Feature remains Proposed.

Simulated-panel recommendation: RETURN for exact-item human scope and architecture disposition; retain technical evidence without inferring approval.

Recorded sign-off

RootAtSkic · 2026-08-28T06:00:47.327Z · Proposed evidence

Task states: Done 3

AEROSIM-EP-1 · Establish the AeroSim Engineering Foundation · Feature profile

AEROSIM-FT-47 · Introduce the Terrain Pipeline

Proposed 6 Tasks 2 FR/NFR 2 design-linked · 4 non-visual

Actor / owner / stakeholders	The AeroSim delivery team · AeroSim Scope · AeroSim Architecture and Delivery · AeroSim Architecture
Purpose and value	The capability becomes an explicit, testable project boundary.
Scope boundary	Establish heightmap terrain and aligned Rapier collision
Dependencies / questions	AEROSIM-FT-45, AEROSIM-FT-46 · Q-0015
Repositories / C4	corp-v1-aerosim/corp-v1-aerosim · Web application, API Service, Documentation site
UI/UX evidence	2/6 Tasks link to approved package AEROSIM-UIUX-REL-1.0.0 revision 6608; 4 Tasks are explicitly non-visual; refs: UIUX-100-CHASE, UIUX-100-WARNING

Benefits / intended outcomes

The capability becomes an explicit, testable project boundary.
Visual terrain and Rapier collision are generated from the same normalized height data.
Representative probes keep rendered elevation and collision elevation within the defined tolerance.

Drawbacks, constraints and failure exposure

Partial introduction could leave an ungoverned or duplicated technical boundary.
Reject width or height below 2, sample-count mismatch, non-finite samples, non-positive scales, and unsupported sampling modes.
Return OutOfTerrainBounds for sample coordinates outside the closed grid extent; do not clamp silently.

Lifecycle mismatch — no acceptance inference

Requirements

ID	Type	Governance status	Requirement / target	Interpretation
FR-0054	FR	Proposed	The system shall establish heightmap terrain and aligned Rapier collision.	Not accepted; linked Task states are implementation history only.
NFR-0007	NFR	Proposed	Keep foundation builds, schemas, contracts, assets, validation, images, and deployment artifacts reproducible and traceable to governed inputs.	Not accepted; linked Task states are implementation history only.

Type

Governance status

Requirement / target

Interpretation

FR-0054

Proposed

The system shall establish heightmap terrain and aligned Rapier collision.

Not accepted; linked Task states are implementation history only.

NFR-0007

NFR

Proposed

Keep foundation builds, schemas, contracts, assets, validation, images, and deployment artifacts reproducible and traceable to governed inputs.

Not accepted; linked Task states are implementation history only.

All release Tasks

Task	Execution status	Outcome / component	Trace links — not acceptance	Execution evidence
AEROSIM-TS-31	Done	Terrain rendering and collision consume one validated normalized height-data representation with explicit dimensions, scale, orig…	FR-0054, NFR-0007 · outcomes 0 · mapping does not establish requirement acceptance	task flow/evidence
AEROSIM-TS-32	Done	The R3F flight scene generates its terrain geometry and elevation sampling from the normalized height-data contract.	FR-0054, NFR-0007 · outcomes 0 · mapping does not establish requirement acceptance	task flow/evidence
AEROSIM-TS-33	Done	The physics runtime generates the terrain collider from the same normalized height data used by the renderer.	FR-0054, NFR-0007 · outcomes 0 · mapping does not establish requirement acceptance	task flow/evidence
AEROSIM-TS-34	Done	Representative probes demonstrate that rendered and collision elevations remain within the documented tolerance across the terrai…	FR-0054, NFR-0007 · outcomes 1 · mapping does not establish requirement acceptance	task flow/evidence
AEROSIM-TS-152	Done	Terrain presentation, spawn, collision, aircraft presentation, and camera coordinates share one authored world-space contract, an…	FR-0054 · outcomes 0, 1 · mapping does not establish requirement acceptance	task flow/evidence
AEROSIM-TS-160	Done	Training Airfield, Coastal Range, and Mountain Valley each render their selected identity with continuous usable terrain and no v…	FR-0054 · outcomes 0, 1 · mapping does not establish requirement acceptance	task flow/evidence

Task

Execution status

Outcome / component

Trace links — not acceptance

Execution evidence

AEROSIM-TS-31

Done

Terrain rendering and collision consume one validated normalized height-data representation with explicit dimensions, scale, orig…

FR-0054, NFR-0007 · outcomes 0 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-32

Done

The R3F flight scene generates its terrain geometry and elevation sampling from the normalized height-data contract.

FR-0054, NFR-0007 · outcomes 0 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-33

Done

The physics runtime generates the terrain collider from the same normalized height data used by the renderer.

FR-0054, NFR-0007 · outcomes 0 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-34

Done

Representative probes demonstrate that rendered and collision elevations remain within the documented tolerance across the terrai…

FR-0054, NFR-0007 · outcomes 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-152

Done

Terrain presentation, spawn, collision, aircraft presentation, and camera coordinates share one authored world-space contract, an…

FR-0054 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-160

Done

Training Airfield, Coastal Range, and Mountain Valley each render their selected identity with continuous usable terrain and no v…

FR-0054 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

KDD / advisory disposition

No feature-specific ADR recorded

Board disposition required: canonical Feature remains Proposed.

Simulated-panel recommendation: RETURN for exact-item human scope and architecture disposition; retain technical evidence without inferring approval.

Recorded sign-off

RootAtSkic · 2026-08-28T06:00:47.327Z · Proposed evidence

Task states: Done 6

AEROSIM-EP-1 · Establish the AeroSim Engineering Foundation · Feature profile

AEROSIM-FT-48 · Introduce the 3D Asset Pipeline

Proposed 6 Tasks 2 FR/NFR 2 design-linked · 4 non-visual

Actor / owner / stakeholders	The AeroSim delivery team · AeroSim Scope · AeroSim Architecture and Delivery · AeroSim Architecture
Purpose and value	The capability becomes an explicit, testable project boundary.
Scope boundary	Establish governed glTF/GLB sourcing, licensing, provenance, and optimization
Dependencies / questions	AEROSIM-FT-45 · Q-0014, Q-0015
Repositories / C4	corp-v1-aerosim/corp-v1-aerosim · Web application, API Service, Documentation site
UI/UX evidence	2/6 Tasks link to approved package AEROSIM-UIUX-REL-1.0.0 revision 6608; 4 Tasks are explicitly non-visual; refs: UIUX-100-HANGAR, UIUX-100-FLIGHT-SETUP, UIUX-100-CHASE, UIUX-100-CAMERAS

Benefits / intended outcomes

The capability becomes an explicit, testable project boundary.
Each runtime asset is optimized to glTF/GLB and has source, license, provenance, and budget metadata.
Validation rejects an unlicensed, untraceable, unsupported, or over-budget asset.

Drawbacks, constraints and failure exposure

Partial introduction could leave an ungoverned or duplicated technical boundary.
Reject absent provenance fields, unknown schemaVersion, non-SPDX license, absolute/path-traversal runtimePath, invalid SHA-256, and negative metrics.
Reject duplicate assetId or runtimePath across the manifest registry.

Lifecycle mismatch — no acceptance inference

Requirements

ID	Type	Governance status	Requirement / target	Interpretation
FR-0055	FR	Proposed	The system shall establish governed glTF/GLB sourcing, licensing, provenance, and optimization.	Not accepted; linked Task states are implementation history only.
NFR-0007	NFR	Proposed	Keep foundation builds, schemas, contracts, assets, validation, images, and deployment artifacts reproducible and traceable to governed inputs.	Not accepted; linked Task states are implementation history only.

Type

Governance status

Requirement / target

Interpretation

FR-0055

Proposed

The system shall establish governed glTF/GLB sourcing, licensing, provenance, and optimization.

Not accepted; linked Task states are implementation history only.

NFR-0007

NFR

Proposed

Keep foundation builds, schemas, contracts, assets, validation, images, and deployment artifacts reproducible and traceable to governed inputs.

Not accepted; linked Task states are implementation history only.

All release Tasks

Task	Execution status	Outcome / component	Trace links — not acceptance	Execution evidence
AEROSIM-TS-35	Done	Every runtime 3D asset can be described by a validated manifest containing source, license, provenance, format, optimization, and…	FR-0055, NFR-0007 · outcomes 0 · mapping does not establish requirement acceptance	task flow/evidence
AEROSIM-TS-36	Done	Supported source assets are converted or optimized to deterministic runtime glTF/GLB artifacts with measured budget metadata.	FR-0055, NFR-0007 · outcomes 0 · mapping does not establish requirement acceptance	task flow/evidence
AEROSIM-TS-37	Done	Automated validation admits only licensed, traceable, supported, and within-budget runtime assets.	FR-0055, NFR-0007 · outcomes 1 · mapping does not establish requirement acceptance	task flow/evidence
AEROSIM-TS-38	Done	The Web Application loads a validated optimized asset through the governed manifest and cannot import an unregistered runtime ass…	FR-0055, NFR-0007 · outcomes 0, 1 · mapping does not establish requirement acceptance	task flow/evidence
AEROSIM-TS-146	Done	AeroSim has three governed Trainer candidates, three governed Fighter candidates, and three governed Utility candidates available…	FR-0055 · outcomes 0, 1 · mapping does not establish requirement acceptance	task flow/evidence
AEROSIM-TS-150	Done	Every one of the nine governed aircraft assets enters flight through one validated production presentation contract with determin…	FR-0055 · outcomes 0, 1 · mapping does not establish requirement acceptance	task flow/evidence

Task

Execution status

Outcome / component

Trace links — not acceptance

Execution evidence

AEROSIM-TS-35

Done

Every runtime 3D asset can be described by a validated manifest containing source, license, provenance, format, optimization, and…

FR-0055, NFR-0007 · outcomes 0 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-36

Done

Supported source assets are converted or optimized to deterministic runtime glTF/GLB artifacts with measured budget metadata.

FR-0055, NFR-0007 · outcomes 0 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-37

Done

Automated validation admits only licensed, traceable, supported, and within-budget runtime assets.

FR-0055, NFR-0007 · outcomes 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-38

Done

The Web Application loads a validated optimized asset through the governed manifest and cannot import an unregistered runtime ass…

FR-0055, NFR-0007 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-146

Done

AeroSim has three governed Trainer candidates, three governed Fighter candidates, and three governed Utility candidates available…

FR-0055 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-150

Done

Every one of the nine governed aircraft assets enters flight through one validated production presentation contract with determin…

FR-0055 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

KDD / advisory disposition

No feature-specific ADR recorded

Board disposition required: canonical Feature remains Proposed.

Simulated-panel recommendation: RETURN for exact-item human scope and architecture disposition; retain technical evidence without inferring approval.

Recorded sign-off

RootAtSkic · 2026-08-28T06:00:47.327Z · Proposed evidence

Task states: Done 6

AEROSIM-EP-1 · Establish the AeroSim Engineering Foundation · Feature profile

AEROSIM-FT-50 · Introduce Keycloak Identity Integration

Proposed 5 Tasks 2 FR/NFR 1 design-linked · 4 non-visual

Actor / owner / stakeholders	The AeroSim delivery team · AeroSim Scope · AeroSim Architecture and Delivery · AeroSim Architecture
Purpose and value	The capability becomes an explicit, testable project boundary.
Scope boundary	Establish Keycloak SSO without registration or local credentials
Dependencies / questions	AEROSIM-FT-41, AEROSIM-FT-42 · Q-0016
Repositories / C4	corp-v1-aerosim/corp-v1-aerosim, corp-v1-aerosim/corp-v1-aerosim; corp-v1-aerosim/gondor-v1-tmpl-aerosim; corp-v1-aerosim/gondor-v1-aerosim · Web application, API Service, Documentation site
UI/UX evidence	1/5 Tasks link to approved package AEROSIM-UIUX-REL-1.0.0 revision 6608; 4 Tasks are explicitly non-visual; refs: UIUX-100-ENTRY

Benefits / intended outcomes

The capability becomes an explicit, testable project boundary.
Protected AeroSim access redirects to Keycloak and returns to the intended route after success.
No registration, password, or local credential form exists in AeroSim.

Drawbacks, constraints and failure exposure

Partial introduction could leave an ungoverned or duplicated technical boundary.
Reject state/nonce mismatch, reused callback, missing code, discovery issuer mismatch, and callback error; clear the pending transaction.
Reject intended routes with an origin, protocol-relative path, or control characters and restore / instead.

Lifecycle mismatch — no acceptance inference

Requirements

ID	Type	Governance status	Requirement / target	Interpretation
FR-0057	FR	Proposed	The system shall establish Keycloak SSO without registration or local credentials.	Not accepted; linked Task states are implementation history only.
NFR-0007	NFR	Proposed	Keep foundation builds, schemas, contracts, assets, validation, images, and deployment artifacts reproducible and traceable to governed inputs.	Not accepted; linked Task states are implementation history only.

Type

Governance status

Requirement / target

Interpretation

FR-0057

Proposed

The system shall establish Keycloak SSO without registration or local credentials.

Not accepted; linked Task states are implementation history only.

NFR-0007

NFR

Proposed

Keep foundation builds, schemas, contracts, assets, validation, images, and deployment artifacts reproducible and traceable to governed inputs.

Not accepted; linked Task states are implementation history only.

All release Tasks

Task	Execution status	Outcome / component	Trace links — not acceptance	Execution evidence
AEROSIM-TS-39	Done	A protected Nebula route redirects an unauthenticated user to Keycloak and restores the originally intended route after successfu…	FR-0057, NFR-0007 · outcomes 0 · mapping does not establish requirement acceptance	task flow/evidence
AEROSIM-TS-40	Done	Protected API routes validate Keycloak JWT signatures and claims and expose a trusted authenticated-subject context.	FR-0057, NFR-0007 · outcomes 0 · mapping does not establish requirement acceptance	task flow/evidence
AEROSIM-TS-41	Done	AeroSim contains no registration, password-entry, password-reset, or local-credential persistence path.	FR-0057, NFR-0007 · outcomes 1 · mapping does not establish requirement acceptance	task flow/evidence
AEROSIM-TS-42	Done	Automated integration tests prove intended-route restoration, authenticated API access, and rejection of missing, invalid, expire…	FR-0057, NFR-0007 · outcomes 0, 1 · mapping does not establish requirement acceptance	task flow/evidence
AEROSIM-TS-128	Done	AeroSim deployment reads its Keycloak issuer, client identity, API audience, JWKS endpoint, and cache policy from project-scoped…	FR-0057, NFR-0007 · outcomes 0, 1 · mapping does not establish requirement acceptance	task flow/evidence

Task

Execution status

Outcome / component

Trace links — not acceptance

Execution evidence

AEROSIM-TS-39

Done

A protected Nebula route redirects an unauthenticated user to Keycloak and restores the originally intended route after successfu…

FR-0057, NFR-0007 · outcomes 0 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-40

Done

Protected API routes validate Keycloak JWT signatures and claims and expose a trusted authenticated-subject context.

FR-0057, NFR-0007 · outcomes 0 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-41

Done

AeroSim contains no registration, password-entry, password-reset, or local-credential persistence path.

FR-0057, NFR-0007 · outcomes 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-42

Done

Automated integration tests prove intended-route restoration, authenticated API access, and rejection of missing, invalid, expire…

FR-0057, NFR-0007 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-128

Done

AeroSim deployment reads its Keycloak issuer, client identity, API audience, JWKS endpoint, and cache policy from project-scoped…

FR-0057, NFR-0007 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

KDD / advisory disposition

No feature-specific ADR recorded

Board disposition required: canonical Feature remains Proposed.

Simulated-panel recommendation: RETURN for exact-item human scope and architecture disposition; retain technical evidence without inferring approval.

Recorded sign-off

RootAtSkic · 2026-08-28T06:00:47.327Z · Proposed evidence

Task states: Done 5

AEROSIM-EP-1 · Establish the AeroSim Engineering Foundation · Feature profile

AEROSIM-FT-51 · Introduce Automated Engineering Validation

Proposed 6 Tasks 2 FR/NFR 2 design-linked · 4 non-visual

Actor / owner / stakeholders	The AeroSim delivery team · AeroSim Scope · AeroSim Architecture and Delivery · AeroSim Architecture
Purpose and value	The capability becomes an explicit, testable project boundary.
Scope boundary	Establish tests, linting, type checking, and production builds
Dependencies / questions	AEROSIM-FT-41, AEROSIM-FT-42, AEROSIM-FT-43, AEROSIM-FT-45, AEROSIM-FT-46 · Q-0015, Q-0016
Repositories / C4	corp-v1-aerosim/corp-v1-aerosim · Documentation site, Web application, API Service
UI/UX evidence	2/6 Tasks link to approved package AEROSIM-UIUX-REL-1.0.0 revision 6608; 4 Tasks are explicitly non-visual; refs: UIUX-100-FULL-JOURNEY

Benefits / intended outcomes

The capability becomes an explicit, testable project boundary.
The declared local validation and Gitea Actions run the same lint, type, test, and production-build gates.
CI reports success only for the exact immutable candidate head after every required gate passes.

Drawbacks, constraints and failure exposure

Partial introduction could leave an ungoverned or duplicated technical boundary.
Fail before success when a workspace package lacks a required script or is omitted from task selection.
Run all gates for diagnostics but return non-zero if any gate fails; no continue-on-error can convert failure to success.

Lifecycle mismatch — no acceptance inference

Requirements

ID	Type	Governance status	Requirement / target	Interpretation
FR-0058	FR	Proposed	The system shall establish tests, linting, type checking, and production builds.	Not accepted; linked Task states are implementation history only.
NFR-0007	NFR	Proposed	Keep foundation builds, schemas, contracts, assets, validation, images, and deployment artifacts reproducible and traceable to governed inputs.	Not accepted; linked Task states are implementation history only.

Type

Governance status

Requirement / target

Interpretation

FR-0058

Proposed

The system shall establish tests, linting, type checking, and production builds.

Not accepted; linked Task states are implementation history only.

NFR-0007

NFR

Proposed

Keep foundation builds, schemas, contracts, assets, validation, images, and deployment artifacts reproducible and traceable to governed inputs.

Not accepted; linked Task states are implementation history only.

All release Tasks

Task	Execution status	Outcome / component	Trace links — not acceptance	Execution evidence
AEROSIM-TS-43	Done	The application monorepo exposes deterministic root commands for linting, type checking, testing, and production builds across Ne…	FR-0058, NFR-0007 · outcomes 0 · mapping does not establish requirement acceptance	task flow/evidence
AEROSIM-TS-44	Done	Gitea Actions invokes the same lint, type, test, and production-build entry points used locally and fails when any required gate…	FR-0058, NFR-0007 · outcomes 0 · mapping does not establish requirement acceptance	task flow/evidence
AEROSIM-TS-45	Done	The workflow records and reports the exact candidate commit and cannot publish a successful aggregate result until every required…	FR-0058, NFR-0007 · outcomes 1 · mapping does not establish requirement acceptance	task flow/evidence
AEROSIM-TS-46	Done	Automated workflow-contract tests prove local and CI gate parity, immutable-SHA binding, and failure of the aggregate result when…	FR-0058, NFR-0007 · outcomes 0, 1 · mapping does not establish requirement acceptance	task flow/evidence
AEROSIM-TS-157	Done	Rendered-flight automation cannot pass an unusable release: production asset, camera, world, control, state, warning, route, and…	FR-0058 · outcomes 0, 1 · mapping does not establish requirement acceptance	task flow/evidence
AEROSIM-TS-162	Done	Release automation rejects a build that accepts key events but cannot sustain pilot-directed flight or produces unusable producti…	FR-0058 · outcomes 0, 1 · mapping does not establish requirement acceptance	task flow/evidence

Task

Execution status

Outcome / component

Trace links — not acceptance

Execution evidence

AEROSIM-TS-43

Done

The application monorepo exposes deterministic root commands for linting, type checking, testing, and production builds across Ne…

FR-0058, NFR-0007 · outcomes 0 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-44

Done

Gitea Actions invokes the same lint, type, test, and production-build entry points used locally and fails when any required gate…

FR-0058, NFR-0007 · outcomes 0 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-45

Done

The workflow records and reports the exact candidate commit and cannot publish a successful aggregate result until every required…

FR-0058, NFR-0007 · outcomes 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-46

Done

Automated workflow-contract tests prove local and CI gate parity, immutable-SHA binding, and failure of the aggregate result when…

FR-0058, NFR-0007 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-157

Done

Rendered-flight automation cannot pass an unusable release: production asset, camera, world, control, state, warning, route, and…

FR-0058 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-162

Done

Release automation rejects a build that accepts key events but cannot sustain pilot-directed flight or produces unusable producti…

FR-0058 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

KDD / advisory disposition

No feature-specific ADR recorded

Board disposition required: canonical Feature remains Proposed.

Simulated-panel recommendation: RETURN for exact-item human scope and architecture disposition; retain technical evidence without inferring approval.

Recorded sign-off

RootAtSkic · 2026-08-28T06:00:47.327Z · Proposed evidence

Task states: Done 6

AEROSIM-EP-1 · Establish the AeroSim Engineering Foundation · Feature profile

AEROSIM-FT-52 · Introduce the Delivery Runtime

Proposed 6 Tasks 2 FR/NFR 0 design-linked · 6 non-visual

Actor / owner / stakeholders	The AeroSim delivery team · AeroSim Scope · AeroSim Architecture and Delivery · AeroSim Architecture
Purpose and value	The capability becomes an explicit, testable project boundary.
Scope boundary	Establish Docker, Helm, Harbor, Gitea Actions, and Argo CD GitOps
Dependencies / questions	AEROSIM-FT-51 · No linked questions
Repositories / C4	corp-v1-aerosim/corp-v1-aerosim, corp-v1-aerosim/gondor-v1-aerosim · Web application, API Service, Documentation site
UI/UX evidence	6/6 Tasks are explicitly non-visual and make no approved-package conformance claim.

Benefits / intended outcomes

The capability becomes an explicit, testable project boundary.
Nebula and Singularity produce versioned container images and lintable Helm charts.
Harbor publication and Argo CD GitOps deployment use governed automation without direct CI runtime mutation.

Drawbacks, constraints and failure exposure

Partial introduction could leave an ungoverned or duplicated technical boundary.
Fail build if SOURCE_REVISION is absent/not 40 hex, frozen install changes the lockfile, or production build fails.
Fail contract test if runtime user is root, source files/dev dependencies are copied unnecessarily, labels mismatch, or health endpoint does not respond.

Lifecycle mismatch — no acceptance inference

Requirements

ID	Type	Governance status	Requirement / target	Interpretation
FR-0059	FR	Proposed	The system shall establish Docker, Helm, Harbor, Gitea Actions, and Argo CD GitOps.	Not accepted; linked Task states are implementation history only.
NFR-0007	NFR	Proposed	Keep foundation builds, schemas, contracts, assets, validation, images, and deployment artifacts reproducible and traceable to governed inputs.	Not accepted; linked Task states are implementation history only.

Type

Governance status

Requirement / target

Interpretation

FR-0059

Proposed

The system shall establish Docker, Helm, Harbor, Gitea Actions, and Argo CD GitOps.

Not accepted; linked Task states are implementation history only.

NFR-0007

NFR

Proposed

Keep foundation builds, schemas, contracts, assets, validation, images, and deployment artifacts reproducible and traceable to governed inputs.

Not accepted; linked Task states are implementation history only.

All release Tasks

Task	Execution status	Outcome / component	Trace links — not acceptance	Execution evidence
AEROSIM-TS-47	Done	Nebula and Singularity each produce reproducible runtime images labeled and tagged with the immutable application source revision.	FR-0059, NFR-0007 · outcomes 0 · mapping does not establish requirement acceptance	task flow/evidence
AEROSIM-TS-48	Done	Lintable Helm charts render Web and API workloads with explicit immutable image selection, probes, ingress paths, configuration,…	FR-0059, NFR-0007 · outcomes 0 · mapping does not establish requirement acceptance	task flow/evidence
AEROSIM-TS-49	Done	Gitea Actions publishes both validated source-revision images to Harbor only after required engineering gates pass.	FR-0059, NFR-0007 · outcomes 1 · mapping does not establish requirement acceptance	task flow/evidence
AEROSIM-TS-50	Done	The Gondor GitOps repository declaratively selects reviewed Nebula and Singularity image revisions and linted chart configuration…	FR-0059, NFR-0007 · outcomes 1 · mapping does not establish requirement acceptance	task flow/evidence
AEROSIM-TS-51	Done	Automated checks prove CI can publish artifacts but cannot directly mutate Kubernetes or Argo CD runtime state.	FR-0059, NFR-0007 · outcomes 1 · mapping does not establish requirement acceptance	task flow/evidence
AEROSIM-TS-52	Done	A governed GitOps change reconciles through Argo CD to healthy Web and API workloads whose running image revisions match the revi…	FR-0059, NFR-0007 · outcomes 0, 1 · mapping does not establish requirement acceptance	task flow/evidence

Task

Execution status

Outcome / component

Trace links — not acceptance

Execution evidence

AEROSIM-TS-47

Done

Nebula and Singularity each produce reproducible runtime images labeled and tagged with the immutable application source revision.

FR-0059, NFR-0007 · outcomes 0 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-48

Done

Lintable Helm charts render Web and API workloads with explicit immutable image selection, probes, ingress paths, configuration,…

FR-0059, NFR-0007 · outcomes 0 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-49

Done

Gitea Actions publishes both validated source-revision images to Harbor only after required engineering gates pass.

FR-0059, NFR-0007 · outcomes 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-50

Done

The Gondor GitOps repository declaratively selects reviewed Nebula and Singularity image revisions and linted chart configuration…

FR-0059, NFR-0007 · outcomes 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-51

Done

Automated checks prove CI can publish artifacts but cannot directly mutate Kubernetes or Argo CD runtime state.

FR-0059, NFR-0007 · outcomes 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-52

Done

A governed GitOps change reconciles through Argo CD to healthy Web and API workloads whose running image revisions match the revi…

FR-0059, NFR-0007 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

KDD / advisory disposition

ADR-0004: Accepted

Board disposition required: canonical Feature remains Proposed.

Simulated-panel recommendation: RETURN for exact-item human scope and architecture disposition; retain technical evidence without inferring approval.

Recorded sign-off

RootAtSkic · 2026-08-28T06:00:47.327Z · Proposed evidence

Task states: Done 6

AEROSIM-EP-2 · Maintain My Pilot Profile and Progress · Feature profile

AEROSIM-FT-30 · Access AeroSim Through Keycloak SSO

Proposed 5 Tasks 2 FR/NFR 1 design-linked · 4 non-visual

Actor / owner / stakeholders	An AeroSim player · AeroSim Scope · AeroSim Architecture and Delivery · AeroSim UI/UX, Architecture and Delivery · AeroSim Architecture
Purpose and value	The player receives one coherent, observable capability.
Scope boundary	Authenticate through Keycloak without registration or local credentials
Dependencies / questions	AEROSIM-FT-50 · No linked questions
Repositories / C4	corp-v1-aerosim/corp-v1-aerosim · Web application, API Service
UI/UX evidence	1/5 Tasks link to approved package AEROSIM-UIUX-REL-1.0.0 revision 6608; 4 Tasks are explicitly non-visual; refs: UIUX-100-ENTRY

Benefits / intended outcomes

The player receives one coherent, observable capability.
Unauthenticated access uses the approved Keycloak SSO flow.
Successful SSO establishes one AeroSim pilot identity without registration or local credentials.

Drawbacks, constraints and failure exposure

Representative browser or input configurations may expose an unmet outcome.
Reject callbacks with missing or mismatched state, absent code, invalid nonce, or failed token exchange without creating an AeroSim session
When refresh fails or the token expires, clear the browser session and require a new Keycloak authorization flow rather than continuing with stale credentials

Lifecycle mismatch — no acceptance inference

Requirements

Type

Governance status

Requirement / target

Interpretation

FR-0037

Proposed

The system shall authenticate through Keycloak without registration or local credentials.

Not accepted; linked Task states are implementation history only.

NFR-0008

NFR

Proposed

Protect Keycloak-authenticated identity, pilot profiles, preferences, progress, and resumable activity from cross-pilot access or local-credential fallback.

Not accepted; linked Task states are implementation history only.

All release Tasks

Task

Execution status

Outcome / component

Trace links — not acceptance

Execution evidence

AEROSIM-TS-53

Done

Unauthenticated browser access redirects through the approved Keycloak OIDC Authorization Code with PKCE flow and returns with a…

FR-0037, NFR-0008 · outcomes 0 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-54

Done

The API accepts only valid Keycloak access tokens and derives one immutable authenticated-subject context for protected HTTP and…

FR-0037, NFR-0008 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-55

Done

A successful SSO session supplies the same Keycloak subject identity to protected AeroSim HTTP and Socket.IO requests without cre…

FR-0037, NFR-0008 · outcomes 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-56

Done

Reviewed automated and browser evidence demonstrates the approved Keycloak flow, stable subject propagation, denial of invalid or…

FR-0037, NFR-0008 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-118

Done

The implemented Entry experience matches the approved orientation, copy, imagery, action placement, and SSO transition.

FR-0037, NFR-0008 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

KDD / advisory disposition

No feature-specific ADR recorded

Board disposition required: canonical Feature remains Proposed.

Simulated-panel recommendation: RETURN for exact-item human scope and architecture disposition; retain technical evidence without inferring approval.

Recorded sign-off

RootAtSkic · 2026-08-28T06:00:47.327Z · Proposed evidence

Task states: Done 5

AEROSIM-EP-2 · Maintain My Pilot Profile and Progress · Feature profile

AEROSIM-FT-31 · Create a Pilot Profile From the Authenticated Identity

Proposed 5 Tasks 2 FR/NFR 1 design-linked · 4 non-visual

Actor / owner / stakeholders	An AeroSim player · AeroSim Scope · AeroSim Architecture and Delivery · AeroSim UI/UX, Architecture and Delivery · AeroSim Architecture
Purpose and value	The player receives one coherent, observable capability.
Scope boundary	Resolve one AeroSim pilot profile for the Keycloak subject
Dependencies / questions	AEROSIM-FT-30, AEROSIM-FT-43 · No linked questions
Repositories / C4	corp-v1-aerosim/corp-v1-aerosim · Web application, API Service
UI/UX evidence	1/5 Tasks link to approved package AEROSIM-UIUX-REL-1.0.0 revision 6608; 4 Tasks are explicitly non-visual; refs: UIUX-100-PROFILE

Benefits / intended outcomes

The player receives one coherent, observable capability.
The first authorized Keycloak subject creates one linked pilot profile.
Later sessions resolve the same profile without duplication.

Drawbacks, constraints and failure exposure

Representative browser or input configurations may expose an unmet outcome.
Reject null, empty, or duplicate subject identifiers and roll back migrations that cannot preserve the one-subject-to-one-profile invariant
Prevent schema changes that add password hashes, local credentials, or identity-provider tokens to pilot records

Lifecycle mismatch — no acceptance inference

Requirements

Type

Governance status

Requirement / target

Interpretation

FR-0038

Proposed

The system shall resolve one AeroSim pilot profile for the Keycloak subject.

Not accepted; linked Task states are implementation history only.

NFR-0008

NFR

Proposed

Protect Keycloak-authenticated identity, pilot profiles, preferences, progress, and resumable activity from cross-pilot access or local-credential fallback.

Not accepted; linked Task states are implementation history only.

All release Tasks

Task

Execution status

Outcome / component

Trace links — not acceptance

Execution evidence

AEROSIM-TS-57

Done

The data model can store exactly one AeroSim pilot profile for each Keycloak subject without storing identity-provider credential…

FR-0038, NFR-0008 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-58

Done

The first authorized request creates one linked pilot profile, while concurrent or later requests for the same Keycloak subject r…

FR-0038, NFR-0008 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-59

Done

After authentication, the Web Application loads and retains the profile linked to the active Keycloak subject and reuses it in la…

FR-0038, NFR-0008 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-60

Done

Reviewed evidence demonstrates first-session creation, repeated-session reuse, concurrency-safe non-duplication, and denial of ac…

FR-0038, NFR-0008 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-119

Done

The pilot sees the approved profile identity, progress summary, controls, and close behavior without visual or navigation drift.

FR-0038, NFR-0008 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

KDD / advisory disposition

No feature-specific ADR recorded

Board disposition required: canonical Feature remains Proposed.

Simulated-panel recommendation: RETURN for exact-item human scope and architecture disposition; retain technical evidence without inferring approval.

Recorded sign-off

RootAtSkic · 2026-08-28T06:00:47.327Z · Proposed evidence

Task states: Done 5

AEROSIM-EP-2 · Maintain My Pilot Profile and Progress · Feature profile

AEROSIM-FT-32 · Preserve Pilot Preferences and Settings

Proposed 5 Tasks 2 FR/NFR 1 design-linked · 4 non-visual

Actor / owner / stakeholders	An AeroSim player · AeroSim Scope · AeroSim Architecture and Delivery · AeroSim UI/UX, Architecture and Delivery · AeroSim Architecture
Purpose and value	The player receives one coherent, observable capability.
Scope boundary	Store and restore supported personal preferences
Dependencies / questions	AEROSIM-FT-31 · No linked questions
Repositories / C4	corp-v1-aerosim/corp-v1-aerosim · Web application, API Service
UI/UX evidence	1/5 Tasks link to approved package AEROSIM-UIUX-REL-1.0.0 revision 6608; 4 Tasks are explicitly non-visual; refs: UIUX-100-SETTINGS

Benefits / intended outcomes

The player receives one coherent, observable capability.
Saving a supported preference associates it with the active pilot.
A later authenticated session restores the last valid supported value.

Drawbacks, constraints and failure exposure

Representative browser or input configurations may expose an unmet outcome.
Reject unknown keys, values outside the declared type or bounds, and records without a valid pilot owner
Migration failure must leave the prior schema usable and must not create duplicate key records for one pilot

Lifecycle mismatch — no acceptance inference

Requirements

Type

Governance status

Requirement / target

Interpretation

FR-0039

Proposed

The system shall store and restore supported personal preferences.

Not accepted; linked Task states are implementation history only.

NFR-0008

NFR

Proposed

Protect Keycloak-authenticated identity, pilot profiles, preferences, progress, and resumable activity from cross-pilot access or local-credential fallback.

Not accepted; linked Task states are implementation history only.

All release Tasks

Task

Execution status

Outcome / component

Trace links — not acceptance

Execution evidence

AEROSIM-TS-61

Done

Supported preference values can be stored against one pilot with deterministic defaults and validation while unsupported or malfo…

FR-0039, NFR-0008 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-62

Done

An authenticated pilot can save supported preference values and retrieve only that pilot's last valid values.

FR-0039, NFR-0008 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-63

Done

Preference changes are saved for the active pilot and the last valid supported values are restored and applied after a later auth…

FR-0039, NFR-0008 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-64

Done

Reviewed evidence demonstrates active-pilot association, later-session restoration of the last valid supported value, rejection o…

FR-0039, NFR-0008 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-120

Done

Supported settings render, validate, save, recover, and return exactly through the approved Settings experience.

FR-0039, NFR-0008 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

KDD / advisory disposition

No feature-specific ADR recorded

Board disposition required: canonical Feature remains Proposed.

Simulated-panel recommendation: RETURN for exact-item human scope and architecture disposition; retain technical evidence without inferring approval.

Recorded sign-off

RootAtSkic · 2026-08-28T06:00:47.327Z · Proposed evidence

Task states: Done 5

AEROSIM-EP-2 · Maintain My Pilot Profile and Progress · Feature profile

AEROSIM-FT-33 · Save Flight and Training Progress

Proposed 5 Tasks 2 FR/NFR 1 design-linked · 4 non-visual

Actor / owner / stakeholders	An AeroSim player · AeroSim Scope · AeroSim Architecture and Delivery · AeroSim Architecture
Purpose and value	The player receives one coherent, observable capability.
Scope boundary	Persist governed flight, lesson, and progression state
Dependencies / questions	AEROSIM-FT-31, AEROSIM-FT-43 · No linked questions
Repositories / C4	corp-v1-aerosim/corp-v1-aerosim · Web application, API Service
UI/UX evidence	1/5 Tasks link to approved package AEROSIM-UIUX-REL-1.0.0 revision 6608; 4 Tasks are explicitly non-visual; refs: UIUX-100-FULL-JOURNEY

Benefits / intended outcomes

The player receives one coherent, observable capability.
Governed flight and training progress is persisted against the active pilot.
A later session retrieves the same canonical progress state.

Drawbacks, constraints and failure exposure

Representative browser or input configurations may expose an unmet outcome.
Reject unowned records, unknown activity types, absent payload versions, invalid outcomes, and resumable records without required context
Database constraints must prevent ambiguous duplicate canonical updates for the same pilot activity and migration rollback must preserve prior records

Lifecycle mismatch — no acceptance inference

Requirements

Type

Governance status

Requirement / target

Interpretation

FR-0040

Proposed

The system shall persist governed flight, lesson, and progression state.

Not accepted; linked Task states are implementation history only.

NFR-0008

NFR

Proposed

Protect Keycloak-authenticated identity, pilot profiles, preferences, progress, and resumable activity from cross-pilot access or local-credential fallback.

Not accepted; linked Task states are implementation history only.

All release Tasks

Task

Execution status

Outcome / component

Trace links — not acceptance

Execution evidence

AEROSIM-TS-65

Done

Governed flight, lesson, progression, outcome, and resumable-context state has one versioned, pilot-owned persistence model.

FR-0040, NFR-0008 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-66

Done

The API transactionally stores governed progress for the active pilot and returns that same pilot's canonical latest state in a l…

FR-0040, NFR-0008 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-67

Done

Governed flight and training checkpoints are sent for the active pilot, and a later authenticated session retrieves the canonical…

FR-0040, NFR-0008 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-68

Done

Reviewed evidence demonstrates pilot-owned persistence and later retrieval of identical canonical progress, including failure int…

FR-0040, NFR-0008 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-143

Done

Ending or completing a launched flight writes one authenticated pilot-scoped progress record that can be retrieved in a later ses…

FR-0040 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

KDD / advisory disposition

No feature-specific ADR recorded

Board disposition required: canonical Feature remains Proposed.

Simulated-panel recommendation: RETURN for exact-item human scope and architecture disposition; retain technical evidence without inferring approval.

Recorded sign-off

RootAtSkic · 2026-08-28T06:00:47.327Z · Proposed evidence

Task states: Done 5

AEROSIM-EP-2 · Maintain My Pilot Profile and Progress · Feature profile

AEROSIM-FT-34 · Resume the Player’s Most Recent Activity

Proposed 6 Tasks 2 FR/NFR 2 design-linked · 4 non-visual

Actor / owner / stakeholders	An AeroSim player · AeroSim Scope · AeroSim Architecture and Delivery · AeroSim UI/UX, Architecture and Delivery · AeroSim Architecture
Purpose and value	The player receives one coherent, observable capability.
Scope boundary	Continue from the most recent valid resumable state
Dependencies / questions	AEROSIM-FT-33 · No linked questions
Repositories / C4	corp-v1-aerosim/corp-v1-aerosim · Web application, API Service
UI/UX evidence	2/6 Tasks link to approved package AEROSIM-UIUX-REL-1.0.0 revision 6608; 4 Tasks are explicitly non-visual; refs: UIUX-100-HOME

Benefits / intended outcomes

The player receives one coherent, observable capability.
Home identifies only an activity that is actually resumable.
Resume restores its recorded context or explains why continuation is unavailable.

Drawbacks, constraints and failure exposure

Representative browser or input configurations may expose an unmet outcome.
Return no resumable activity for malformed, completed, failed, aborted, unsupported-version, missing-context, or deleted-resource records
Never inspect or return another pilot’s activity when selecting the latest candidate

Lifecycle mismatch — no acceptance inference

Requirements

Type

Governance status

Requirement / target

Interpretation

FR-0041

Proposed

The system shall continue from the most recent valid resumable state.

Not accepted; linked Task states are implementation history only.

NFR-0008

NFR

Proposed

Protect Keycloak-authenticated identity, pilot profiles, preferences, progress, and resumable activity from cross-pilot access or local-credential fallback.

Not accepted; linked Task states are implementation history only.

All release Tasks

Task

Execution status

Outcome / component

Trace links — not acceptance

Execution evidence

AEROSIM-TS-69

Done

The API returns a most-recent activity only when its pilot-owned canonical state is complete, supported, and actually resumable.

FR-0041, NFR-0008 · outcomes 0 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-70

Done

Home offers Resume only for the active pilot's API-confirmed resumable activity and otherwise presents an explicit no-continuatio…

FR-0041, NFR-0008 · outcomes 0 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-71

Done

Selecting Resume reconstructs the recorded governed context for the active pilot or explains a stable reason that continuation is…

FR-0041, NFR-0008 · outcomes 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-72

Done

Reviewed evidence demonstrates that Home identifies only actually resumable activity, Resume restores its recorded context, unava…

FR-0041, NFR-0008 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-121

Done

Home presents the approved primary journey and only a valid resumable activity with correct states and destinations.

FR-0041, NFR-0008 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-144

Done

A pilot with no resumable activity sees a stable empty state without an error-level 404 request or misleading retry action.

FR-0041 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

KDD / advisory disposition

No feature-specific ADR recorded

Board disposition required: canonical Feature remains Proposed.

Simulated-panel recommendation: RETURN for exact-item human scope and architecture disposition; retain technical evidence without inferring approval.

Recorded sign-off

RootAtSkic · 2026-08-28T06:00:47.327Z · Proposed evidence

Task states: Done 6

AEROSIM-EP-3 · Believable Aircraft and World Behaviour · Feature profile

AEROSIM-FT-1 · Experience Aircraft Motion Produced by Flight Forces

Proposed 6 Tasks 7 FR/NFR 2 design-linked · 4 non-visual

Actor / owner / stakeholders	An AeroSim player · AeroSim Scope · AeroSim Architecture and Delivery · AeroSim Architecture
Purpose and value	The player receives one coherent, observable capability.
Scope boundary	Translate controls and aircraft state into continuous force-driven motion
Dependencies / questions	No Feature dependencies · Q-0001, Q-0002, Q-0018
Repositories / C4	corp-v1-aerosim/corp-v1-aerosim · Web application
UI/UX evidence	2/6 Tasks link to approved package AEROSIM-UIUX-REL-1.0.0 revision 6608; 4 Tasks are explicitly non-visual; refs: UIUX-100-CHASE, UIUX-100-WARNING, UIUX-100-OUTCOME-DEBRIEF

Benefits / intended outcomes

The player receives one coherent, observable capability.
Aircraft motion changes continuously with modeled lift, drag, thrust, gravity, attitude, and player input.
The same initial state and timed input sequence produces the same motion trace within the defined tolerance.

Drawbacks, constraints and failure exposure

Prototype behaviour may not meet the current acceptance outcomes.
Throw FlightForceInputError(code='NON_FINITE_STATE') before calculation when any position, velocity, attitude, or angular-velocity component is NaN or infinite.
Throw FlightForceInputError(code='CONTROL_OUT_OF_RANGE') for pitch, roll, or yaw outside [-1,1], or throttle outside [0,1].

Lifecycle mismatch — no acceptance inference

Requirements

Type

Governance status

Requirement / target

Interpretation

FR-0001

Proposed

The system shall calculate lift, drag, thrust, and gravity for each supported simulation step.

Not accepted; linked Task states are implementation history only.

FR-0002

Proposed

The system shall advance aircraft position, velocity, and attitude from net force and moments.

Not accepted; linked Task states are implementation history only.

NFR-0001

NFR

Proposed

Maintain responsive rendering and simulation.

Not accepted; linked Task states are implementation history only.

NFR-0002

NFR

Proposed

Reproduce defined simulation and restart results.

Not accepted; linked Task states are implementation history only.

NFR-0005

NFR

Proposed

Keep browser and deployed workload consumption within explicit budgets.

Not accepted; linked Task states are implementation history only.

NFR-0006

NFR

Proposed

Support the declared browser and input compatibility matrix.

Not accepted; linked Task states are implementation history only.

NFR-0009

NFR

Proposed

Keep aircraft, environment, collision, and invalid-state outcomes consistent for equivalent governed inputs and visibly recoverable at supported boundaries.

Not accepted; linked Task states are implementation history only.

All release Tasks

Task

Execution status

Outcome / component

Trace links — not acceptance

Execution evidence

AEROSIM-TS-1

Done

Each fixed simulation step produces lift, drag, thrust, gravity, and net force/moment values from validated bounded gameplay para…

FR-0001 · outcomes 0 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-73

Done

Net forces and moments advance aircraft position, velocity, and attitude continuously and reject invalid state transitions.

FR-0002 · outcomes 0 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-74

Done

Identical builds, initial states, timed inputs, fixed timesteps, and seeds produce equivalent governed motion traces across every…

NFR-0002, NFR-0006, NFR-0009 · outcomes 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-75

Done

The force-driven motion path satisfies explicit simulation-step, frame-time, CPU, and memory budgets under representative governe…

NFR-0001, NFR-0005 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-154

Done

Rendered motion, telemetry, warnings, initial state, boundary/collision recovery, and explicit restart have one authoritative sta…

FR-0002 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-158

Done

A neutral aircraft remains in a bounded, trimmable state and ordinary keyboard commands produce directional aircraft responses in…

FR-0002 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

KDD / advisory disposition

ADR-0001: Accepted

Board disposition required: canonical Feature remains Proposed.

Simulated-panel recommendation: RETURN for exact-item human scope and architecture disposition; retain technical evidence without inferring approval.

Recorded sign-off

RootAtSkic · 2026-08-24T15:06:15.606Z · Proposed evidence

Task states: Done 6

AEROSIM-EP-3 · Believable Aircraft and World Behaviour · Feature profile

AEROSIM-FT-2 · Interact with Terrain and World Boundaries

Proposed 6 Tasks 7 FR/NFR 2 design-linked · 4 non-visual

Actor / owner / stakeholders	An AeroSim player · AeroSim Scope · AeroSim Architecture and Delivery · AeroSim Architecture
Purpose and value	The player receives one coherent, observable capability.
Scope boundary	Respond predictably to terrain, collision surfaces, altitude limits, and world boundaries
Dependencies / questions	AEROSIM-FT-47 · Q-0003, Q-0004, Q-0018
Repositories / C4	corp-v1-aerosim/corp-v1-aerosim · Web application
UI/UX evidence	2/6 Tasks link to approved package AEROSIM-UIUX-REL-1.0.0 revision 6608; 4 Tasks are explicitly non-visual; refs: UIUX-100-WARNING

Benefits / intended outcomes

The player receives one coherent, observable capability.
Contact with terrain or a configured world boundary produces a visible governed response.
A boundary violation ends or recovers the session without leaving an unexplained aircraft state.

Drawbacks, constraints and failure exposure

Prototype behaviour may not meet the current acceptance outcomes.
Return CONTACT_DATA_INVALID for missing collider IDs, unsupported category, non-unit normal beyond tolerance, or non-finite point/speed/orientation fields; route the session to invalid-state handling rather than classifying safe contact.
Return CONTACT_POLICY_INVALID when speed, orientation, or gear thresholds are missing, non-finite, negative, or internally contradictory.

Lifecycle mismatch — no acceptance inference

Requirements

Type

Governance status

Requirement / target

Interpretation

FR-0003

Proposed

The system shall detect supported ground and obstacle contact.

Not accepted; linked Task states are implementation history only.

FR-0004

Proposed

The system shall present a bounded, recoverable response to collision and world limits.

Not accepted; linked Task states are implementation history only.

NFR-0001

NFR

Proposed

Maintain responsive rendering and simulation.

Not accepted; linked Task states are implementation history only.

NFR-0002

NFR

Proposed

Reproduce defined simulation and restart results.

Not accepted; linked Task states are implementation history only.

NFR-0005

NFR

Proposed

Keep browser and deployed workload consumption within explicit budgets.

Not accepted; linked Task states are implementation history only.

NFR-0006

NFR

Proposed

Support the declared browser and input compatibility matrix.

Not accepted; linked Task states are implementation history only.

NFR-0009

NFR

Proposed

Keep aircraft, environment, collision, and invalid-state outcomes consistent for equivalent governed inputs and visibly recoverable at supported boundaries.

Not accepted; linked Task states are implementation history only.

All release Tasks

Task

Execution status

Outcome / component

Trace links — not acceptance

Execution evidence

AEROSIM-TS-2

Done

The deterministic runtime reports controlled terrain contact, unsafe terrain contact, and solid-object collision using the aligne…

FR-0003 · outcomes 0 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-83

Done

Configured horizontal and altitude limits produce a visible warning zone, a return grace zone, and an unambiguous hard-limit even…

FR-0004 · outcomes 0 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-84

Done

A hard-limit or governed collision event restores the last safe state/configured recovery point or explicitly concludes the sessi…

FR-0004 · outcomes 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-85

Done

Supported contact, warning, recovery, and terminal scenarios remain responsive, resource-bounded, and equivalent within governed…

NFR-0001, NFR-0002, NFR-0005, NFR-0006, NFR-0009 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-141

Done

A boundary warning appears only from the active confirmed world policy and never reports a hard limit before a world has been sel…

FR-0004 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-148

Done

A launched flight remains usable within the intended world area and reaches warning, hard-limit, recovery, and restart states onl…

FR-0004 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

KDD / advisory disposition

ADR-0001: Accepted

Board disposition required: canonical Feature remains Proposed.

Simulated-panel recommendation: RETURN for exact-item human scope and architecture disposition; retain technical evidence without inferring approval.

Recorded sign-off

RootAtSkic · 2026-08-24T15:06:15.606Z · Proposed evidence

Task states: Done 6

AEROSIM-EP-3 · Believable Aircraft and World Behaviour · Feature profile

AEROSIM-FT-9 · Experience Different Aircraft Handling Characteristics

Proposed 3 Tasks 2 FR/NFR 2 design-linked · 1 non-visual

Actor / owner / stakeholders	An AeroSim player · AeroSim Scope · AeroSim Architecture and Delivery · AeroSim Architecture
Purpose and value	The player receives one coherent, observable capability.
Scope boundary	Represent meaningful differences in stability, responsiveness, speed, and control authority
Dependencies / questions	AEROSIM-FT-1 · No linked questions
Repositories / C4	corp-v1-aerosim/corp-v1-aerosim · Web application
UI/UX evidence	2/3 Tasks link to approved package AEROSIM-UIUX-REL-1.0.0 revision 6608; 1 Tasks are explicitly non-visual; refs: UIUX-100-PREFLIGHT, UIUX-100-CHASE, UIUX-100-FULL-JOURNEY

Benefits / intended outcomes

The player receives one coherent, observable capability.
Supported aircraft produce observably different stability, responsiveness, speed, or control authority under equivalent conditions.
Displayed handling characteristics match the configuration used by flight physics.

Drawbacks, constraints and failure exposure

Representative browser or input configurations may expose an unmet outcome.
Reject with AIRCRAFT_CONFIG_SCHEMA_UNSUPPORTED when schemaVersion is not '1'.
Reject with AIRCRAFT_CONFIG_INVALID and JSON-pointer error paths for missing, non-finite, non-positive, or out-of-bound fields.

Lifecycle mismatch — no acceptance inference

Requirements

Type

Governance status

Requirement / target

Interpretation

FR-0016

Proposed

The system shall represent meaningful differences in stability, responsiveness, speed, and control authority.

Not accepted; linked Task states are implementation history only.

NFR-0009

NFR

Proposed

Keep aircraft, environment, collision, and invalid-state outcomes consistent for equivalent governed inputs and visibly recoverable at supported boundaries.

Not accepted; linked Task states are implementation history only.

All release Tasks

Task

Execution status

Outcome / component

Trace links — not acceptance

Execution evidence

AEROSIM-TS-86

Done

Each supported aircraft has one validated configuration for stability, responsiveness, speed, and control authority.

FR-0016 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-87

Done

The deterministic runtime and displayed handling characteristics consume the same validated aircraft configuration.

FR-0016 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-88

Done

Equivalent governed scenarios demonstrate repeatable, configuration-consistent differences between supported aircraft.

FR-0016, NFR-0009 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

KDD / advisory disposition

No feature-specific ADR recorded

Board disposition required: canonical Feature remains Proposed.

Simulated-panel recommendation: RETURN for exact-item human scope and architecture disposition; retain technical evidence without inferring approval.

Recorded sign-off

RootAtSkic · 2026-08-28T06:00:47.327Z · Proposed evidence

Task states: Done 3

AEROSIM-EP-3 · Believable Aircraft and World Behaviour · Feature profile

AEROSIM-FT-10 · Experience Environmental Conditions Affecting Flight

Proposed 4 Tasks 2 FR/NFR 2 design-linked · 2 non-visual

Actor / owner / stakeholders	An AeroSim player · AeroSim Scope · AeroSim Architecture and Delivery · AeroSim Architecture
Purpose and value	The player receives one coherent, observable capability.
Scope boundary	Apply selected wind, visibility, and environmental conditions to aircraft and world
Dependencies / questions	AEROSIM-FT-1, AEROSIM-FT-47 · No linked questions
Repositories / C4	corp-v1-aerosim/corp-v1-aerosim · Web application
UI/UX evidence	2/4 Tasks link to approved package AEROSIM-UIUX-REL-1.0.0 revision 6608; 2 Tasks are explicitly non-visual; refs: UIUX-100-FLIGHT-SETUP, UIUX-100-CHASE, UIUX-100-FULL-JOURNEY

Benefits / intended outcomes

The player receives one coherent, observable capability.
Selected environmental conditions produce visible world and aircraft effects.
The confirmed condition set remains consistent for the complete session.

Drawbacks, constraints and failure exposure

Representative browser or input configurations may expose an unmet outcome.
Reject launch with ENVIRONMENT_PRESET_NOT_FOUND and the field name when any preset ID is unknown.
Reject launch with ENVIRONMENT_PRESET_INVALID and JSON-pointer paths when any preset value is missing, non-finite, or outside its schema bound.

Lifecycle mismatch — no acceptance inference

Requirements

Type

Governance status

Requirement / target

Interpretation

FR-0017

Proposed

The system shall apply selected wind, visibility, and environmental conditions to aircraft and world.

Not accepted; linked Task states are implementation history only.

NFR-0009

NFR

Proposed

Keep aircraft, environment, collision, and invalid-state outcomes consistent for equivalent governed inputs and visibly recoverable at supported boundaries.

Not accepted; linked Task states are implementation history only.

All release Tasks

Task

Execution status

Outcome / component

Trace links — not acceptance

Execution evidence

AEROSIM-TS-76

Done

A launched Flight session owns one validated immutable condition snapshot covering wind, visibility, and governed environmental v…

FR-0017 · outcomes 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-77

Done

The deterministic runtime applies the frozen wind vector and configured variation to aircraft forces at each fixed step.

FR-0017 · outcomes 0 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-78

Done

The flight scene visibly reflects the frozen visibility and supported environmental settings.

FR-0017 · outcomes 0 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-79

Done

Aircraft and world effects remain calculated from the confirmed condition set for the complete session and reproduce within gover…

FR-0017, NFR-0009 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

KDD / advisory disposition

No feature-specific ADR recorded

Board disposition required: canonical Feature remains Proposed.

Simulated-panel recommendation: RETURN for exact-item human scope and architecture disposition; retain technical evidence without inferring approval.

Recorded sign-off

RootAtSkic · 2026-08-28T06:00:47.327Z · Proposed evidence

Task states: Done 4

AEROSIM-EP-3 · Believable Aircraft and World Behaviour · Feature profile

AEROSIM-FT-11 · Recover From or Conclude Invalid Flight States

Proposed 3 Tasks 2 FR/NFR 2 design-linked · 1 non-visual

Actor / owner / stakeholders	An AeroSim player · AeroSim Scope · AeroSim Architecture and Delivery · AeroSim Architecture
Purpose and value	The player receives one coherent, observable capability.
Scope boundary	Handle crashes, out-of-bounds states, and unrecoverable conditions clearly
Dependencies / questions	AEROSIM-FT-1, AEROSIM-FT-2 · No linked questions
Repositories / C4	corp-v1-aerosim/corp-v1-aerosim · Web application
UI/UX evidence	2/3 Tasks link to approved package AEROSIM-UIUX-REL-1.0.0 revision 6608; 1 Tasks are explicitly non-visual; refs: UIUX-100-WARNING, UIUX-100-OUTCOME-DEBRIEF, UIUX-100-FULL-JOURNEY

Benefits / intended outcomes

The player receives one coherent, observable capability.
Each governed crash, out-of-bounds, or unrecoverable state produces a clear outcome.
Every invalid-state outcome offers only valid recovery, retry, or exit actions.

Drawbacks, constraints and failure exposure

Representative browser or input configurations may expose an unmet outcome.
Return INVALID_EVENT_UNSUPPORTED when reasonCode has no explicit policy mapping; classify as UNRECOVERABLE with allowedActions=['EXIT'] rather than guessing recovery.
Return INVALID_EVENT_CORRUPT when IDs are empty, tick/count is invalid, or a required state digest is absent; stop the session and permit EXIT only.

Lifecycle mismatch — no acceptance inference

Requirements

Type

Governance status

Requirement / target

Interpretation

FR-0018

Proposed

The system shall handle crashes, out-of-bounds states, and unrecoverable conditions clearly.

Not accepted; linked Task states are implementation history only.

NFR-0009

NFR

Proposed

Keep aircraft, environment, collision, and invalid-state outcomes consistent for equivalent governed inputs and visibly recoverable at supported boundaries.

Not accepted; linked Task states are implementation history only.

All release Tasks

Task

Execution status

Outcome / component

Trace links — not acceptance

Execution evidence

AEROSIM-TS-80

Done

Crash, out-of-bounds, and unrecoverable runtime events transition to one typed recoverable, retryable, or terminal outcome.

FR-0018 · outcomes 0 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-81

Done

Each invalid-state outcome clearly presents only its permitted recovery, retry, or exit actions and executes the selected action…

FR-0018 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-82

Done

Every governed invalid-state scenario yields a repeatable clear outcome and exposes no invalid or dead-end action.

FR-0018, NFR-0009 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

KDD / advisory disposition

No feature-specific ADR recorded

Board disposition required: canonical Feature remains Proposed.

Simulated-panel recommendation: RETURN for exact-item human scope and architecture disposition; retain technical evidence without inferring approval.

Recorded sign-off

RootAtSkic · 2026-08-28T06:00:47.327Z · Proposed evidence

Task states: Done 3

AEROSIM-EP-4 · Complete a Free-Flight Session · Feature profile

AEROSIM-FT-3 · Control an Aircraft Continuously

Proposed 2 Tasks 7 FR/NFR 2 design-linked · 0 non-visual

Actor / owner / stakeholders	An AeroSim player · AeroSim Scope · AeroSim Architecture and Delivery · AeroSim Architecture
Purpose and value	The player receives one coherent, observable capability.
Scope boundary	Accept continuous player input throughout free flight
Dependencies / questions	AEROSIM-FT-1, AEROSIM-FT-11 · Q-0005, Q-0006, Q-0017
Repositories / C4	corp-v1-aerosim/corp-v1-aerosim · Web application
UI/UX evidence	2/2 Tasks link to approved package AEROSIM-UIUX-REL-1.0.0 revision 6608; 0 Tasks are explicitly non-visual; refs: UIUX-100-CHASE

Benefits / intended outcomes

The player receives one coherent, observable capability.
Supported control inputs update the active aircraft continuously during free flight.
Loss or change of input is shown and handled without silently transferring control.

Drawbacks, constraints and failure exposure

Prototype behaviour may not meet the current acceptance outcomes.
Reject samples from a device or ownership epoch that does not match ControlOwnership; publish no FlightControlCommand.
Reject non-finite values, regressing timestamps/sequences, unknown mappings, and samples older than staleAfterMs; publish an explicit unavailable/invalid reason.

Lifecycle mismatch — no acceptance inference

Requirements

Type

Governance status

Requirement / target

Interpretation

FR-0005

Proposed

The system shall accept continuous pitch, roll, yaw, and thrust values during flight.

Not accepted; linked Task states are implementation history only.

FR-0006

Proposed

The system shall apply valid control changes to subsequent aircraft motion.

Not accepted; linked Task states are implementation history only.

NFR-0001

NFR

Proposed

Maintain responsive rendering and simulation.

Not accepted; linked Task states are implementation history only.

NFR-0003

NFR

Proposed

Present control and state feedback within a measurable budget.

Not accepted; linked Task states are implementation history only.

NFR-0005

NFR

Proposed

Keep browser and deployed workload consumption within explicit budgets.

Not accepted; linked Task states are implementation history only.

NFR-0006

NFR

Proposed

Support the declared browser and input compatibility matrix.

Not accepted; linked Task states are implementation history only.

NFR-0010

NFR

Proposed

Keep flight controls, aircraft state, cameras, pause, outcomes, and recovery responsive within the declared latency budget.

Not accepted; linked Task states are implementation history only.

All release Tasks

Task

Execution status

Outcome / component

Trace links — not acceptance

Execution evidence

AEROSIM-TS-3

Done

Supported pitch, roll, yaw, and thrust inputs produce normalized authoritative control commands, while input loss or ownership ch…

FR-0005, NFR-0006 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-96

Done

Each valid authoritative control command affects subsequent aircraft motion continuously within the declared timing and resource…

FR-0006, NFR-0001, NFR-0003, NFR-0005, NFR-0010 · outcomes 0 · mapping does not establish requirement acceptance

task flow/evidence

KDD / advisory disposition

ADR-0001: Accepted

Board disposition required: canonical Feature remains Proposed.

Simulated-panel recommendation: RETURN for exact-item human scope and architecture disposition; retain technical evidence without inferring approval.

Recorded sign-off

RootAtSkic · 2026-08-24T15:06:15.606Z · Proposed evidence

Task states: Done 2

AEROSIM-EP-4 · Complete a Free-Flight Session · Feature profile

AEROSIM-FT-4 · Understand Aircraft State and Control Response

Proposed 3 Tasks 7 FR/NFR 1 design-linked · 2 non-visual

Actor / owner / stakeholders	An AeroSim player · AeroSim Scope · AeroSim Architecture and Delivery · AeroSim UI/UX, Architecture and Delivery · AeroSim Architecture
Purpose and value	The player receives one coherent, observable capability.
Scope boundary	Show the feedback needed to understand aircraft response
Dependencies / questions	AEROSIM-FT-3 · Q-0007, Q-0008, Q-0017
Repositories / C4	corp-v1-aerosim/corp-v1-aerosim · Web application
UI/UX evidence	1/3 Tasks link to approved package AEROSIM-UIUX-REL-1.0.0 revision 6608; 2 Tasks are explicitly non-visual; refs: UIUX-100-CHASE, UIUX-100-WARNING

Benefits / intended outcomes

The player receives one coherent, observable capability.
Critical aircraft state and control response remain visible and update from authoritative flight state.
The player can distinguish normal, warning, and invalid aircraft states during flight.

Drawbacks, constraints and failure exposure

Prototype behaviour may not meet the current acceptance outcomes.
Reject stale, regressing-step, mismatched-attempt, or non-finite AircraftState and render an explicit invalid-data state instead of carrying values forward as current.
Clamp only display-domain formatting such as heading wrap; do not repair or overwrite authoritative aircraft values.

Lifecycle mismatch — no acceptance inference

Requirements

Type

Governance status

Requirement / target

Interpretation

FR-0007

Proposed

The system shall present attitude, speed, altitude, heading, and control position.

Not accepted; linked Task states are implementation history only.

FR-0008

Proposed

The system shall present timely control-response cues and warnings.

Not accepted; linked Task states are implementation history only.

NFR-0001

NFR

Proposed

Maintain responsive rendering and simulation.

Not accepted; linked Task states are implementation history only.

NFR-0003

NFR

Proposed

Present control and state feedback within a measurable budget.

Not accepted; linked Task states are implementation history only.

NFR-0005

NFR

Proposed

Keep browser and deployed workload consumption within explicit budgets.

Not accepted; linked Task states are implementation history only.

NFR-0006

NFR

Proposed

Support the declared browser and input compatibility matrix.

Not accepted; linked Task states are implementation history only.

NFR-0010

NFR

Proposed

Keep flight controls, aircraft state, cameras, pause, outcomes, and recovery responsive within the declared latency budget.

Not accepted; linked Task states are implementation history only.

All release Tasks

Task

Execution status

Outcome / component

Trace links — not acceptance

Execution evidence

AEROSIM-TS-4

Done

Attitude, speed, altitude, heading, and control position remain visible and update from the authoritative flight state.

FR-0007, NFR-0001, NFR-0003, NFR-0006, NFR-0010 · outcomes 0 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-5

Done

Normal, warning, and invalid aircraft states are distinguishable through timely, prioritized control-response cues and warnings.

FR-0008, NFR-0003, NFR-0005, NFR-0010 · outcomes 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-125

Done

Delivered instruments, contextual warnings, and controller recovery match the approved Minimal Edge HUD and warning screen.

FR-0007, FR-0008, NFR-0001, NFR-0003, NFR-0005, NFR-0006, NFR-0010 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

KDD / advisory disposition

ADR-0001: Accepted

Board disposition required: canonical Feature remains Proposed.

Simulated-panel recommendation: RETURN for exact-item human scope and architecture disposition; retain technical evidence without inferring approval.

Recorded sign-off

RootAtSkic · 2026-08-24T15:06:15.606Z · Proposed evidence

Task states: Done 3

AEROSIM-EP-4 · Complete a Free-Flight Session · Feature profile

AEROSIM-FT-5 · End, Retry, or Restart a Flight Session

Proposed 5 Tasks 6 FR/NFR 4 design-linked · 1 non-visual

Actor / owner / stakeholders	An AeroSim player · AeroSim Scope · AeroSim Architecture and Delivery · AeroSim Architecture
Purpose and value	The player receives one coherent, observable capability.
Scope boundary	Conclude free flight and establish a known retry or restart state
Dependencies / questions	AEROSIM-FT-3 · Q-0009, Q-0010
Repositories / C4	corp-v1-aerosim/corp-v1-aerosim · Web application
UI/UX evidence	4/5 Tasks link to approved package AEROSIM-UIUX-REL-1.0.0 revision 6608; 1 Tasks are explicitly non-visual; refs: UIUX-100-PAUSE, UIUX-100-OUTCOME-DEBRIEF, UIUX-100-CHASE, UIUX-100-WARNING

Benefits / intended outcomes

The player receives one coherent, observable capability.
The player can deliberately end a flight and see its recorded outcome.
Retry and restart each establish the documented known starting state.

Drawbacks, constraints and failure exposure

Prototype behaviour may not meet the current acceptance outcomes.
Reject a terminal request for a stale attempt or a session already outside ACTIVE/PAUSED; do not overwrite an existing outcome.
Treat duplicate commandId or repeated terminal requests after commit as idempotent and return the original outcome reference.

Lifecycle mismatch — no acceptance inference

Requirements

Type

Governance status

Requirement / target

Interpretation

FR-0009

Proposed

The system shall produce a clear free-flight outcome or abort and restart from the initial state.

Not accepted; linked Task states are implementation history only.

NFR-0001

NFR

Proposed

Maintain responsive rendering and simulation.

Not accepted; linked Task states are implementation history only.

NFR-0002

NFR

Proposed

Reproduce defined simulation and restart results.

Not accepted; linked Task states are implementation history only.

NFR-0005

NFR

Proposed

Keep browser and deployed workload consumption within explicit budgets.

Not accepted; linked Task states are implementation history only.

NFR-0006

NFR

Proposed

Support the declared browser and input compatibility matrix.

Not accepted; linked Task states are implementation history only.

NFR-0010

NFR

Proposed

Keep flight controls, aircraft state, cameras, pause, outcomes, and recovery responsive within the declared latency budget.

Not accepted; linked Task states are implementation history only.

All release Tasks

Task

Execution status

Outcome / component

Trace links — not acceptance

Execution evidence

AEROSIM-TS-6

Done

The player can deliberately end or abort an active flight and receives one explicit recorded session outcome.

FR-0009, NFR-0006, NFR-0010 · outcomes 0 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-97

Done

Retry and restart each dispose transient flight state and establish their documented known starting state reproducibly.

FR-0009, NFR-0001, NFR-0002, NFR-0005, NFR-0006, NFR-0010 · outcomes 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-142

Done

END FLIGHT concludes the active session, presents its recorded outcome, and offers valid retry, restart, or exit actions instead…

FR-0009 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-156

Done

Direct Restart, Menu/Resume, and dialog-scoped Menu/Restart are visible topmost hit targets and work through ordinary user input…

FR-0009 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-159

Done

A flight attempt changes identity only after an explicit visible restart or terminal recovery decision, never as a hidden respons…

FR-0009 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

KDD / advisory disposition

ADR-0001: Accepted

Board disposition required: canonical Feature remains Proposed.

Simulated-panel recommendation: RETURN for exact-item human scope and architecture disposition; retain technical evidence without inferring approval.

Recorded sign-off

RootAtSkic · 2026-08-24T15:06:15.606Z · Proposed evidence

Task states: Done 5

AEROSIM-EP-4 · Complete a Free-Flight Session · Feature profile

AEROSIM-FT-12 · Fly Using the Primary Chase Camera

Proposed 5 Tasks 2 FR/NFR 3 design-linked · 2 non-visual

Actor / owner / stakeholders	An AeroSim player · AeroSim Scope · AeroSim Architecture and Delivery · AeroSim UI/UX, Architecture and Delivery · AeroSim Architecture
Purpose and value	The player receives one coherent, observable capability.
Scope boundary	Provide the primary full-screen chase-view flight experience
Dependencies / questions	AEROSIM-FT-3, AEROSIM-FT-45 · No linked questions
Repositories / C4	corp-v1-aerosim/corp-v1-aerosim · Web application
UI/UX evidence	3/5 Tasks link to approved package AEROSIM-UIUX-REL-1.0.0 revision 6608; 2 Tasks are explicitly non-visual; refs: UIUX-100-CHASE

Benefits / intended outcomes

The player receives one coherent, observable capability.
The initial active-flight view is the chase camera and follows the controlled aircraft continuously.
Aircraft, flight direction, and nearby hazards remain legible in the representative viewport.

Drawbacks, constraints and failure exposure

Representative browser or input configurations may expose an unmet outcome.
Reject start when the aircraft entity is absent, the attempt identifier differs from the active attempt, or any pose/configuration number is non-finite; do not activate a camera.
Ignore an AircraftFrame whose attemptId is stale or whose simulationStep is not greater than the last applied step, retaining the last valid camera state.

Lifecycle mismatch — no acceptance inference

Requirements

Type

Governance status

Requirement / target

Interpretation

FR-0019

Proposed

The system shall provide the primary full-screen chase-view flight experience.

Not accepted; linked Task states are implementation history only.

NFR-0010

NFR

Proposed

Keep flight controls, aircraft state, cameras, pause, outcomes, and recovery responsive within the declared latency budget.

Not accepted; linked Task states are implementation history only.

All release Tasks

Task

Execution status

Outcome / component

Trace links — not acceptance

Execution evidence

AEROSIM-TS-89

Done

Active flight starts in the primary chase view, which follows the controlled aircraft continuously without becoming a second owne…

FR-0019 · outcomes 0 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-90

Done

The representative viewport keeps the aircraft, flight direction, and nearby hazards legible while the chase camera follows the a…

FR-0019, NFR-0010 · outcomes 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-126

Done

The primary gameplay viewport matches the approved aircraft-visible Chase composition, camera control, Menu control, and shared H…

FR-0019, NFR-0010 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-140

Done

The default chase camera frames and follows the controlled aircraft continuously from the first launched frame.

FR-0019 · outcomes 0 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-155

Done

After launch, /flight mounts one route-specific runtime-only screen with no legacy setup/Foundation selectors or content and boun…

FR-0019 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

KDD / advisory disposition

No feature-specific ADR recorded

Board disposition required: canonical Feature remains Proposed.

Simulated-panel recommendation: RETURN for exact-item human scope and architecture disposition; retain technical evidence without inferring approval.

Recorded sign-off

RootAtSkic · 2026-08-28T06:00:47.327Z · Proposed evidence

Task states: Done 5

AEROSIM-EP-4 · Complete a Free-Flight Session · Feature profile

AEROSIM-FT-13 · Pause and Resume a Flight

Proposed 2 Tasks 2 FR/NFR 1 design-linked · 1 non-visual

Actor / owner / stakeholders	An AeroSim player · AeroSim Scope · AeroSim Architecture and Delivery · AeroSim Architecture
Purpose and value	The player receives one coherent, observable capability.
Scope boundary	Suspend active simulation and resume without losing context
Dependencies / questions	AEROSIM-FT-3 · No linked questions
Repositories / C4	corp-v1-aerosim/corp-v1-aerosim · Web application
UI/UX evidence	1/2 Tasks link to approved package AEROSIM-UIUX-REL-1.0.0 revision 6608; 1 Tasks are explicitly non-visual; refs: UIUX-100-PAUSE

Benefits / intended outcomes

The player receives one coherent, observable capability.
Pause visibly suspends governed simulation progression.
Resume continues from the preserved paused state without an implicit restart.

Drawbacks, constraints and failure exposure

Representative browser or input configurations may expose an unmet outcome.
Reject PauseRequested unless its attempt is ACTIVE and matches the current attempt; the session and clock remain unchanged.
Treat a repeated commandId as idempotent: return the original PauseAccepted and do not create another snapshot or transition.

Lifecycle mismatch — no acceptance inference

Requirements

Type

Governance status

Requirement / target

Interpretation

FR-0020

Proposed

The system shall suspend active simulation and resume without losing context.

Not accepted; linked Task states are implementation history only.

NFR-0010

NFR

Proposed

Keep flight controls, aircraft state, cameras, pause, outcomes, and recovery responsive within the declared latency budget.

Not accepted; linked Task states are implementation history only.

All release Tasks

Task

Execution status

Outcome / component

Trace links — not acceptance

Execution evidence

AEROSIM-TS-91

Done

A valid pause atomically freezes fixed-step advancement and captures one typed attempt snapshot.

FR-0020, NFR-0010 · outcomes 0 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-92

Done

Resume restarts fixed-step processing from the snapshot without a time jump, duplicate command, reset, or changed attempt identit…

FR-0020, NFR-0010 · outcomes 1 · mapping does not establish requirement acceptance

task flow/evidence

KDD / advisory disposition

No feature-specific ADR recorded

Board disposition required: canonical Feature remains Proposed.

Simulated-panel recommendation: RETURN for exact-item human scope and architecture disposition; retain technical evidence without inferring approval.

Recorded sign-off

RootAtSkic · 2026-08-28T06:00:47.327Z · Proposed evidence

Task states: Done 2

AEROSIM-EP-4 · Complete a Free-Flight Session · Feature profile

AEROSIM-FT-14 · Change to Secondary Camera Views

Proposed 6 Tasks 2 FR/NFR 6 design-linked · 0 non-visual

Actor / owner / stakeholders	An AeroSim player · AeroSim Scope · AeroSim Architecture and Delivery · AeroSim Architecture
Purpose and value	The player receives one coherent, observable capability.
Scope boundary	Change supported camera views without losing control continuity
Dependencies / questions	AEROSIM-FT-12 · No linked questions
Repositories / C4	corp-v1-aerosim/corp-v1-aerosim · Web application
UI/UX evidence	6/6 Tasks link to approved package AEROSIM-UIUX-REL-1.0.0 revision 6608; 0 Tasks are explicitly non-visual; refs: UIUX-100-CAMERAS, UIUX-100-CHASE

Benefits / intended outcomes

The player receives one coherent, observable capability.
Each supported secondary camera is deliberately selectable during flight.
Changing camera does not alter aircraft state or control ownership.

Drawbacks, constraints and failure exposure

Representative browser or input configurations may expose an unmet outcome.
Fail registry construction on an empty, duplicate, or blank identifier, missing factory, or missing lifecycle policy; publish no partial registry.
Return UnsupportedSecondaryCamera for an identifier absent from the registry; do not substitute the primary camera or another secondary view.

Lifecycle mismatch — no acceptance inference

Requirements

Type

Governance status

Requirement / target

Interpretation

FR-0021

Proposed

The system shall change supported camera views without losing control continuity.

Not accepted; linked Task states are implementation history only.

NFR-0010

NFR

Proposed

Keep flight controls, aircraft state, cameras, pause, outcomes, and recovery responsive within the declared latency budget.

Not accepted; linked Task states are implementation history only.

All release Tasks

Task

Execution status

Outcome / component

Trace links — not acceptance

Execution evidence

AEROSIM-TS-93

Done

Every supported secondary view resolves through one typed identifier to a camera rig with explicit lifecycle behavior.

FR-0021 · outcomes 0 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-94

Done

One deliberate valid selection activates the requested view while preserving the simulation attempt and input owner.

FR-0021, NFR-0010 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-95

Done

Trace and browser checks show supported, rapid, repeated, and invalid selections leave aircraft state, attempt identity, and cont…

FR-0021, NFR-0010 · outcomes 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-151

Done

Chase, Cockpit, Orbit, and Fly-by are production aircraft-bound rigs whose rendered semantics remain usable while the authoritati…

FR-0021 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-161

Done

Chase, Cockpit, Orbit, and Fly-by retain a usable world view and correct aircraft framing throughout sustained pilot-controlled f…

FR-0021 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-163

Done

Every production camera renders exactly one intended active-aircraft presentation with no detached wing, duplicated aircraft mesh…

FR-0021 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

KDD / advisory disposition

No feature-specific ADR recorded

Board disposition required: canonical Feature remains Proposed.

Simulated-panel recommendation: RETURN for exact-item human scope and architecture disposition; retain technical evidence without inferring approval.

Recorded sign-off

RootAtSkic · 2026-08-28T06:00:47.327Z · Proposed evidence

Task states: Done 6

AEROSIM-EP-5 · Configure and Launch a Flight · Feature profile

AEROSIM-FT-6 · Choose the Flying World

Proposed 6 Tasks 6 FR/NFR 2 design-linked · 4 non-visual

Actor / owner / stakeholders	An AeroSim player · AeroSim Scope · AeroSim Architecture and Delivery · AeroSim UI/UX, Architecture and Delivery · AeroSim Architecture
Purpose and value	The player receives one coherent, observable capability.
Scope boundary	Select one supported world or terrain before flight
Dependencies / questions	AEROSIM-FT-47 · Q-0011
Repositories / C4	corp-v1-aerosim/corp-v1-aerosim · Web application
UI/UX evidence	2/6 Tasks link to approved package AEROSIM-UIUX-REL-1.0.0 revision 6608; 4 Tasks are explicitly non-visual; refs: UIUX-100-FLIGHT-SETUP

Benefits / intended outcomes

The player receives one coherent, observable capability.
Each available world is identifiable before selection and resolves to one canonical terrain configuration.
Launch loads exactly the world confirmed in pre-flight.

Drawbacks, constraints and failure exposure

Prototype behaviour may not meet the current acceptance outcomes.
Absent, duplicate, disabled, or unknown world entries return the matching catalogue code and cannot produce WorldSnapshot.
A catalogue-version change invalidates an existing confirmation.

Lifecycle mismatch — no acceptance inference

Requirements

Type

Governance status

Requirement / target

Interpretation

FR-0010

Proposed

The system shall list each supported flying scene with an identifiable name and description.

Not accepted; linked Task states are implementation history only.

FR-0011

Proposed

The system shall load the chosen scene for the next session.

Not accepted; linked Task states are implementation history only.

NFR-0001

NFR

Proposed

Maintain responsive rendering and simulation.

Not accepted; linked Task states are implementation history only.

NFR-0005

NFR

Proposed

Keep browser and deployed workload consumption within explicit budgets.

Not accepted; linked Task states are implementation history only.

NFR-0006

NFR

Proposed

Support the declared browser and input compatibility matrix.

Not accepted; linked Task states are implementation history only.

NFR-0011

NFR

Proposed

Ensure the launched session exactly reflects the confirmed world, aircraft, conditions, controls, and camera.

Not accepted; linked Task states are implementation history only.

All release Tasks

Task

Execution status

Outcome / component

Trace links — not acceptance

Execution evidence

AEROSIM-TS-7

Done

Each supported flying world is shown with an identifiable name and description, and one selection resolves to its canonical terra…

FR-0010 · outcomes 0 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-111

Done

The launch configuration contains exactly the canonical world identifier and terrain configuration confirmed during pre-flight.

FR-0011, NFR-0011 · outcomes 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-112

Done

The new flight session renders and collides against the world identified by the immutable launch configuration.

FR-0011, NFR-0011 · outcomes 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-113

Done

World listing, confirmation, and launch pass the declared timing, browser-resource, namespace-resource, and compatibility checks.

NFR-0001, NFR-0005, NFR-0006 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-123

Done

Every supported world appears and selects through the approved Flight Setup presentation without catalogue or navigation drift.

FR-0010, FR-0011, NFR-0001, NFR-0005, NFR-0006, NFR-0011 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-134

Done

A player starting from Home selects one supported world before pre-flight, and the exact confirmed world remains present through…

FR-0011 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

KDD / advisory disposition

ADR-0002: Accepted

Board disposition required: canonical Feature remains Proposed.

Simulated-panel recommendation: RETURN for exact-item human scope and architecture disposition; retain technical evidence without inferring approval.

Recorded sign-off

RootAtSkic · 2026-08-24T15:06:15.606Z · Proposed evidence

Task states: Done 6

AEROSIM-EP-5 · Configure and Launch a Flight · Feature profile

AEROSIM-FT-7 · Choose and Confirm the Aircraft for This Flight

Proposed 6 Tasks 6 FR/NFR 2 design-linked · 4 non-visual

Actor / owner / stakeholders	An AeroSim player · AeroSim Scope · AeroSim Architecture and Delivery · AeroSim UI/UX, Architecture and Delivery · AeroSim Architecture
Purpose and value	The player receives one coherent, observable capability.
Scope boundary	Choose a supported aircraft for the planned flight and confirm its model and flight parameters.
Dependencies / questions	No Feature dependencies · Q-0012
Repositories / C4	corp-v1-aerosim/corp-v1-aerosim · Web application
UI/UX evidence	2/6 Tasks link to approved package AEROSIM-UIUX-REL-1.0.0 revision 6608; 4 Tasks are explicitly non-visual; refs: UIUX-100-HANGAR, UIUX-100-FLIGHT-SETUP

Benefits / intended outcomes

The player receives one coherent, observable capability.
The player can list, choose, and confirm a supported aircraft for the planned flight.
Launch applies the confirmed aircraft model and flight parameters.

Drawbacks, constraints and failure exposure

Prototype behaviour may not meet the current acceptance outcomes.
Absent, duplicate, disabled, unknown, or incomplete catalogue entry returns the corresponding code and cannot be confirmed.
A catalogue or parameterVersion change invalidates prior confirmation.

Lifecycle mismatch — no acceptance inference

Requirements

Type

Governance status

Requirement / target

Interpretation

FR-0012

Proposed

The system shall list each supported aircraft with identifiable characteristics.

Not accepted; linked Task states are implementation history only.

FR-0013

Proposed

The system shall apply the chosen aircraft model and flight parameters.

Not accepted; linked Task states are implementation history only.

NFR-0001

NFR

Proposed

Maintain responsive rendering and simulation.

Not accepted; linked Task states are implementation history only.

NFR-0005

NFR

Proposed

Keep browser and deployed workload consumption within explicit budgets.

Not accepted; linked Task states are implementation history only.

NFR-0006

NFR

Proposed

Support the declared browser and input compatibility matrix.

Not accepted; linked Task states are implementation history only.

NFR-0011

NFR

Proposed

Ensure the launched session exactly reflects the confirmed world, aircraft, conditions, controls, and camera.

Not accepted; linked Task states are implementation history only.

All release Tasks

Task

Execution status

Outcome / component

Trace links — not acceptance

Execution evidence

AEROSIM-TS-8

Done

The player can identify supported aircraft by governed characteristics, select one, and visibly confirm it for the planned flight.

FR-0012 · outcomes 0 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-114

Done

The immutable launch configuration contains exactly the confirmed aircraft model identifier and governed flight parameters.

FR-0013, NFR-0011 · outcomes 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-115

Done

The launched session uses the confirmed visual aircraft model and the corresponding deterministic flight parameters.

FR-0013, NFR-0011 · outcomes 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-116

Done

Aircraft listing, confirmation, and launch pass the declared timing, browser-resource, namespace-resource, and compatibility chec…

NFR-0001, NFR-0005, NFR-0006 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-122

Done

Trainer, Jet, and Utility selection states match the approved cards, imagery, active treatment, confirmation, and navigation.

FR-0012, FR-0013, NFR-0001, NFR-0005, NFR-0006, NFR-0011 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-133

Done

Start Your Flight opens Flight Setup directly, where the player can select and confirm a supported aircraft alongside the other f…

FR-0012 · outcomes 0 · mapping does not establish requirement acceptance

task flow/evidence

KDD / advisory disposition

ADR-0002: Accepted

Board disposition required: canonical Feature remains Proposed.

Simulated-panel recommendation: RETURN for exact-item human scope and architecture disposition; retain technical evidence without inferring approval.

Recorded sign-off

RootAtSkic · 2026-08-24T15:06:15.606Z · Proposed evidence

Task states: Done 6

AEROSIM-EP-5 · Configure and Launch a Flight · Feature profile

AEROSIM-FT-15 · Choose Flight and Environmental Conditions

Proposed 5 Tasks 2 FR/NFR 2 design-linked · 3 non-visual

Actor / owner / stakeholders	An AeroSim player · AeroSim Scope · AeroSim Architecture and Delivery · AeroSim UI/UX, Architecture and Delivery · AeroSim Architecture
Purpose and value	The player receives one coherent, observable capability.
Scope boundary	Select supported flight presets and environmental conditions
Dependencies / questions	AEROSIM-FT-10 · No linked questions
Repositories / C4	corp-v1-aerosim/corp-v1-aerosim · Web application
UI/UX evidence	2/5 Tasks link to approved package AEROSIM-UIUX-REL-1.0.0 revision 6608; 3 Tasks are explicitly non-visual; refs: UIUX-100-FLIGHT-SETUP

Benefits / intended outcomes

The player receives one coherent, observable capability.
Supported flight and environmental conditions are distinguishable and selectable before launch.
The launched session receives exactly the confirmed condition values.

Drawbacks, constraints and failure exposure

Representative browser or input configurations may expose an unmet outcome.
An unknown preset, non-finite numeric field, out-of-range value, or incompatible field combination returns a field-specific validation result and does not replace the last valid draft.
A catalogue-version change invalidates confirmation made against the prior catalogue and requires reconfirmation.

Lifecycle mismatch — no acceptance inference

Requirements

Type

Governance status

Requirement / target

Interpretation

FR-0022

Proposed

The system shall select supported flight presets and environmental conditions.

Not accepted; linked Task states are implementation history only.

NFR-0011

NFR

Proposed

Ensure the launched session exactly reflects the confirmed world, aircraft, conditions, controls, and camera.

Not accepted; linked Task states are implementation history only.

All release Tasks

Task

Execution status

Outcome / component

Trace links — not acceptance

Execution evidence

AEROSIM-TS-98

Done

The pre-flight configurator exposes validated condition options as one governed selection state.

FR-0022 · outcomes 0 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-99

Done

The flight session receives exactly the flight preset and environmental values confirmed during pre-flight.

FR-0022, NFR-0011 · outcomes 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-100

Done

Automated evidence proves that displayed, confirmed, launched, and runtime condition values are equal for every supported preset…

FR-0022, NFR-0011 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-124

Done

Supported condition presets display, validate, select, and reach pre-flight through the approved controls and states.

FR-0022, NFR-0011 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-135

Done

The condition preset selected in Flight Setup survives pre-flight review and the launched session receives exactly those confirme…

FR-0022 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

KDD / advisory disposition

No feature-specific ADR recorded

Board disposition required: canonical Feature remains Proposed.

Simulated-panel recommendation: RETURN for exact-item human scope and architecture disposition; retain technical evidence without inferring approval.

Recorded sign-off

RootAtSkic · 2026-08-28T06:00:47.327Z · Proposed evidence

Task states: Done 5

AEROSIM-EP-5 · Configure and Launch a Flight · Feature profile

AEROSIM-FT-16 · Configure and Verify Flight Controls

Proposed 5 Tasks 2 FR/NFR 4 design-linked · 1 non-visual

Actor / owner / stakeholders	An AeroSim player · AeroSim Scope · AeroSim Architecture and Delivery · AeroSim Architecture
Purpose and value	The player receives one coherent, observable capability.
Scope boundary	Choose an input method and verify essential controls before launch
Dependencies / questions	AEROSIM-FT-3 · No linked questions
Repositories / C4	corp-v1-aerosim/corp-v1-aerosim · Web application
UI/UX evidence	4/5 Tasks link to approved package AEROSIM-UIUX-REL-1.0.0 revision 6608; 1 Tasks are explicitly non-visual; refs: UIUX-100-PREFLIGHT, UIUX-100-CHASE

Benefits / intended outcomes

The player receives one coherent, observable capability.
The chosen input method exposes its required control mapping before launch.
The player can verify essential input and receives a visible result for missing or invalid controls.

Drawbacks, constraints and failure exposure

Representative browser or input configurations may expose an unmet outcome.
Unsupported method, duplicate essential binding, missing essential action, or profile-version mismatch produces an explicit profile validation code and cannot be confirmed.
Disconnecting or changing the selected device invalidates the current confirmation.

Lifecycle mismatch — no acceptance inference

Requirements

Type

Governance status

Requirement / target

Interpretation

FR-0023

Proposed

The system shall choose an input method and verify essential controls before launch.

Not accepted; linked Task states are implementation history only.

NFR-0011

NFR

Proposed

Ensure the launched session exactly reflects the confirmed world, aircraft, conditions, controls, and camera.

Not accepted; linked Task states are implementation history only.

All release Tasks

Task

Execution status

Outcome / component

Trace links — not acceptance

Execution evidence

AEROSIM-TS-101

Done

Selecting a supported input method shows its complete required control mapping before launch.

FR-0023 · outcomes 0 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-102

Done

The player can exercise essential controls before launch and receives a visible, specific result when a required control is absen…

FR-0023 · outcomes 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-103

Done

The launched session uses the exact input method and required mapping shown and verified during pre-flight.

FR-0023, NFR-0011 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-104

Done

Configuration-round-trip and invalid-control tests prove that only a successfully verified control profile reaches a session and…

FR-0023, NFR-0011 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-153

Done

The exact bindings declared and confirmed before launch are the only runtime mapping for pitch, bank, yaw, throttle, gear, and fl…

FR-0023 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

KDD / advisory disposition

No feature-specific ADR recorded

Board disposition required: canonical Feature remains Proposed.

Simulated-panel recommendation: RETURN for exact-item human scope and architecture disposition; retain technical evidence without inferring approval.

Recorded sign-off

RootAtSkic · 2026-08-28T06:00:47.327Z · Proposed evidence

Task states: Done 5

AEROSIM-EP-5 · Configure and Launch a Flight · Feature profile

AEROSIM-FT-17 · Select the Initial Camera

Proposed 7 Tasks 2 FR/NFR 7 design-linked · 0 non-visual

Actor / owner / stakeholders	An AeroSim player · AeroSim Scope · AeroSim Architecture and Delivery · AeroSim UI/UX, Architecture and Delivery · AeroSim Architecture
Purpose and value	The player receives one coherent, observable capability.
Scope boundary	Choose the supported camera active when flight begins
Dependencies / questions	AEROSIM-FT-12 · No linked questions
Repositories / C4	corp-v1-aerosim/corp-v1-aerosim · Web application
UI/UX evidence	7/7 Tasks link to approved package AEROSIM-UIUX-REL-1.0.0 revision 6608; 0 Tasks are explicitly non-visual; refs: UIUX-100-PREFLIGHT

Benefits / intended outcomes

The player receives one coherent, observable capability.
Every supported initial camera is selectable in pre-flight.
The launched session starts with the confirmed camera.

Drawbacks, constraints and failure exposure

Representative browser or input configurations may expose an unmet outcome.
Unknown, disabled, duplicate, or missing cameraId cannot be confirmed and returns its registry validation code.
A registry-version change invalidates an older confirmation.

Lifecycle mismatch — no acceptance inference

Requirements

Type

Governance status

Requirement / target

Interpretation

FR-0024

Proposed

The system shall choose the supported camera active when flight begins.

Not accepted; linked Task states are implementation history only.

NFR-0011

NFR

Proposed

Ensure the launched session exactly reflects the confirmed world, aircraft, conditions, controls, and camera.

Not accepted; linked Task states are implementation history only.

All release Tasks

Task

Execution status

Outcome / component

Trace links — not acceptance

Execution evidence

AEROSIM-TS-105

Done

Every supported initial camera is identifiable, selectable, and confirmable in pre-flight.

FR-0024 · outcomes 0 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-106

Done

The first rendered flight frame uses the camera confirmed during pre-flight.

FR-0024, NFR-0011 · outcomes 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-107

Done

Automated evidence proves equality between the displayed, confirmed, launched, and initially active camera for every supported op…

FR-0024, NFR-0011 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-136

Done

A player can confirm a supported initial camera during pre-flight and continue to launch with that camera active.

FR-0024 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-147

Done

A player can select any supported initial camera through the complete visible card, immediately see an unambiguous selected state…

FR-0024 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-149

Done

A player sees and operates one polished, design-conformant camera-selection body that makes all four initial-camera choices equal…

FR-0024 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-171

ToBeReleased

A player selects an available initial camera in one action and can launch as soon as the remaining required pre-flight selections…

FR-0024 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

KDD / advisory disposition

No feature-specific ADR recorded

Board disposition required: canonical Feature remains Proposed.

Simulated-panel recommendation: RETURN for exact-item human scope and architecture disposition; retain technical evidence without inferring approval.

Recorded sign-off

RootAtSkic · 2026-08-28T06:00:47.327Z · Proposed evidence

Task states: Done 6 · ToBeReleased 1

AEROSIM-EP-5 · Configure and Launch a Flight · Feature profile

AEROSIM-FT-18 · Review the Pre-Flight Summary and Launch

Proposed 6 Tasks 2 FR/NFR 6 design-linked · 0 non-visual

Actor / owner / stakeholders	An AeroSim player · AeroSim Scope · AeroSim Architecture and Delivery · AeroSim UI/UX, Architecture and Delivery · AeroSim Architecture
Purpose and value	The player receives one coherent, observable capability.
Scope boundary	Review the complete setup and deliberately launch one session
Dependencies / questions	AEROSIM-FT-6, AEROSIM-FT-7, AEROSIM-FT-15, AEROSIM-FT-16, AEROSIM-FT-17 · No linked questions
Repositories / C4	corp-v1-aerosim/corp-v1-aerosim · Web application
UI/UX evidence	6/6 Tasks link to approved package AEROSIM-UIUX-REL-1.0.0 revision 6608; 0 Tasks are explicitly non-visual; refs: UIUX-100-PREFLIGHT, UIUX-100-FULL-JOURNEY

Benefits / intended outcomes

The player receives one coherent, observable capability.
The summary shows aircraft, world, conditions, controls, and initial camera from canonical selections.
One deliberate launch action creates one session from that displayed configuration.

Drawbacks, constraints and failure exposure

Representative browser or input configurations may expose an unmet outcome.
A missing, invalid, stale, cross-version, or changed section sets readyToLaunch false, identifies the section and reason, and emits no launchable summary hash.
Summary rendering never fills missing sections from defaults or independent component state.

Lifecycle mismatch — no acceptance inference

Requirements

Type

Governance status

Requirement / target

Interpretation

FR-0025

Proposed

The system shall review the complete setup and deliberately launch one session.

Not accepted; linked Task states are implementation history only.

NFR-0011

NFR

Proposed

Ensure the launched session exactly reflects the confirmed world, aircraft, conditions, controls, and camera.

Not accepted; linked Task states are implementation history only.

All release Tasks

Task

Execution status

Outcome / component

Trace links — not acceptance

Execution evidence

AEROSIM-TS-108

Done

One review summary shows the exact confirmed aircraft, world, flight and environmental conditions, controls, and initial camera.

FR-0025, NFR-0011 · outcomes 0 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-109

Done

One deliberate launch action freezes the displayed configuration and creates exactly one flight session from it.

FR-0025, NFR-0011 · outcomes 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-110

Done

End-to-end evidence proves that each reviewed configuration creates one session whose world, aircraft, conditions, controls, and…

FR-0025, NFR-0011 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-127

Done

One deterministic browser suite proves every in-scope Penpot screen, state, action, and destination is owned and implemented with…

FR-0025, NFR-0011 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-137

Done

The normal signed-in journey presents aircraft, world, conditions, controls, and initial camera together and offers one deliberat…

FR-0025 · outcomes 0, 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-138

Done

The /flight route remains inactive and cannot start until a complete reviewed configuration produces one deliberate launch event.

FR-0025 · outcomes 1 · mapping does not establish requirement acceptance

task flow/evidence

KDD / advisory disposition

No feature-specific ADR recorded

Board disposition required: canonical Feature remains Proposed.

Simulated-panel recommendation: RETURN for exact-item human scope and architecture disposition; retain technical evidence without inferring approval.

Recorded sign-off

RootAtSkic · 2026-08-28T06:00:47.327Z · Proposed evidence

Task states: Done 6

AEROSIM-EP-9 · Release AeroSim 1.0.0 · Feature profile

AEROSIM-FT-53 · Promote and verify AeroSim Release 1.0.0

Approved for Solution 5 Tasks 2 FR/NFR 1 design-linked · 0 non-visual

Actor / owner / stakeholders	The AeroSim release team · AeroSim Releases · AeroSim Architecture and Delivery · AeroSim Architecture
Purpose and value	One exact release package prevents unreviewed artifact drift, inferred deployment, and premature lifecycle closure.
Scope boundary	Release-management work for AeroSim 1.0.0 from immutable-candidate freeze through approval-gated production verification and canonical Task closure; no deployment occurs from this documentation change.
Dependencies / questions	No Feature dependencies · No linked questions
Repositories / C4	corp-v1-aerosim/corp-v1-aerosim-documentation; corp-v1-aerosim/corp-v1-aerosim; corp-v1-aerosim/gondor-v1-tmpl-aerosim; corp-v1-aerosim/gondor-v1-aerosim, corp-v1-aerosim/corp-v1-aerosim-documentation, corp-v1-aerosim/gondor-v1-tmpl-aerosim; corp-v1-aerosim/gondor-v1-aerosim, corp-v1-aerosim/gondor-v1-aerosim; corp-v1-aerosim/corp-v1-aerosim-documentation, corp-v1-aerosim/corp-v1-aerosim · Web application, API Service, Documentation site
UI/UX evidence	1/5 Tasks link to approved package AEROSIM-UIUX-REL-1.0.0 revision 6608; 0 Tasks are explicitly non-visual; refs: UIUX-100-FULL-JOURNEY

Benefits / intended outcomes

One exact release package prevents unreviewed artifact drift, inferred deployment, and premature lifecycle closure.
One immutable candidate binds application source, Harbor digests, chart, template, rendered GitOps revision, and mismatch rejection.
Release notes and the operational plan reconcile all 162 Tasks in the governed Release 1.0.0 Feature inventory, readiness, migration, compatibility, rollback, capacity, risk, owners, and acceptance criteria.

Drawbacks, constraints and failure exposure

Mutable or mismatched source, image, chart, template, or rendered references could deploy a candidate that was not reviewed.
Treating documentation, CI, artifact publication, PR creation, or merge as deployment evidence could close the release prematurely.
Reject tag-only, branch-only, latest, missing, inaccessible, or mutable candidate identities.

Lifecycle mismatch — no acceptance inference

Requirements

Type

Governance status

Requirement / target

Interpretation

FR-0059

Proposed

The system shall establish Docker, Helm, Harbor, Gitea Actions, and Argo CD GitOps.

Not accepted; linked Task states are implementation history only.

NFR-0007

NFR

Proposed

Keep foundation builds, schemas, contracts, assets, validation, images, and deployment artifacts reproducible and traceable to governed inputs.

Not accepted; linked Task states are implementation history only.

All release Tasks

Task

Execution status

Outcome / component

Trace links — not acceptance

Execution evidence

AEROSIM-TS-129

Done

One immutable candidate binds the exact application source revision, Harbor web and API digests, chart revision, GitOps template…

FR-0059, NFR-0007 · outcomes 0 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-130

Done

Release notes and the operational plan reconcile all 144 cumulative Release 1.0.0 Tasks—the original 130 allocations plus 14 Wave…

FR-0059, NFR-0007 · outcomes 1 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-131

Done

A reviewable GitOps change binds the exact Release 1.0.0 candidate through project template source, authoritative rendering, rend…

FR-0059, NFR-0007 · outcomes 2 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-132

Done

After separate exact-head approval, AeroSim Release 1.0.0 is reconciled, verified through runtime health, route, login, and relea…

FR-0059, NFR-0007 · outcomes 3 · mapping does not establish requirement acceptance

task flow/evidence

AEROSIM-TS-145

Done

The production flight experience visibly identifies product version 1.0.0.0 and cannot display stale BUILD 0.2.0 or PLAYABLE FLIG…

FR-0059 · outcomes 0, 3 · mapping does not establish requirement acceptance

task flow/evidence

KDD / advisory disposition

No feature-specific ADR recorded

Canonical Feature status: Approved for Solution.

Simulated-panel recommendation: CONDITIONALLY ACKNOWLEDGE the recorded solution approval; retain UAT, immutable identity, promotion and acceptance gates.

Recorded sign-off

RootAtSkic · 2026-09-14T07:59:57.086Z · Approved for Solution evidence

Task states: Done 5

KDD · Key design decision

ADR-0001 · Force-driven browser flight model boundary

Accepted 5 Features 3 Options

Context	Release 1 requires force-driven motion, world interaction, continuous control, state feedback, and repeatable sessions. The reviewed implementation uses browser-local fixed-step simulation while the API command path fails closed.
Recorded decision	Use browser-local force integration as the Release 1 flight authority. The API and Socket.IO scaffold are not physics authorities.
Rationale	The implemented 60 Hz fixed-step model, bounded catch-up, deterministic tests, invalid-state handling, and browser-owned world composition establish a coherent Release 1 boundary without claiming server-authoritative anti-tamper behavior.
Consequences	Client performance variance, client tampering, replay provenance, and unsupported-device behavior remain bounded residual risks. Multiplayer or competitive integrity requires a superseding decision. The Socket.IO command path remains unavailable unless separately approved.
Affected scope	AEROSIM-FT-1, AEROSIM-FT-2, AEROSIM-FT-3, AEROSIM-FT-4, AEROSIM-FT-5 · Web application, API service
Owner / sign-off	AeroSim Architecture · Giedrius K · 2026-09-25T08:10:51.412Z

Option evaluation

Option

Benefits

Drawbacks / trade-offs

Browser-local force integration

Low-latency input and rendering; offline-capable deterministic loop; current implementation alignment.

Client performance variance; stronger anti-tamper limits; authoritative state and replay/verification complexity.

Service-assisted simulation

Central authority, consistency and stronger server-side validation.

Latency and network dependency; higher runtime cost; more complex real-time reconciliation.

Hybrid simulation boundary

Responsive local experience with selective server authority/validation.

Highest interface and reconciliation complexity; drift and split-authority failure modes.

Evaluation criteria: Evaluate latency, consistency, availability, security, failure recovery, operability, portability, cost, migration impact and evidence testability.

Simulated-panel recommendation: Advisory recommendation: accept browser-local fixed-step flight authority for Release 1, conditioned on explicit client authority, deterministic replay/test evidence, fail-closed invalid-state handling, and no claim of server-authoritative anti-tamper. Revisit hybrid/service authority only with a separately approved multiplayer or competitive requirement.

Governance disposition

Accepted decision

Human acceptance is recorded with authority basis, conditions, timestamp, evidence and hash. The Board should confirm that the internal HTTP residual risk remains acceptable.

KDD · Key design decision

ADR-0002 · Flight configuration boundary

Accepted 2 Features 3 Options

Context	Release 1 preparation requires independent governed scene and aircraft choices that configure one immutable flight launch snapshot. The reviewed implementation bundles validated catalogues in the Web build and has no active API catalogue service.
Recorded decision	Use static browser-bundled catalogues for Release 1 with build-time validation and source-revision-bound immutable launch snapshots.
Rationale	This matches the implemented authority boundary, rejects stale or incompatible selections, and avoids claiming a runtime catalogue service that does not exist.
Consequences	Catalogue availability and updates are coupled to the Web build and release. Dynamic catalogue adoption requires a superseding decision covering stale-cache, compatibility, availability, and operational ownership.
Affected scope	AEROSIM-FT-6, AEROSIM-FT-7 · Web application, API service
Owner / sign-off	AeroSim Architecture · Giedrius K · 2026-09-25T08:10:51.412Z

Option evaluation

Option

Benefits

Drawbacks / trade-offs

Static browser catalogue

Simple, fast and deterministic; no runtime catalogue dependency.

Content changes require build/release; browser bundle owns catalogue truth.

API-backed catalogue

Runtime governance, centralized compatibility and content updates.

Availability/latency dependency; cache and stale-data semantics required.

Build-time generated catalogue

Single generated contract with build-time validation and deploy-time determinism.

Generation pipeline becomes critical; still requires release for change.

Evaluation criteria: Evaluate latency, consistency, availability, security, failure recovery, operability, portability, cost, migration impact and evidence testability.

Simulated-panel recommendation: Advisory recommendation: accept a build-time generated and validated catalogue for Release 1 with revision-bound launch configuration and mandatory reconfirmation after catalogue change. Defer an API-backed dynamic catalogue until availability, cache, stale-data and operational ownership are approved.

Governance disposition

Accepted decision

Human acceptance is recorded with authority basis, conditions, timestamp, evidence and hash. The Board should confirm that the internal HTTP residual risk remains acceptable.

KDD · Key design decision

ADR-0004 · Terminate public AeroSim TLS on Osgiliath

Accepted 1 Features 3 Options

Context	Before the TASK-0050 application change, the AeroSim chart always rendered Ingress TLS and required an aerosim-tls Secret, while the verified Gondor path terminates public TLS on Osgiliath and the aerosim namespace has no such Secret.
Recorded decision	Keep public HTTPS and WSS termination and certificate lifecycle on Osgiliath. Forward HTTP from Osgiliath to Kubernetes Ingress. Keep in-cluster Ingress TLS optional in the AeroSim chart and disable it for Gondor. Require a named pre-existing TLS Secret only when chart TLS is explicitly enabled.
Rationale	This matches the verified runtime boundary, removes a nonexistent Secret dependency from TASK-0050, preserves public transport security, and keeps the chart portable to environments that terminate TLS in-cluster.
Consequences	Gondor values render no Ingress spec.tls block. Osgiliath remains responsible for ACME and certificate renewal. The internal Osgiliath-to-Ingress hop is HTTP. Environments enabling chart TLS must supply and govern a Kubernetes TLS Secret.
Affected scope	AEROSIM-FT-52 · Gondor platform, Osgiliath TLS boundary, Kubernetes Ingress, Web Application, API Service
Owner / sign-off	AeroSim Architecture · RootAtSkic · 2026-09-08T12:04:53.909Z

Option evaluation

Option

Benefits

Drawbacks / trade-offs

Osgiliath TLS + optional chart TLS

Matches verified topology; removes nonexistent secret dependency; preserves chart portability.

Internal hop is HTTP; Osgiliath certificate/ACME availability is critical.

Remove chart TLS support

Simplest Gondor chart and no duplicate TLS ownership.

Reduces portability and prevents in-cluster TLS environments.

Re-encrypt to Ingress

Encrypts internal hop and supports stronger defense in depth.

Requires Kubernetes TLS secret lifecycle, rotation and additional failure modes.

Evaluation criteria: Evaluate latency, consistency, availability, security, failure recovery, operability, portability, cost, migration impact and evidence testability.

Simulated-panel recommendation: Recorded accepted option remains appropriate for the verified Gondor topology. Board action is limited to confirming the residual internal-HTTP risk and Osgiliath certificate/ACME operational ownership.

Governance disposition

Accepted decision

Human acceptance is recorded with authority basis, conditions, timestamp, evidence and hash. The Board should confirm that the internal HTTP residual risk remains acceptable.

48 · Audit register

Risk, decision and evidence register

Stable residual-risk register

Risk

Asset / scenario

Existing controls / residual

Owner / treatment

Status

R-SEC-01

Public/API traffic: Internal Osgiliath-to-Ingress hop is HTTP.

ADR-0004; public HTTPS/WSS at Osgiliath; optional chart TLS. Residual: Likelihood/impact not quantitatively assessed.

AeroSim Architecture / Gondor platform: Board confirms accepted residual or requires re-encryption.

Accepted architecture decision; residual review open

R-SEC-02

Identity/session: Authenticated UAT cannot restore the in-memory OIDC session.

OIDC PKCE, invalid-token rejection, ordinary-user UAT rule. Residual: Complete authenticated release evidence absent.

AeroSim UAT / Delivery: Repair fixture and rerun against exact tuple.

Open release blocker

R-SEC-03

Pilot data: Data classification, retention, deletion and legal basis are not recorded.

Pilot-subject isolation and transactional persistence tests. Residual: Retention/deletion obligations and ownership unresolved.

Product authority / Data owner: Board records classification, retention, deletion and audit policy.

Open governance decision

R-SEC-04

Database recovery: Backup, restore, PITR, RPO/RTO and restore testing are not release decisions.

Prisma migrations and transactional verification. Residual: Recovery capability cannot be claimed.

Operations / Data owner: Approve recovery objectives and provide restore evidence.

Open governance decision

R-SEC-05

Secrets: Rotation, compromise response and privileged Keycloak credentials are outside current evidence.

Bitwarden-backed External Secrets; no browser receipt of administrative secrets. Residual: Rotation and incident ownership unrecorded.

Gondor platform / Security: Record rotation cadence, emergency procedure, owner and evidence.

Open governance decision

R-SEC-06

Database transport: API-to-database TLS is not established by reviewed manifests.

NetworkPolicy permits TCP 5432 only from aerosim-api; credentials arrive through External Secrets. Residual: Transport encryption is unproven.

Security / Operations / Architecture: Enable verified PostgreSQL TLS or accept the bounded namespace risk.

Open security decision

R-ARC-01

Flight authority: ADR-0001 accepts browser-local flight authority under explicit conditions.

Deterministic 60 Hz fixed-step tests, bounded catch-up and fail-closed validation. Residual: Client variance, tampering, replay provenance and unsupported-device behaviour remain bounded but not eliminated.

AeroSim Architecture: Preserve the accepted conditions; require a superseding decision for server-authoritative or competitive behaviour.

Accepted with residual conditions

R-ARC-02

Configuration/catalogue: ADR-0002 accepts static browser-bundled catalogue authority for Release 1.

Build-time validation, source revision binding, immutable launch snapshot and mismatch rejection. Residual: Catalogue updates remain release-coupled; dynamic authority remains deferred.

AeroSim Architecture: Preserve accepted conditions; require a superseding decision for dynamic catalogues.

Accepted with residual conditions

R-REL-01

Release audit identity: Rejected 1.0.0.2 identity is associated with different corrective images.

Immutable digest/GitOps tuple and mismatch rejection. Residual: Current desired state cannot be promoted as the rejected identity.

AeroSim Releases / RootAtSkic: Approve a new release and chart identity before promotion.

Open release blocker

R-REL-02

Environment evidence: Development advanced to source 7e7d557 and GitOps fb54699 while production remains on dbba4a1 / 5a440bb.

Exact source, image and GitOps tuple recording; evidence invalidation rule. Residual: Prior development UAT cannot prove the current or production candidate.

AeroSim UAT / Releases: Classify new source scope, freeze one tuple, rerun all required journeys and prohibit evidence mixing.

Open release blocker

R-GOV-01

Lifecycle authority: 33 Proposed Features and all 49 Release 1 requirements remain unapproved while linked child Tasks carry Done or ToBeReleased execution states.

Exact lifecycle events, hashes and fail-closed report language preserve the contradiction. Residual: Technical delivery could be mistaken for authorized scope, accepted requirements, or release acceptance.

AeroSim Scope / Architecture / Product authority: Issue exact-item dispositions or conservatively reconcile unauthorized lifecycle states; never infer approval from Task completion.

Open governance blocker

Unresolved decisions that must not be assumed

Gap

Affected scope

Required disposition

Proposed Feature lifecycle

33 Features

Approve/condition/reject exact items with authority, date, conditions and evidence.

Conditional KDD closure

KDD-R1-01 through KDD-R1-03; ADR-0001 and ADR-0002

Preserve accepted conditions and attributable evidence; do not infer closure of KDD-R1-04 through KDD-R1-06.

Identity/data/operations

IAM-01–05, data lifecycle, NFR targets, recovery, secrets

Approve owners, numeric targets, retention/deletion, rotation and recovery controls.

Cross-release references

TASK-0010, TASK-0164, TASK-0165, TASK-0166, TASK-0167

Explicitly excluded from the 162-Task Release 1 packet; retained only as requirement traceability to deferred/later scope.

Authenticated UAT

Current development tuple

Produce durable UAT_PASSED evidence using ordinary SSO.

Immutable release identity

Corrective candidate after rejected 1.0.0.2

Approve new release/chart identity and exact tuple.

Product acceptance

Production corrective candidate

Explicit human acceptance after promotion and production UAT.

Every Feature and Task links to its canonical reader and flow/acceptance evidence. The complete fields, event IDs, actor/authority, dates, hashes, requirements, acceptance mappings, inputs, outputs, failures, exclusions, verification and design traceability are preserved in the companion JSON. Artifact hashes are published in the report manifest.

49 · Independent review gate

Architecture Board simulation and review record

Panel status

This page is populated from the final multi-role simulated Board review. Review findings are advisory and cannot replace real human Board sign-off.

Required panel roles

Role

Review focus

Pass condition

Enterprise Architecture Chair

Scope, C4 consistency, KDD completeness, authority and conditions.

Every item is traceable; unresolved decisions are explicit and non-assumed.

Security & Privacy Architect

Identity, authorization, secrets, TLS, data lifecycle and residual risk.

Security gaps have owners and Board actions.

Data & Integration Architect

Schemas, persistence, events, API/Socket contracts and consistency.

Data ownership and failure semantics are visible.

Reliability & Operations Architect

NFRs, observability, rollback, deployment and runtime evidence.

Targets and verification are evidence-bound.

Product / Scope Governor

Value, outcomes, dependencies, UI/UX and stakeholder accountability.

No Feature is hidden behind aggregate summary.

Audit & Release Governor

Sign-offs, immutable evidence, UAT, promotion and acceptance.

No approval is inferred from technical evidence.

Mechanical publication gates

Generate and verify exactly 49 PDF pages with no HTML overflow.
Publish PDF, HTML and companion JSON SHA-256 values in the report manifest.
Commit the frozen package and review the exact PR head.
Require exact-head CI, production dependency audit, PDF text/page checks and Docusaurus publication readback.

Final simulated-panel result

Role

Final packet verdict

Residual authority

Enterprise Architecture Board Chair

PASS

Cross-release traceability corrected; real Board dispositions remain open.

Security & Privacy Architect

PASS

Identity, data, secrets, TLS, recovery and residual risks are explicit Board actions.

Data & Integration Architect

PASS

Contracts, ordering, retry, persistence and open KDDs are fully exposed.

Reliability & Operations Architect

PASS

NFR metrics, observability, capacity, recovery, freshness and UAT gaps are explicit.

Product / Scope Governor

PASS

All items are visible; Proposed-vs-delivered authority contradiction is explicit.

Audit & Release Governor

PASS

Evidence provenance and release gates are audit-ready, subject to manifest/commit publication.

PASS ON PACKET COMPLETENESS. Round 1 returned six FAIL verdicts. The report was corrected and independently re-reviewed until all six roles had no remaining unacknowledged or assumed report gap. When application/development evidence advanced, Chair, Reliability and Audit roles re-reviewed the refreshed full tuple and all three passed. This advisory result does not approve the architecture, risks, release, promotion or product acceptance.

Real Board decision fields

Decision

Disposition

Owner / date / evidence

Report accepted as audit baseline

□ Approve □ Conditional □ Return

Release 1 architecture

□ Approve □ Conditional □ Return

Open KDDs

□ Accepted □ Deferred □ Return

Residual risks

□ Accepted □ Mitigate □ Reject