The file's text, extracted by GovTribe without its formatting.
Enclosure No. 4 Evaluation Criteria April 29, 2026
I. Introduction
This document defines the evaluation criteria that will be applied to the Offeror’s proposal for the ALCF HPSS Disk Cache acquisition. The criteria address conformance to the Statement of Work (SOW), "ALCF Archive Disk Storage Cache", dated April 29, 2026 and all other requirements of the RFP.
II. Evaluation Process and Relative Importance of Evaluation Factors
Proposals will be evaluated in three (3) separate parts:
· Part I – Technical Proposal
· Part II – Business/Management Proposal
· Part III – Price Proposal
Argonne intends to award a contract on a best-value basis. Best value is expected to result from selection of the proposal that offers the greatest overall value to the Laboratory, considering technical merit, contractor responsibility, and price.
As an initial step, the Laboratory will evaluate the Business/Management Proposal to conduct a Contractor Responsibility Determination. This review will consist of a general business assessment and will result in a pass/fail determination. The Business/Management Proposal will be evaluated solely for this purpose.
Only those proposals receiving a passing Contractor Responsibility Determination will be eligible for further evaluation. Proposals determined to be responsible will then be evaluated in the following areas:
· Technical Criteria
· Price Criteria
The Technical Proposal is more important than the Price Proposal. Although price may not be the controlling factor in the award decision, it will be a significant consideration in the Laboratory’s source selection process.
III. Technical Criteria
Technical Proposals will be evaluated and assigned one overall adjectival rating of:
· Outstanding – Proposal indicates an exceptional approach and understanding of all requirements. The proposal contains multiple strengths, few to no weaknesses, and no deficiencies.
· Good – Proposal indicates a thorough approach and understanding of the requirements. The proposal has at least one strength, few weaknesses, and no deficiencies.
· Acceptable – Proposal meets the requirements and indicates an adequate approach and understanding of the requirements. There may be no strengths, or any notable strengths are balanced by weaknesses. Proposal has no deficiencies.
· Marginal – Proposal has demonstrated a less than adequate approach and understanding that does not clearly meet requirements. Weaknesses may be major and outweigh strengths. Proposal is barely awardable and may require extra Laboratory involvement to achieve success.
· Unacceptable – Proposal does not meet requirements, contains one or more deficiencies, and is unawardable.
Failure to meet one or more minimum mandatory requirements set forth in the SOW may result in a rating of “Unacceptable”, rendering the proposal ineligible for award.
In addition to the overall adjectival rating, the Laboratory will assess the overall proposal risk as follows:
· Low Risk – Any proposal weaknesses have little potential to cause disruption of schedule, increase in cost, or degradation of performance. Normal Contractor effort and normal Government monitoring will probably minimize any difficulties. The Proposal demonstrates a clear understanding of scope and successful contract performance is likely.
· Moderate Risk – Proposal has weaknesses or insufficiences that may potentially cause some disruption of schedule, increase in cost, or degradation of performance. However, special Contractor emphasis and close Government monitoring should minimize difficulties, and successful contract performance can likely still be achieved.
· High Risk – Proposal has weaknesses that have the potential to cause serious disruption of schedule, increase in cost, or degradation of performance even with special Contractor emphasis and close Government monitoring.
Technical Proposals will be evaluated in the following areas, listed in descending order of importance:
1. Overall Technical Requirements
· Including, but not limited to, hardware, software, and licensing.
2. Maintenance and Support
3. Installation Services
The detailed technical criteria are set forth in Appendix 1 – Technical Criteria below.
IV. Business/Management Criteria
The Business/Management Proposal will not receive an adjectival rating. It will be evaluated on a pass/fail basis to determine whether the Offeror is a responsible contractor. In making this determination, the Laboratory may consider factors including, but not limited to, the Offeror’s general business integrity, financial and organizational capability, past performance record, ability to comply with required delivery or performance schedules, and any other information relevant to the Offeror’s responsibility. Preference will be given to Offerors that demonstrate minimal financial risk and a strong ability to successfully perform under the agreement. The Offeror shall provide sufficient information, as detailed in Enclosure No. 1, Part II, to enable the Laboratory to make this determination.
V. Price Criteria
The Price Proposal will not receive an adjectival rating. It will be evaluated to determine the most advantageous probable cost to the Laboratory. In evaluating price, the Laboratory may consider the total evaluated price, price realism, price reasonableness, and any other factors relevant to determining the probable cost of successful performance. Total evaluated price will be considered in relation to the relative merits of the technical proposals to determine whether the advantages of a higher-rated technical proposal warrant payment of any associated price premium. In conducting this evaluation, the Laboratory may consider information obtained from Government and/or commercially available sources.
VI. Basis for Award
The Laboratory intends to award a contract resulting from this solicitation to the responsible Offeror whose proposal is compliant with and responsive to this RFP, demonstrates conformance with the Statement of Work and all other RFP requirements, and offers pricing determined to be fair and reasonable. Award will be made to the responsible Offeror whose proposal represents the best value to Argonne, as determined in accordance with the evaluation criteria set forth in this solicitation.
RFP No. 6-B143-P-00143-00
Appendix 1 – Technical Criteria
| 4.1 |
| Overall Storage System requirements acknowledged and addressed |
| Required |
| 4.1 |
| Storage system is a standalone appliance primarily accessible by Linux data mover hosts with direct block storage access over standard transport |
| Required |
| 4.1 |
| Each data mover host has access to all block devices in the storage system |
| Required |
| 4.1 |
| Storage system presents raw unformatted block devices to Linux hosts in an HPSS-compatible raw device presentation model |
| Required |
| 4.1 |
| Only block devices are used |
| Required |
| 4.1 |
| Offeror describes maximum supported block device count and relevant memory-related scaling constraints |
| Required |
| 4.1.1 |
| Solution includes internal virtual machines for storage access or provides up to 16 external Intel Xeon or AMD based Linux data mover servers over standard transport |
| Desired |
| 4.1.1 |
| If internal virtual machines are used Offeror demonstrates sufficient CPU memory device bandwidth and network bandwidth for data mover workload |
| Desired |
| 4.1.1 |
| Data mover hosts whether virtual or physical support provisioning with a current RHEL distribution |
| Desired |
| 4.1.1 |
| Data mover node configuration meets node requirements including 1RU chassis redundant 208V PSUs single socket 16 core 3.0 GHz CPU 256 GB DDR5 RDIMM RAM sufficient PCIe and adapters for redundant 400GbE connectivity and two 300 GB RAID1 SSDs |
| Desired |
| 4.1.1 |
| Intel Xeon or AMD CPU preference is met for data mover nodes |
| Desired |
| 4.1.1 |
| Offeror describes mover memory sizing relative to device count concurrent requests and internal buffering requirements |
| Desired |
| 4.2 |
| Storage system provides minimum of 10 PiB usable capacity excluding redundancy overhead and hot spare capacity |
| Required |
| 4.3 |
| If SSD based storage system supports minimum aggregate throughput of 140 GB per second minimum 5 million IOPS and approximately 500 MB per second per block device |
| Desired |
| 4.3 |
| If HDD based storage system supports minimum aggregate throughput of 90 GB per second minimum 3.2 million IOPS and approximately 200 MB per second per block device |
| Desired |
| 4.3 |
| Storage system supports minimum of 16 parallel data streams to achieve 90 percent of line rate on a 400GbE link |
| Desired |
| 4.4 |
| Offeror describes monitoring tools provided with the storage system and identifies any data collection processes that can or will run on the data mover hosts |
| Required |
| 4.5.1 |
| Offeror describes the durability model of the storage system |
| Required |
| 4.5.2 |
| Storage system is serviceable with field-replaceable components and Offeror describes FRUs including hot warm or cold swap characteristics operational impact integrity impact and any maintenance conditions affecting resiliency or data integrity |
| Required |
| 4.5.3 |
| Storage system is highly reliable and available and tolerant of electrical and mechanical or cooling events |
| Required |
| 4.5.3 |
| Storage system includes hardware and or software redundancy sufficient to recover data under double failure of the same component type and automates rebuild initiation for storage media failures |
| Required |
| 4.5.3 |
| Offeror fully describes storage system failure modes including caches single points of failure electrical and cooling fault impacts redundancy schemes recovery limitations and additional reliability features |
| Required |
| 4.5.4 |
| Storage system supports hot swapping of FRUs with minimal impact to operating state for power supplies fans controllers storage media cabling host adapters and drive enclosure bays or Offeror identifies and describes exceptions |
| Required |
| 4.5.5 |
| Storage system demonstrates scheduled availability of not less than 99.5 percent including accessibility for existing data and ability to store new data |
| Desired |
| 4.5.6 |
| Storage system includes built-in mechanisms to protect against silent data corruption |
| Required |
| 4.5.7 |
| Commonly replaced FRUs have externally visible fault lights or displays indicating failure and location |
| Required |
| 4.6.1 |
| Solution integrates into existing ALCF Ethernet-based management and monitoring networks |
| Required |
| 4.6.1 |
| All individually managed units devices or components provide a 1000BASE-T compatible management Ethernet port a software interface for configuring a single IPv4 address through which all necessary management functions are reachable and an out-of-band interface sufficient to establish management network communication parameters without additional connectivity |
| Required |
| 4.6.1 |
| Offeror explicitly indicates compliance with management network requirements |
| Required |
| 4.7.1 |
| Solution minimizes total number of electrical connections and for 415Vac supports site-provided 3P+E or 3P+N+E service with IEC60309 plugs preferred or describes alternate connection types |
| Desired |
| 4.7.2 |
| All racks are fed from two separate power sources can run unencumbered on one source and distribute load evenly across both sources except permissible low-power imbalance |
| Required |
| 4.7.3 |
| Offeror describes tolerance to power quality events including voltage surge sag and duration and compatibility of 208 to 240Vac components with dual-fed UPS ride-through configurations |
| Required |
| 4.7.4 |
| Proposed solution power factor is at least 0.95 and harmonic current levels meet IEEE STD 519-2014 Table 2 recommendations for Isc divided by Il less than 20 |
| Required |
| 4.7.5 |
| Offeror specifies cooling requirements including heat load relation CFM temperature humidity rack cooling envelopes environmental thresholds alarm set points allowable excursions and variation across idle typical and maximum operating conditions |
| Required |
| 5 |
| Maintenance and Support requirements acknowledged and addressed |
| Required |
| 5 |
| Offeror includes 9x5 Next Business Day support problem escalation procedures on-site support services for significant hardware or software problems and an on-site parts cache for laboratory personnel use |
| Required |
| 5 |
| Offeror proposes optional 12x7 support model |
| Required |
| 5.1 |
| Offeror provides hardware and software maintenance for 5 years with optional 1 year extension beginning upon system acceptance |
| Required |
| 5.2.1 |
| 9x5 NBD support provides 9 hours per day 5 days per week support window one hour response time second-level hardware diagnosis by Offeror during support window on-site repair by Offeror if Argonne cannot repair from local parts cache and use of 9x5 NBD contracts for redundant or non-critical components |
| Required |
| 5.2.2 |
| Optional 12x7 support provides 12 hours per day 7 days per week support window one hour response time second-level hardware diagnosis by Offeror during support window on-site repair by Offeror if Argonne cannot repair from local parts cache and use of 9x5 NBD contracts for redundant or non-critical components |
| Desired |
| 5.3 |
| Offeror provides software support and maintenance for maintenance period including 24x7 support for critical software failures 9x5 NBD for non-critical failures problem reporting tracking and regular software updates |
| Required |
| 5.4 |
| Offeror provides on-site parts cache of FRUs controllers and drives sized by MTBF and governed by SLA sufficient to sustain Argonne repair actions from local cache without waiting for regional depot delivery |
| Required |
| 5.4 |
| Offeror resupplies and refreshes on-site parts cache during hardware maintenance period and backs on-site spares inventory with a regional supply depot |
| Required |
| 5.4 |
| System components are fully tested and burned in prior to delivery to minimize dead-on-arrival components |
| Required |
| 5.4 |
| Offeror agrees to reassess and adjust on-site parts cache if SLA is not met and cause is not attributable to Argonne |
| Required |
| 5.4 |
| Offeror defines self-maintenance period responsibilities including FRU replacement RMA failed FRU handling and ownership transitions for installed and returned FRUs |
| Required |
| 5.5 |
| Offeror provides detailed description of problem escalation if hardware or software issues are not adequately addressed |
| Required |
| 6 |
| Offeror confirms understanding of post-award management plan deliverables and compliance obligations |
| Required |
| 6.1 |
| Offeror provides a single point of contact through delivery and installation who is available for conference calls and coordination with Offeror technical and operational staff |
| Required |
| 6.2 |
| Offeror confirms installation plan will be provided 90 days before target installation date and will include installation team delivery schedule staging and storage needs shipping plan installation details bring-up plan and safety plan |
| Required |
| 6.3 |
| Offeror confirms Acceptance Test Plan will be jointly developed and agreed no later than 60 days before delivery and incorporated into contract documentation as applicable |
| Required |
| 6.3 |
| Offeror confirms Acceptance Test Plan will verify SOW technical specifications through benchmark tests and will evaluate performance functionality availability scalability resilience and reliability using benchmarks forced-failure scenarios and stability tests |
| Required |
| 6.3 |
| Offeror confirms any technical requirement identified in the Technical Specifications may give rise to a corresponding acceptance test |
| Required |
Department of Energy Office of Science