--- title: "River forecast issued time vs valid time" description: "Distinguish river forecast issuance, valid, generated, observation, and retrieval times. Keep revised forecasts and missing data clear in a shift handoff." canonical: "https://scalewithsearch.com/articles/river-forecast-issuance-valid-time-shift-handoff" --- ## Site navigation - [Scale With Search](https://scalewithsearch.com/) - Services - Services - [AI systems](https://scalewithsearch.com/ai-systems) - [Site build](https://scalewithsearch.com/work#site-build) - [Whole website fix](https://scalewithsearch.com/work#whole-website-fix) - [Content library with SEO](https://scalewithsearch.com/work#content-library) - [Working session](https://scalewithsearch.com/audit) - Start here - [Send your brief](https://scalewithsearch.com/work#send-your-brief) - [Example scope](https://scalewithsearch.com/work#review-the-example-scope) - [Prices and terms](https://scalewithsearch.com/work#prices-and-terms) - Industries - Real estate - [Real estate agents and teams](https://scalewithsearch.com/for/real-estate) - [Platforms, ownership, and IDX](https://scalewithsearch.com/for/real-estate/real-estate-website-platforms-ownership-idx) - [Search, content, and AI](https://scalewithsearch.com/for/real-estate/real-estate-search-content-ai) - [Inquiries, campaigns, and handoffs](https://scalewithsearch.com/for/real-estate/real-estate-website-inquiries-campaigns-handoffs) - [Buyer, seller, and local pages](https://scalewithsearch.com/for/real-estate/real-estate-buyer-seller-local-resources) - [Rules, privacy, and trust](https://scalewithsearch.com/for/real-estate/real-estate-website-rules-privacy-trust) - Browse by business - [Trades and home services](https://scalewithsearch.com/for/#group-trades) - [Health, wellness, and animal care](https://scalewithsearch.com/for/#group-practices) - [Law, finance, and IT](https://scalewithsearch.com/for/#group-professional) - [Marketing and SEO agencies](https://scalewithsearch.com/for/#group-agencies) - [Shops and manufacturers](https://scalewithsearch.com/for/#group-manufacturing) - [Restaurants, shops, studios, and nonprofits](https://scalewithsearch.com/for/#group-local-services) - Chiropractic practices - [Chiropractic and wellness practices](https://scalewithsearch.com/for/chiropractic-and-wellness-practices) - [Chiropractic and physical therapy clinics](https://scalewithsearch.com/for/chiropractic-and-physical-therapy-clinics) - [All industries](https://scalewithsearch.com/for/) - Resources - Free tools - [AI readiness check](https://scalewithsearch.com/check) - [Free tools](https://scalewithsearch.com/tools/) - [Free Starter Kit](https://scalewithsearch.com/kit/business-memory-starter-kit.zip) - Guides - [AI-native library](https://scalewithsearch.com/ai-native) - [Industry intelligence](https://scalewithsearch.com/intelligence) - [Office job guides](https://scalewithsearch.com/guides/) - [Business memory](https://scalewithsearch.com/articles/business-memory-for-ai-agents-guide) - [Agent governance](https://scalewithsearch.com/articles/ai-agent-governance-guide-small-business) - [Migration and ownership](https://scalewithsearch.com/articles/leaving-vendor-ai-memory-guide) - Articles - [All articles](https://scalewithsearch.com/articles/) - [What changed](https://scalewithsearch.com/changes/) - About - Evidence - [Proof](https://scalewithsearch.com/proof) - Scale With Search - [About](https://scalewithsearch.com/about) - [How it works](https://scalewithsearch.com/how-it-works) # River forecast timestamps: keep issuance and valid time in the shift handoff A river forecast handoff needs two times before it needs a summary: when the forecast was issued and when the predicted value applies. A screenshot saved this morning can contain an older forecast. A forecast issued this morning can describe tomorrow's river stage. Keep those times separate from the observation time, product generation time, and your own retrieval time. They answer different questions. Combining them into a single “updated” label leaves the next supervisor unable to reconstruct the preparation decision. This guide uses NOAA's National Water Prediction Service application API and a fictional Smithfield shift handoff. It concerns reading and preserving evidence. The [restoration company overview](/for/restoration-and-water-fire-damage) covers the separate office records used after a loss is reported. ## Give each clock its own meaning The NWPS API documentation defines time fields in its `gaugeStageFlow` and `gaugeDatum` objects. The schema identifies itself as version 1.0.0. The following interpretation follows that schema, reopened on October 28, 2026. See the [official schema](https://api.water.noaa.gov/nwps/v1/docs/swagger.json). Table: Time meanings for a river forecast handoff | Time | Source or field | What it tells the reader | | --- | --- | --- | | Forecast issuance | Forecast `issuedTime` | When the forecast product was issued | | Forecast valid time | Forecast point `validTime` | When that predicted value applies | | Observation time | Observed point `validTime` | When the observation was made | | Product generation | Point `generatedTime` | When the product was generated | | Retrieval | Your team's recorded access time | When your team obtained the response | The final row is a proposed record your team adds. It is not a substitute name for a NOAA field. A retrieval timestamp describes your access, not the age of the forecast inside the response. The schema also states that `issuedTime` does not apply to observed data. The [Smithfield stageflow response](https://api.water.noaa.gov/nwps/v1/gauges/SMFN7/stageflow) nevertheless contains an `issuedTime` field within its observed object. Follow the documented meaning: use each observed point's `validTime` for the observation time. That difference is worth preserving in the written handoff. A populated field is not permission to assign it a different meaning. If a colleague asks when the gauge was observed, point to the observed point and its valid time. ## Keep the source time zone visible The Smithfield series checked for this article used timestamps ending in `Z`, alongside the location's `EST5EDT` time-zone field. NOAA's [hydrograph terminology](https://water.noaa.gov/about/hydrograph) explains UTC and its relationship to time-zone offsets. Read the timestamp's explicit zone rather than assuming every displayed hour is local. For a clear handoff, preserve the original timestamp and add a labeled local display only when your team has verified the conversion. Include the calendar date in both. A time such as “six” without a date and zone cannot identify the intended forecast point. The fictional examples below use UTC throughout. This avoids an unnecessary conversion while teaching the difference between issuance and validity. It does not prescribe which display format your company should use in everyday work. Ask the incoming supervisor to identify the exact future time being discussed. If two people give different dates or zones, resolve that mismatch before describing a forecast revision. They may be comparing different points rather than different forecasts. ## Compare two issuances at the same valid time Suppose a training packet contains two fictional forecasts for SMFN7. Both include a stage value for October 29, 2026, at 18:00 UTC. Every value and timestamp in this comparison is invented for instruction, not taken from a live event. Table: Fictional forecast revisions for one Smithfield valid time | Training forecast | Issued at UTC | Valid at UTC | Forecast stage | | --- | --- | --- | --- | | A | October 28, 06:00 | October 29, 18:00 | 15.2 ft | | B | October 28, 12:00 | October 29, 18:00 | 16.1 ft | Forecast B is issued six hours after A. For the same future valid time, its predicted stage is 0.9 feet higher. That is a change between two forecasts. It is not an observed 0.9-foot river rise. A useful handoff says: “The newer training forecast raises the prediction for October 29 at 18:00 UTC from 15.2 to 16.1 feet.” Include both issuance times in the retained note. The comparison remains understandable even after a third forecast arrives. Now suppose A also contains a point for October 29 at 12:00 UTC. Do not compare that point with B's 18:00 UTC point and describe the difference as a revision. You would be changing both the forecast version and the valid time at once. If B omits a valid time that A included, mark that comparison unavailable. Do not silently fill the newer curve with an older point. The missing point does not mean the two forecasts agree, and it does not mean the predicted stage is zero. For the physical quantities behind the example, read the [stage and flow guide](/articles/river-stage-flow-restoration-readiness-hydrograph). It explains why the comparison must also retain gauge identity, quantity, units, and reference. ## Preserve complete forecast identity when summarizing A shift summary can be short without mixing forecast curves. Identify the gauge and issuance first. Then name the relevant valid time or time interval. Keep any comparison with the prior issuance in a separate sentence. Avoid constructing a single apparent forecast from whichever points look most useful in several screenshots. A high point from the morning issuance and a later point from yesterday's issuance do not become one official curve. Label each version independently if both are needed for review. NOAA's [river forecasting explanation](https://www.noaa.gov/jetstream/rfcs) describes precipitation inputs, runoff, and routed upstream flow. A changed forecast is not, by itself, evidence of why a particular revision occurred. Quote an official explanation when available. Otherwise leave the reason unknown. Likewise, `generatedTime` does not establish when your company received the forecast. The API schema describes it as product generation. Retain that field when needed, but do not relabel it as retrieval, approval, or the time a supervisor acted. A decision record should therefore have its own decision time. Record who reviewed which issuance and what preparation question they resolved. Keep the interpretation attached to the evidence that was available then. ## Handoff one: a new forecast is available In a fictional morning handoff, the outgoing supervisor used forecast A at 07:00 UTC. The incoming supervisor retrieves forecast B at 12:10 UTC. The new retrieval contains a later issuance and a changed value for the shared valid time. The note should preserve both facts: A supported the earlier review, while B is now available for the next review. Do not rewrite the old decision as though its author had already seen B. Retain the prior reasoning and create a new review entry. A proposed handoff could read: “Earlier preparation review used the 06:00 UTC issuance. The 12:00 UTC issuance is now available. For the shared 18:00 UTC valid time tomorrow, the training stage changes from 15.2 to 16.1 feet.” Then name the responsible person who will consider whether the preparation decision needs revision. The forecast update is evidence for that review. It does not independently authorize dispatch, staffing commitments, purchases, or entry to a location. ## Handoff two: the retrieved forecast is old Suppose the team accesses the source again at 14:00 UTC and still receives forecast B, issued at 12:00 UTC. The retrieval is new. The issuance has not changed. Record both times without refreshing the forecast's age to zero. Whether that forecast is too old for a particular decision requires a defined review rule and source context. Do not invent a universal expiry interval from this example. The [Smithfield metadata](https://api.water.noaa.gov/nwps/v1/gauges/SMFN7) describes routine year-round forecast issuance, but that statement does not promise a specific replacement minute. A useful note says: “Source checked at 14:00 UTC; latest retrieved issuance remains 12:00 UTC.” If the company considers it stale, add the rule and reviewer responsible for that judgment. Keep the original issuance visible beneath the status label. An unchanged response is also different from a failed access attempt. The former supplies evidence about what was returned. The latter cannot establish whether a newer forecast exists elsewhere on the service. ## Handoff three: no forecast is supplied A successful source response may provide observations without a usable forecast for your discussion. Record “forecast not supplied in this response” and identify the gauge and retrieval time. Preserve any observation with its own valid time. NWPS explains that forecast hydrograph availability varies with location and expected conditions. Some key locations receive daily forecasts even when flooding is not anticipated. This means a missing forecast is not a general all-clear rule. See the [hydrograph guide](https://water.noaa.gov/about/hydrograph). For a location where routine forecasts are expected, the absence deserves review. Do not infer its cause from a blank chart. Keep the missing forecast separate from a forecast explicitly predicting a value below a threshold. The next shift should know what remains unknown and who will check the official source. It should not receive a blank cell that could mean zero stage, no change, no forecast, or a forgotten review. ## Handoff four: the data cannot be retrieved If the source is unavailable, write down the failed access time separately from the last successful retrieval. Retain the old evidence with its original issuance and valid times. Do not display the old curve under a new freshness label. A proposed note reads: “Current source unavailable at this check. Last successful retrieval and its forecast issuance are retained below. Current forecast status is unknown.” That statement describes the team's evidence without guessing whether NOAA has issued an update. Give the responsible supervisor the unresolved question and the next review responsibility. Avoid turning source failure into either reassurance or a forecast of worsening conditions. Neither interpretation follows from the failed access. The [restoration intelligence overview](/intelligence/restoration-and-water-fire-damage) explains how source age belongs beside readiness information. This handoff keeps the time evidence readable without prescribing a collector, polling interval, or automated response. ## Retain snapshots prospectively without claiming an archive The NWPS service page states that its application API does not provide historical data beyond crest and low-water history. It separately describes other services with different scopes. Do not apply another service's historical availability to this application's gauge endpoint. See [NWPS data-service scope](https://water.noaa.gov/about/api). For a future review, retain the response or source view your team used when it made the decision. Keep gauge identity, quantities, units, timestamps, source URL, and retrieval time together. Save the interpretation and decision separately so a later correction does not replace the original evidence. This is a prospective company record. It contains what your team retained from that point forward. It is not a complete archive of every official forecast, and missing earlier issuances should remain missing. A later review can compare the preserved prediction with an appropriately timed observation. That review must still distinguish forecast validity from observation time and avoid selecting only convenient points. Record gaps and changes in reference before drawing conclusions about the team's preparation rule. The [business memory guide](/articles/business-memory-for-ai-agents-guide) provides the broader principle: keep source evidence, decisions, and corrections available to the next person. For this handoff, five separately labeled clocks are more useful than one confident “updated” badge. Scale With Search can discuss a written scope for preserving those records and review boundaries. Start with one shift handoff and the question the next supervisor could not answer from it. [Discuss the scope](/work) Continue the website review: [AI-native restoration: the first functions to build](/articles/ai-native-restoration-first-functions); [Restoration AI rules: data, approvals, and spend](/articles/restoration-ai-rules-data-approvals-spend); [Restoration website: build a clear emergency call path](/articles/restoration-emergency-call-website); [Mold remediation pages: remove unsupported health claims](/articles/restoration-mold-remediation-website-claims); [Restoration job files in Google: protect the documents](/articles/restoration-private-job-documents-google-search); [Restoration case studies: show the work your records prove](/articles/restoration-project-case-study-pages); [Restoration Google profiles: assess storm-response bases](/articles/restoration-storm-response-google-profile-locations); [Restoration website insurance claims: write the limits](/articles/restoration-website-insurance-claims); [River stage and flow: read a hydrograph before a restoration readiness meeting](/articles/river-stage-flow-restoration-readiness-hydrograph); [Water damage drying FAQs: avoid a false completion date](/articles/water-damage-drying-time-website-faq). [restoration and water or fire damage companies](/for/restoration-and-water-fire-damage): website and search resources. ## Related: restoration and water or fire damage companies - [River stage and flow: read a hydrograph before a restoration readiness meeting](/articles/river-stage-flow-restoration-readiness-hydrograph) - [Water damage drying FAQs: avoid a false completion date](/articles/water-damage-drying-time-website-faq) - [AI-native restoration: the first functions to build](/articles/ai-native-restoration-first-functions) ---- ```text .|########||. .|########||. .|########||. |##||. .||##|. |##||. .||##|. |##||. .||##|. |#|. .|#|. |#|. .|#|. |#|. .|#|. |#| |#| |#| |#| |#| |#| .#| |#. .#| |#. .#| |#. .#. .#| .#. .#| .#. .#| |#. .#| |#. .#| |#. .#| |# ...... #| |# ...... #| |# ...... #| .# ||#########| #| .# ||#########| #| .# ||#########| #| .#. |######||######|. .#. .#. |######||######|. .#. .#. |######||######|. .#. #. .##|###|##|#|######| .# #. .##|###|##|#|######| .# #. .##|###|##|#|######| .# || |##|#||||||||||||#||#| || || |##|#||||||||||||#||#| || || |##|#||||||||||||#||#| || # |#||||||||||||||||||||#| #. # |#||||||||||||||||||||#| #. # |#||||||||||||||||||||#| #. || |#||||||||||||||||||||||#| || || |#||||||||||||||||||||||#| || || |#||||||||||||||||||||||#| || # .#||||||||||||||||||||||||#| # # .#||||||||||||||||||||||||#| # # .#||||||||||||||||||||||||#| # || ....|||#||||||##|#|||#|#||##||||....|. || || ....|||#||||||##|#|||#|#||##||||....|. || || ....|||#||||||##|#|||#|#||##||||....|. || #. . ....|# ....#||| ||| .#||| ....#. .# #. . ....|# ....#||| ||| .#||| ....#. .# #. . ....|# ....#||| ||| .#||| ....#. .# # . ||||#| .#####|| . .#| .#||| ||||# #. # . ||||#| .#####|| . .#| .#||| ||||# #. # . ||||#| .#####|| . .#| .#||| ||||# #. .| ||||| #. |#|||||. || #. |#||. .||||| || .| ||||| #. |#|||||. || #. |#||. .||||| || .| ||||| #. |#|||||. || #. |#||. .||||| || || |.... #. ....|#. |. ...|. ....|| || || |.... #. ....|#. |. ...|. ....|| || || |.... #. ....|#. |. ...|. ....|| || #. .||||||##||||||##||####|||||||#||||||#| .# #. .||||||##||||||##||####|||||||#||||||#| .# #. .||||||##||||||##||####|||||||#||||||#| .# # .||####|###########################|. # # .||####|###########################|. # # .||####|###########################|. # # .#||||||.#.|| # |. ..# #| #|||||#| # # .#||||||.#.|| # |. ..# #| #|||||#| # # .#||||||.#.|| # |. ..# #| #|||||#| # # .#|||||| .. |# ## |#| ...#|#|||#| # # .#|||||| .. |# ## |#| ...#|#|||#| # # .#|||||| .. |# ## |#| ...#|#|||#| # # .#|||#|# .# .#| #| ##|.#..#|||||#| # # .#|||#|# .# .#| #| ##|.#..#|||||#| # # .#|||#|# .# .#| #| ##|.#..#|||||#| # # .#||||||############|######|||||#| # # .#||||||############|######|||||#| # # .#||||||############|######|||||#| # # |...||#||||||#||||#|#||||||#|||||#||| |.| # # |...||#||||||#||||#|#||||||#|||||#||| |.| # # |...||#||||||#||||#|#||||||#|||||#||| |.| # #. .. ||||# .|||##|. |#| .|| || .|||#. #| # .# #. .. ||||# .|||##|. |#| .|| || .|||#. #| # .# #. .. ||||# .|||##|. |#| .|| || .|||#. #| # .# || | ...|| ...##| | #| .|. |. ##### .. .| || || | ...|| ...##| | #| .|. |. ##### .. .| || || | ...|| ...##| | #| .|. |. ##### .. .| || || ||||| || ||||#| . |. |. |#. ||||| |#| || || || ||||| || ||||#| . |. |. |#. ||||| |#| || || || ||||| || ||||#| . |. |. |#. ||||| |#| || || .# |.....#|....|#.||||.|||##.|#|....||.#||.#. #. .# |.....#|....|#.||||.|||##.|#|....||.#||.#. #. .# |.....#|....|#.||||.|||##.|#|....||.#||.#. #. #.|||||||#############################| ||| .# #.|||||||#############################| ||| .# #.|||||||#############################| ||| .# || ##||#||#||||||#||#||#||#||##. || || ##||#||#||||||#||#||#||#||##. || || ##||#||#||||||#||#||#||#||##. || # .#|||||||||#||#|||||||||||#| # # .#|||||||||#||#|||||||||||#| # # .#|||||||||#||#|||||||||||#| # || |#||||||||||||||||||||||#| || || |#||||||||||||||||||||||#| || || |#||||||||||||||||||||||#| || .# |#||||||||||||||||||||#| #. .# |#||||||||||||||||||||#| #. .# |#||||||||||||||||||||#| #. || |#||||||||||||||||||#| || || |#||||||||||||||||||#| || || |#||||||||||||||||||#| || #. .######|#|#########| .# #. .######|#|#########| .# #. .######|#|#########| .# .#. |#####||||#####| .#. .#. |#####||||#####| .#. .#. |#####||||#####| .#. |# ||########|| #. |# ||########|| #. |# ||########|| #. |# ...... #| |# ...... #| |# ...... #| |#. .#| |#. .#| |#. .#| |#. .#. |#. .#. |#. .#. .#| |#. .#| |#. .#| |#. |#| |#| |#| |#| |#| |#| .|#|. .|#|. .|#|. .|#|. .|#|. .|#|. |##||. .||##| |##||. .||##| |##||. .||##| .||########||. .||########||. .||########||. Scale With Search 2026 [scalewithsearch.com](https://scalewithsearch.com) ```