B_Data Procurement Document (DPD).pdf

B-1

DATA PROCUREMENT DOCUMENT

NO. ISSUE

1916 RFP

XXXXX

CONTRACT/RFP

EXHIBIT NUMBER

B

ATTACHMENT NUMBER

Network Extension for User Continuity and Sustainability (NEXUS)

PROJECT/SYSTEM

Contractor

CONTRACTOR

June 2, 2026

DATE

National Aeronautics and Space Administration

06/02/26

B-2

National Aeronautics and Space Administration

DOCUMENT CHANGE LOG

NO. ISSUE

1916 RFP

INCORPORATED REVISIONS

OUTSTANDING REVISIONS

AS OF:

06-02-26

SUPERSEDING:

PAGE:

AUTHORITY PORTION AFFECTED - PAGE NO./NO.

REMARKS

(DPD Revision) INTRO SGR DRL DRD

B-3

1.0 INTRODUCTION

1.1 Scope: Subject to the Rights in Data clause, this Data Procurement Document (DPD) sets forth the data requirements in each Data Requirements Description (DRD) and shall govern that data required by the DPD for the contract. The contractor shall furnish data defined by the DRDs listed on the Data Requirements List (DRL) by category of data, attached hereto, and made a part of this DPD. Such data shall be prepared, maintained, and delivered to NASA in accordance with the requirements set forth within this DPD. In cases where data requirements are covered by a Federal Acquisition Regulation (FAR) or NASA FAR Supplement (NFS) clause, that clause shall take precedence over the DPD, consistent with clause FAR 52.215-8, Order of Precedence - Uniform Contract Format (DEVIATION NOV 2025)

1.2 DPD Description: This DPD consists of a Document Change Log, an Introduction, a

Statement of General Requirements, DPD maintenance procedures, a DRL, and the DRDs.

1.2.1 General Requirements: The general requirements, as specified in paragraph 2.0 of this DPD, prescribe those requirements applicable to the preparation, maintenance, and delivery of data that are better defined in aggregate than in the individual DRDs.

1.2.2 Data Requirements List (DRL): Throughout the performance of the contract, the DRL provides a listing by data category of the data requirements of the DPD.

1.2.3 Data Requirements Description (DRD)

1.2.3.1 Each data requirement listed on the DRL is given complete definition by a DRD. The DRD prescribes content, format, maintenance instructions, and submittal requirements.

1.2.3.2 RESERVED

1.2.3.3 The symbols representing these data categories form part of the prefix of the DRD identification number. The first numerical characters reflect the DPD number.

1.2.3.4 To facilitate the usage and maintenance of the DPD, the DRDs have been sectionalized in accordance with the above data categories.

1.2.3.5 The DRDs are filed by data category and are in alpha-numeric sequence as listed on the

DRL page (or pages) that precedes the DRDs.

1.2.4 Document Change Log (DCL): The Document Change Log chronologically records all revision actions that pertain to the DPD.

1.2.5 DPD Maintenance Procedures: Maintenance procedures define the detailed methods to be employed in maintaining the DPD. Detailed maintenance procedures are specified in paragraph 3.0 of this DPD.

1.3 Data Types for Contractual Efforts: The types of data and their contractually applicable requirements for approval and delivery are:

B-4

TYPE DESCRIPTION

1* All issues and interim changes to those issues require written approval from the requiring organization before formal release for use or implementation.

2* NASA reserves a time-limited right to disapprove in writing any issues and interim changes to those issues. The contractor shall submit the required data to NASA for review not less than 45 calendar days** prior to its release for use. The contractor shall clearly identify the release target date in the “submitted for review” transmittal***. If the data is unacceptable, NASA will notify the contractor within 45 calendar days** from the date of submission, regardless of the intended release date***. The contractor shall resubmit the information for reevaluation if disapproved.

The submittal is considered approved if the contractor does not receive disapproval or an extension request from NASA within 45 calendar days**.

3 These data shall be delivered by the contractor as required by the contract and do not require NASA approval. However, to be a satisfactory delivery, the data shall satisfy all applicable contractual requirements and be submitted on time.

4 These data are produced or used during performance of the contract and are retained by the contractor. They shall be delivered only when NASA requests in writing and shall be delivered in accordance with the instructions in the request. The contractor shall maintain a list of these data and shall furnish copies of the list to NASA when requested to do so.

5 These data are incidental to contract performance and are retained by the contractor in those cases where contracting parties have agreed that formal delivery is not required.

However, the Contracting Officer (CO) or the Contracting Officer’s Representative (COR) shall have access to and can inspect this data at its location in the contractor’s or subcontractor’s facilities, or in an electronic database accessible to the Government.

* Note: Type 1 and Type 2 data may be placed under NASA configuration management control when designated by NASA. CM control requires the contractor to submit Type 1 and Type 2 data updates through Engineering Change Proposals (ECPs).

** Note: This time limit may be tailored for individual DRDs to meet the requirements of the procuring activity.

*** Note: If the contractor does not identify a release target date or if the intended release date is shorter than 45 calendar days from the date of submission, the 45 calendar days review cycle stands (or the tailored Type 2 time limitation for the specific procurement).

2.0 STATEMENT OF GENERAL REQUIREMENTS

2.1 Applicable/Reference Documents: Documents included as applicable documents in this

DPD are the issue specified in the Statement of Work and form a part of the DPD to the extent specified herein. Applicable documents listed in Item 15.2 of a DRD are applicable only to the preparation of the deliverable documentation described by that DRD.

References to documents other than applicable documents in the data requirements of this DPD may sometimes be utilized and shall be indicated in 13. Remarks of the DRD. These do not constitute a contractual obligation on the contractor. They are to be used only as a

B-5 possible example or to provide related information to assist the contractor in developing a response to that particular data requirement.

2.2 Subcontractor Data Requirements

2.2.1 The contractor shall specify to subcontractors and vendors, if any, the availability source of all data required for the satisfactory accomplishment of their contracts. The contractor shall validate these requirements for documents when appropriate; where the requirement concerns other contractor data, the contractor shall provide his subcontractor or vendor with the necessary documents. All such requests shall be accomplished under the auspices of the contractor.

2.2.2 Reference to subcontractor data in the contractor’s responses is permissible, providing the references are adequate and includes such identification elements as title, number, revision, etc., and a copy of the referenced data is supplied with the response document at time of delivery to NASA.

2.3 Data Distribution, Format, Data Restriction Marking, and Transmittal

2.3.1 Distribution: Distribution of required documentation shall be in quantities determined by the CO. Recipient names and email addresses (if applicable) shall be noted on a separate distribution list to be furnished by the CO. The CO’s letter may include other information pertinent to delivery of data, as required.

2.3.2 Format

2.3.2.1 Electronic Format: Electronic submission of data deliverables is required. Electronic deliverables shall be printable. Data deliverables shall be delivered to NASA in the format specified below unless a specific format is required by a DRD. Data submittals shall consist of a single Adobe Acrobat PDF file and the native format electronic file(s). The preferred native formats include Microsoft Word, Excel, PowerPoint or CAD drawing plot file, as appropriate. Where a single native format file is not possible, multiple files may be integrated into a single ZIP file for submission. The organization of the contents of the integrated ZIP file shall be made readily apparent to the reader, and each file within the integrated product shall be clearly identifiable and traceable within the organization of the integrated product. If files are fragmented, file names shall be labeled logically and contiguously, and the files shall be easily reassembled or merged (e.g. 1 filename, 2 filename, 2a filename, etc.). The software versions shall be confirmed prior to submittals.

2.3.2.2 Hardcopy Format: Hardcopy of the DPD is not required unless electronic delivery is not possible or practical. The contractor’s transmittal memo shall be delivered in a hardcopy to the CO. The DPD shall be emailed to the CO.

2.3.3 Controlled Unclassified Information (CUI) Data Restriction Markings

2.3.3.1 CUI Data Restriction Determination and Marking Requirements: The contractor shall determine whether each data deliverable contains Controlled Unclassified Information (CUI), information the Government creates or possesses, or that an entity creates or

B-6 possesses for or on behalf of the Government, that a law, regulation, or Government-wide policy requires or permits an agency to handle using safeguarding or dissemination controls.

Data deliverables that contain CUI shall be managed, marked, and protected in accordance with NPR 2810.7 and CFR 32 Part 2002. Per NPR 2810.7, CUI data shall be marked with a CUI Banner on each page that is inclusive of all CUI within the data. The CUI Banner will be the same on each page, be placed at the top of each page, centered, bolded, in a single line with multiple CUI markings in alphabetic order separated by a single slash (NOTE: See NPR 2810.7 for CUI Specified correct slash and dash placement and usage). In addition, the following statement from Standard Form (SF) 901 may be placed on the title page:

“ATTENTION: This document is CONTROLLED UNCLASSIFIED INFORMATION (CUI). All individuals handling this information are required to protect it from unauthorized disclosure. Handling, storage, reproduction, and disposition of the attached document(s) must be in accordance with 32 CFR Part 2002 and applicable agency policy. Access to and dissemination of Controlled Unclassified Information shall be allowed as necessary and permissible to any individual(s), organization(s), or grouping(s) of users, provided such access or dissemination is consistent with or in furtherance of a Lawful Government Purpose and in a manner consistent with applicable law, regulations, and Government-wide policies.”

2.3.3.2 Data Restriction Categories and Marking Statements: In addition to CUI markings, the contractor shall consider the following data restriction categories, as a minimum, and utilize specified marking statements.

2.3.3.2.1 Export Control Restrictions. If data delivered under this contract is subject to export control restrictions, which includes International Traffic in Arms Regulations (ITAR) or Export Administration Regulations (EAR), the export-controlled information is required to be marked “CUI//SP-EXPT” in accordance with NPR 2810.7 prior to dissemination to NASA.

CUI//SP‐EXPT controlled information is unclassified information concerning certain items, commodities, technology, software, or other information whose export could reasonably be expected to adversely affect the United States national security and nonproliferation objectives.

If data delivered under this contract is subject to ITAR, in addition to the CUI marking the data shall contain an “ITAR Notice” on the cover page as required by NAII 2190.1, section 2.2.1.1, with the appropriate United States Munitions List (USML) category filled in at the top of the ITAR Notice. On subsequent pages, it is recommended to place the following statement at the bottom or footer, “See title page for restrictions”.

B-7

If data delivered under this contract is subject to EAR, in addition to the CUI marking the data shall contain the “EAR Notice” on the cover page as required by NAII 2190.1, section 2.2.1.1, with the appropriate Commerce Control List (CCL) Export Control Classification Number (ECCN) filled in at the top of the EAR Notice. On subsequent pages, it is recommended to place the following statement at the bottom or footer, “See title page for restrictions”.

2.3.3.2.2 Limited Rights Restrictions. If the contract contains FAR 52.227-14 Alternate II, the “Limited Rights Notice” may be applicable to technical data (other than computer software) delivered under this contract. The “Limited Rights Notice” is as follows:

2.3.3.2.3 Restricted Rights Computer Software. If the contract contains FAR 52.227-14 Alternate III, the “Restricted Rights Notice” may be applicable to computer software delivered under this contract. The “Restricted Rights Notice” is as follows:

USML Category ___ International Traffic in Arms Regulations (ITAR) Notice

This document contains information which falls under the purview of the U.S. Munitions List (USML), as defined in the International Traffic in Arms Regulations (ITAR), 22 CFR §120-130, and is export controlled. It shall not be transferred to foreign persons, in the U.S. or abroad, without specific approval of a knowledgeable NASA export control official, and/or unless an export license or license exemption is obtained/available from the Directorate of Defense Trade Controls, United States Department of State. Violations of these regulations are punishable by fine, imprisonment, or both.

CCL ECCN ___

Export Administration Regulations (EAR) Notice

This document contains information within the purview of the Export Administration Regulations (EAR), 15 CFR §730-774, and is export controlled. It may not be transferred to foreign persons in the U.S. or abroad without specific approval of a knowledgeable NASA export control official, and/or unless an export license or license exception is obtained/available from the Bureau of Industry and Security, United States Department of Commerce. Violations of these regulations are punishable by fine, imprisonment, or both.

Limited Rights Notice (Dec 2007)

a) These data are submitted with limited rights under Government Contract No. _____ (and subcontract ______, if appropriate). These data may be reproduced and used by the Government with the express limitation that they will not, without written permission of the Contractor, be used for purposes of manufacture nor disclosed outside the Government; except that the Government may disclose these data outside the Government for the following purposes, if any; provided that the Government makes such disclosure subject to prohibition against further use and disclosure: [Agencies may list additional purposes as set forth in 27.404-2(c)(1) or if none, so state. (b) This notice shall be marked on any reproduction of these data, in whole or in part.

B-8

2.3.3.2.4 Small Business Innovation Research (SBIR) Rights. If the contract contains FAR 52.227- 20, the “SBIR Rights Notice” may be applicable to SBIR data delivered under this contract.

The “SBIR Rights Notice” is as follows:

2.3.3.2.5 Other Restrictions. If the contract contains NFS 1852.237-73, a sensitive information legend may be applicable to information (which does not qualify as technical data or computer software) delivered under this contract.

In accordance with the applicable data clause (e.g., FAR 52.227-14(c) or FAR 52.227- 20(c)), the contractor may be able to assert copyright in data first produced in the performance of the contract. When claim to copyright is made, the Contractor shall affix

Restricted Rights Notice (Dec 2007)

(a) This computer software is submitted with restricted rights under Government Contract No. _______ (and subcontract ________, if appropriate). It may not be used, reproduced, or disclosed by the Government except as provided in paragraph (b) of this notice or as otherwise expressly stated in the contract. (b) This computer software may be— (1) Used or copied for use with the computer(s) for which it was acquired, including use at any Government installation to which the computer(s) may be transferred; (2) Used or copied for use with a backup computer if any computer for which it was acquired is inoperative; (3) Reproduced for safekeeping (archives) or backup purposes; (4) Modified, adapted, or combined with other computer software, provided that the modified, adapted, or combined portions of the derivative software incorporating any of the delivered, restricted computer software shall be subject to the same restricted rights; (5) Disclosed to and reproduced for use by support service Contractors or their subcontractors in accordance with paragraphs (b)(1) through (4) of this notice; and (6) Used or copied for use with a replacement computer. (c) Notwithstanding the foregoing, if this computer software is copyrighted computer software, it is licensed to the Government with the minimum rights set forth in paragraph (b) of this notice. (d) Any other rights or limitations regarding the use, duplication, or disclosure of this computer software are to be expressly stated in, or incorporated in, the contract. (e) This notice shall be marked on any reproduction of this computer software, in whole or in part.

SBIR Rights Notice (DEC 2007) These SBIR data are furnished with SBIR rights under Contract No._____ (and subcontract _____, if appropriate). For a period of 4 years, unless extended in accordance with FAR 27.409(h), after acceptance of all items to be delivered under this contract, the Government will use these data for Government purposes only, and they shall not be disclosed outside the Government (including disclosure for procurement purposes) during such period without permission of the Contractor, except that, subject to the foregoing use and disclosure prohibitions, these data may be disclosed for use by support Contractors. After the protection period, the Government has a paid-up license to use, and to authorize others to use on its behalf, these data for Government purposes, but is relieved of all disclosure prohibitions and assumes no liability for unauthorized use of these data by third parties. This notice shall be affixed to any reproductions of these data, in whole or in part.

B-9 the applicable copyright notices of 17 U.S.C. 401 or 402 and acknowledgment of Government sponsorship (including contract number) to the data.

2.3.4 Transmittal

2.3.4.1 Data shall be transmitted to NASA by email, CD or DVD, hardcopy, or other mechanism agreed to by the CO, COR, and Project representatives who are responsible to receive, index, and store the data deliverables.

2.3.4.2 If email is used to transmit data deliverables, the email size shall be 10 Megabytes or less to ensure receipt by the NASA email servers. Encrypted email format shall be used to transmit data which has been judged sensitive by the contractor (e.g., export controlled, limited rights data, SBIR, restricted computer software, copyrighted, etc.).

2.3.4.3 Data Transmittal Package: Each data transmittal package shall include:

a. Transmittal memorandum that specifies the meta-data below for each data transmittal:

1. Contract number.

2. Data Requirements Description (DRD) number.

3. DRD data type (specified in Item 3 on the DRD).

4. Submission date or milestone being satisfied.

5. Document number and revision.

6. Document title.

7. File names of all files being delivered; file naming convention shall clearly identify the document being delivered.

8. Distribution (as defined by the CO’s letter).

9. Requested response date.

10. Contractor assigned data restriction (export controlled, limited rights data, SBIR, restricted computer software, copyrighted, etc.) if not marked on data.

11. NASA Records Retention Schedule (NRRS) number, if applicable (See NRRS

1441.1, NASA Records Retention Schedules).

b. Printable electronic files or hardcopy data.

2.3.5 When electronic data deliverables are transmitted directly to the MSFC Repository, SharePoint web interface shall be utilized. Instructions for electronic data submittals can be found at https://sharepoint.msfc.nasa.gov/rm/repo/SitePages/Home.aspx. For further information, contact the MSFC Repository Manager.

2.4 Printing: All printing, duplicating, or binding shall be in accordance with NFS 1852.208-81

(DEVIATION PCD 25-18), Restrictions on Printing and Duplicating. Printing formal reports and Type 1 and 2 data in book format shall be in accordance with the following general specifications:

a. Method of reproduction – offset/xerography.

b. Finished size – 8 1/2” X 11”.

c. Paper – 20-pound opaque bond.

d. Cover – Litho cover stock.

e. Pages shall be printed on both sides; blank pages shall be avoided when possible.

f. Oversize pages shall be avoided, when possible, but, if necessary, shall be folded to 8 1/2” X 11”.

B-10

g. Binding shall be the most economical method commensurate with the size of the report and its intended use.

2.5 Contractor’s Internal Documents: The contractor’s internal documents shall be used to meet the data requirements of this DPD unless a specific format is required by the applicable

DRD.

2.6 Document Identification: Type 1 and 2 documents published by the contractor and submitted in response to the data requirements of this DPD shall be identified within an organized identification numbering system prescribed to NASA by the contractor and, if applicable, as approved by NASA. For all data types, the document number, change legend, date, and title constitute the minimum identification of the specific document and shall appear on the cover and title page. The contract number shall also appear on the cover and title page as separate markings. The originator and organization shall be included on the title page. The document number, change legend, and date shall appear on each page of the document. In the front matter of each document, identify the DPD number and applicable DRD number(s) required for document preparation. Successive issues or revisions of documents shall be identified in the same manner as the basic issue and shall have appropriate change identification. Drawings and ECP's are excluded from the marking provisions of this paragraph. All Type 1 documentation, excluding configuration management requirements, shall be marked “PRELIMINARY PENDING NASA APPROVAL,” and once approved shall be reissued with “APPROVED BY NASA” and the date and approval authority annotated on the cover.

2.7 Reference to Other Documents and Data Deliverables in Data Submittals: All referenced documents shall be made readily available to the cognizant NASA organization upon request. The contractor shall make sure that the references are available to NASA in a manner which does not incur delays in the use of the response document. Reference may be made, within one data submittal, to other data submittals delivered in response to this DPD in those cases where the data required by one DRD may have been delivered by the contractor in response to another DRD. The reference to previously submitted data shall include the applicable DRD number, data submittal version date, and location within the referenced document.

2.8 Maintenance of Type 1 Document Submittals

2.8.1 Revisions of Type 1 documentation may be accomplished either by individual page revision or by a complete reissue of the document identified in accordance with requirements of 2.6 above, with the exception of drawings (which shall be revised in accordance with contract configuration management requirements).

2.8.2 Individual page revisions shall be made as deemed necessary by the contractor or as directed by the CO.

2.8.3 A Type 1 document shall be completely reissued when, in the opinion of the contractor and/or NASA, the document has been revised to the extent that it is unusable in its present state, or when directed by the CO. When complete reissues are made, the entire contents of the document shall be brought up to date and shall incorporate revised pages. All revisions

B-11 shall be recorded. A revision log shall identify complete reissues except for periodic reports and documents which are complete within themselves as final.

2.8.4 Changes of a minor nature to correct obvious typing errors, misspelled words, etc., shall only be made when a technical change is made, unless the accuracy of the document is affected.

2.8.5 All revised pages shall be identified by a revision symbol and a new date. Each document shall contain a log of revised pages that identify the revision status of each page with the revision symbol. This list shall follow the table of contents in each document. The line or lines revised on a given page shall be designated by the use of vertical line in the margin of the page, and the change authority shall be indicated adjacent to the change.

2.8.6 Contractor Type 1 document shall not be submitted containing pen and ink markups which correct, add to, or change the text, unless schedule problems exist and approval is obtained in writing from the CO. Such markups, however, shall not exceed 20 percent of the page content and shall be acceptable provided that the reproduced copies are legible. In addition, hand-drawn schematics, block diagrams, data curves, and similar charts may be used in original reports in lieu of formally prepared artwork, as long as legibility of copies is not impaired. Acceptability shall be determined by the CO.

3.0 DPD MAINTENANCE PROCEDURES

3.1 NASA-Initiated Change: New and/or revised data requirements shall be incorporated by contract modification to which the new or revised portion of the DPD shall be appended.

The contractor shall notify the CO in the event a deliverable data requirement is imposed and is not covered by a DRD, or when a DRD is changed by a contract modification and for which no revision to DPD is appended. In such cases, the contractor shall submit the requested changes to NASA for approval. See paragraph 3.3.1 for change procedures.

3.2 Contractor-Initiated Change: Contractor-proposed data requirements or proposed changes to existing requirements shall be submitted to NASA for approval.

3.3 DPD Change Procedures

3.3.1 Changes to a contractual issue of this DPD shall be identified by NASA on the Document

Change Log.

3.3.2 The date of the DPD shall be entered under the “as of” block of the Document Change Log.

The date that was in the “as of” block shall be entered in the “Superseding” block.

3.3.3 The Document Change Log entitled “Incorporated Revisions” shall be changed to indicate the modification number, portions affected, and remarks. All changes to the DPD/DRDs shall be identified in the “Remarks” column.

B-12

3.4 DPD Reissues

3.4.1 When conditions warrant, the DPD shall be reissued by NASA for each contract modification that affects the DPD and shall supersede the existing DPD in its entirety.

Reissues shall be issued by contractual direction.

3.4.2 All revision dates shall remain in the Date Revised block on all DRDs. The issue symbol, which shall commence with "A" and progress through "Z," shall be entered in the DPD identification block of each DRD page of the DPD.

3.5 Contract Line-Item Number: A uniquely numbered contract item used to identify and manage specific deliverables, services, work scope, or funding elements within a Government contract. CLINs establish the contractual basis for performance, pricing, funding, and payment.

3.6 Authority to Proceed (ATP): A formal Government authorization that allows a contractor to begin a specified phase of contract work, incur associated costs, and execute activities defined within the contract or task order. ATP is typically issued after the Government determines that required prerequisites, approvals, funding, and readiness criteria have been satisfied.

B-13

Network Extension for User Continuity and Sustainability (NEXUS)

Data Requirements List (DRL)

DRD DATA TYPE TITLE OPR

NEXUS-DRD-001 1 Service Requirements Compliance Matrix NEXUS

(SRCM)

NEXUS-DRD-002 1 Service Demonstration & Validation Plan NEXUS

(SDVP)

NEXUS-DRD-003 1 Verification Closure Notices (VCN) NEXUS NEXUS-DRD-004 2 External Interface Control Documents (ICDs) NEXUS NEXUS-DRD-005 2 Security Architecture Definition (SAD) NEXUS NEXUS-DRD-006 2 Service Transition Plan (STP) NEXUS NEXUS-DRD-007 2 Security Architecture Definition (SAD) NEXUS NEXUS-DRD-008 1 Service Financial & Pricing Structure Definitions NEXUS

(SFPSD)

NEXUS-DRD-009 2 Training Emulator NEXUS NEXUS-DRD-010 3 Continuity of Service Operations Plan (CSOP) NEXUS NEXUS-DRD-011 2 Verification/Validation Compliance Report NEXUS

(VVCR)

NEXUS-DRD-012 1 CLIN 1 Decision Report and Presentation Package NEXUS NEXUS-DRD-013 1 CLIN 2 Demonstration Readiness Package NEXUS NEXUS-DRD-014 2 Monthly Program Status Report (MPSR) NEXUS NEXUS-DRD-015 2 CLIN 2 Demonstration Performance Validation NEXUS Package (DPVP) NEXUS-DRD-016 1 Organizational Conflict of Interest (OCI) Plan OP NEXUS-DRD-017 1 Security Requirements for Unclassified IT OCIO Resources NEXUS-DRD-018 1 Demonstration Integration & Maturity NEXUS Presentation Package NEXUS-DRD-019 2 Integrated Master Schedule (IMS) NEXUS NEXUS-DRD-020 2 Radio Frequency Link Margin and Dynamic Link NEXUS Budget Analysis Report (RF-LMDBAR)

B-14

DATA REQUIREMENTS DESCRIPTION (DRD)

1. DPD NO.: NEXUS ISSUE: RFP 2. DRD NO.: NEXUS-DRD-001

3. DATA TYPE: 1 4. DATE REVISED:

5. PAGE: 1/2

6. TITLE: Service Requirements Compliance Matrix (SRCM)

7. DESCRIPTION/USE: Provides compliance with the NEXUS Service Requirements

Document (SRD) to include expected compliance, compliance rationale, verification approach, and verification evidence, along with references to any analysis, test, or other substantiating evidence used to demonstrate compliance. Enables the Government to verify compliance with NASA-provided service requirements and assess the Contractor's approach to meeting requirements during the Demonstration Phase.

8. OPR: NEXUS 9. DM: ST40

10. DISTRIBUTION: Per program/project/activity determination

11. SUBMISSIONS: Verification and Validation Compliance Review: Not applicable; CLIN 1

Design Outbrief: Not applicable; CLIN 2 Authorization to Proceed (ATP) + 30 days: Initial Baseline. Demonstration & Integration Maturity Checkpoint: Final Baseline.

Demonstration Readiness Review: Update compliance matrix as required. Demonstration Performance Validation Review: Update compliance matrix as required.

12. SUBMISSION FREQUENCY: Update as required or upon significant changes to requirements verification approach

13. REMARKS: This DRD supports the Government's need to evaluate progress toward demonstration objectives and support formal milestone reviews. The Service Requirements Compliance Matrix is a Type 1 data item requiring formal Government review and approval.

14. INTERRELATIONSHIP: NEXUS-DRD-002, Service Demonstration & Validation Plan, NEXUS-DRD-003, Verification Closure Notices and applicable contract paragraphs [TBD] related to verification and compliance demonstration.

15. DATA PREPARATION INFORMATION:

15.1 SCOPE: The Service Requirements Compliance Matrix (SRCM) provides comprehensive traceability from each NEXUS Service Requirements Document (SRD) requirement to the verification method(s) and evidence used to demonstrate compliance. The SRCM serves as the primary document for demonstrating how the Contractor's service architecture, implementation, and performance meet NASA service requirements. This document enables objective performance verification and supports informed transition decisions from Demonstration.

15.2 APPLICABLE DOCUMENTS/CLAUSES:

NEXUS-RQMT-001 NEXUS Service Requirements Document (SRD)

B-15

DRD Continuation Sheet TITLE: Service Requirements Compliance Matrix (SRCM) DRD NO.: NEXUS-DRD-001

DATA TYPE: 1 PAGE: 2/2

15. DATA PREPARATION INFORMATION (CONTINUED):

15.3 CONTENTS: The Service Requirements Compliance Matrix (SRCM) must include the following:

a. Complete listing of all NEXUS SRD requirements with unique requirement identifiers.

b. Traceability mapping from NEXUS SRD requirements to first-level Contractor derived/decomposed requirements and associated verification method(s) to be employed (e.g., test, analysis, inspection, demonstration).

c. Verification compliance rationale for each NEXUS SRD requirement, including:

1. Description of the verification approach.

2. Status of verification (planned, in-progress, complete).

3. Compliance determination (compliant, non-compliant, partially compliant, not yet verified).

d. References and access to substantiating evidence including:

1. Test reports and results.

2. Analysis documentation.

3. Inspection records.

4. Demonstration data.

5. Other relevant verification artifacts.

e. Documentation of any deviations, waivers, or variances from stated requirements, including proposed mitigation approaches.

f. Cross references to related verification documentation including the Service Demonstration

& Validation Plan and Verification Closure Notices.

g. Explicit identification of verification and validation evidence derived from end-to-end service demonstration, including:

1. Mapping of demonstration scenarios to SRD requirements.

2. Identification of multi-user, high-load, and stressed condition validation cases.

3. Traceability to NEXUS-DRD-002, Service Demonstration and Validation Plan activities.

15.4 FORMAT: Contractor format is acceptable. The matrix may be provided in spreadsheet, database, or other electronic format that supports sorting, filtering, and traceability analysis. At a minimum, the following fields should be included: Requirement ID, Requirement Text, Verification Method, Verification Status, Compliance Status, Rationale, and Evidence References.

15.5 MAINTENANCE: The SRCM must be maintained current throughout the Demonstration

Phase. Changes and/or updates must be submitted in accordance with the schedule specified in Item 12 or as requested by the Government. Updates must reflect changes in requirements, verification approaches, verification status, and compliance determinations. The Contractor must highlight all changes from the previous submission and provide a summary of significant updates in a transmittal letter or revision history section. Changes and/or updates must be in accordance with the provider/contractor's approved change control system.

B-16

1. DPD NO.: NEXUS ISSUE: RFP 2. DRD NO.: NEXUS-DRD-002

5. PAGE: 1/4

6. TITLE: Service Demonstration & Validation Plan (SDVP)

7. DESCRIPTION/USE: To define the test approach, requirement validation matrix mapping validation tests to requirements with associated validation criteria, and demonstration acceptance thresholds for the NEXUS service. This plan documents the validation activities and organizational structure necessary to demonstrate performance against NASA service requirements.

11. SUBMISSIONS: Verification and Validation Compliance Review: Not applicable; CLIN 1

Design Outbrief: Not applicable; CLIN 2 Authorization to Proceed (ATP) + 30 days: Initial Baseline; Demonstration & Integration Maturity: Final Baseline; Demonstration Readiness Review: Update as required or upon significant changes to requirements validation approach; Demonstration Performance Validation Review: Update as required.

12. SUBMISSION FREQUENCY: Update as required or prior to major validation activities

13. REMARKS: This DRD supports the Government's need to evaluate progress toward demonstration objectives and enable objective performance verification as identified in Attachment E of the Government Insight Deliverables document. The Service Demonstration & Validation Plan is a Type 1 data item requiring formal Government review and approval.

This plan may be supplemented by specific test procedures, analysis plans, or demonstration scripts as appropriate, provided the collective documentation meets the content requirements specified herein.

14. INTERRELATIONSHIP: NEXUS-DRD-001, Service Requirements Compliance Matrix, NEXUS-DRD-003, Verification Closure Notices and NEXUS-DRD-004, External Interface Control Documents and applicable contract paragraphs [TBD] related to verification and compliance demonstration.

B-17

TITLE: Service Demonstration & Validation Plan (SDVP) DRD NO.: NEXUS-DRD-002

DATA TYPE: 1 PAGE: 2/4

15. DATA PREPARATION INFORMATION:

15.1 SCOPE: The Service Demonstration & Validation Plan (SDVP) provides a comprehensive description of the Contractor's approach to validating service performance during the Demonstration Phase. The plan defines the strategy, methods, criteria, and acceptance thresholds for demonstrating that the NEXUS service meets NASA-provided service requirements at the defined demarcation boundaries. The validation approach must include end-to-end validation across the complete service chain from user system interfaces through the space relay and ground segments and return path, including representative or actual user systems. This document addresses validation of service architecture, interfaces, performance parameters, and operational capabilities necessary to support informed relay service transition decisions. The SDVP emphasizes demonstrated outcomes and objective performance verification while preserving Contractor flexibility in design and implementation approach.

15.3 CONTENTS: The Service Demonstration & Validation Plan (SDVP) must include the following:

a. Overview of the service demonstration and validation program, including:

1. Validation philosophy and approach.

2. Demonstration phase objectives and success criteria.

3. Relationship to Initial Operational Capability (IOC) readiness determination.

4. Schedule and phasing of validation activities.

b. Requirement Validation Matrix that maps each NEXUS SRD requirement to planned validation test(s), including:

1. Requirement identifier and text.

2. Validation method (test, demonstration, analysis, inspection).

3. Validation test identifier and description.

4. Associated validation criteria (pass/fail criteria, measurement parameters).

5. Demonstration acceptance thresholds (quantitative performance thresholds).

6. Planned validation timeline.

c. Detailed test approach and methodology, including:

1. Test architecture and configuration.

2. Test scenarios and use cases.

3. Test procedures and protocols.

4. Data collection and measurement methods.

5. Test environment description (facilities, equipment, simulators).

6. End-to-end validation architecture including user system participation and full-service path representation.

d. Description of the organizational structure for implementing the validation program, including:

1. Organizations involved in validation activities.

2. Roles and responsibilities for test execution, data collection, and analysis.

B-18

TITLE: Service Demonstration & Validation Plan (SDVP) DRD NO.: NEXUS-DRD-002

DATA TYPE: 1 PAGE: 3/4

15. DATA PREPARATION INFORMATION (CONTINUED):

3. Review and approval authority for validation results.

4. Interface with Government oversight and observation activities.

e. Detailed descriptions of all planned validation activities including:

1. Prerequisites, dependencies, and constraints including spectrum authorization for RF testing.

2. Objectives and expected outcomes.

3. Success criteria and acceptance thresholds.

4. Risk mitigation strategies.

5. Contingency plans for test anomalies or failures.

6. Validation under multi-user access scenarios.

7. Validation under high-load or stressed service conditions.

8. Validation of degraded or constrained operational modes.

f. Time-correlated sequence of validation activities, including:

1. Validation activity schedule with key milestones.

2. Dependencies between validation events.

3. Integration with overall demonstration phase schedule.

4. Government observation or participation opportunities.

g. Description of the validation environment and supporting capabilities sufficient to demonstrate credible execution of verification and validation activities, including:

1. The overall validation architecture and approach (e.g., test, analysis, demonstration, simulation).

2. High-level description of representative validation assets (e.g., test environments, instrumentation, or tools), to the extent necessary to demonstrate adequacy and credibility of the validation approach, without requiring disclosure of proprietary implementation details.

3. Capabilities supporting interface validation and interoperability validation at defined service demarcation boundaries for ground and space segments used to exercise end-to-end service performance.

4. Modeling, simulation, or emulation capabilities used to supplement validation, including their role and limitations, data processing, analysis, and evidence generation methods used to support verification closure and Government Inspection of Records (IoR).

h. Data management approach including:

1. Validation data collection, storage, and access procedures

2. Test results documentation and reporting.

3. Traceability to Service Requirements Compliance Matrix.

4. Evidence package preparation for Verification Closure Notices.

i. Identification of any validation deviations, limitations, or assumptions, including those that may affect end-to-end service performance or multi-user operational behavior

j. Identification of demonstration Test Like You Fly (TLYF) exceptions.

B-19

TITLE: Service Demonstration & Validation Plan (SDVP) DRD NO.: NEXUS-DRD-002

DATA TYPE: 1 PAGE: 4/4

15. DATA PREPARATION INFORMATION (CONTINUED):

15.4 FORMAT: Contractor format is acceptable. The plan may be organized in sections, chapters, or modules as appropriate to the Contractor's approach. The Requirement Validation Matrix may be provided as an integrated section within the plan or as a separate controlled appendix/annex, and may utilize spreadsheet, database, or other electronic format that supports sorting, filtering, and traceability analysis.

15.5 MAINTENANCE: The SDVP must be maintained current throughout the Demonstration

Phase. Changes and/or updates shall be submitted in accordance with the schedule specified in Item 12 or as requested by the Government. Updates must reflect changes in requirements, validation approaches, test schedules, validation criteria, acceptance thresholds, or organizational structure. The Contractor must highlight all changes from the previous submission and provide a summary of significant updates in a transmittal letter or revision history section. Changes and/or updates must be in accordance with the provider/contractor's approved change control system.

B-20

1. DPD NO.: NEXUS ISSUE: RFP 2. DRD NO.: NEXUS-DRD-003

5. PAGE: 1/3

6. TITLE: Verification Closure Notices (VCN)

7. DESCRIPTION/USE: To document verification closure statements with rationale for closure of NEXUS service requirements, including references and access to actual verification data.

These notices provide formal documentation that individual NASA-provided service requirements or groups of requirements have been successfully verified.

11. SUBMISSIONS: Verification and Validation Compliance Review: Not applicable; CLIN

1 Design Outbrief: Not applicable; CLIN 2 Authorization to Proceed + 30 days: Initial verification closure notices as applicable; Demonstration & Integration Maturity: Updated verification closure notices as applicable; Demonstration Readiness Review: Compilation of VCNs for all verified requirements; apart from those requirements with Demo flight verification test activities planned for requirement closure; Demonstration Performance Validation Review: Final compilation of VCNs for all NEXUS service requirements NLT 30-days post demonstration flight tests.

12. SUBMISSION FREQUENCY: Submit as verification activities are completed or as requirements are closed.

13. REMARKS: MSFC-HDBK-2221 Volume II provides examples of verification closure documentation that can be used as a guide in the development of or in the assessment of similar documentation. This DRD supports the Government's need to verify compliance with NEXUS service requirements and evaluate progress toward demonstration objectives as identified in Attachment C of the Government Insight Deliverables document.

VCNs are Type 1 data items requiring formal Government review and approval. VCNs may be submitted individually as verification activities are completed or in consolidated packages covering related requirements, provided all required content is included and traceability is maintained.

NEXUS-DRD-002, Service Demonstration & Validation Plan and applicable contract paragraphs [TBD] related to verification and compliance demonstration.

B-21

TITLE: Verification Closure Notices (VCN) DRD NO.: NEXUS-DRD-003

DATA TYPE: 1 PAGE: 2/3

15. DATA PREPARATION INFORMATION:

15.1 SCOPE: The Verification Closure Notices (VCN) provide formal documentation that specific

NEXUS Service Requirements Document (SRD) requirements have been successfully verified through completion of planned verification activities. Each VCN documents the verification approach executed, presents the verification evidence and results, provides a rationale for requirement closure, and includes references to the actual verification data packages. VCNs serve as the definitive record demonstrating that individual NEXUS service requirements have been met and support the Government's assessment of Initial Operational Capability (IOC) readiness. The VCNs enable objective performance verification and support Government transition decisions (e.g., Demonstration to IOC) by providing traceable evidence of requirement verification, while also providing Government insight into verification completeness and quality.

NEXUS-RQMT-001 Service Requirements Document (SRD)

15.3 CONTENTS: Each Verification Closure Notice (VCN) must include the following:

a. Requirement identification and traceability information:

1. Unique requirement identifier(s) from the NEXUS SRD.

2. Complete requirement statement(s).

3. Parent/child requirement relationships, if applicable

4. Cross-reference to Service Requirements Compliance Matrix per NEXUS-DRD-001.

b. Verification summary statement clearly declaring the verification status (e.g., "Requirement XXX has been successfully verified and is recommended for closure").

c. Verification approach and methodology:

1. Description of verification method(s) employed (test, demonstration, analysis, inspection).

2. Summary of verification activities performed.

3. Verification environment and configuration.

4. Dates of verification activities

d. Verification results and evidence:

1. Summary of verification data collected.

2. Test results, measurements, or analysis outputs.

3. Comparison of actual results against acceptance criteria/thresholds.

4. Identification of any anomalies, deviations, or non-conformances encountered and their resolution.

5. Photographic, video, or other documentary evidence as appropriate.

6. Identification of whether verification evidence includes end-to-end demonstration results and associated operational conditions.

e. Rationale for verification closure, including:

1. Technical justification that the requirement has been satisfied.

2. Assessment of verification completeness and adequacy.

3. Explanation of how verification results demonstrate compliance.

B-22

TITLE: Verification Closure Notices (VCN) DRD NO.: NEXUS-DRD-003

DATA TYPE: 1 PAGE: 3/3

15. DATA PREPARATION INFORMATION (CONTINUED):

4. Discussion of any limitations, assumptions, or conditions affecting the verification.

5. Identification of any waivers, deviations, or variances approved

f. References and access to actual verification data:

1 Identification and location of detailed test reports, analysis reports, inspection records, or other verification documentation.

2. Document identifiers, revision levels, and dates.

3. Data repository location or access instructions.

4. List of supporting evidence packages.

5. References to specific sections within larger documents

g. Approval signatures and dates:

1. Contractor verification lead or responsible engineer.

2. Contractor program/project approval authority.

3. Date of closure recommendation

h. Cross-references to related verification activities:

1. Links to Service Demonstration & Validation Plan activities.

2. Dependencies on other requirement verifications.

3. Related Interface Control Document (ICD) verification activities

i. Any supplementary information necessary to support Government review and approval:

1. Lessons learned or observations from verification activities.

2. Identification of follow-on verification activities, if any.

3. Identification of any operational constraints, limitations, or performance sensitivities identified during verification activities

15.4 FORMAT: Contractor format is acceptable. VCNs may be submitted as individual documents for each requirement, consolidated documents covering related requirements, or as entries in a verification database or tracking system, provided all required content is accessible and traceable. Each VCN should be uniquely identified and version controlled. Electronic submission with hyperlinks to support evidence packages is encouraged to facilitate Government review and access to actual verification data.

15.5 MAINTENANCE: Individual VCNs must be considered final upon Government approval and must not require routine updating. However, if post-closure issues are identified (e.g., verification data errors, requirement changes, operational anomalies), the Contractor must submit revised VCNs with clear identification of changes, rationale for revision, and updated closure justification. A master VCN tracking log must be maintained and updated to reflect submission dates, approval status, and revisions for all VCNs. The tracking log must be submitted monthly or as requested by the Government to provide insight into verification progress and closure status across all NEXUS SRD requirements. Changes and/or updates must be in accordance with the provider/contractor's approved change control system.

B-23

1. DPD NO.: NEXUS ISSUE: RFP 2. DRD NO.: NEXUS-DRD-004

3. DATA TYPE: 2 4. DATE REVISED:

5. PAGE: 1/5

6.…