USGS ShakeAlert Code Review RFI

Responses are requested by October 16, 2026 at 12:00pm PST.

All responses should be submitted electronically in PDF format and emailed

[name] at [email].

Applicable socioeconomic designation.

Business size standard.

SAM UEI number.

GSA contract number, if applicable.

Ability to execute all tasks listed.

General marketing information or reference to vendor web sites will not be considered responsive

No telephone, mail, or fax responses will be accepted.

All written reports shall be submitted in both PDF and editable Word (.docx) format

The subject line of the email should read as follows “RFI: 140G0326Q0223 – ShakeAlert Production System Code Review.”

A rigorous, module-by-module review of source code quality, correctness, and maintainability.

An assessment of current software development and deployment practices, with concrete recommendations for modernizing the CI/CD pipeline

Respondents must submit capability statements and information describing the general approach/solution to addressing the listed requirements.

The contractor shall perform a deep qualitative review of each module, examining:

Inter-process interactions: correctness of message-passing interfaces (currently ActiveMQ, transitioning to NATS); adherence to defined message schemas

identification of all runtime-configurable parameters in each module; documentation of their expected ranges, sensitivity, and default values

review of specific issues identified in prior work (e.g., differences in solutions across server instances due to variations

Data flow and interface consistency: whether module inputs and outputs are consistent in format, units, coordinate systems

specific attention to the Solution Aggregator (SA) logic that merges EPIC, FinDer, and GFAST solutions

review of the Decision Module (DM) logic used to determine if ShakeAlert Message should be published

review of the alert-pause feature and alert-update thresholds for correctness, with attention to the 2022 Ferndale earthquake bug case

The contractor shall review the current GitLab repository structure, branching strategy, merge request process, and tagging/versioning practices

The contractor shall recommend specific static open-source analysis tools compatible with the ShakeAlert code base

The contractor shall implement at least a baseline CI/CD pipeline configuration in the project’s GitLab repository as part of Deliverable 6

The contractor shall review the project’s existing coding standards documentation (if any), assess compliance across the code base

The contractor shall review the current deployment process (Ansible and related tooling) and assess:

The contractor shall review all of the following production modules, plus any Earthworm modules and third-party libraries

All review work shall be based on the production branch of the code at the time of repository access

The contractor shall request and document, for each module, the design intent, known limitations, and any open issues

The contractor shall communicate findings to USGS ShakeAlert staff progressively (not only in final reports)

Primary recommendations shall be technically sound, clearly linked to identified deficiencies, and actionable within the constraints

Recommendations that require a complete rewrite of major modules are unlikely to be actionable and should be avoided

Recommendations related to inter-process communication shall be written to remain valid under the anticipated NATS architecture

MISRA C/C++ guidelines (or equivalent; to be agreed at kickoff based on language profile of code base)

CERT C/C++ Secure Coding Standard for security-relevant findings

SEI CERT guidelines for concurrency and real-time considerations

Federal government IT security and software assurance guidance relevant to USGS systems

At kickoff, the contractor and USGS shall agree on the specific standards and tools to be applied

The contractor shall acknowledge they understand the Intellectual Property rules which govern the ShakeAlert production code

The contractor shall participate in a kickoff meeting (in person or virtual) within 30 days of contract award

The contractor shall hold at least monthly progress meetings with USGS ShakeAlert technical staff throughout the contract period

Contractor questions shall be submitted in writing (e.g. email or issue tracker) or captured in meeting minutes

the contractor shall address USGS comments within 30 days thereafter

Kickoff meeting and work plan Month 1 Meeting + written plan

Code metrics baseline report Month 3 Written report + data files

Detailed code review findings Month 6 Written report with prioritized

CI/CD and development Month 8 Written report with

Final report and Month 11 Comprehensive report; briefing

Demonstration of CI/CD Month 12 Working pipeline changes in

Within 30 days of contract award, the contractor shall conduct a kickoff meeting with USGS ShakeAlert technical staff and deliver a written work plan

deliver a written work plan that specifies the review methodology, tools and standards to be applied, task schedule with milestones, points of contact

A quantitative characterization of the code base covering all modules in Section 4. The report shall include per-module and aggregate metrics

The report shall include per-module and aggregate metrics (LOC, cyclomatic complexity, Halstead metrics, test coverage, documentation coverage), a dependency graph

a dependency graph, and a prioritized list of modules and subsystems flagged for deeper review based on the metrics

Raw metric data shall be provided as machine-readable files (e.g., CSV or JSON) in addition to the narrative report

A module-by-module code review report organized by the review dimensions in Section 3.1.2

For each finding, the report shall identify the affected module and file, describe the issue and its potential impact on alert reliability or correctness

The report shall include a consolidated findings table for easy prioritization

Critical and High severity findings shall include proposed code changes (pseudocode or actual code) where practical

A report covering the assessment of GitLab workflow, automated static analysis tooling, coding standards, and deployment practices described in Section 3.2

For each area, the report shall describe current practice, identify gaps relative to applicable standards and industry practice, and provide prioritized

The report shall include a step-by-step implementation guide for the recommended CI/CD pipeline improvements

A comprehensive final report that synthesizes findings across all tasks, highlights the most impactful improvements, and provides a recommended prioritized action plan

The report shall include an executive summary suitable for non-technical stakeholders

The contractor shall present the findings to ShakeAlert technical staff and program management in a virtual briefing of approximately two hours

Working CI/CD configuration changes implemented in the ShakeAlert GitLab repository, reviewed and approved by USGS

that automate at a minimum: build verification, static analysis (linting and complexity checks), unit test execution, and coverage reporting on every merge request

The contractor shall document the pipeline configuration and provide a brief user guide for ShakeAlert staff

Period of performance: 12 months from date of contract award

All work may be performed remotely. Travel to USGS facilities is not required but may be proposed by the contractor

The contractor shall treat all non-public ShakeAlert code, configuration, and documentation as sensitive and shall not disclose it to third parties

A non-disclosure agreement (NDA) or comparable instrument will be executed at contract award

The contractor is not expected to implement code fixes; that responsibility remains with USGS staff

The exception is Deliverable 6, where the contractor will implement CI/CD pipeline changes in the repository under USGS review

All recommendations shall consider the strong preference of USGS to use open-source code, libraries, and tools

Contractor personnel performing the code review shall have demonstrated experience in real-time or safety-critical software systems

Relevant domain experience in seismology or geophysical data processing is desirable but not required