M1 discovery contracts and acceptance boundary

Status: working contract for the authorized M1 feasibility phase; review and external decisions remain open. This document records the current scope and the evidence needed to move beyond a prototype. It does not declare M1 complete, approve an aircraft model or promise a desktop delivery date. The discovery agenda, delivery plan, assurance plan and executable-model architecture provide the larger product context.

Current decisions and assumptions

The task has two separate acceptance horizons. M1 demonstrates that a small executable model can be checked, compiled and simulated reproducibly. M2 and later milestones turn that engine into the user-facing aircraft/controller workflow. A scalar feedback prototype cannot close the desktop, aircraft-data, hybrid-control or customer-acceptance portions of that workflow.

Acceptance scenarios

Scenario IDs identify evidence to retain, not passing results already obtained. The independent model conformance protocol owns numerical case definitions and budgets. This contract does not widen its tolerances or replace its independent references with captured Galata output.

For every exercised scenario retain the exact source/build, inputs, protocol revision, environment, observed values, tolerance rationale, diagnostics and review disposition. Mark unimplemented scenarios pending, not skipped-success. The reviewer must be able to identify whether an expected result is analytic, published, independently implemented or merely a regression lock.

The current prototype API declares schema galata.model.v1 and profile continuous-scalar.v1: real scalar Constant, Gain, ordered signed Sum, Integrator and Output blocks. A dimension has seven SI exponents plus an additional semantic angle exponent, each bounded to [-16, 16]; frames are None, Body and NED. These are compile-time connection contracts, not a frame-transformation library. No implicit scale/offset conversion, Boolean/vector/bus block, model reference, presentation field, sampled clock or algebraic solver is admitted by this profile.

The API separates immutable compiled-model semantics from simulation options. State/output/schedule IDs are inspectable, including stateless models. Fixed step/count/stride options and returned samples are run-specific; changing step size does not change the underlying model's semantic digest. Test the complete recorded model-plus-run request before calling two executions equivalent.

Data pedigree and permitted evidence route

The initial reference is the existing NT-33A model, its pedigree record, and the published-value transcription. They cite Heffley and Jewell, NASA CR-2144, December 1972, NTRS 19730003312. The repository records a source-PDF digest, visual transcription method, page/table locations and a second reading of selected values. Those records are useful existing evidence; this contract does not claim a new independent transcription or flight-data validation campaign has occurred.

The selected condition is a local first-order expansion at the documented power-approach configuration. It does not provide a stall model, propulsion availability, configuration transitions or a validated operating envelope. The reference trim pitching moment/elevator convention is an explicit model choice, so a near-zero trimmed elevator is not an independent prediction. Stability-to-body-axis conversion is part of the model interpretation and must remain visible. Numerical rounding/conversion error, parameter uncertainty and omitted physics have different meanings and must not share an invented error budget.

The existing rights record relies on the report's public/unclassified distribution and lack of identified restrictions. It also characterizes the contractor report as a government work. A distribution statement alone should not be promoted into a new blanket copyright or redistribution conclusion: NASA's current STI terms distinguish government works from contractor works and direct users to record-specific copyright metadata. This phase has not independently retrieved that record's current rights metadata or obtained a rights-holder determination. Retain the existing provenance, apply ADR-0007, and resolve the record-specific basis before expanding the dataset or its redistribution claims. This is a review gap, not a finding that the existing transcription is unlawful. NASA STI terms.

The M1 data register must distinguish these routes:

For a new field record its name, quantity/unit/frame/reference point, source location and revision, original value, transformation, SI value, uncertainty or unknown uncertainty, configuration and domain, reviewer and rights route. Missing engine/actuator/flight evidence narrows the use; it must not be filled by an undocumented zero or by relabeling a synthetic value as measured.

Public contracts required for the M1 profile

These requirements are acceptance obligations for the bounded profile. They do not assert that all are already implemented by a newly compiled prototype.

Compiler metadata is checked before numerical execution; it does not add a unit tag branch to every Eigen arithmetic operation. Angle/frame semantics still need explicit declarations even where SI dimensional exponents alone would be identical. The profile must refuse shapes or conversions it cannot establish.

The declared prototype limits below are engineering containment limits, not customer performance SLAs or measured throughput. Their checks and boundary tests remain acceptance obligations; merely declaring a constant is insufficient.

A node-count limit alone does not bound memory: state, logging width, sample count and their checked products also matter. The prototype's cancellation is cooperative at defined work boundaries; a caller callback is not guaranteed to return promptly. An in-process C++ API is not an operating-system sandbox; hostile native code and hard wall-time containment require a later worker isolation decision.

No additional runtime dependency is selected by this document. Retain the existing open-source engine/dependency notices; use Python through the current CLI/build/test route unless a native binding is separately reviewed. A model format, extension interface or optional adapter does not override third-party license obligations or justify a mandatory proprietary simulator dependency.

D01–D16 dispositions for this phase

“Proceed” authorizes the bounded investigation described here, not closure of the discovery package or acceptance by an external party.

Exit review and next decisions

M1 may close its technical feasibility subgate when the supported graph profile is explicit, the independent conformance cases and negative/resource tests pass on the claimed environments, source/run identity is demonstrated, and the implementation/status limitations are reviewable. Preserve M0 release and numerical evidence while adding the new component; a green prototype test must not waive a failed existing gate.

The complete M1 product gate also needs a named target user/reviewer and accepted workflow, a defensible data-use route, error/validity budgets for the intended decisions, selected platform/workload requirements, relevant reviewed ADRs, and funded ownership/independent review estimates. Those external facts remain open. Technical progress can proceed without pretending they have been supplied.

The next review should confirm or change the workflow assumption, record macOS/Linux OS and hardware targets, assign the receiving reviewer, resolve the NT-33A rights-record basis, and decide the smallest aircraft adapter and desktop spikes. Any scope change updates this contract, the conformance profile and the associated ADRs together. No customer contact, data acquisition agreement or licensing approval is created by writing this plan.