# BIPAD river archives and corridor flood-alert records

Searches conducted on 8 September 2026 UTC, corresponding to 9 September in the working location, Europe/Bucharest. This phase follows the [DHM and CHWRR searches](2026-09-08-hydrology.md). It adds two candidate service families and five assets with automated metadata assessments. Resource eligibility, independent human review and manuscript inclusion remain unassigned.

## Search scope and outcomes

| Search | Execution and outcome | Screened discovery records | Retained assets |
|---|---|---|---|
| Archived river-gauge observations at Malekhu and Galchi on the Trishuli corridor, 25–31 August 2026 — Nepal BIPAD | RUN-20260908-045; completed bounded retrieval | Four station identities: two known-item selections and two nonselected identities from a small interface-discovery sample | Two station query routes; 628 observation rows |
| Public flood alerts for the Bhote Koshi–Trishuli–Narayani corridor, 25 August–2 September 2026 — Nepal BIPAD | RUN-20260908-046; completed bounded retrieval | 56 date-filtered alert IDs, plus two separately excluded interface-discovery IDs | Three public corridor river-alert records |

The river run began at 21:07:16 UTC and the alert run at 21:07:41 UTC. Both finished source charting at 21:11:52 UTC. There were 17 native HTTP requests: 11 for river/API documentation and six for alerts. All returned HTTP 200. The complete request ledger records methods, exact URLs and parameters, actual request times, media types, byte counts and SHA-256 hashes. Empty terminal pages are included. A supplementary pair of web queries helped locate the provider's API documentation; their result dispositions and unrecorded timing limitation are documented separately below.

“Completed” refers to the bounded retrieval and screening procedure. It does not establish a complete event record, a complete national archive or completion of the overall search programme. The catalogue now contains 46 executions: 37 completed, eight partial and one unavailable. There are 27 reviewed resources with 270 assets and 98 candidate families with 6,047 assets. All 6,317 current asset records have an automated assessment; 665 retain follow-up flags. Earlier assessments retain their evidence dates.

## Methods and reproducibility

The prospective plan was written before the first BIPAD request and copied into each frozen strategy. Earlier local holdings supplied station-series IDs 31967 and 36628 and the river/alert API routes. These holdings are known-item leads, not retrospectively counted discoveries. The catalogue screening population is source records; measurements inside a returned time series are separately charted data rows.

The [provider OpenAPI schema](https://bipadportal.gov.np/api/?format=openapi) lists river filters `station_series_id`, `water_level_on__gt`, `water_level_on__lt` and `ordering`, and alert filters `started_on__gt`, `started_on__lt` and `ordering`. The discovery responses exposed `count`, `next`, `previous` and `results`. Their count value, **9223372036854775807**, was not a credible enumerated total. It is retained as a string in page metadata and never treated as a PRISMA count. The schema's response description differs from the observed paginated envelope; the actual response governs the record of this execution.

The river analysis window was **[25 August 00:00 UTC, 1 September 00:00 UTC)**. The alert search window was **[25 August 00:00 UTC, 3 September 00:00 UTC)**, applied to alert start time. These are UTC intervals, not Nepal calendar days. Nepal time is UTC+05:45. Because the documented filters are strict greater-than/less-than, the lower request bound was `2026-08-24T23:59:59.999999Z`; this includes a possible sample exactly at target midnight. Returned river timestamps were independently classified within the intended window. This adaptation was recorded before the bounded queries and did not use undocumented `gte` filters.

River requests used `limit=1000`, each selected station-series ID, the two timestamp bounds and `ordering=water_level_on,id`. Alert requests used `limit=100`, the start-time bounds and `ordering=started_on,id`; no server-side hazard or geographic filter was applied. Each selection returned fewer rows than its requested page size but still supplied a next link. That link returned an empty page, which ended pagination. The two current station-identity metadata listings were also followed to empty pages. These metadata snapshots are not historical observations.

Anonymous access, 30-second request timeouts and a 10 MiB response limit were used. One retry was permitted for transient failure; none was needed. The plan imposed finite pagination and row safeguards; no safeguard truncated these results. Exact strategies, API adaptations, queries and response provenance are downloadable below. No credentials, provider contact, research-model execution or third-party response-body publication occurred. The initial search and integration phase ran no software checks. The user's subsequent requested audit, corrections and verification are documented in the [audit report](2026-09-09-bipad-audit.md).

## River observations and upstream overlap

| Station | BIPAD identifiers | Rows / unique times | First observation, UTC | Last observation, UTC | Largest internal interval |
|---|---|---:|---|---|---:|
| Trishuli at Furke Khola (Malekhu) | Series 31967; station 261 | 161 / 161 | 25 August 00:05 | 26 August 05:55 | 30 minutes |
| Trishuli at Galchi | Series 36628; station 281 | 467 / 467 | 28 August 11:05 | 31 August 23:55 | 40 minutes |

Both series identify the Narayani basin and upstream `dataSource=hydrology.gov.np`. Malekhu is at source coordinates 84.844102, 27.802439; Galchi at 85.00305, 27.802328. These are station points, not observed flood footprints. BIPAD metadata and alerts use different identifier namespaces: station IDs 261/281, series IDs 31967/36628 and alert reference IDs must not be interchanged.

All 628 readings fall inside the requested river window. The two series have no duplicated observation IDs or timestamps, null water levels, nonnumeric or nonfinite values, negative values or unresolved timestamps in the retrieved rows. This describes source structure, not measurement accuracy. The modal positive interval is 600 seconds in both series. Malekhu has 18 intervals longer than that mode; Galchi has 41. No interpolation, missing-value replacement or removal was applied. Database creation follows observation by roughly 309–343 seconds at Malekhu and 309–914 seconds at Galchi; these are timestamp differences, not measured communications latency.

Malekhu ends at **11:40 Nepal time on 26 August**. Neither this endpoint nor the final available value establishes the physical event peak, flood arrival or the reason telemetry ended. Its source description is `CDCP_TEST_2025`; the current station metadata does not explain that label. Instrument, calibration and quality-control documentation remain unresolved.

**Every one of the 467 Galchi readings has exactly the same UTC timestamp and numeric value in the previously retrieved 1,008-row DHM Galchi series.** The comparison used timestamp equality and exact equality of parsed JSON numbers, with no rounding, tolerance, interpolation or resampling. There are 541 DHM timestamps absent from BIPAD and no BIPAD timestamps absent from DHM. This establishes overlap between retrieved distributions, not independent observational corroboration. The catalogue links the BIPAD asset to the existing DHM asset and does not count these as 467 new independent measurements.

The BIPAD River schema supplies no unit or gauge-datum definition. The DHM Galchi interface labels its matching water-level series in metres, but agreement alone does not resolve the Malekhu datum or authorize comparisons between station magnitudes. Water level must not be presented as discharge or inundation depth. BIPAD's historical Galchi rows have a null warning threshold in 390 records and 367 in 77; the danger threshold is null throughout, while all 467 status labels say “BELOW WARNING LEVEL”. These mutable fields cannot establish safety or historically valid threshold settings. Malekhu's rows carry warning 7 and danger 8, with historical validity and reference still unresolved.

## Public corridor flood alerts

| BIPAD alert | Station and place | Alert start, Nepal time | Database creation, Nepal time | Embedded observation, Nepal time | Expiry, Nepal time |
|---|---|---|---|---|---|
| [45649](https://bipadportal.gov.np/api/v1/alert/45649/) | Phalakhu Khola at Betrawati; Uttargaya-5, Rasuwa | 25 August 21:10 | 25 August 21:15:09.946486 | 25 August 22:00 | 25 August 22:15:04.284556 |
| [45654](https://bipadportal.gov.np/api/v1/alert/45654/) | Trishuli at Malekhu; Siddhalek-6, Dhading | 26 August 11:30 | 26 August 11:35:15.344855 | 26 August 11:40 | Not supplied |
| [45656](https://bipadportal.gov.np/api/v1/alert/45656/) | Trishuli at Kali Khola; Aanbookhaireni-4, Tanahu | 26 August 14:00 | 26 August 14:05:09.955498 | 26 August 14:50 | 26 August 15:05:04.007106 |

All three records carry provider labels `source=dhm`, `public=true` and `verified=true`. Those are source flags, not independent human verification by this review. Their embedded reference objects identify hydrological series 19926, 31967 and 19583, respectively, and reference IDs 4658, 5611 and 4781 link the known DHM station-page leads.

The embedded measurement is **50, 10 and 50 minutes later than the respective alert start**. Each record's description water level also differs from its embedded reference water level. The values must therefore remain attached to their own fields and temporal context; the later embedded value must not be labelled a measurement at issuance. Update history or an immutable issuance snapshot was not recovered. Alert start, database creation, expiry, embedded observation and actual dissemination remain different concepts. No delivery, receipt, understanding or evacuation evidence is supplied by these records. A null expiry does not demonstrate an ongoing flood, and a non-null expiry does not establish that the river became safe.

The start-time selection does not enumerate alerts that began before the window but remained active inside it. Nor does it recover missing/deleted alerts or every warning channel. Alert points and demographic fields are not measured impact footprints or affected-person counts; demographic fields and user identifiers are omitted from the public charting exports.

## Screening counts and next-search leads

Among the 56 date-filtered alert IDs, three corridor river alerts were retained; seven corridor road closures were recorded as follow-up leads; 22 records were other alert types; and 24 river alerts belonged outside the declared corridor. The latter include other Narayani tributaries: sharing a basin name is not sufficient for corridor selection. Two additional discovery-sample alerts started outside the window and were excluded separately. The disposition ledger therefore contains 58 alert IDs, not 58 date-filtered results. Repeated appearances of the three selected IDs in detail requests were not counted as new records.

The seven road-closure leads are **45655, 45658, 45659, 45660, 45661, 45662 and 45703**, in Rasuwa, Dhading and Chitwan. They were returned by the broader native alert query but lie outside this flood-alert selection. A useful next search is **“Road closures and reopening records along the Rasuwa–Trishuli corridor, August–September 2026 — Nepal Department of Roads and BIPAD.”** The neutral date wording does not presume that all closures followed or resulted from the cascade. It should establish road/chainage identity, original incident and update timestamps, stated cause, closure/reopening status and source lineage before attributing a disruption to flooding or estimating duration. The [lead register](2026-09-08-bipad-next-search-leads.json) preserves source IDs and URLs; these are not newly included road-impact assets.

A supporting web-navigation batch used exactly `BIPAD API river water_level_on__gt station_series_id github` and `BIPAD api alert started_on filter github`. Fifteen visible result entries were returned across the batch. Only the official BIPAD API documentation was followed; third-party feeder code and unrelated API documentation were not used as evidence. Separate result sets per query and exact start/end timestamps were not retained by that tool call, so no per-query total, ranking coverage or exhaustive web-search claim is made. This was interface navigation rather than a third resource-discovery execution. The [navigation ledger](2026-09-08-bipad-navigation.json) records all visible URLs and dispositions.

## Evidence downloads

- [Search outcomes and actual counting units (CSV)](2026-09-08-bipad-outcomes.csv)
- [Phase totals and scope (JSON)](2026-09-08-bipad-summary.json)
- [Frozen prospective strategies (JSON)](2026-09-08-bipad-strategies.json)
- [Exact queries and counting units (JSON)](2026-09-08-bipad-queries.json)
- [Recorded API adaptations (JSON)](2026-09-08-bipad-adaptations.json)
- [All 17 native request attempts, response sizes and hashes (JSON)](2026-09-08-bipad-requests.json)
- [Station and alert discovery dispositions (CSV)](2026-09-08-bipad-dispositions.csv)
- [Station identities, coverage and Galchi overlap analysis (JSON)](2026-09-08-bipad-stations.json)
- [Selected alert metadata and distinct temporal fields (JSON)](2026-09-08-bipad-alerts.json)
- [Original and reader-facing asset titles (CSV)](2026-09-08-bipad-asset-titles.csv)
- [Five asset assessments (JSON)](2026-09-08-bipad-assessments.json) / [CSV](2026-09-08-bipad-asset-assessments.csv)
- [Source-linked field values, evidence states and locators (CSV)](2026-09-08-bipad-metadata.csv)
- [Relationships to previously catalogued assets (CSV)](2026-09-08-bipad-relationships.csv)
- [Remaining source questions (JSON)](2026-09-08-bipad-follow-ups.json)

The two new resource families describe distribution services. They are not two independent studies or a claim that every linked observation is new. Candidate inclusion, human screening and manuscript decisions remain separate from the automated source and asset assessment documented here.