Blank CRM - Due 18 Mar 2024 by 1200L.xlsx
XLSX spreadsheet 68 KB Posted
- Attached to
- SSC/AATS SAFS 2. 1 Federal contract opportunity
- Solicitation number
- FA881124RB003(FA881124FB005)
About this file
This presolicitation notice outlines plans for the Space Systems Command Acquisition and Financial Support Task Order 2.1 contract. The Space Systems Command intends to issue a competitive solicitation using the General Services Administration OASIS Small Business Pool 5B IDIQ contract vehicle to acquire advisory and assistance services that are non-personal in nature and not inherently governmental. The period of performance is anticipated to begin in fiscal year 2025 with a firm fixed price contract. The objectives of the acquisition strategy are to provide flexibility for dynamic requirements, increase competition, and reduce award complexities through standardized documents on the GSA OASIS SB vehicle. Only contractors holding GSA OASIS SB Pool 5B prime contracts may submit proposals as the prime; subcontracting with OASIS SB primes is permitted. Respondents are to complete an attached comment resolution matrix on the draft solicitation and submit it to the government point of contact by March 18, 2024, properly marking any proprietary information. This notice is not itself a solicitation and responses cannot form a binding contract.
View the file
Other files for this federal contract opportunity
Show all 18
On GovTribe
Work with this file on GovTribe
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
(2) PWS
Document Title:
Document Date:
Types of Comments:
A - Administrative: addresses what appears to be typographical, format, grammar, punctuation, and style errors S - Substantive: addresses factually incorrect material C - Critical: addresses contentious issue that will cause non-concurrence with the publication tc={D49FA48F-A9B0-44E2-B905-41D9666979B5}: [Threaded comment]
Your version of Excel allows you to read this threaded comment; however, any edits to it will get removed if the file is opened in a newer version of Excel. Learn more: https://go.microsoft.com/fwlink/?linkid=870924
Comment:
[Mention was removed] [Mention was removed] [Mention was removed] .....not sure why but someone is collapsing rows and columns while others like me are reviewing responses. Can we not do that collapsing please?
| Item # | Organization/ Company | Source Document | Type | |||
| A/S/C | Page | |||||
| # | Para / Section # | Comment |
For any proposed changes include WAS/IS text.
| If you need clarification or have a question, please contact the document author; do not pose questions as comments. | Rationale | |||
| Provide concise, objective explanation of the rationale for the comment. Include requirement justification (e.g. "This requirement needed to meet SPRD360"). | Gov't Decision | |||
| A/R/M | Suggested Response | Notes / Need Help? | Ready for Review (Y/N) | NL/KP Concur |
| (Y/N) | Change made to doc |
(Y/N)
| 119 | 1 | SpaceX | PWS | S | 5 | 1.2.2.1 Notify | Remove the last sentence, “Notification is considered complete when the USG Team acknowledges receipt.” | It is not appropriate to tie LVC requirement compliance to USG actions. It is not part of the USG’s current process to acknowledge receipt of 10,000+ actions, activities, or processes which could be submitted as virtual notifications or live access to Contractor systems, and does not seem in line with the Government’s desire to transition to an always-accessible digital ecosystem. | R | Government considered but deemed the language necessary to support standards and methodology. | this sentence is consistent with phase 2 language | Y | Y | |
| 120 | 2 | SpaceX | PWS | S | 6 | 1.2.2.6 Provide | Change second sentence from “The responsibility to provide is accomplished when the specified recipient acknowledges receipt,” to “The responsibility to provide is accomplished when the Contractor notifies the receiving party the item has been delivered.” | It is not appropriate to tie LVC requirement compliance to USG actions. Outside of CDRL deliveries which are confirmed to be received by the COR, it is not part of the USG’s current process to acknowledge receipt of 10,000+ data products “provided” over the course of a Launch Service or mission Task Order. It does not appear to be manageable for USG to implement this process to individually acknowledge receipt of everything provided. | R | Government considered but deemed the language necessary to support standards and methodology. | Phase 2 language - The responsibility to provide is accomplished when the Contracting Officer’s Representative (COR) acknowledges receipt, or the PCO approves, the relevant Contract Data Requirements List (CDRL). | Y | Y | N/A |
| 323 | 3 | SpaceX | PWS | C | 6 | 2.1 Compliance Documents | Recommend edits as follows: From “The Contractor shall comply with the applicable documents listed in Appendix C unless tailoring is approved per the instructions listed in CDRL A019.” to “The Contractor shall comply with the applicable documents listed in Appendix C unless tailoring or meeting the intent of a substitute of the standard is approved per the instructions listed in CDRL A019.” | CDRL A019 allows two different methods for Contractor approval, 1) “an approved tailored version of the standard” or 2) meeting the intent via “a substitute of the standard which can be an existing company standard, documented and configuration controlled company processes, NASA standard, other industry standard, or international standard.” As written, the PWS language only mentions the first option and not both; thus we suggest a minor edit to be consistent with CDRL A019 language. | AAE |
MR: please confirm if the LSP's requested change, "applicable documents listed in Appendix C unless tailoring or meeting the intent of a substitute of the standard is ..... acceptable.
| 324 | 5 | SpaceX | PWS | S | 7 | 3 Space Launch Service, last paragraph | Recommend adding the sentence “Similarly, the Contractor will work with the Government to innovate the Government’s IV&V and mission assurance practices as much as practical.” | Working together on innovation should be encouraged in both directions, from the Government to the Contractor (as noted in current sentence), and vice versa (in the proposed added sentence). This provides value both to the Contractor and the Government. | M | Government has updated the paragraph in the PWS. | Y | Y | |
| 121 | 6 | SpaceX | PWS | S | 7 | 3 Space Launch Service, last paragraph | Please provide clarification/definition of what is considered “innovation” of the launch service (“The Government will work with the Contractor to innovate the launch service as much as practicable.”) | Unclear what “innovation” is referring to. Further, the PWS should state necessary/”required” requirements and not just possible innovations. | M | Government has updated the paragraph in the PWS. | Y | Y | |
| 226 | 7 | SpaceX | PWS | S | 7 | 3.1.4.1 LSS Launch System Integrated Data Environment | Please consider removing duplicative requirements. | Many of the requirements in the IDE section are duplicative with each other. | Not an AAE item | ||||
| 325 | 8 | SpaceX | PWS | S | 7 | 3.1.4.1 LSS Launch System Integrated Data Environment | Recommend adding the following sentence: “The Contractor shall work with the USG Product Line Chief Engineer to partner and implement requirements within this section.” | As many requirements in this section are generalized or could be up for interpretation, recommend providing a USG POC to oversee this section and work with the contractor to partner a solution that meets Government needs. | A | Government concurs and has updated the PWS as per the recommendation. | Greg |
MR: wasn't this a NO, per a comment from first PWS review? I'll look at the first CRM which captured those comments GP Coment is valid I dont think the CE is the right person though
| 326 | 9 | SpaceX | PWS | C | 7 | 3.1.4.1.1 Implement and Maintain Integrated Data Environment | Recommended revising to “The Contractor shall implement and maintain an IDE providing USG continuous near real-time access to all Launch System Data generated in support of this contract.” | As currently written “Launch System Data” is not clarified to apply specifically to data within scope of this contract. This is not defined in the Glossary either. | A | Government concurs and has updated the PWS as per the recommendation. | MR: Agree with addition of "generated in support of this contract". Adds clarity to which Launch System Data is included in this contract's scope | Y | Y |
| 327 | 10 | SpaceX | PWS | S | 7 | 3.1.4.1.1 Implement and Maintain Integrated Data Environment | Suggest removal of the word “readable” as it has a different connotation with model-based systems engineering. | The interpreted intent is for the IDE to be compatible with the Government system, not necessarily be setup so meta-data can be stripped off with unknown Government tools. | AAE | ||||
| 329 | 11 | SpaceX | PWS | S | 7 | 3.1.4.1.1 Implement and Maintain Integrated Data Environment | Add “per mutual agreement” after “…USG software applications used in support of this contract”. | This isn’t scopeable without understanding what USG software applications will be used. As written, the Contractor would be continually obligated to change internal systems/data to be compatible with unknown future systems. | Comment is valid I dont think the CE is the right person though | ||||
| 122 | 12 | SpaceX | PWS | S | 8 | 3.1.4.1.4 LSS Itemized Listing of IDE Content | Remove 3.1.4.1.4. | The itemized listing of IDE content is duplicative with the CDRL for DAL (3.1.4.5). In addition, the IDE isn’t defined as a single item but rather the entire digital ecosystem, as explained by the Government during Industry day. | AAE |
FED: The ask in 3.1.4.1.4 seems a little different from the DAL in the nature of formatting, but I don't understand how the 2 are different otherwise
| 328 | 13 | SpaceX | PWS | S | 8 | 3.1.4.1.5 LSS Notification of IDE Content Updates | Consider adding “Alternatively, the Contractor may meet this requirement by providing a subscription capability that automatically notifies a Government subscriber upon update.” | The Government is requesting IDE access, and automated updates are the most efficient way to provide updates/insight into Contractor data products. There are thousands of data products in a company’s system and it would be impossible to manually notify the Government of every change. | A | Government concurs and has updated the PWS as per the recommendation. | automatic updates are not explicitly disallowed, but changing the wording to make that clear may help with any confusion. | Y | Y |
| 123 | 14 | SpaceX | PWS | S | 8 | 3.1.4.1.7 LSS Remote Access to Data Environment | Remove “…and cloud-based communication…” | As written this is not scopeable or specific, and is unnecessarily opening Contractor data to security risks when remote access is more than sufficient. Does the Government intend to have applications log into a Contractor’s database? How would that work for multi-factor authentication? How would security be managed in a “cloud-based” system? | AAE | ||||
| 124 | 15 | SpaceX | PWS | C | 9 | 3.1.4.2.3 LSS Cybersecurity Maturity Model Certification (CMMC) Compliance | Remove section in its entirety. | CMMC is not authorized for contract inclusion and the DD 254 already specifies the appropriate protections for Covered Contractor Information Systems. | AAE | ||||
| 125 | 16 | SpaceX | PWS | S | 9 | 3.1.4.2.4 LSS Notification of Software Security and Malware Incidents | Remove requirement. | These requirements are already specified in the DFARS 252.204-7012 requirements. | PCO |
FED: Timelines are different. DFARS says 72 hours while PWS says 1 CD.
| 330 | 17 | SpaceX | PWS | S | 9 | 3.1.4.4.2 LSS Cybersecurity and MFA | Remove requirement. | Redundant to 3.1.4.2.3 requirements, which enforce applicable DFARS 252.20407012 requirements. | A | Government concurs and has updated the PWS as per the recommendation. | Have AAE and Titi to look at DFARS clause to verify prior to deletion. confirmed that section 3.1.4.2.3 and 3.1.4.4.2 say the same thing |
| 331 | 18 | SpaceX | PWS | S | 9 | 3.1.4.5 LSS Data Accession List | Consider removing requirement (CDRL A001) | Given the significant scope of IDE and Digital Engineering requirements, the DAL seems to be outdated and redundant to many other higher-quality products to be provided. | AAE | ||
| 126 | 19 | SpaceX | PWS | C | 9 | 3.1.4.6 LSS Supplier Data Access | Please remove section, or revise requirements to establish a threshold for suppliers that require data access. | This section is not achievable as written, unbounded by level of supplier. “Major sub-contractors” is extremely different from “all suppliers”. For providers who have major sub-contractors, these requirements would make sense, but it is not possible for all suppliers to have this level of data available. | AAE |
FED: Recommend specifying the level of supplier
| 127 | 20 | SpaceX | PWS | S | 10 | 3.1.5.1 LSS IDE On Demand Computer-Based Training | Add the following to the end of the paragraph: “The USG Team will follow all guidelines and rules for access to Contractor data. Failure to do so may result in loss of access.” | This is the same sentence used in later requirements for USG access to Contractor facilities; recommend adding here for access to Contractor data. | R | Government considered but does not concur. | Similar language used 3.1.13.2. This could potentially be used to restrict Gov't access to data as a result of a data spillage. | Y | Y | N/A |
| 128 | 21 | SpaceX | PWS | S | 12 | 3.1.9.1 LSS Reviews and Meetings | Add intended scope, audience, and agenda for the semi-annual Current Launch Schedule Review. | The LVC needs to understand the parameters and agenda of the CLSR in order to understand the support requirements. | AAMI | |||||
| 129 | 22 | SpaceX | PWS | S | 12 | 3.1.9.1 LSS Reviews and Meetings | Update launch manifest status teleconferences from “weekly” to “bi-weekly”. | The Government leads a bi-weekly integrated launch manifest teleconference. | R | Government non-concurs, the weekly meeting is necessary to address possible tempo of updates. | AAMI |
new provider or issues could change cadence. Weekly meeting is necessary to address possible tempo of updates.
NCL - Check with Falcon/Vulcan to confirm recurrence needed for this meeting 332 23 SpaceX PWS S 12 3.1.9.1 LSS Reviews and Meetings Remove the Contractor-led bi-monthly manifest review. This meeting is redundant to the current Government bi-weekly integrated launch manifest teleconference, the bi-monthly PMRs (covering manifest), and the monthly senior management review. Eliminating this redundant review would allow Government and Contractor teams to reduce cost and focus more on activities driving mission success. "The USG values the contractors participation in the bi-weekly government run manifest meetings and PMRs. We accept this change and will modify the requirement to contractor required to provide manifest insight bi-monthly in existing USG engagement." - Mission Manager Recco AAMI
MR: I agree that removing a redundant review is beneficial financially to both the LSP and USG. However need feedback to see if this review is being held currently,
| 334 | 25 | SpaceX | PWS | S | 13 | 3.1.10.3 LSS System Safety Non-Compliance Meetings | Recommend removing requirement entirely. | ||
| If the requirement is not removed, recommend making this LS instead of LSS, since the requirement specifies “for each mission”. | This is a significant additional burden for the same insight that is already provided at the PMRs, SSWGs, SSGs and recurring mission reviews. Because this topic is already covered in many other forums, recommend removing this entirely. We do not anticipate that a weekly meeting would provide additional insight beyond that already covered in other meetings. | AAE |
| 338 | 29 | SpaceX | PWS | S | 14 | 3.1.16.1 LSS Security | Change this section to read: “SCI work at contractor sites may be performed in a Sensitive Compartmented Information Facility (SCIF) accredited by the Air Force or other accrediting agency. SAP work at contractor sites must be performed in an Air Force dual-accredited SCIF and Special Access Program Facility (SAPF) or Other Government Agency (OGA) SCIF and SAPF that has either a Memorandum of Agreement (MOA), Memorandum of Understanding (MOU), Joint Use Agreement or Co-Use Agreement with USAF for this effort . In the instance work for this effort is going to be performed at an OGA SCIF and SAPF, the LVC will submit appropriate paperwork for a MOA, MOU, Joint Use or Co-Use agreement and the government will maintain the responsibility for timely approvals of the agreement in order for the LVC to properly support the mission specific security requirements. Performance of work for the OGA will take precedence in those facilities.” | The proposed revision clarifies that the intent of this statement is that the LVC will perform work in a facility that is accredited to the level of information being processed by the appropriate agency. | Capt Jensen/Capt Johnson proposed updated language that is being reviewed by Security Teams (Suspense: EOD 5 Apr) | ||
| 130 | 30 | SpaceX | PWS | S | 15 | 3.1.16.1 LSS Security | Replace NISPOM with 32 CFR Part 117. | NISPOM is no longer used and is now 32 CFR Part 117. This reference is incorrect. | Capt Jensen/Capt Johnson proposed updated language that is being reviewed by Security Teams (Suspense: EOD 5 Apr) | ||
| 131 | 31 | SpaceX | PWS | C | 15 | 3.1.16.2 LSS Classified Networks | Please update this language to clarify that instances of “meeting facility” and “each facility” are intended to mean places of performance where NSSL missions will be executed per the DD254 (i.e. engineering facilities, launch sites, etc.) | As written, “meeting facilities” is not clear and could vary in scope depending on interpretation. | R | Government has modifed the language as follows: |
"please add the modification here" Capt Jensen/Capt Johnson proposed updated language that is being reviewed by Security Teams (Suspense: EOD 5 Apr)
AAE to confirm 339 32 SpaceX PWS S 15 3.1.16.2 LSS Classified Networks Change “The contractor shall also provide access to other Intelligence Community (IC) virtual environments via an approved network” to “The contractor shall have access to at least one Intelligence Community (IC) virtual environments via an approved network (i.e. Contractor Wide Area Network [CWAN])” The proposed revision clarifies that the intent of this statement is that the LVC will have access to at least one SCI level network. Capt Jensen/Capt Johnson proposed updated language that is being reviewed by Security Teams (Suspense: EOD 5 Apr)
| 341 | 34 | SpaceX | PWS | S | 16 | 3.1.16.5 LSS Cleared Personnel | Please adjust the requirement to read “These personnel shall maintain active network accounts to access SCI and SAP information as applicable and driven by mission requirements.” | Not all critical management and technical leadership will require network access in support of every mission, and it is more supportive of program security and OPSEC requirements to limit the number of personnel with access. The required personnel will have access when they need it, but may not maintain active network access on an ongoing basis depending on their level of involvement in the mission at a given time. | Capt Jensen/Capt Johnson proposed updated language that is being reviewed by Security Teams (Suspense: EOD 5 Apr) | ||||
| 342 | 35 | SpaceX | PWS | S | 16 | 3.1.16.5 LSS Cleared Personnel | Please change “Personnel should be split among headquarters and launch site locations” to “Cleared personnel shall be available as needed to support mission performance at both headquarters and launch site locations.” | LVC will provide sufficient cleared support as needed at all locations although personnel will not be specifically split between headquarters and launch site locations. | Capt Jensen/Capt Johnson proposed updated language that is being reviewed by Security Teams (Suspense: EOD 5 Apr) | ||||
| 343 | 36 | SpaceX | PWS | S | 16 | 3.1.16.7 LSS OPSEC Program | Please change “…as determined by the relevant COR” to “…as determined by the relevant GMIM”. | Traditionally CORs are not cleared and do not have the program tickets. This information should come from the GMIM who is the person representing the owner of the classified requirements - the SV customer. | Capt Jensen/Capt Johnson proposed updated language that is being reviewed by Security Teams (Suspense: EOD 5 Apr) | ||||
| 8 | 37 | SpaceX | PWS | S | 16 | 3.1.16.7 LSS OPSEC Program | Please clarify “a product” and “all data”. | Words like “a product” and “all data” are unbounded and undefined. The LVC needs to understand the requirement in order to propose a deliverable, otherwise this may be redundant to the Program Protection Implementation Plan. Please clarify the intent of this requirement. | Capt Jensen/Capt Johnson proposed updated language that is being reviewed by Security Teams (Suspense: EOD 5 Apr) | ||||
| 132 | 38 | SpaceX | PWS | S | 18 | 3.1.21 LSS Hazardous Materials | Add language such as “per the instructions listed in CDRL A019. (CDRLs A019).” | MIL-STD 882-E (T) is a tailorable document per CDRL A019. | R | Government non-concurs....need to follow with the rationale as to rejection. | the document is tailorable, however, so are many other documents per CDRL A019. If we decide to make this addition, a similar additon may be needed throughout the PWS. Overall, not sure this addition does much more than point back to the CDRL that says they can tailor the requirement. | Y | N/A |
| 133 | 39 | SpaceX | PWS | S | 19 | 3.1.22.3 LSS Major Non-conformance Incident Reporting | Change “or more of the following (a) delay to the ship date of flight hardware for NSS missions,…” to “or more of the following for NSS missions (a) delay to the ship date of flight hardware…” | These are all applicable to NSS Missions. | R | Government considered but does not concur. Requirements still applicable to fleet surveillance. | A similar requirement is still applicable to Fleet Surveillance missions. Suggested change would nullify the requirement for non-NSS missions. |
| Language is also consistent with Phase 2 language. | Y | Y | N/A | ||||||||
| 344 | 40 | SpaceX | PWS | S | 20 | 3.1.24 LS Mission Milestone Reviews | Regarding the requirement “The Contractor shall support the USG Team’s incremental in-depth reviews of the mission-specific requirements…” This needs to be scoped/bounded. Please define how many in-depth reviews the Contractor will be required to support. | Contractor cannot scope estimated support for an unbounded number of meetings. | "The Contractor shall provide answers via data management tool or in existing technical meetings any questions the USG may have during the USG Team's review of mission-specific requirements, derived requirements, verification methods, and artifacts leading up to mission milestone review events." - Mission Manager Recco | ||
| More context: the USG doesn't hold in-depth reviews, we participate in the reuqirements development with the LSP and ask questions as we go. More questions and engagement may come up as we get closer to launch, but we don't hold a specific meeting we require the LSP attend. | AAMI |
MR: For a FFP contract, we need bounded events like meetings
| 345 | 41 | SpaceX | PWS | C | 20 | 3.1.24 LS Mission Milestone Reviews | Remove requirement “The Contractor shall provide the USG Team with continuous access, through launch, to all artifacts directly or indirectly pertaining to the mission or that serve as evidence of successful completion of mission milestone review success criteria.” | This is not value-added and is redundant with requirements for milestone success criteria as defined in CDRLs and elsewhere in this PWS. In addition, “directly or indirectly pertaining to the mission” is not bounded or achievable. | AAE | |
| 346 | 42 | SpaceX | PWS | C | 21 | 3.1.24 LS Mission Milestone Reviews | Remove requirement “The Contractor shall provide the USG Team members with access to a web-based collaborative modeling environment for hosting mission requirements and artifacts.” | The LVC is responsible for developing the mission requirements document and makes that document available in both draft and final forms to the Government and SV contractors via shared spaces. Collaboration occurs via a series of working groups, technical discussions, and iterative releases of the requirements documents, and is not on a web-based platform. In fact, configuration control would be lost in a “web-based collaborative modeling environment”. | "The USG is not suggesting building requirements documents via collaborative "google doc" type process. This requirement is stating a need for a digital environment to maintain the config controlled products, and other documentation that needs to be accessed by multiple customers in a mission. Products like JIRA that can track specific paragraphs, change coordination process and actions is useful for all teams to see status on various tasks and collaborate on. Requirements documents will continue to be config controlled." Mission Manager Recco | AAMI -We didn’t put this in there, sounds like a digital engineering add, we do agree that the requirements documents need to be closely config controlled by the LSP, so yeah we shouldn't have the ICD in a google doc, but doesn't mean a collaborative environemnt like JIRA isn't a good ides. |
Product Lines 347 43 SpaceX PWS C 21 3.1.24 LS Mission Milestone Reviews Remove requirement or clarify "The Contractor shall provide the USG Team member(s) with API access to the data required for each mission milestone review to support data retrieval automation." As written this does not make sense. AAMI - No clue what this means sounds like a digital engineering add, or a specific request from a product line Product Lines
| 348 | 44 | SpaceX | PWS | C | 21 | 3.1.24 LS Mission Milestone Reviews | Remove requirement "The Contractor shall ensure the model-based mission milestone review data is ingestible using an API into the Government Digital Ecosystem." | As written this does not make sense; this has no practical meaning to mission planning processes or systems. | AAMI - No clue what this means sounds like a digitla engineering add. I agree with SpaceX's comment, this needs to be definedProduct Lines |
| 349 | 45 | SpaceX | PWS | C | 21 | 3.1.24 LS Mission Milestone Reviews | Remove requirement "The Contractor shall provide the USG Team member(s) with automated, targeted email and app notifications for changes to the mission requirements and artifacts." | This does not make sense with the mission planning/integration process and disregards configuration control. | AAMI - This is a digital engineering add, what SpaceX currently does with JIRA notifications of new issues is sufficient. None of us are looking for more text message notifications.Product Lines |
| 350 | 46 | SpaceX | PWS | C | 21 | 3.1.24 LS Mission Milestone Reviews | Remove requirement "The Contractor shall link the completion of each mission milestone success criterion to the dependent requirements for the next mission milestone review." | Mission milestone reviews are not linked in this way. This does not make sense with the mission integration process. | AAMI - We need to talk more about all these requirements and what we really need in terms of digital engineering. SpaceX is making valid points. |
Product Lines
| 351 | 47 | SpaceX | PWS | C | 21 | 3.1.24 LS Mission Milestone Reviews | Remove requirement "The Contractor shall update the web-based modeling environment and dashboard continuously through completion of the launch." | This does not make sense, given all prior comments on Section 3.1.24. | AAMI - We need to talk more about all these requirements and what we really need in terms of digital engineering. SpaceX is making valid points. Product Lines | |
| 134 | 48 | SpaceX | PWS | C | 21 | 3.1.24 LS Mission Milestone Reviews | Remove requirement "The Contractor shall develop presentation content for each mission milestone review by creating views within the modeling environment that provide evidence of satisfaction of the milestone review criteria." | This does not make sense and is not how mission milestone reviews are executed. | AAMI - We need to talk more about all these requirements and what we really need in terms of digital engineering. SpaceX is making valid points. Product Lines | |
| 135 | 49 | SpaceX | PWS | C | 21 | 3.1.24 LS Mission Milestone Reviews | Remove requirement "The Contractor shall cooperate with the USG Team to develop an implementation plan by L-20 months to implement the requirements within this section by L-4 months." | There are current established processes that accomplish coordination of mission requirements, verification artifacts, mission milestone reviews, and delivery of all required data. If this section is only directed at providers who may not have established processes, please add a note that the Contractor may meet the intent of these requirements via existing systems. | Just because a provider currently has a process, doesn't mean our new contract won't continue to levy the requirement of that process in future contracts | AAMI |
Product Lines
| 136 | 50 | SpaceX | PWS | S | 22 | 3.2.2.1 LSS Provide API | Please clarify or remove this requirement. | This is redundant to the IDE section of the PWS and is overly vague given the IDE solution is not yet defined. | AAE | |||
| 137 | 51 | SpaceX | PWS | S | 23 | 3.2.4.2 LS/LSS Launch System Configuration Reporting | Please clarify or remove this requirement, as this is likely redundant to the IDE requirements. | This is overly vague and not achievable as written. It is unclear what “list data” refers to. Similarly, please clarify “automated data ingestion” - ingestion into what, and automated how? | AAE | |||
| 138 | 52 | SpaceX | PWS | S | 23 | 3.2.4.2.1 LSS As Designed Configuration List | Change LSS to LS. If the intent is that this is a fleet deliverable and not a mission deliverable, please update the CDRL and Payment Plan accordingly. | ADCL is specific to the mission as described in the CDRL requirements: “Submittal of ADCL will be provided to the Government for each Launch task order, NLT 60 calendar days (CD) after issue of task order.” | AAE | |||
| 139 | 53 | SpaceX | PWS | S | 24 | 3.2.4.3.1 LS Change Notification | Update to “LS/LSS” | Many of these tasks are conducted fleet-wide for NSSL (for example, “provide… for the first affected NSS mission”) and thus are LSS tasks, not LS tasks. | Aerospace, AAE, AAMP | |||
| 352 | 54 | SpaceX | PWS | S | 24 | 3.2.4.3.1 LS Change Notification | Add “or 60 CDs after task order for missions with a Government accelerated schedule of 12 months or less” | Current language contradicts the CDRL language: “Submit initial Technical Rational NLT L-15 months. No Government approval required. With a Government accelerated schedule of 12 months or less, provide list of changes from as proposed launch vehicle configuration no later than 60 CDs after task order for Government Approval.” We recommend editing for consistency. | AAE | |||
| 353 | 55 | SpaceX | PWS | S | 24 | 3.2.4.3.1 LS Change Notification | Add reference to CDRL A036. | CDRL A036 covers both the Initial technical rationale for Class 1A changes (covered in this paragraph), and the Final technical (covered in the next paragraph), hence CDRL A036 should be referenced here as well. | AAE | |||
| 354 | 56 | SpaceX | PWS | S | 25 | 3.2.4.4.3 LS Class 1A and 1B Change Implementation | Recommend revising “NLT L-6 mo for the first affected NSS mission” to “NLT start of applicable Government Hardware Review for the first affected NSS mission.” | This requirement contradicts other PWS requirements and should be reviewed by the Government or removed as duplicative/encompassed by other requirements. As currently written, for any changes to hardware, acceptance testing must be complete by L-6 mo unless approved for a later date. However, for unchanged hardware assigned to a given mission, there is no requirement for all flight hardware to be fully built and tested by L-6 mo, but instead driven by Pedigree Review requirements for completion. Thus, this requirement could artificially create earlier need to build hardware or could create excessive work for the Government to review each individual change for an exception to the L-6 mo date. We recommend revising to be similar to paragraph 3.2.4.3.1, where the final technical rationale deadline is tied to the Government Hardware Review. | Aerospace, AAE | |||
| 355 | 57 | SpaceX | PWS | S | 26 | 3.2.6.2 LSS Non-NSS Launch System Parameters | Not all of 3.2.61 should be required for non-NSS missions—USG should only need limits/criteria/etc., not “data, rationale, source, and justification”, especially compiled for every non-NSS mission. Also recommend updating delivery to L-1 CD prior to Static Fire or Launch. | It is not manageable to continually assemble this for every mission, and it is only needed by the time USG is on console for launch. | Aerospace, AAE | |||
| 356 | 58 | SpaceX | PWS | S | 26 | 3.2.7 LSS Performance Capabilities Guide | Please clarify what the Government is looking for regarding “web viewable” and “machine readable” and “launch system environment”. | As currently written, providers will not understand the scope of what is required per the Performance Capability Guide deliverable. For example, providers need to maintain a guide within a system for which we do not have interface specifications at this time. | AAE DE | |||
| 140 | 59 | SpaceX | PWS | S | 26 | 3.2.9 LSS Quality Management | Please update LE-T-014 to LE-T-AS9100D (2019). | Per the list of compliance documents in the PWS, it appears LE-T-014 has been renamed as LE-T-AS9100D (2019). | M | RB - The Government will update document references, as necessary, to be in alignment with Bidder's Library | Y | |
| 141 | 60 | SpaceX | PWS | S | 32 | 3.3 LS/LSS Launch Vehicle Production | Recommend removing "the performance and accuracy requirements stated in the SPRD Rev B and SIS Rev C " | The mission ICD and MRA will always define the performance and accuracy requirements for a given mission. The SPRD and SIS only have generic reference orbit requirements. In addition, Phase 3 would be applicable to SPRD Rev C and SIS Rev D. | R | Government non-concurs, however, will ensure the most recent approved SPRD and SIS versions are referenced in the final RFP. | RB - The end of the paragraph qualifies, by adding "and further defined in the MRA/IRD and the Mission ICD", making the recommended change unneccessary | Y |
| 142 | 61 | SpaceX | PWS | S | 33 | 3.3.1.4 LSS USG Team Office Accommodations | Please specify that the NTE 16 is total between all sites, or specify a certain number per site. Note that PWS Section 3.5.2.4 already specifies that office accommodations for two personnel are required per launch site. | Regular accommodations for 16-person USG teams at every site is excessive | AAE, Product Lines | |||
| 357 | 62 | SpaceX | PWS | C | 34 | 3.3.1.5 LSS Technical Baseline (LV Family) | Recommend removing requirement, per corresponding CDRL A048 feedback. | The requirements of this CDRL are not actionable, achievable, or realistic. It is unclear what the Government is looking for in this CDRL that is not already delivered as part of the LV baseline, technical change reporting, and IDE access. | AAE DE |
358 64 SpaceX PWS S 35 3.3.2.4 LSS Payload Environment Instrumentation Change “Vibration” to “acceleration” Acceleration data is used to perform the vibration assessment. Acceleration is the actual data being captured. A Government concurs, language has been updated as follows:
| "e.g., temperature, pressure, acoustic sound pressure level, shock, and acceleration" | Y | |||||||||
| 359 | 65 | SpaceX | PWS | C | 35 | 3.3.2.5 LS Mission-Specific Technical Baseline Data | Recommend removing requirement, per corresponding CDRL A048 feedback. | The requirements of this CDRL are not actionable, achievable, or realistic. It is unclear what the Government is looking for in this CDRL that is not already delivered as part of the LV baseline, technical change reporting, and IDE access. | AAE DE | |
| 360 | 66 | SpaceX | PWS | S | 35 | 3.4.1 MI Mission Integration Data | At minimum, please remove changes to “manufacturing”, “testing”, “operational”, and “process”. | Much of this is redundant to the Change Reporting section of the PWS and shouldn’t be part of the mission assurance CLIN, but would be part of LSS. | RB - Changed from "mission integration data supporting this Contract". |
NEED HELP from AAE, Aerospace Not AAMI 144 67 SpaceX PWS S 35 3.4.1 MI Mission Integration Data Please remove “Note Some CDRLs may be able to be maintained in the Government's database.” As written the scope of documentation that may live on the Government's database is unclear; therefore, it is not clear what the Contractor needs to assess or how this is related to the requirement. RB - Added scope in Phase 3 NEED HELP from AAMI, AAE, Aerospace 361 68 SpaceX PWS S 37 3.4.2.2 MI Quarterly Management Working Group Reviews Recommend removal of Quarterly Management Working Groups. Management Working Groups are held on a mission-specific basis and would include the SV contractors, which would render the meeting inappropriate to cover summaries of other missions. In addition, it is under the MI CLIN which is only for each individual mission. If the intent is for a MWG with the requirements as written, it would be completely redundant with the bi-monthly PMRs. Agree, waste of a meeting - Mission Manager Input RB - This was also a Phase 2 PWS requirement.
NEED HELP from AAMI 362 69 SpaceX PWS S 39 3.4.5 MI Mission Design and Analyses Remove requirements to comply with the IRD. The IRD is used to develop the ICD, which then supersedes the IRD. Analyses verification will only be to ICD requirements. Further, IRDs are considered reference documents. Recco change language to "with initial inputs from the IRD, and final inputs from the signed mission ICD in order to verify those ICD requirements are met." SpaceX makes a valid point, but we still need to point them to start analyses with inputs from IRD. - Mission Manager Input RB - I think it is understood that until a signed ICD exists, it is necessary to comply with the IRD(s).
NEED HELP from AAMI 145 70 SpaceX PWS S 43 3.4.10 MI Ground Hardware Interface Checks Please remove all uses of “and/or” and define the number of interface checks required for an IPS. As written this is unbounded, which is not appropriate for an FFP contract. R Government non-concurs; a Firm-Fixed Price contract does require a defined number. MR
AAK
AAE
149 73 SpaceX PWS C 44 3.4.12 MI Payload Processing and Encapsulation For clarity, please add a statement that says the Government will provide the Payload Processing Facility services as government furnished services. The language in the section is vague as to whether the Government or the Contractor is providing the PPF. RB - The Government recognizes that providing the PPF is usually an SV function.
RB - Need to make response consistent with Proprietary comments response. The LSP providing a PPF should be a mission unique item.
AAMI -
We need to talk about this I don't think we want to box ourselves into a corner by stating the USG will always provide it, especially if we make it a MU NEED HELP from AAMI 150 74 SpaceX PWS S 44 3.4.12.2.2 MI Facility Requirements Document There is contradictory language in this section. Item 1 “The Contractor shall provide a draft FRD to the applicable USG Team member(s) by ATP+1 month and a final FRD by L-18 months.” Versus Item 2 “The Contractor shall provide a draft FRD to the applicable USG Team member(s) by L-18 months and a final FRD by L-12 months.” Please rectify this discrepancy. We believe it should be draft by L-18M and final by L-12M. Edits are needed to correct the timeline discrepancy. RB - Need to make response consistent with Proprietary comments response.
NEED HELP from AAMI -Agree with SpaceX comment, we should not be tying deliveries to ATP since the best data is freshest when tied to ILC. Initial requirements at L-24, final at L-18 151 75 SpaceX PWS S 44 3.4.12.2.2 MI Facility Requirements Document Remove “The FRD shall also include all communications requirements needed by the Contractor in order to operate in the PEF. The USG team will review and assess the requirements identified in the FRD during the integration process and provide feedback on acceptability leading to formal acceptance at the reviews in Table 3-1.” This is redundant to the preceding paragraph. RB - Need to make response consistent with Proprietary comments response.
NEED HELP from AAMI - Agree with SpaceX this is redundant, we could just mod the first paragraph to say "for the PPF and PEF" 152 76 SpaceX PWS C 45 3.4.12.2.2 MI Facility Requirements Document Please confirm if the Government’s intent is to have the Payload Encapsulation Facility be a mission-unique requirement, or if it is a baseline PWS requirement. Section 3.4.12.2.2. states “The Contractor shall provide a PEF for fairing encapsulation per the requirements of the ICD(s) and the established CONOPs”, but Section 3.8.7.1.2 defines the Payload Encapsulation Facility as a Mission-Unique item. The inclusion of this requirement as a Mission Unique item makes it unclear if the LVC should consider provision of the PWS a MU or baseline PWS requirement. RB - Need to make response consistent with Proprietary comments response.
NEED HELP from AAMI - Yeah we need to have a meeting to nail this down - AAMI
| 153 | 77 | SpaceX | PWS | S | 45 | 3.4.13 MI Launch Operations Validation Activities | Remove “The Contractor shall provide 3D models to the PEF operators. Models to include the LV fairing; P/L Adaptor and associated GSE for processing in the PEF.” | If the LVC is required to procure the PEF, it will be a commercial and direct contract and the USG cannot levy requirements from the LVC to the PEF operator. | AAE DE |
| 154 | 78 | SpaceX | PWS | S | 45 | 3.4.1MI Reflight Mission Integration | Recommend adding a similar, parallel paragraph for mission acceleration. | The recommended addition would provide guidance for accelerated missions WRT reflights. | RB - As acceleration may require tailoring of mission integration, this is a reasonable suggestion. |
NEED HELP from AAMI
| 155 | 79 | SpaceX | PWS | S | 46 | 3.5.1.1 LS Discrete Personnel Access | Recommend changing “…discussing emergent issues and task specific inquiries.” to “…discussing urgent/critical task-specific inquiries” | Just because something is “emergent”, doesn’t mean it’s “critical” to be addressed immediately on the spot. There can be “emerging”, non-critical topics that can be addressed in subsequent TIMs (as called out in the next sentence). | |
| Note, the proposed language also corrects minor typos (task-specific vs. task specific, and inquires vs. inquiries). | RB - Need to make response consistent with Proprietary comments response. |
NEED HELP from SLDs, AAMI 156 80 SpaceX PWS S 46 3.5.1.2 LSS Non-Discrete Personnel Access Replace “site director” with “Launch Technical Lead” in the following sentence “This will include coordination with the contractor site director for personnel performing work to minimize interference to the maximum extent possible” The site director is not always the most appropriate person for coordination. RB - Needs to apply equally to all LSPs.
NEED HELP from SLDs 363 81 SpaceX PWS S 46 3.5.2.1 LSS Work Authorizing Documents Change language from “The Contractor shall produce procedures IAW SSC-S-016 paragraph 4.8.2, per the instructions in CDRL A019.” to “…shall produce procedures used for NSS missions under this contract IAW….” Proposed language clarifies that procedures for NSS hardware need to comply with the LE tailoring of SMC-S-016, but not that ALL contractor procedures at the launch site (such as for non-NSS missions) need to comply with S-016. RB - Phase 1A-6 did not reference a CDRL. This was added for Phase 2. Three thoughts - CDRL A019 is for tailoring compliance documents, so we could interpret that the inference is a tailored version of SSC-S-016. Or change the reference to CDRL A032 (Work Authorizing Documents). Or delete the CDRL reference entirely. BTW - there is no SSC-S-016 listed as a compliance document. It seems to have been replaced by LE-S-016 and we should update this section reference accordingly.
NEED HELP from AAE SLDs
157 83 SpaceX PWS S 47 3.5.2.3 LSS Physical Access and Non-Escort Privileges Please add clarification language “future NSS missions under this Phase 3 contract”. This needs to be bounded to future missions under this contract, versus NSS missions that may be supported on other contracts (Lane 1 or others). RB - Is this a reference that there may be missions added to Phase 3 Lane 2 that are not currently identified in the Ordering Clause?
NEED HELP from AAMP, AAK
| 158 | 84 | SpaceX | PWS | S | 47 | 3.5.2.5 LSS Pre-Coordination of Launch Site Processing Activities | Change to “hardware readiness for launch site processing operations”. | Not all hardware will necessarily arrive at launch site at once. Some hardware, such as reused hardware, may arrive at the launch site very early relative to other hardware, and thus shouldn’t pace when all WADs are required to be provided for the entire mission. Proposed text resolves this concern. | A | Government concurs, the PWS has been updated as per the recoommendation. | RB - I agree with the comment here that launch hardware arrival may be well prior to the need. | Y |
| 159 | 85 | SpaceX | PWS | S | 48 | 3.5.2.6 LSS Daily Schedule | Recommend rewriting this requirement as follows “The Contractor shall maintain and provide the applicable USG Team member(s) a daily schedule that forecasts relevant operations NLT 7CD in advance and provides updates to operations less than 7 days out. Daily status includes work directed by WADs and non-conformance process in addition to major maintenance activities associated with the launch site and LV Schedules shall be linear, legible use common scheduling techniques, and provide key milestones and their relationships which drive critical path such that the government can plan resources to execute Mission Assurance and fleet surveillance. Contractor format acceptable.” | Revised language clarifies the requirement to provide task relationships is specifically for key milestones which drive critical path. It is not feasible or valuable to show all relationships for each individual operation on a linear format schedule. | SLDs | |||
| 160 | 86 | SpaceX | PWS | S | 48 | 3.5.2.8 LSS Launch Site Status Meetings | Recommend adding “For meetings with formal pre-prepared presentations, the Contractor shall make available all presentation material (current drafts)…” | Many of these meetings will likely be recurring tag-ups (possibly daily or multiple times per week), and it may not be feasible to provide presentation material (even draft material) 2 days prior – as the purpose of these meetings would be to provide the latest status. Draft materials two days prior to a daily meeting is not an achievable requirement. | SLDs | |||
| 161 | 87 | SpaceX | PWS | S | 49 | 3.5.2.10 LSS Operational Surveillance Requirements | Please remove “API-format” from the sentence “For all missions, the Contractor shall provide both full-rate native format and government-specified rate API-format launch vehicle and GSE telemetry data, operational voice, launch site video, countdown timing, and processed telemetry displays as defined below.” | “API” does not make sense in this context, and the motivation for including the term in this requirement is unclear. | SLDs, AAE DE | |||
| 365 | 88 | SpaceX | PWS | S | 49 | 3.5.2.10.2 LSS Operational Voice Requirements | Please add language to clarify that talk access on Contractor operational voice nets is limited to NSS missions only. | USG will only have talk access for NSSL missions. | RB - Seems like a reasonable clarification. |
NEED HELP from SLDs
| 366 | 89 | SpaceX | PWS | S | 50 | 3.5.2.10.2.2 LSS Mobile Devices | Edit “and access to all voice nets” to “and access to all applicable voice nets”. | The requirement as written states that the USG should have the “same capability” as the Contractor, but can be interpreted to mean that Mobile Devices must include access to all voice nets, even if the Contractor just uses Mobile Devices for some nets. As mobile devices are an optional capability (“if the contractor utilizes…”), the requirement should be that the USG has the same capability as the Contractor, not more capability. | SLDs |
| 162 | 90 | SpaceX | PWS | S | 53 | 3.5.2.10.8 LSS NOPS Requirements | Remove “…in accordance with the Mission Support Requirements Document (MSRD) or other coordinated documents.” | The MSRD is mission-specific and an agreement between NOPS and OSLMM. LVC is not a part of that agreement, so it is not appropriate for inclusion in PWS requirements. | OSL |
| 163 | 91 | SpaceX | PWS | S | 54 | 3.5.2.10.9.3 LSS Contractor Operational Voice Nets | Please remove this requirement. | This requirement is redundant to 3.5.2.10.2. | SLDs |
| 367 | 92 | SpaceX | PWS | S | 55 | 3.5.3.3 LS Facilitation of USG Readiness Review Participation | Add “or as soon as possible if scheduled less than 7 CD prior to review” after “For integrated operations, the Contractor shall invite the applicable USG Team member(s) NLT 7 CDs in advance of each readiness review.” | This is consistent with other PWS language for providing invitations to reviews. | RB - seems reasonable |
NEED HELP from SLDs
| 368 | 93 | SpaceX | PWS | S | 55 | 3.5.3.4.3 LS Environmental Consideration Monitoring | Recommend removing requirement. If this requirement is retained, please replace the word “considerations” with “conditions”, and replace the word “vibration control” with “acceleration”. | This requirement is redundant to separate sections of the PWS. If the requirement is retained, the proposed language updates are more technically correct. | SLDs | ||
| 369 | 94 | SpaceX | PWS | S | 56 | 3.5.3.10 LS Contingency Operations | Update “If directed by the COR,….” to “If directed by the MD,…” | The MD is responsible for the mission and launch contingency operations, not the Contracting Officer Representative. | SLDs | ||
| 370 | 95 | SpaceX | PWS | S | 56 | 3.5.3.13 LS Interface Testing | Please remove this requirement. | This language is redundant to requirement 3.4.9. | SLDs | ||
| 371 | 96 | SpaceX | PWS | S | 57 | 3.5.3.14.1.4 LS Communications Equipment Rack Room Configuration | Please provide a discrete number of consoles requiring LIDS computers in the Contractor’s launch control facility. Additionally, please add “or wireless network access” to the Ethernet requirement. | The Government needs to define support scope and a specific number of consoles for LIDS computers, especially if Ethernet access is required at each one. | M | Government has modifed the language as follows: |
"please add the modification here" MR: Govt accepts with modification
AAK, AAE
MR: Specific numbers of HW must be defined in a FFP contract, for bidding
| 372 | 97 | SpaceX | PWS | S | 59 | 3.5.3.14.6 LS Winds Team Voice and Data Communication | change from “wind balloon run” to “wind profile”. | Proposed language is generic to all systems used by providers. | A | Government concurs, the PWS has been updated as per the recoommendation. | Y | |
| 373 | 98 | SpaceX | PWS | S | 60 | 3.5.3.14.10 LS 3D Computer Simulation Support | Please add language such as “…or live video/data of the launch vehicle”. | This requirement is unnecessary if live video/data from the LV is available. | SLDs, |
AAMI - We don't need this, seems excessive
| 9 | 99 | SpaceX | PWS | S | 61 | 3.5.4.2 LSS Corrective Action Status | Please add at the beginning of the requirement “For NSS missions…” | Clarifies requirement scope. | SLDs |
| 10 | 100 | SpaceX | PWS | S | 61 | 3.5.4.2 LSS Corrective Action Status | “…after the FRR and NLT 72 hours prior to the LRR” should be changed to “…after the Post-Flight Data review.” | The FRR and LRR take place prior to launch. All known “repairs” for a launch site won’t be known until after launch. Thus, this should be connected to the PFDR. | RB - Is the intent of this Section for corrective actions/repairs identified before launch? If so, I don't think changes are required. |
NEED HELP from SLDs
| 11 | 101 | SpaceX | PWS | S | 61 | 3.5.4.2 LSS Corrective Action Status | Remove "If maintenance software is proprietary/license controlled, Contractor shall obtain license for USG Team members to be able to access data.” | Does not appear to belong in this paragraph; likely a mistake. | A | Government concurs, the PWS has been updated as per the recoommendation. | AAE | ||
| MR: after reviewing the scope of para 3.5.4.2, the last sentence should be removed | Y |
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it. Updated .