Delivery action plan
Proposed plan, not a delivery promise. The target and feature boundary are in the product definition. Feature IDs F refer to the catalog, S to the Simulink-style plan, D to discovery, A to assurance, and R to the audit baseline. Roles below are responsibilities to assign, not people already allocated. All acceptance criteria are proposed future gates.
Milestones and completion gates. Discovery can run alongside M0. UI prototypes and data acquisition can proceed while contracts mature, but production integration must wait for the relevant decisions. Do not promote a release because its UI looks finished while its evidence or support remains incomplete.
Current authorized platform order is macOS first, Linux next. The bounded continuous-model feasibility work and remaining M1 gates are recorded in M1 implementation and M1 contracts. Windows is no longer a supported platform: its engine CI leg, presets and release packaging were withdrawn after an installed-package consumer failure that was never root-caused. Engine and product now target the same two platforms. The M2 preview increment adds project revisions, a shared CLI worker, typed linear-system/LQR graph import, explicit retained-revision restoration and native block/sample tables in the macOS feasibility surface. Synthetic and local linear aircraft/controller workflows cover a bounded part of M2; toolkit selection, hosted verification, complete accessibility/recovery and clean-machine installation acceptance remain open. The project-file contract records the implemented boundary.
| Milestone | Deliverable the user can review | Implementation focus | Required exit evidence |
|---|---|---|---|
| M0 — Restore trust in existing outputs | Corrected CLI/reference reports and a defect-closure record | R01–R08; finite/conditioning checks; diagnostic preservation; complete release gate and source/runtime identity | Every audit counterexample corrected or explicitly refused at the affected public interface; reviewed independent expectations; supported-platform tests; no widened gate hiding a discrepancy |
| M1 — Freeze product and model contracts | Intended-use agreement, selected aircraft/data route, acceptance scripts, benchmark plan and architecture ADRs | D01–D16 relevant to v1; F02/F03/F27/F32/F35 contracts; S02/S06 execution semantics; A02–A04/A13 protocols | Named target user/reviewer, licensed data route, fixed v1 block/model profile, error budgets, evidence schema, platform/workload requirements and estimates reviewed before broad implementation |
| M2 — Deliver a graphical vertical slice | Installable preview: create/open project, build a basic aircraft/controller block diagram, simulate/analyze and inspect a report | F28/F29; S01–S04/S07/S08; worker protocol; preserved existing numerical kernels | One complete workflow works through UI and headless runner with equivalent results; invalid wiring, algebraic loops, cancelled/crashed jobs and unsupported charts cannot appear as accepted studies |
| M3 — Complete declared engineering depth | Scheduled fixed-wing model package, feasible operating-point analysis, sampled controller/sensor/actuator simulation and data exchange | F04–F22/F26; S05/S06/S11/S12; bounded data adapters | Independent model and solver evidence covers the declared use/domain; multirate, delay, initialization, saturation and transition cases pass reviewed protocols; unsupported conditions are explicit |
| M4 — Complete study campaigns and review | Reproducible sweeps, uncertainty studies, convergence checks, test harnesses, design comparison and review packages | F23–F25/F30/F31; campaign service; S09/S10/S13–S15 | All cases accounted for, including failures; worker-count/restart invariance where promised; requirement evaluation never hides unresolved/invalid evidence; independent reviewer can reconstruct a decision |
| M5 — Accept the end product | Supported installers, training, documentation, verified updates/rollback, maintenance policy and acceptance dossier | F33–F36; A07–A12; performance/usability/recovery/security checks | External engineer completes the accepted workflow on a clean supported installation; release evidence is complete and bound to exact artifacts; primary/backup owners and support process are in place |
| Expansion — Separate accepted increments | State-machine modeling, restricted C/C++ code generation, model translation, SITL/PIL/HIL or advanced design methods | S16–S20; F37/F38 and catalog expansions | Named user/target, scoped execution semantics, independent equivalence/target evidence and funding; onboard acceptance remains a separate decision |
M3 covers only the aircraft configurations, table structures, controllers and disturbance profiles selected at M1. “Scheduled model” does not promise arbitrary full-envelope aircraft fidelity. M4 handling-quality assessments implement only the criteria whose applicability and reference rights are established. A stage's computational completion is separate from numerical reliability, model validity and engineering acceptance; a diagnostic exploration may finish computing while its requirement outcome remains unresolved or failed.
The first actionable backlog. These work packages can be turned directly into issues. Preserve existing user changes; establish a reviewed source baseline before creating the release branch. Size labels are planning categories only: Small is a contained change, Medium spans a component and its evidence, Large spans contracts or multiple components, and Discovery ends in a decision. Estimate calendar/effort after examining each patch and assigning people.
| Work package | Priority / owner | Concrete action and existing surface | Dependencies / size | Done when |
|---|---|---|---|---|
| W01 — Preserve and replay audit defects | P0 / independent verification engineer | Move the R01–R05 fixtures and independent proofs into the appropriate existing unit/integration tiers; record current failure and affected public paths | None / Small | Tests express the correct physical/mathematical expectation and fail against the faulty implementation; each has a traceable R ID |
| W02 — Correct margin guarantees | P0 / control numerics engineer | Correct sampled sensitivity/disk result semantics and all report writers; use justified conservative endpoints for supported bounded analyses | W01 / Medium | Default out-of-band case cannot emit false guarantees; grid refinement/limits and uncertainty are visible in every consumer |
| W03 — Qualify stability numerically | P0 / numerical linear algebra engineer | Review margin, disk and sensitivity eigenvalue gates; design scaling/conditioning/error checks | W01, independent protocol / Medium | Exact unstable adversarial case is classified correctly or refused as unresolved; near-axis/scaling cases cannot silently pass |
| W04 — Preserve linearization evidence | P0 / flight-dynamics engineer | Recompute trim validity, retain chart/truncation/coupling/perturbation evidence through linearization and pipeline artifacts | W01 / Medium | Stale trim is rejected and near-vertical case is refused/gated visibly; evidence survives export and controller derivation |
| W05 — Make API boundaries consistent | P0 / engine engineer | Audit finite values, dimensions, channel indices, residual tolerances and step/count options across exported model/numerics/analyze/sim APIs | W01 / Medium | Invalid direct C++ input cannot become a successful finite-looking engineering result; positive/negative tests cover each contract |
| W06 — Bind publication to evidence | P0 / release engineer | Resolve immutable SHA, require full CI and package verification; bind runtime inventory; align CMake minimum; reconcile stale assurance prose | None / Medium | Failed/missing/skipped evidence prevents publishing; every platform archive proves the same source and verified runtime identity |
| W07 — Choose the customer acceptance task | P0 / product lead and customer reviewer | Execute D01–D03 and initial D16; define aircraft/configurations, output decisions, independent evidence/data rights and support environment | None / Discovery | A reviewable acceptance script and data/authority/funding owners exist; remaining unknowns have explicit consequences |
| W08 — Specify engineering artifact contracts | P0 / engine/API architect | Extend Artifact beyond display summary/type-erased payload with serializable data and four evidence dimensions; define compatibility/migration | W02–W05 findings, W07 / Large | Contract examples cover good, estimated, unresolved, invalid-domain, cancelled and partial runs; GUI/CLI/export cannot discard required evidence |
| W09 — Specify block IR and clock semantics | P0 / simulation architect | D07; S02/S06/S08; define ports, state/output/update ordering, direct feedthrough, sample rates, initialization and unsupported loops | W07/W08 / Discovery then Large | Written semantics plus independent executable fixtures exist before a broad palette is implemented |
| W10 — Prove the block compiler headlessly | P1 / simulation engineer | Lower gain/sum/integrator/state-space/PID/saturation/scope blocks into the numerical worker; preserve hierarchy IDs and canonical model revisions | W09 / Large | Analytic closed loops and an existing Galata study reproduce; invalid cycles/wiring/rates fail before execution |
| W11 — Select the desktop and worker boundary | P1 / desktop/platform engineer with UX | D10–D14; prototype the same import→diagram→run→plot→failure task in shortlisted stacks; measure offline packaging, accessibility and responsiveness | W07/W08; W09 for model editing / Discovery | Recorded framework/license/platform decision, representative measurements and worker IPC/resource/cancellation design |
| W12 — Ship the first installed study | P1 / desktop and engine engineers | Project browser, model/block editing, run controls, evidence inspector, scope and review export using the shared engine | W10/W11 / Large | Clean-machine preview executes the accepted vertical slice and preserves headless equivalence/recovery |
| W13 — Acquire independent aircraft evidence | P0 / model-data lead with independent verifier | D03/D09; obtain permitted scheduled model data and separate comparison/holdout data; document pedigree, budgets and omitted physics | W07; may run parallel to W08–W12 / Discovery then Large | Supported-domain validation plan is feasible and funded; lack of suitable evidence narrows M3 claims rather than creating invented data |
| W14 — Build sampled and scheduled studies | P1 / controls and simulation engineers | F05–F22; selected discrete design/estimation, model tables, feasible trim, actuator/sensor/clock/delay/disturbance behavior | W09/W10/W13, independent protocols / Large | Supported mixed-rate closed-loop reference scenarios and model validation meet their predeclared budgets |
| W15 — Build campaigns and engineering review | P1 / platform and verification engineers | F23–F25/F30/F31; immutable run queue, recorded seeds, resume, convergence, uncertainty, harnesses, comparison and acceptance tables | W08/W12/W14 / Large | Review package contains every case and decision; retries/cancellation/tuning changes retain provenance and cannot overwrite accepted evidence |
| W16 — Complete release, support and acceptance | P1 / product assurance and release leads | A07–A12; installers, signatures/SBOM/offline verification, updates, migration, recovery, user trials, training and maintenance drills | W06 and integrated M4 candidate / Large | M5 checklist and independent acceptance dossier pass for each supported platform/profile |
First ten working days: planning and executable evidence, not a v1 deadline. This kickoff sequence assumes parallel ownership; with a solo developer, execute the same packages sequentially and obtain independent review externally. Dependencies govern the order even if the window expands.
| Window | Engineering work | Product/evidence work | Reviewable output |
|---|---|---|---|
| Days 1–2 | W01 reproductions; inspect release provenance for W06; capture controlled baseline | W07 acceptance task, intended reliance, platforms and data contacts; assign owners/reviewers | Ranked defect board, baseline evidence and explicit assumptions register |
| Days 3–5 | W02–W05 focused patches and independent regression expectations; W06 gate design | W13 data route; initial W08 artifact examples and W09 event/loop fixtures | Small reviewable fixes; draft acceptance/semantics contracts and unresolved questions |
| Days 6–8 | Integrate reviewed fixes; exercise complete relevant gates; headless compiler feasibility spike | W11 desktop comparison on the same task; numerical/model benchmark protocols and licensing review | M0 closure candidate, measured architectural alternatives and data/benchmark risks |
| Days 9–10 | Review M0 evidence; demonstrate smallest graph-runtime prototype if semantics permit | Review M1 scope, role capacity, external data/verification cost and milestone estimate | Go/narrow/stop decisions; funded milestone backlog with named owners and dates |
Do not manufacture estimates from feature counts. At the day-10 review, split Large packages until their behavior and evidence are independently reviewable, estimate them with their owners, and include integration, reference-data acquisition, independent review, installer/security work and support cost. A missed data or assurance prerequisite changes the supported product scope or schedule openly.
Staffing and parallel work. A practical planning model has product/domain ownership, control/numerical engineering, simulation/model-data engineering, desktop/platform engineering, and independent verification/assurance coverage, with release/security/UX expertise available. One person may hold several roles, but a developer's self-review does not establish verification independence when it is required. Do not assume all listed roles are full-time. For a small team, prioritize one platform, one aircraft family/configuration profile and a compact supported block set; verify cross-platform support before advertising it. A larger team can run audit/benchmarks, model evidence, runtime semantics and desktop work in parallel after contracts stabilize. The rate of acquiring trustworthy aircraft evidence may remain the critical path regardless of developer count.
Critical dependencies and architectural decisions. Reliable result semantics and independent oracles precede broad synthesis claims. Units/frame/model identity precedes reusable connections and import. Block state/direct-feedthrough/clock semantics precedes hybrid controllers and code generation. Representative data and performance workloads precede desktop/storage choices. Campaign determinism must be specified before parallelism/caching; stable ordering, seeds, reduction policy and resume behavior are part of the contract. Compatibility policy precedes persistent public schemas. Native plugin execution, state machines and generated code each require a separate trust/semantics review rather than inheriting assurance from the study registry.
Use the existing ADR process to record the result artifact/identity design, model IR and clock rules, desktop/worker boundary, project storage/migrations, model-table interpolation/extrapolation, controller scheduling, distributed/parallel determinism, extension ABI and import/code-generation profiles. Existing ADRs remain authoritative until a reviewed decision supersedes them. Framework selection is intentionally deferred to the evidence from W11.
Definition of done for each numerical feature. Its requirement and supported domain are written; accepted reference data and independent comparison are identified; error budgets are justified before measuring results; boundary/negative/conditioning cases are exercised; units/frames/sample semantics are explicit; diagnostics and provenance survive all interfaces; documentation and generated evidence reflect actual behavior; existing regressions remain intact. An unresolved mathematical/model result is retained and displayed as such, never converted into an engineering pass. For UI/platform features, use task-based usability, accessibility, recovery, compatibility and security checks appropriate to the change rather than duplicating numerical tests in the UI.
Release acceptance and change control. At M5 verify new install, prior-version upgrade, project migration, offline run, replay, export/import, cancellation/crash recovery, disk/resource failures, denied writes, invalid data, unsupported models, signed artifact verification and rollback on each advertised platform. Publish a compatibility/support policy and known limitations with the exact accepted runtime/data profiles. Any waiver has an owner, affected requirement/use case, rationale and compensating evidence; it cannot silently turn unknown validity into a successful result. Product acceptance, customer aircraft-model acceptance and any tool qualification are separately recorded decisions.
Issue and progress format. Every issue should identify the W/F/S requirement, R/A risk if relevant, user-visible behavior, supported/unsupported cases, source surface, dependencies, owner/reviewer, independent reference and budget, acceptance evidence, migration/report implications and milestone. Track defects closed with independent evidence, workflow acceptance, benchmark/domain coverage, unresolved-case handling, reproducibility, user-task outcomes and release readiness. Raw test counts and UI screenshots alone are insufficient completion metrics.