C_Data Requirements Deleiverables.pdf

DRD No. Title Proposal V&V Compliance Review Checkpoint 1

Initial Baseline

DRD

Delieverable Checkpoint 2 Demo Readiness Review Post Demo Flight Submission Frequency

NEXUS-DRD-001 Service Requirements Compliance Matrix (SRCM) Initial Update Initial Baseline Final Baseline Update as required N/A Update as required or upon significant changes to requirements verification approach

NEXUS-DRD-002 Service Demonstration & Validation Plan (SDVP) Initial Update Initial Baseline Final Baseline Update as required N/A Update as required or prior to major validation activities

NEXUS-DRD-003 Verification Closure Notices (VCN) N/A N/A

Initial verification closure notices as applicable

Updated verification closure notices as applicable

Compilation of VCNs for all verified requirements;

apart from those requirements with Demo flight test activities planned for requirement closure

Final compilation of VCNs for all L1 requirements NLT 30-days post demonstration flight tests

Submit as verification activities are completed or as requirements are closed.

NEXUS-DRD-004 External Interface Control Documents (ICDs) Initial (concept level external interface definition diagrams)

Update Initial Baseline Final Baseline Update as required N/A Update as required or when interface definitions change

NEXUS-DRD-005 Security Architecture Definition (SAD) Initial N/A Initial Baseline Baseline Update as required N/A

Update as required, when security architecture changes, upon completion of security assessments, or as requested by the Government for cybersecurity risk resolution

NEXUS-DRD-006 Service Transition Plan (STP) Initial N/A Initial Baseline Baseline Update as required Update as required Update as required or quarterly during the transition period.

NEXUS-DRD-007 Intellectual Property & Data Rights Management Plan (IPDRMP) Initial N/A Initial Baseline Baseline Update as required Update as required Update as required or when IP/data rights assertions change

NEXUS-DRD-008 Service Financial & Pricing Structure Definition (SFPSD) Preliminary pricing proposal

N/A Initial Baseline Baseline N/A N/A Update as required or annually, or when pricing structure changes

NEXUS-DRD-009+A12:J13Training Emulator Initial (emulator concept)

N/A

Initial simulation delivery with basic functionality

Full-featured simulation with documentation

N/A N/A Updates (with simulation version releases or interface changes)

NEXUS-DRD-010 Continuity of Service Operations Plan (CSOP) Initial Update Initial-Baseline Formal-Baseline Update as required Update as required Update as required or annually, or following significant changes to service architecture or asset configuration

NEXUS-DRD-011 Verification and Validation Compliance Report Initial Final

NEXUS-DRD-012 CLIN 1 Decision Package (Report and Presentation) Final

NEXUS-DRD-013 CLIN 2 Demonstration Readiness Package (Report and Presentation) Final

NEXUS-DRD-014 Monthly Program Status Report (MPSR)

Submission Milestones MaturityExpected Content Maturity

DATA REQUIREMENTS DESCRIPTION (DRD)

1. DPD NO.: TBD

3. DATA TYPE: 1

2. DRD NO.: NEXUS-DRD-001

4. DATE REVISED:

5. PAGE: 1 of 3

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. This deliverable enables the Government to verify compliance with NASA-provided service requirements and assess the Contractor's approach to meeting requirements during the Demonstration Phase.

9. OPR: NEXUS 9. DM: [TBD]

10. DISTRIBUTION: Per program/project/activity determination

11. SUBMISSIONS:

Checkpoint 1 Down-select + 30 days: Initial Baseline

Checkpoint 2: Final Baseline

Demonstration Readiness Review: Updated compliance matrix as required

Post Demonstration Flight: Not applicable

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 as identified in Attachment C of the Government Insight Deliverables document. The Service Requirements Compliance Matrix is a Type 1 data item requiring formal Government review and approval.

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

3. DATA TYPE: 1

2. DRD NO.: NEXUS-DRD-001

4. DATE REVISED:

5. PAGE: 2 of 3

DRD Continuation Sheet

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 during the Demonstration Phase. This document enables objective performance verification and supports informed transition decisions from Demonstration.

15.2 APPLICABLE DOCUMENTS/CLAUSES:

NEXUS Service Requirements Document (SRD) NEXUS-XXX

Applicable contract paragraphs [TBD]

Government Insight Deliverables, Attachment C

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 showing the relationship between each SRD requirement and the verification method(s) to be employed (e.g., test, analysis, inspection, demonstration).

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

Description of the verification approach

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

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

d. References to substantiating evidence including:

Test reports and results

Analysis documentation

3. DATA TYPE: 1

2. DRD NO.: NEXUS-DRD-001

4. DATE REVISED:

5. PAGE: 3 of 3

Inspection records

Demonstration data

Other relevant verification artifacts

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

g. Cross-references to related verification documentation, including the Service Demonstration & Validation Plan and Verification Closure Notices.

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.

3. DATA TYPE: 1

2. DRD NO.: NEXUS-DRD-002

4. DATE REVISED:

5. PAGE: 1 of 5

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.

8. OPR: NEXUS 9. DM: [TBD]

10. DISTRIBUTION: Per program/project/activity determination

11. SUBMISSIONS:

Checkpoint 1 Down-select + 30 days: Initial Baseline

Checkpoint 2: Final Baseline

Demonstration Readiness Review: Updates as required or upon significant changes to requirements validation approach

Post Demonstration Flight: Not applicable

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: Related to Service Requirements Compliance Matrix (NEXUS- DRD-001), Verification Closure Notices, Interface Control Documents (ICDs), and applicable

3. DATA TYPE: 1

2. DRD NO.: NEXUS-DRD-002

4. DATE REVISED:

5. PAGE: 2 of 5 contract paragraphs [TBD] related to demonstration and validation activities.

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. 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.2 APPLICABLE DOCUMENTS/CLAUSES:

NEXUS Service Requirements Document (SRD)

Applicable Interface Control Documents (ICDs)

Government Insight Deliverables, Attachment C

Applicable contract paragraphs [TBD]

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

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

Validation philosophy and approach

Demonstration phase objectives and success criteria

Relationship to IOC readiness determination

Schedule and phasing of validation activities

3. DATA TYPE: 1

2. DRD NO.: NEXUS-DRD-002

4. DATE REVISED:

5. PAGE: 3 of 5

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

Requirement identifier and text

Validation method (test, demonstration, analysis, inspection)

Validation test identifier and description

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

Demonstration acceptance thresholds (quantitative performance thresholds)

Planned validation timeline

c. Detailed test approach and methodology, including:

Test architecture and configuration

Test scenarios and use cases

Test procedures and protocols

Data collection and measurement methods

Test environment description (facilities, equipment, simulators)

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

Organizations involved in validation activities

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

Review and approval authority for validation results

Interface with Government oversight and observation activities

e. Detailed descriptions of all planned validation activities, including:

Prerequisites, dependencies, and constraints

3. DATA TYPE: 1

2. DRD NO.: NEXUS-DRD-002

4. DATE REVISED:

5. PAGE: 4 of 5

Objectives and expected outcomes

Success criteria and acceptance thresholds

Risk mitigation strategies

Contingency plans for test anomalies or failures

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

Validation activity schedule with key milestones

Dependencies between validation events

Integration with overall demonstration phase schedule

Government observation or participation opportunities

g. Description and planned usage of support equipment, software, facilities, and tooling necessary to execute validation activities, including:

Test equipment and instrumentation

Ground systems and network infrastructure

Simulation tools and models

Interface verification capabilities

Data processing and analysis tools

h. Data management approach, including:

Validation data collection, storage, and access procedures

Test results documentation and reporting

Traceability to Service Requirements Compliance Matrix

Evidence package preparation for Verification Closure Notices

i. Identification of any validation deviations, limitations, or assumptions that may affect demonstration results or relay service readiness assessment.

3. DATA TYPE: 1

2. DRD NO.: NEXUS-DRD-002

4. DATE REVISED:

5. PAGE: 5 of 5

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

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.

3. DATA TYPE: 1

2. DRD NO.: NEXUS-DRD-003

4. DATE REVISED:

5. PAGE: 1 of 4

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.

8. OPR: NEXUS 9. DM: [TBD]

10. DISTRIBUTION: Per program/project/activity determination

11. SUBMISSIONS:

Checkpoint 1 Down-select + 30 days: Initial verification closure notices as applicable

Checkpoint 2: 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

Post Demonstration Flight: 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.

14. INTERRELATIONSHIP: Related to Service Requirements Compliance Matrix (NEXUS- DRD-001), Service Demonstration & Validation Plan (NEXUS-DRD-002), and applicable contract paragraphs [TBD] related to verification activities.

3. DATA TYPE: 1

2. DRD NO.: NEXUS-DRD-003

4. DATE REVISED:

5. PAGE: 2 of 4

15. DATA PREPARATION INFORMATION:

15.1 SCOPE: The VCNs 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 IOC readiness. The VCNs enable objective performance verification and informed transition decisions while providing Government insight into verification completeness and quality.

15.2 APPLICABLE DOCUMENTS/CLAUSES:

NEXUS Service Requirements Document (SRD)

Service Requirements Compliance Matrix (NEXUS-DRD-001)

Service Demonstration & Validation Plan (NEXUS-DRD-002)

Government Insight Deliverables, Attachment C

Applicable contract paragraphs [TBD]

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

a. Requirement identification and traceability information:

Unique requirement identifier(s) from the NEXUS SRD

Complete requirement statement(s)

Parent/child requirement relationships, if applicable

Cross-reference to Service Requirements Compliance Matrix (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:

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

3. DATA TYPE: 1

2. DRD NO.: NEXUS-DRD-003

4. DATE REVISED:

5. PAGE: 3 of 4

Summary of verification activities performed

Verification environment and configuration

Dates of verification activities

d. Verification results and evidence:

Summary of verification data collected

Test results, measurements, or analysis outputs

Comparison of actual results against acceptance criteria/thresholds

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

Photographic, video, or other documentary evidence as appropriate

e. Rationale for verification closure, including:

Technical justification that the requirement has been satisfied

Assessment of verification, completeness and adequacy

Explanation of how verification results demonstrate compliance

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

Identification of any waivers, deviations, or variances approved

f. References and access to actual verification data:

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

Document identifiers, revision levels, and dates

Data repository location or access instructions

List of supporting evidence packages

References to specific sections within larger documents

g. Approval signatures and dates:

3. DATA TYPE: 1

2. DRD NO.: NEXUS-DRD-003

4. DATE REVISED:

5. PAGE: 4 of 4

Contractor verification lead or responsible engineer

Contractor program/project approval authority

Date of closure recommendation

h. Cross-references to related verification activities:

Links to Service Demonstration & Validation Plan activities

Dependencies on other requirement verifications

Related Interface Control Document (ICD) verification activities

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

Lessons learned or observations from verification activities

Recommendations for operational constraints or limitations

Identification of follow-on verification activities, if any

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 supporting 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 any revisions. 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.

3. DATA TYPE: 1

2. DRD NO.: NEXUS-DRD-004

4. DATE REVISED:

5. PAGE: 1 of 6

6. TITLE: External Interface Control Documents (ICDs)

7. DESCRIPTION/USE: To document the following for demonstration:

Technical characteristics of the RF interfaces between the customer vehicle and the NEXUS relay satellite.

Technical characteristics of the digital IF interfaces between the customer control center/system and the NEXUS ground system.

Characteristics of the external interfaces for the scheduling, configuring, monitoring, and controlling of services by the customer control center/system.

The ICDs define the technical and operational interfaces between the NEXUS service provider and NASA user systems, enabling validation of service architecture and interfaces and supporting interoperability verification during the Demonstration Phase.

8. OPR: NEXUS 9. DM: [TBD]

10. DISTRIBUTION: Per program/project/activity determination

11. SUBMISSIONS:

Checkpoint 1 Down-select + 30 days: Initial Baseline

Checkpoint 2: Final Baseline

Demonstration Readiness Review: Updates as required

Post Demonstration Flight: Not applicable

12. SUBMISSION FREQUENCY: Update as required or when interface definitions change

13. REMARKS: This DRD supports the Government's need to assess technical feasibility and interface interoperability at defined demarcation boundaries as identified in Attachment E of the Government Insight Deliverables document. The Interface Control Documents are Type 2 data items subject to Government review and approval by exception, with a 45-calendar day review period. ICDs may be submitted as individual documents for each major interface or as a consolidated ICD package covering multiple related interfaces, provided all required content is included and interfaces are clearly delineated. The ICDs are critical

3. DATA TYPE: 1

2. DRD NO.: NEXUS-DRD-004

4. DATE REVISED:

5. PAGE: 2 of 6 for validating service architecture and supporting interface verification testing during the Demonstration Phase.

14. INTERRELATIONSHIP: Related to Service Demonstration & Validation Plan (NEXUS- 002), Application Programming Interface (API), Interface Simulation, Security Architecture Definition, and applicable contract [TBD] paragraphs related to interface requirements and interoperability validation.

15. DATA PREPARATION INFORMATION:

15.1 SCOPE: The Interface Control Documents (ICDs) define the technical characteristics of all interfaces between the NEXUS service provider systems and NASA user systems at established demarcation boundaries. These documents establish the interface baseline necessary to ensure interoperability, support verification and validation activities, and enable NASA users to design, develop, and integrate their systems with the NEXUS service. The ICDs address all relevant interfaces required for demonstration and operational service delivery, including spacecraft interfaces (forward and return links), ground network interfaces, user interaction interfaces, and service scheduling interfaces. The level of detail must be sufficient to support independent development and integration of interfacing systems, as well as objective verification of interface compliance and interoperability. Each ICD must define interface specifications, protocols, and data exchange mechanisms using standards-based, non-proprietary approaches at the defined service demarcation boundaries to enable interoperability with external providers, including commercial, international, and government systems. The Contractor must identify applicable open standards, document any proprietary extensions or constraints, and clearly state assumptions that may affect interoperability, multi-provider integration, or future service expansion.

15.2 APPLICABLE DOCUMENTS/CLAUSES:

NEXUS Service Requirements Document (SRD)

Applicable industry standards for interface specifications

Applicable RF spectrum regulations and frequency coordination requirements

Service Demonstration & Validation Plan (NEXUS-DRD-002)

Government Insight Deliverables, Attachment C

Applicable contract paragraphs [TBD]

15.3 CONTENTS: The Interface Control Documents (ICDs) must include the following content, organized by interface type or as appropriate to the NEXUS service architecture:

3. DATA TYPE: 1

2. DRD NO.: NEXUS-DRD-004

4. DATE REVISED:

5. PAGE: 3 of 6

a. General Information:

ICD identification, revision level, and date

Scope and applicability of the ICD

Interface overview and context diagram

List of interfacing systems/entities

Demarcation boundary definition and responsibility allocation

Identification of applicable interface standards and protocols supporting interoperability, including any deviations or proprietary elements

Acronyms, abbreviations, and definitions

Points of contact for interface coordination

b. RF Interface Characteristics:

Frequency allocations and channel assignments

Polarization characteristics

Power levels (EIRP, G/T, antenna gain patterns)

Bandwidth and spectral characteristics

Link budget analysis and margins

Pointing requirements and coverage areas

Doppler considerations

Interference mitigation and coordination requirements

Regulatory compliance information (spectrum licensing)

d. Ground Network Interfaces:

Ground interface architecture (Architecture of the digital IF interface between the customer control center/system and NEXUS ground system)

Forward Service Digital IF Interface (Characteristics of the digitally sampled Forward Service IF signal provided by the customer control center/system to the NEXUS ground system)

Return Service Digital IF Interface (Characteristics of the digitally sampled Return Service IF signal provided by the NEXUS ground system to the customer control center/system)

Digital Transport Interface (Transport mechanism used to convey digital IF signals between the customer control center/system and the NEXUS ground system)

Timing and Synchronization (Timing and synchronization requirements associated with the digital IF interface)

Interface Configuration and Control (Configuration parameters and control information required to establish or modify Forward or Return Service interfaces)

3. DATA TYPE: 1

2. DRD NO.: NEXUS-DRD-004

4. DATE REVISED:

5. PAGE: 4 of 6

Monitoring and Status Information (Interface monitoring information available to the Customer MOC)

DRD Continuation Sheet

Interface Performance Constraints (Performance constraints applicable to the digital IF interfaces)

e. Application Programming Interface (API)

API Overview API Architecture and Design API access methods and Authentication API Reference Documentation Data Models and Schemas Data exchange formats between API and other interfaces Service Request and Provisioning Functions Scheduling and Reservation Functions Data Transfer and File Management Error Handling and Status Codes Code Examples and SDKs API Security and Best Practices Versioning and Backward Compatibility Data Transfer and File Management Monitoring and Status Retrieval User and Account Management Testing and Sandbox Environment Change Log and Release Notes Compliance and Standards Support and Resources

f. User Interaction and Scheduling Interfaces:

User service request procedures and format

Scheduling request interfaces and protocols

g. Service reservation and allocation mechanisms

User notification and status reporting interfaces Mission planning interface requirements Contact scheduling parameters and constraints Real-time monitoring and control interfaces Post-pass data delivery interfaces and formats Customer support and help desk interfaces

3. DATA TYPE: 1

2. DRD NO.: NEXUS-DRD-004

4. DATE REVISED:

5. PAGE: 5 of 6

h. Interface Performance and Quality Requirements:

Availability and reliability requirements Performance thresholds and acceptance criteria Interface monitoring and reporting requirements Anomaly reporting and resolution procedures Maintenance windows and notification requirements

i. Interface Verification and Validation:

Interface verification approach and test methods Interoperability test requirements, including validation of compatibility with external or alternate service providers using standards-based interfaces Interface validation criteria and acceptance thresholds Cross-reference to Service Demonstration & Validation Plan Interface compatibility certification procedures

j. Interface Change Control:

Change management procedures Version control and configuration management Impact analysis requirements for interface changes Notification and coordination procedures Backwards compatibility considerations

k. Operational Constraints and Limitations:

Interface operational constraints Environmental constraints affecting interface performance Known limitations or conditions Contingency operations and degraded mode interfaces Failure modes and recovery procedures

l. Supporting Information:

Interface drawings, diagrams, and schematics Message catalogs and data dictionaries Example transactions and use cases Interface compliance matrices

15.4 FORMAT: Contractor format is acceptable. ICDs may be organized as individual documents for each major interface category (e.g., separate ICDs for spacecraft interfaces, ground network interfaces, user scheduling interfaces) or as a consolidated ICD document with clearly delineated sections for each interface. Electronic format with searchable content, hyperlinks, and embedded diagrams is preferred. Interface diagrams should follow standard

3. DATA TYPE: 1

2. DRD NO.: NEXUS-DRD-004

4. DATE REVISED:

5. PAGE: 6 of 6 interface definition conventions (e.g., block diagrams, protocol stack diagrams, timing diagrams). Where applicable, industry-standard ICD formats may be utilized.

15.5 MAINTENANCE: The ICDs must be maintained current throughout the Demonstration Phase and into operational service delivery. Changes and/or updates must be submitted in accordance with the schedule specified in Item 12, prior to implementing any interface changes, or as requested by the Government. All updates must follow the interface change control procedures defined within the ICDs. Significant interface changes requiring Government review must be submitted at least 30 days prior to planned implementation. The Contractor must highlight all changes from the previous submission using revision marks or a comprehensive revision summary and must provide assessment of impacts on interfacing systems and verification activities. Changes and/or updating must be in accordance with the provider/contractor's approved change control system. ICD revision history must be maintained and included in each submission.

3. DATA TYPE: 1

2. DRD NO.: NEXUS-DRD-005

4. DATE REVISED:

5. PAGE: 1 of 12

6. TITLE: Security Architecture Definition (SAD)

7. DESCRIPTION/USE: To define the security architecture design addressing all aspects of cybersecurity, encryption, and other security protocols for the NEXUS service. Includes submittal of a Cybersecurity Assessment and Authorization (CASQ) package. This document enables the Government to assess cybersecurity risks, resolve cybersecurity concerns, protect Government interests during demonstration execution, and ensure compliance with NASA security requirements and policies during the Demonstration Phase.

8. OPR: NEXUS 9. DM: [TBD]

10. DISTRIBUTION: Per program/project/activity determination; distribution limited based on security classification and sensitivity

11. SUBMISSIONS:

Checkpoint 1 Down-select + 30 days: Initial Baseline

Checkpoint 2: Final Baseline

Demonstration Readiness Review: Updates as required

Post Demonstration Flight: Not applicable

12. SUBMISSION FREQUENCY: Update as required, when security architecture changes, upon completion of security assessments, or as requested by the Government for cybersecurity risk resolution

13. REMARKS: Reference applicable NASA cybersecurity policies, NIST standards (e.g., NIST SP 800-53, NIST Cybersecurity Framework), and Federal Information Security Modernization Act (FISMA) requirements. This DRD supports the Government's need to resolve cybersecurity risks and protect Government interests as identified in Attachment C of the Government Insight Deliverables document. The Security Architecture Definition is a Type 2 data item subject to Government review and approval by exception, with a 45-calendar day review period. Where appropriate, the Contractor may consolidate cybersecurity and CASQ artifacts to reduce administrative burden while maintaining required insight. Due to the sensitive nature of security information, special handling and distribution restrictions apply to this deliverable.

3. DATA TYPE: 1

2. DRD NO.: NEXUS-DRD-005

4. DATE REVISED:

5. PAGE: 2 of 12

14. INTERRELATIONSHIP: Related to Interface Control Documents (NEXUS-004), Service Demonstration & Validation Plan (NEXUS-002), and applicable contract paragraphs [TBD] related to cybersecurity, information assurance, and data protection requirements.

15. DATA PREPARATION INFORMATION:

15.1 SCOPE: The Security Architecture Definition (SAD) provides a comprehensive description of the NEXUS service cybersecurity architecture, including technical and operational security controls, encryption methods, security protocols, risk management approach, and continuous monitoring capabilities. The SAD addresses security across all system elements including space segment, ground segment, network infrastructure, user interfaces, and data management systems.

The document demonstrates how the Contractor's security architecture protects NASA data, systems, and operations from cybersecurity threats and vulnerabilities while meeting applicable NASA security policies and Federal requirements. The SAD includes or references the Cybersecurity Assessment and Authorization (CASQ) package that documents the security authorization process, risk assessment results, security control implementation, and authorization decisions. The level of detail must be sufficient to enable Government assessment of cybersecurity posture, identification and mitigation of security risks, and informed authorization decisions.

15.2 APPLICABLE DOCUMENTS/CLAUSES:

NEXUS Service Requirements Document (SRD) NASA cybersecurity policies and directives, as applicable

NIST Special Publication 800-53 (Security and Privacy Controls)

NIST Cybersecurity Framework

Federal Information Security Modernization Act (FISMA) requirements as applicable

Committee on National Security Systems (CNSS) instructions, as applicable

DoD security requirements, as applicable

3. DATA TYPE: 1

2. DRD NO.: NEXUS-DRD-005

4. DATE REVISED:

5. PAGE: 3 of 12

Interface Control Documents (NEXUS-DRD-004)

Government Insight Deliverables, Attachment C

Applicable contract paragraphs [TBD]

15.3 CONTENTS: The Security Architecture Definition (SAD) must include the following:

a. Executive Summary:

Overview of the security architecture approach

Security architecture philosophy and design principles

Summary of key security capabilities and controls

Compliance statement with NASA security requirements

Security authorization status

b. System Security Context:

System description and operational environment

System boundaries and demarcation points

Data flow diagrams showing information flows and security domains

Identification of assets requiring protection (data, systems, networks)

Classification and sensitivity of data handled by the system

Threat environment and adversary characterization

Security categorization (NIST.FIPS.199 or equivalent)

c. Security Architecture Design:

Overall security architecture framework and structure

Security zones and domains

Defense-in-depth strategy and layered security approach

3. DATA TYPE: 1

2. DRD NO.: NEXUS-DRD-005

4. DATE REVISED:

5. PAGE: 4 of 12

Security architecture diagrams and models

Security design principles applied (e.g., least privilege, separation of duties)

Integration of security controls across system layers

Secure-by-design features and capabilities

d. Access Control and Authentication:

User authentication methods and multi-factor authentication

Access control policies and role-based access control (RBAC)

Privileged user management and monitoring

Account management and provisioning procedures

Session management and timeout policies

Remote access controls and VPN security

Physical access controls for facilities and equipment

e. Encryption and Cryptography:

Encryption methods for data at rest and data in transit

Cryptographic algorithms and key lengths

Key management architecture and procedures

Certificate management and public key infrastructure (PKI)

Encryption for command and telemetry links

Encryption for ground network communications

Compliance with FIPS 140-3 for cryptographic modules

End-to-end encryption capabilities

f. Network Security:

3. DATA TYPE: 1

2. DRD NO.: NEXUS-DRD-005

4. DATE REVISED:

5. PAGE: 5 of 12

3. DATA TYPE: 1

2. DRD NO.: NEXUS-DRD-005

4. DATE REVISED:

5. PAGE: 6 of 12

Network architecture security design

Firewall configurations and policies

Intrusion detection and prevention systems (IDS/IPS)

Network segmentation and isolation

Secure network protocols and standards

Virtual private networks (VPN) and secure tunneling

Wireless security measures, if applicable

Denial of Service (DoS) protection mechanisms

Network monitoring and traffic analysis capabilities

g. Security Controls Implementation:

Detailed description of security controls implemented

Mapping of controls to NIST SP 800-53 or equivalent framework

Technical controls (e.g., firewalls, encryption, monitoring)

Operational controls (e.g., procedures, training, incident response)

Management controls (e.g., policies, risk management, oversight)

Control implementation status and effectiveness

Compensating controls for any unimplemented or partially implemented controls

h. Vulnerability Management and Patching:

Vulnerability assessment and scanning procedures

Patch management process and schedules

Configuration management and secure baseline maintenance

Software and firmware update procedures

3. DATA TYPE: 1

2. DRD NO.: NEXUS-DRD-005

4. DATE REVISED:

5. PAGE: 7 of 12

Security testing and evaluation approach

Penetration testing plans and results

i. Security Monitoring and Incident Response:

Continuous monitoring of architecture and capabilities

Security Information and Event Management (SIEM) implementation

Log collection, retention, and analysis

Anomaly detection and alerting mechanisms

Incident detection and response procedures

Incident reporting and coordination with NASA

Forensics capabilities and evidence preservation

Security metrics and performance indicators

j. Data Protection and Privacy:

Data protection measures throughout the data lifecycle

Data sanitization and disposal procedures

Backup and recovery security controls

Privacy protection measures for sensitive data

Data loss prevention (DLP) capabilities

Separation of customer data and multi-tenancy security

k. Supply Chain Security:

Supply chain risk management approach

Vendor and third-party security assessments

Hardware and software component security

3. DATA TYPE: 1

2. DRD NO.: NEXUS-DRD-005

4. DATE REVISED:

5. PAGE: 8 of 12

Trusted sources for critical components

Software provenance and integrity verification

l. Security Governance and Management:

Security organization and roles/responsibilities

Security policies, standards, and procedures

Security training and awareness programs

Security configuration management

Change control procedures for security-relevant changes

Compliance and audit processes

Security risk management framework

m. Cybersecurity Assessment and Authorization (CASQ) Package:

System Security Plan (SSP) or equivalent documentation

Security assessment report and findings

Risk assessment methodology and results

Identified vulnerabilities and mitigation strategies

Plan of Action and Milestones (POA&M) for remediation items

Security authorization decision documentation

Authority to Operate (ATO) status and conditions

Continuous monitoring plan

n. Security Requirements Traceability:

Mapping of NASA security requirements to implemented controls

Compliance demonstration with NEXUS SRD security requirements

3. DATA TYPE: 1

2. DRD NO.: NEXUS-DRD-005

4. DATE REVISED:

5. PAGE: 9 of 12

3. DATA TYPE: 1

2. DRD NO.: NEXUS-DRD-005

4. DATE REVISED:

5. PAGE: 10 of 12

Cross-reference to Service Requirements Compliance Matrix

Identification of any security requirement waivers or deviations

o. Security Testing and Validation:

Security testing approach and methodologies

Penetration testing results and remediation

Security control validation results

Cross-reference to Service Demonstration & Validation Plan

Ongoing security assessment schedule

p. Operational Security Considerations:

Security constraints and operational limitations

Security considerations for contingency operations

Security incident handling during demonstration and operations

Security coordination procedures with NASA security teams

Security decommissioning and data disposition procedures

15.4 FORMAT: Contractor format is acceptable. The SAD may be submitted as a single consolidated document or as a document package with the CASQ artifacts provided separately or as appendices. Due to the sensitive nature of security information, the SAD must clearly mark security-sensitive sections and follow appropriate handling procedures. Detailed technical security information (e.g., firewall rules, encryption keys, vulnerability details) may be provided in classified annexes or supplementary documents with appropriate access controls. Electronic submission with appropriate encryption and access controls is required.

15.5 MAINTENANCE: The SAD must be maintained current throughout the Demonstration Phase and into operational service delivery. Changes and/or updates must be submitted in accordance with the schedule specified in Item 12, following any security architecture changes, after security assessments or audits, upon identification of new threats or vulnerabilities, or as requested by the Government. Significant security

3. DATA TYPE: 1

2. DRD NO.: NEXUS-DRD-005

4. DATE REVISED:

5. PAGE: 11 of 12

3. DATA TYPE: 1

2. DRD NO.: NEXUS-DRD-005

4. DATE REVISED:

5. PAGE: 12 of 12 architecture changes must be coordinated with NASA security authorities prior to implementation. Security incidents, newly identified vulnerabilities, or changes to threat environment must be reported promptly per incident response procedures, with SAD updates submitted within 30 calendar days of incident resolution. The CASQ package must be updated annually or more frequently as required by NASA security policy. Changes and/or updating must be in accordance with the provider/contractor's approved change control system and security configuration management procedures. All updates must include revision history and summary of changes affecting security posture. Changes and/or updates shall must be in accordance with the provider/contractor's approved change control system.

3. DATA TYPE: 1

2. DRD NO.: NEXUS-DRD-006

4. DATE REVISED:

5. PAGE: 1 of 10

6. TITLE: Service Transition Plan (STP)

7. DESCRIPTION/USE: To define readiness criteria and operational activation path from demonstration to service delivery. This plan documents the strategy, activities, criteria, and timeline for transitioning the NEXUS service from the Demonstration Phase to Initial Operational Capability (IOC), enabling the Government to make informed transition decisions, assess IOC readiness, and ensure establishment of the technical and operational foundation for sustained service delivery.

8. OPR: NEXUS 9. DM: [TBD]

10. DISTRIBUTION: Per program/project/activity determination

11. SUBMISSIONS:

Checkpoint 1 Down-select + 30 days: Initial Baseline

Checkpoint 2: Formal Baseline

Demonstration Readiness Review: Updates as required

Post Demonstration Flight: Updates as required

12. SUBMISSION FREQUENCY: Update as required or quarterly during the transition period.

13. REMARKS: This DRD supports the Government's need to enable a structured transition from Demonstration to Initial Operational Capability and prepare for follow-on Full Operational Capability (FOC) acquisition actions as identified in Attachment E of the Government Insight Deliverables document. The Service Transition Plan is a Type 2 data item subject to Government review and approval by exception, with a 45-calendar day review period. This plan is critical for enabling informed transition decisions and ensuring IOC readiness. The plan addresses transition readiness criteria tailored to the demonstration validation and transition readiness scope, recognizing that certain long-term operational artifacts may be deferred to a subsequent Full Operational Capability (FOC) contract.

14. INTERRELATIONSHIP: Related to Service Demonstration & Validation Plan (NEXUS- DRD-002), Verification Closure Notices (NEXUS-DRD-003), Service Requirements Compliance Matrix

3. DATA TYPE: 1

2. DRD NO.: NEXUS-DRD-006

4. DATE REVISED:

5. PAGE: 2 of 10

(NEXUS-DRD-001), Security Architecture Definition (NEXUS-DRD-005), Continuity of Service Operations Plan, Service Financial & Pricing Structure Definition (NEXUS-DRD-008) , and applicable contract paragraphs [TBD] related to IOC criteria and transition requirements.

15. DATA PREPARATION INFORMATION:

15.1 SCOPE: The Service Transition Plan (Demonstration through IOC) provides a comprehensive description of the Contractor's approach to transitioning the NEXUS service from Demonstration Phase to IOC. The plan defines the readiness criteria that must be satisfied to declare IOC, describes the operational activation path and sequence of activities required to achieve service delivery capability, and establishes the timeline and milestones for transition execution. The plan addresses technical readiness, operational readiness, regulatory compliance readiness, infrastructure readiness, organizational readiness, and risk mitigation necessary to support sustained service delivery. The Service Transition Plan enables the Government to assess IOC readiness, make informed transition authorization decisions, and ensure that the technical and operational foundation for sustained service delivery has been established. The scope is tailored to support demonstration validation and transition readiness, recognizing that certain long-term operational artifacts (e.g., enforceable Service Level Agreements, full-service assurance frameworks, mature operational governance plans) may be deferred to a subsequent FOC contract.

15.2 APPLICABLE DOCUMENTS/CLAUSES:

NEXUS Service Requirements Document (SRD) IOC requirements

Service Demonstration & Validation Plan (NEXUS-DRD-002)

Verification Closure Notices (NEXUS-DRD-003)

Service Requirements Compliance Matrix (NEXUS-DRD-001)

Security Architecture Definition (NEXUS-DRD-005)

Government Insight Deliverables, Attachment C

Applicable contract paragraphs [TBD]

3. DATA TYPE: 1

2. DRD NO.: NEXUS-DRD-006

4. DATE REVISED:

5. PAGE: 3 of 10

15.3 CONTENTS: The Service Transition Plan must include the following:

a. Executive Summary:

Overview of transition approach and philosophy

Transition timeline and major milestones

Summary of IOC readiness criteria

Key transition risks and mitigation strategies

Transition decision gates and approval authorities

b. Transition Strategy and Approach:

Transition objectives and success criteria

Phased transition approach (if applicable)

Transition phases and major activities

Relationship between Demonstration Phase, IOC, and future FOC

Service activation strategy (e.g., limited initial service, phased user onboarding)

Parallel operations approach (if demonstration and initial operations overlap)

Fallback and contingency strategies

c. IOC Readiness Criteria:

Technical readiness criteria:

Verification closure status for NEXUS SRD requirements

System performance validation against NEXUS SRD requirements

Interface interoperability demonstration

Service architecture validation at demarcation boundaries

Hardware/software configuration readiness

Spare equipment and redundancy availability

3. DATA TYPE: 1

2. DRD NO.: NEXUS-DRD-006

4. DATE REVISED:

5. PAGE: 4 of 10

Operational readiness criteria:

Operational procedures documented and validated

Mission operations center (MOC) or network operations center (NOC) readiness

24/7 operations capability (if required)

Customer support capabilities established

Service ordering and provisioning systems operational

Infrastructure readiness criteria:

Space segment operational status

Ground segment operational status

Network infrastructure operational status

Monitoring and control systems operational

Backup and contingency systems operational

Regulatory readiness criteria:

Export control compliance established

Spectrum licenses and authorizations obtained

Regulatory approvals in place for service delivery

Cybersecurity authorization (ATO/ATC) obtained

Business readiness criteria:

Service pricing structure defined and approved

Customer agreements templates prepared

Billing and financial management systems…