Team & Current Stewardship

Who is responsible for maintaining BAITSSS now.

Current responsibility is named here. Scientific methods and interpretation remain on the Science page, while earlier collaborators, institutions, and peer-reviewed work remain in Scientific History & Publications.

01 · Current stewardship

Named responsibility for the current BAITSSS system

The current desktop product has a named scientific and software development lead. This page identifies that responsibility without replacing the separate scientific, engineering, and publication records.

Lead developer & scientific steward
Ramesh Dhungel
BAITSSS scientific development and current BAITSSS Desktop development
Current responsibility includes the supported desktop route, scientific continuity, software integration, verification, documentation, release preparation, and research collaboration pathways.

Ramesh Dhungel is the corresponding author of the original 2016 BAITSSS methodology paper and lead author across the selected BAITSSS peer-reviewed research record documented on this site. That work spans evapotranspiration, two-source surface energy balance, soil-water accounting, irrigation, remote sensing, field evaluation, and agricultural water management.

For BAITSSS Desktop V1, current responsibility includes preserving established model behavior while maintaining the desktop workflow, controlling data and parameter authority, verifying numerical behavior, testing run and recovery paths, packaging the runtime, documenting the system, and preparing the first release version.

Earlier institutions and collaborators are credited in Scientific History & Publications. Their participation in the scientific history does not imply present sponsorship, ownership, endorsement, or responsibility for the current independent desktop software unless specifically stated.

02 · Current responsibility

What current stewardship covers

01 · PRODUCT

Maintain one supported desktop route

Keep project state, data preparation, execution, recovery, Results, provenance, packaging, and documentation connected within one maintained product.

02 · VERIFICATION

Require evidence for change

Use numerical comparison, restart testing, source controls, runtime contracts, parameter audits, and release checks to distinguish demonstrated behavior from assumption.

03 · CONTINUITY

Protect scientific implementation

Software modernization should not silently redefine equations, parameters, state behavior, or reference outputs. Scientific changes require explicit scientific review.

04 · COMMUNICATION

Keep status and limits visible

Document what the software does, what has been verified, what remains under development, and how research or educational collaboration can proceed.

03 · One authority per subject

Science, software verification, and history remain separate authorities.

This page identifies current responsibility. It does not duplicate the scientific record, the software verification record, or the historical record.

Current stewardship is named here. Scientific stewardship is maintained in Science. Scientific lineage is credited in history. Software verification is documented separately.