SATPC0042590 Tab 04 SOW revised.pdf

STATEMENT OF WORK for Prototype Operational Modeling Framework for Manifest Feasibility in support of NASA KSC Spaceport Digital Twin

NASA Organization: Spaceport Integration and Services (SI) Directorate University: The University (University performer shall provide one designated graduate-level research participant, supported by faculty advisor oversight as proposed and accepted.)

Project Title: Prototype Operational Modeling Framework for Manifest Feasibility in support of NASA KSC Spaceport Digital Twin Project Sponsor: NASA Kennedy Space Center (KSC)

Period of Performance: The period of performance shall be 120 working days, commencing upon full execution of the agreement, unless modified in writing.

Place(s) of Performance: Primarily at the University’s facility, with on-site performance at NASA KSC as required for coordination, data access, validation activities, and other NASA-approved purposes.

Prepared By: Chad E. Brown

Technical Point of Contact:

• Chad E. Brown

• Spaceport Chief Strategist, Spaceport Integration and Services (SI) Directorate

• Chad.e.brown@nasa.gov

• 321.362.8305 mailto:Chad.e.brown@nasa.gov

Contents Background Objective Scope of Work Period of Performance Staffing Assumption Place of Performance and On-Site Collaboration

Place of Performance On-Site Frequency and Responsiveness In-Person Collaboration Access Eligibility and Processing Demonstration of On-Site Capability

Applicable Documents Definitions Government-Furnished Information, Data, and Materials Assumptions and Constraints NASA Decision and Approval Points Exclusions / Out of Scope Technical Tasks

Task 1. Project Management, Technical Approach, and Domain Selection Proposal Task 2. Operational Use Case and System Boundary Task 3. Prototype Canonical Data Model, Data Dictionary, and Source Mapping Task 4. Constraint Identification, Classification, and Explanation Logic Task 5. Prototype Logic Implementation and Feasibility Evaluation Task 6. Verification and Validation Task 7. Sensitivity and Intervention Analysis Task 8. Scenario Demonstration Package Task 9. Documentation, Transition, and Handoff

Deliverables Schedule and Milestones Deliverable Format Requirements Review, Comment Resolution, and Acceptance Data Rights, Software, and Ownership of Work Product Security, Data Handling, and Public Release Meetings and Reporting Requirements Quality Expectations Basis for Completion Attachment A: Deliverables Matrix

Background NASA Kennedy Space Center requires improved analytical capability to evaluate whether proposed mission-support manifests, campaigns, or operational activity sets are feasible within available infrastructure, operational constraints, and supporting resource limitations. Current assessments rely on legacy tools, historical records, subject matter expertise, and manually maintained artifacts. Available data may include planning records, schedules, facility information, infrastructure dependencies, operations constraints, and related reference materials, but such data may be incomplete, inconsistent, or differently structured across source systems.

This effort supports development of a prototype operational modeling framework to help NASA structure, analyze, and explain manifest-feasibility questions within the Spaceport Digital Twin context.

Objective The objective of this Contract is for the University to design, implement, document, test, and transition a prototype operational modeling framework that evaluates manifest feasibility for a NASA-approved mission-support domain within the Spaceport Digital Twin context.

The resulting prototype shall:

• represent the selected operational domain using a clear and documented system boundary;

• encode relevant operational constraints, dependencies, and resource relationships in a traceable and explainable form;

• evaluate candidate manifests, campaigns, or operational cases against those modeled constraints;

• identify infeasible conditions, bottlenecks, binding constraints, near-binding constraints, and the principal reasons for those outcomes;

• support scenario-based analysis and evaluation of interventions intended to improve feasibility;

and

• be delivered in a form suitable for NASA review, demonstration, reuse, and prototype transition support.

The prototype shall be bounded to one NASA-approved mission-support domain, or a tightly related set of operational threads, suitable for completion within the period of performance.

The framework is intended to support prototype analytical decision support and shall not be construed as a production scheduling, optimization, or mission-approval authority.

Scope of Work The work includes the following required activities. Unless this SOW expressly states otherwise, the University may determine the specific analytical methods, software workflow, data structures, implementation approach, and technical tools used to satisfy the requirements, provided the results are technically defensible, reproducible in delivered form, and compliant with this SOW.

The University shall perform work necessary to:

• define the operational use case, approved mission-support domain, and explicit system boundary;

• develop a prototype canonical data model, data dictionary, and source-to-model mapping sufficient to support the approved use case;

• identify, classify, formalize, and explain the relevant constraints, dependencies, and resource relationships affecting manifest feasibility;

• implement executable prototype logic capable of evaluating candidate manifests or scenarios;

• perform scenario-based analysis and intervention assessment;

• conduct verification and validation activities;

• document assumptions, methods, limitations, outputs, and transition considerations; and

• deliver all required artifacts, documentation, and handoff materials.

The framework is intended to support prototype analytical decision support and shall not be construed as a production scheduling, optimization, or mission-approval authority.

Period of Performance The period of performance shall be 120 working days, commencing upon full execution of the agreement, unless modified in writing.

The anticipated level of effort shall be commensurate with performance by one graduate-level researcher, with university supervisory support as necessary for quality assurance, continuity, and administrative oversight.

If incremental funding, phased authorization, or option periods are contemplated, they shall be stated in the Contract and take precedence over this section.

Staffing Assumption This effort is intended to be performed primarily by one graduate-level researcher at the master’s or doctoral level. The University may provide faculty advisor or principal investigator oversight, and may propose limited ancillary support for quality assurance, continuity, or specialized technical input, but the scope, schedule, and deliverables shall remain consistent with a focused university prototype research effort rather than a large multi-person development team.

The anticipated level of effort shall be commensurate with this staffing construct.

Place of Performance and On-Site Collaboration Place of Performance Work under this Statement of Work (SOW) shall be performed at the University's facilities and on-site at NASA Kennedy Space Center (KSC), Florida, as required to satisfy the technical tasks, data-access needs, integration activities, and milestones defined herein. NASA will coordinate KSC access and badging for authorized University personnel when on-site access is required.

A recurring portion of this effort requires in-person performance at NASA KSC. Certain KSC data, systems, environments, and subject-matter-expert engagements necessary to perform this effort including, but not limited to, controlled operational data, internal locally hosted Spaceport Digital Twin (SDT) architecture and interface environments, manifest and operational planning context, and facility-and operations-specific information cannot be transmitted, replicated, hosted, or accessed remotely and must be accessed on-site at KSC. Accordingly, the University shall be able to provide the designated researcher(s) on-site at KSC as required throughout the period of performance.

On-Site Frequency and Responsiveness The Prototype Operational Modeling Framework for Manifest Feasibility is an iterative, technical-continuation and integration activity that requires sustained, hands-on collaboration with NASA technical personnel, SDT integration staff, and cognizant subject-matter experts. As a result, this effort requires the ability to support frequent, recurring, and at times short-notice on-site working sessions at KSC across the full period of performance, including but not limited to:

• controlled data-access and data-analysis sessions that must be conducted on-site;

• model integration, interface development, and interface testing with the SDT environment;

• verification, validation, and calibration activities requiring access to KSC data and personnel;

• technical interchange meetings and collaborative working sessions with NASA personnel; and

• milestone and decision-point reviews.

The University shall be able to provide qualified personnel on-site at KSC within one (1) business day of a NASA request for the duration of the period of performance, without incurring travel cost, schedule delay, or personnel-availability limitations that would jeopardize the milestone schedule or the quality of the delivered work. Costs associated with on-site presence shall be reflected within the agreed budget; the required on-site cadence shall not result in additional cost to the Government beyond that budget.

In-Person Collaboration Because this effort depends on frequent, iterative, face-to-face collaboration with NASA technical and integration personnel, rather than solely remote engagement, the University shall support regular in-person collaboration at KSC, including recurring on-site working sessions, throughout the period of performance. The University shall structure its performance approach and staffing to sustain this level of on-site presence and responsiveness for the full duration of the effort.

Access Eligibility and Processing Personnel performing on-site at KSC, or otherwise requiring access to NASA facilities, information systems, controlled data, or Government-furnished information under this effort, shall be eligible for, and able to obtain and maintain, the badging, physical access, information-system access, and any credentialing required by NASA in accordance with applicable NASA, Federal, security, and export-control requirements.

Certain facilities, information systems, controlled unclassified information (CUI), and Government-furnished data required to perform this effort are subject to U.S. Government access restrictions, including restrictions arising from U.S. export-control laws and regulations (e.g., the International Traffic in Arms Regulations (ITAR), 22 CFR Parts 120–130, and the Export Administration Regulations (EAR), 15 CFR Parts 730–774), NASA security requirements, and KSC facility- and system-access requirements that may require U.S. citizenship. Access to such facilities, systems, and information may be limited to U.S.

persons and/or U.S. citizens as determined by NASA and applicable law and regulation.

The University shall ensure that personnel assigned to perform tasks requiring such access are able to obtain and maintain the required access consistent with these requirements. Personnel who are unable to obtain or maintain the required badging, security, facility, information-system, or export-control access shall not be assigned to perform tasks that require such access. Where a task requires access that is limited to U.S. persons or U.S. citizens under applicable law, regulation, or NASA requirement, only personnel meeting those criteria may be assigned to perform that task.

The University shall be able to make personnel available for KSC access and credentialing processing on the timeline necessary to meet the milestone schedule and shall ensure that on-site personnel maintain required access eligibility throughout performance. Provision of controlled, export-controlled, or Government-furnished information is contingent upon completion of, and continued compliance with, all applicable access, security, and export-control requirements.

The University shall promptly notify NASA of any change in the eligibility or access status of assigned personnel that may affect performance.

Demonstration of On-Site Capability In response to this SOW, the University shall demonstrate its ability to meet the on-site performance, frequency, responsiveness, in-person collaboration, and access requirements set forth in this section. At a minimum, the University's proposal shall describe:

• its approach and demonstrated capacity to provide the designated researcher(s) on-site at KSC on the required recurring and short-notice cadence, including the ability to respond within one (1) business day;

• how it will sustain frequent in-person collaboration at KSC over the full period of performance without incurring travel cost, schedule delay, or availability limitations that would jeopardize the milestone schedule;

• its ability to make personnel available for KSC access and badging processing consistent with the milestone schedule; and

• any assumptions, dependencies, or constraints affecting its ability to meet these on-site requirements.

The University's demonstrated ability to satisfy the on-site performance, responsiveness, and collaboration requirements of this section is essential to successful performance of this effort and will be considered in NASA's evaluation of the proposed approach.

Applicable Documents Applicable documents include FAR requirements and agency supplements; agency policies on research, data rights, and information handling; and technical, data, or modeling references identified in the Contract or task order, to the extent applicable and made available.

Definitions

Term Definition

Mission-support domain

A bounded operational area, function, or process thread selected for prototype modeling, such as a specific support workflow, infrastructure interaction set, or operational planning thread relevant to manifest feasibility

Manifest A proposed set of planned activities, operations, loads, campaigns, or mission-support demands to be evaluated for feasibility within the selected domain

Campaign A related sequence or grouping of operational activities occurring over time and sharing dependencies or resources

Feasibility The degree to which a manifest or campaign can be executed within modeled operational, resource, policy, infrastructure, temporal, and dependency constraints

Bottleneck A resource, process step, dependency, or constraint condition that materially limits throughput, timing, or feasible execution

Binding constraint A single constraint that directly prevents feasibility under a given case

Near-binding constraint A constraint that does not fully prevent feasibility but materially limits margin or may become binding under plausible variation

Intervention A change to assumptions, resources, sequencing, infrastructure availability, or policy conditions intended to improve feasibility

Prototype

An analytically usable and demonstrable capability suitable for evaluation and transition consideration, but not production-hardened, operationally accredited, or intended for autonomous operational decision authority

Government-Furnished Information, Data, and Materials NASA may furnish available materials relevant to the effort, which may include:

• planning records, process descriptions, and operations reference material;

• schedules, manifests, campaign records, or historical examples;

• facility, infrastructure, and resource reference data;

• interface information, architecture notes, and SDT-related guidance;

• prior studies, prototype materials, and technical notes; and

• subject matter expertise and technical clarification, as available.

NASA does not guarantee the completeness, usability, or fitness of Government-furnished information for any particular modeling purpose.

Provision of furnished materials does not relieve the University of responsibility to assess their appropriateness, completeness, and quality for intended use and to document material limitations.

Assumptions and Constraints The following assumptions and constraints apply unless modified in writing:

• The prototype shall use Government-furnished materials and inherited artifacts, if any, to the maximum extent practicable, except where the University demonstrates that alternative treatment is technically justified.

• Available data may be incomplete, inconsistent, differently structured, or insufficient for some objectives.

• The University shall not be required to acquire or generate large new operational datasets beyond limited data conditioning, transformation, or derived-feature creation needed to support the prototype.

• Some operational logic, parameters, and relationships may require estimation or abstraction where direct evidence is unavailable; all such assumptions shall be documented and traceable.

• The prototype shall be no more detailed than necessary to support the approved use case, constraints, prototype logic, and required scenario analysis.

• This effort assumes performance primarily by one graduate-level researcher with supporting university oversight.

NASA Decision and Approval Points NASA approval is required at the milestones identified in the section titled Deliverables Schedule and Milestones. The University shall not proceed beyond any milestone designated NASA review; approval required until NASA provides written approval to proceed.

Approval points include, at minimum:

• selection of the mission-support domain and system boundary;

• the Verification and Validation Plan; and

• the final transition package and final delivery.

NASA may establish additional approval points during performance when reasonably necessary to address technical, schedule, security, data-rights, or integration risks within the scope of this SOW.

Exclusions / Out of Scope Unless expressly authorized in writing by Contract modification, the following are out of scope:

• enterprise data architecture modernization;

• development of a production-grade optimizer, scheduler, or automated decision engine;

• construction of a production operational digital twin capability;

• independent operational certification or approval of actual manifests, campaigns, or launch decisions;

• large-scale new field data collection or broad enterprise data remediation;

• long-term production operations or sustainment support after final delivery; and

• acquisition of enterprise software licenses, cloud hosting, or permanent operational infrastructure not otherwise provided.

Technical Tasks The University shall perform the following tasks. Required outputs are fixed by this SOW; however, the University is not required to use any specific algorithm, formalism, constraint representation method, optimization routine, data schema technology, or visualization tool unless expressly stated in this SOW.

Task 1. Project Management, Technical Approach, and Domain Selection Proposal The University shall provide project management and technical coordination sufficient to plan, execute, monitor, and report the effort, and shall propose a technically suitable mission-support domain for prototype development.

This task includes:

• development and maintenance of a Project Management Plan scaled to the scope of this effort;

• preparation of a technical approach describing the proposed analytical framework;

• recommendation and justification of a candidate mission-support domain suitable for completion within scope, schedule, data availability, and staffing constraints;

• development of a schedule baseline;

• identification of risks, assumptions, and dependencies; and

• support for kickoff and technical coordination meetings.

The proposed mission-support domain shall be subject to NASA review and approval for scope suitability.

Task 1 Deliverables:

• kickoff briefing;

• Project Management Plan;

• Technical Approach;

• schedule baseline; and

• staffing, risk, and dependency framework.

Task 2. Operational Use Case and System Boundary The University shall define the operational use case and explicit system boundary for the approved mission-support domain.

This task includes:

• identification of the purpose of the prototype and intended analytical questions;

• definition of included and excluded processes, activities, resources, interfaces, and decision points;

• characterization of relevant temporal, operational, policy, and infrastructure boundaries;

• identification of key actors, systems, and dependencies; and

• documentation of assumptions, boundary choices, and rationale.

The system boundary shall explicitly identify included and excluded activities, resources, and interfaces.

Task 2 Deliverables:

• Operational Use Case and System Boundary Package.

Task 3. Prototype Canonical Data Model, Data Dictionary, and Source Mapping The University shall develop a prototype canonical data model, associated data dictionary, and source-to-model mapping sufficient to support the approved use case and executable prototype.

This task includes:

• identification of required data entities, fields, relationships, and reference structures;

• mapping of available source data or inherited materials into the prototype canonical representation;

• development of a data dictionary defining fields, meanings, units, assumptions, and constraints;

• documentation of source gaps, inferred values, conditioning steps, and limitations; and

• preparation of reusable source-to-model mapping documentation.

The canonical model shall be no more detailed than necessary to support the approved use case, constraints, prototype logic, and required scenario analysis.

Task 3 Deliverables:

• Prototype Canonical Data Model Package;

• Data Dictionary; and

• Source Mapping and Data Conditioning Memorandum.

Task 4. Constraint Identification, Classification, and Explanation Logic The University shall identify, classify, formalize, and explain the constraints affecting manifest feasibility within the approved domain.

This task includes:

• identification of relevant operational, infrastructure, resource, temporal, policy, and dependency constraints;

• categorization of constraints by type, source, and modeled effect, such as capacity, infrastructure, workforce, commodity, temporal, policy, or dependency constraints, as applicable;

• formalization of the logic, relationships, or rules by which such constraints affect feasibility;

• documentation of the origin, traceability, and rationale of modeled constraints;

• identification of simplifying assumptions; and

• development of explainability logic or artifacts sufficient to show why a manifest or scenario was found feasible, infeasible, or marginal.

Task 4 Deliverables:

• Constraint Identification and Logic Package; and

• Constraint Traceability and Source-Assumption Package.

Task 5. Prototype Logic Implementation and Feasibility Evaluation The University shall implement executable prototype logic capable of evaluating candidate manifests or scenarios against the approved operational model and identified constraints.

This task includes:

• implementation of executable prototype logic in Jupyter notebook format or other NASA-approved executable and reviewable format;

• representation of feasibility evaluation logic, including resource conflicts, temporal conflicts, dependency violations, and other relevant infeasibility conditions;

• generation of outputs indicating feasibility status, principal drivers, bottlenecks, and explanation traces;

• identification of whether infeasibility is driven by single-point binding constraints, cumulative near-binding effects, or interaction among multiple constraints; and

• preparation of representative prototype outputs suitable for NASA review and demonstration.

Task 5 Deliverables:

• Initial Prototype Capability; and

• Executable Prototype Codebase.

Task 6. Verification and Validation The University shall define and perform verification and validation activities appropriate to the maturity of the prototype and the availability of supporting evidence.

This task includes:

• preparation of a Verification and Validation Plan;

• verification of logic implementation, data flow, and execution behavior;

• assessment of prototype behavior against available historical examples, expected outcomes, or subject matter expert judgment;

• evaluation of model limitations, uncertainty, and confidence boundaries; and

• documentation of findings, issues, and recommended future refinement areas.

Verification and validation shall be performed, as supported by available data and domain maturity, using historical comparison, subject matter expert review, behavior assessment, or other technically justified means.

Task 6 Deliverables:

• Verification and Validation Plan; and

• Verification and Validation Report.

Task 7. Sensitivity and Intervention Analysis The University shall assess how changes in assumptions, resource availability, sequencing, or policy conditions affect feasibility outcomes.

This task includes:

• sensitivity analysis of relevant parameters, assumptions, or resource conditions;

• identification of which assumptions, data gaps, or parameter uncertainties most materially affect feasibility outcomes and bottleneck identification;

• assessment of one or more interventions intended to reduce infeasibility or improve margin; and

• documentation of the effect of interventions on feasibility outcomes and bottleneck behavior.

Task 7 Deliverables:

• Sensitivity and Intervention Analysis Report.

Task 8. Scenario Demonstration Package The University shall prepare a scenario demonstration package showing operation of the prototype over at least five NASA-approved scenarios.

This task includes:

• preparation of at least five NASA-approved scenarios relevant to the selected domain;

• execution of the prototype across those scenarios;

• demonstration of resulting outputs, explanations, feasibility status, and bottleneck identification;

and

• documentation of scenario assumptions and intended analytical use.

At least one scenario shall represent a nominal baseline, and at least one shall test an intervention intended to relieve a binding or near-binding constraint.

Task 8 Deliverables:

• Scenario Demonstration Package.

Task 9. Documentation, Transition, and Handoff The University shall prepare documentation and transition materials sufficient to support NASA review, demonstration, reuse, and prototype handoff.

This task includes:

• preparation of a User Guide;

• preparation of a Technical Maintenance and Transition Guide;

• documentation of runtime dependencies, environment requirements, and execution steps;

• identification of known limitations, assumptions, and transition considerations; and

• conduct of a final briefing and handoff session.

The handoff package shall include run instructions, dependency information, environment requirements, and known limitations.

Task 9 Deliverables:

User Guide;

• Technical Maintenance and Transition Guide; and

• Final Documentation and Transition Package.

Deliverables Schedule and Milestones Milestones are planning targets and may be refined at award based on the approved technical approach, data availability, access timelines, and the staffing model centered on one graduate-level researcher.

Milestone / Deliverable Target Due Review Type

Kickoff Meeting, Project Management Plan, and

Technical Approach

Week 2 NASA review

Operational Use Case and System Boundary Package, including approved mission-support domain selection

Week 4 NASA review; approval required

Prototype Canonical Data Model Package, Data

Dictionary, and Source Mapping Memorandum

Week 7 NASA review

Constraint Identification and Logic Package Week 10 NASA review

Verification and Validation Plan Week 11 NASA review; approval required

Initial Prototype Capability Week 13 NASA review

Sensitivity and Intervention Analysis Report Week 16 NASA review

Scenario Demonstration Package Week 18 NASA review

Verification and Validation Report Week 19 NASA review

Final Documentation, Executable Codebase, Demonstration Artifacts, and Transition Package

Week 20 NASA review; approval required

If the overall period of performance differs materially from 120 working days, milestone dates may be revised by mutual written agreement.

Deliverable Format Requirements Unless otherwise approved in writing, deliverables shall be provided electronically in formats reasonably compatible with NASA’s standard tool environment and sufficient to enable review, reuse, and transition.

Acceptable formats may include:

• reports and memoranda: PDF plus editable source format;

• notebooks, scripts, or code: executable native format plus readable text export where practical;

• structured data: CSV or other NASA-approved non-proprietary format;

• diagrams or mappings: PDF, image, or other NASA-approved format;

• slides or briefings: PDF plus editable source format; and

• packaged artifacts: organized directory structure with readme documentation.

Any open-source or third-party dependencies shall be identified with version, license, and installation requirements.

Review, Comment Resolution, and Acceptance NASA intends to review submitted deliverables and provide comments within a reasonable period unless otherwise agreed.

The University shall address NASA review comments and provide either:

• a revised deliverable; or

• a comment-resolution matrix identifying comment number, source, disposition, response, and cross-reference to revised content.

For draft deliverables, NASA comments may be resolved in the corresponding final version unless NASA directs interim correction.

A deliverable will be considered acceptable when NASA determines that it:

• conforms to the requirements of this SOW;

• is complete for its intended purpose;

• is technically adequate and internally consistent;

• documents assumptions, methods, dependencies, and limitations at a level sufficient for NASA review and reuse;

• is reproducible to the extent reasonably required for its stated purpose and delivered form; and

• is provided in the required format or an approved alternate format.

Data Rights, Software, and Ownership of Work Product Unless superseded by the Contract terms and conditions, the University shall deliver all non-excluded work products generated under this SOW that are necessary for NASA review, use, maintenance, and transition of the prototype.

The University shall identify, prior to incorporation, any pre-existing university-owned code, models, datasets, or other materials proposed for use in performance and any resulting delivery restrictions.

The University shall identify any items withheld from delivery and the basis for withholding.

No proprietary, restricted, or nontransferable components shall be incorporated into the final delivered solution without prior written approval of NASA.

Security, Data Handling, and Public Release The University shall comply with all applicable Contract and NASA requirements related to information handling, site access, and security.

The University shall not disclose, publish, or otherwise release Government-furnished information or derived sensitive operational findings without prior written NASA approval.

Meetings and Reporting Requirements The University shall support the following meetings and reporting events unless otherwise directed:

• one kickoff meeting;

• monthly technical status reviews, unless otherwise directed;

• ad hoc technical interchange meetings, as needed;

• milestone review meetings tied to major deliverables; and

• one final handoff session.

Status reporting shall summarize:

• work accomplished during the reporting period;

• work planned for the next reporting period;

• technical issues, risks, assumptions, and dependencies;

• schedule status; and

• emergent scope-risk conditions that may threaten completion within the one-graduate-researcher staffing construct.

Quality Expectations All work products shall reflect professional technical quality appropriate to a NASA analytical prototype effort.

At a minimum, the University shall ensure:

• clear organization, versioning, and labeling of data, code, models, and documentation;

• traceability between assumptions, source information, logic, and outputs to the extent reasonably applicable;

• identification of software versions, dependencies, and execution requirements;

• explicit documentation of analyst judgment where such judgment substitutes for unavailable data;

• identification of limitations, uncertainty, and intended-use boundaries; and

• identifiable versions or snapshots sufficient for NASA to reproduce milestone submissions.

Basis for Completion The Contract effort will be considered complete when the University has:

• completed all required tasks under this SOW;

• submitted all required deliverables;

• resolved review comments or reached an agreed written disposition for remaining comments;

• completed the final briefing and handoff activities; and

• delivered all final artifacts in accepted form.

Attachment A: Deliverables Matrix

Deliverable Task Minimum Content

Kickoff Briefing Task 1 scope understanding, initial schedule, assumptions, risks, dependencies

Project Management Plan Task 1 management approach, reporting rhythm, milestone plan, coordination approach

Technical Approach Task 1 proposed modeling framework, proposed methods, rationale, risks

Schedule Baseline Task 1 milestone schedule, key dependencies, critical assumptions

Staffing, Risk, and Dependency

Framework

Task 1 staffing plan, continuity approach, risks, dependencies, mitigation approach

Operational Use Case and System

Boundary Package

Task 2 use case, included/excluded activities, interfaces, assumptions, rationale

Prototype Canonical Data Model Package Task 3 core entities, relationships, structural representation, usage notes

Data Dictionary Task 3 field definitions, units, meanings, assumptions, constraints

Source Mapping and Data Conditioning

Memorandum

Task 3 source mapping, conditioning steps, gaps, inferred values, limitations

Constraint Identification and Logic

Package

Task 4 constraint types, logic form, modeled effects, explanation approach

Constraint Traceability and Source-

Assumption Package

Task 4 source references, assumptions, traceability, rationale

Initial Prototype Capability Task 5 executable model logic, representative scenarios, output package, run instructions

Executable Prototype Codebase Task 5 executable notebooks/scripts/code, readme, dependency notes

Verification and Validation Plan Task 6 planned methods, evidence sources, metrics or criteria, limitations

Verification and Validation Report Task 6 plan summary, methods, comparisons, SME review results, uncertainty/limitations, conclusions

Sensitivity and Intervention Analysis

Report

Task 7 sensitivity drivers, interventions assessed, effect on feasibility, findings

Scenario Demonstration Package Task 8 scenario set, assumptions, execution results, output interpretation

User Guide Task 9 user procedures, inputs, outputs, execution steps

Technical Maintenance and Transition

Guide

Task 9 dependencies, environment, maintenance notes, limitations, transition considerations

Final Documentation and Transition

Package

Task 9 organized final delivery of code, docs, artifacts, readme, handoff materials