Across MyMap's August 15, August 20, and August 23 observations of USGS event us6000tkt2, the preferred magnitude stayed M7.7 and the tsunami flag stayed 0, while maximum ShakeMap intensity moved from 8.806 to 7.887, felt reports rose from 38 to 50, PAGER moved from orange to yellow, and later finite-fault and aftershock-product updates advanced the record clock. The direct answer is that one USGS earthquake record is a versioned product graph, not one severity score or one timestamp.
Magnitude describes the source estimate; ShakeMap models spatial shaking; Did You Feel It aggregates public observations; PAGER models possible impact; finite-fault models rupture; and aftershock products describe a forecast sequence. The state diff matters because those products can change on different clocks without creating a new earthquake or invalidating every unchanged field.
The question this map answers
Which values in the August 14 earthquake record stayed stable, which products moved on later clocks, and what can a journalist safely conclude from each state transition?
The preferred origin time remains 2:58:21 PM Pacific Time on August 14. MyMap's baseline observation was 4:29 AM on August 15, followed by a 4:03 AM observation on August 20. The current detail record was observed at 4:05 AM on August 23; its top-level updated time is 11:45:15 AM on August 22, matching the current event-sequence product and arriving milliseconds after the OAF aftershock forecast. Observation time, event time, record time, and each product time are distinct clocks.
Source scope and relationship definitions
The controlling sources are the USGS GeoJSON detail record for us6000tkt2, USGS field definitions, and USGS PAGER and Did You Feel It documentation. The August 15 and August 20 baselines are MyMap's dated captures of that same mutable primary record; the current feed exposes the preferred present state rather than a separately downloadable history of every prior value. Media reports, local damage accounts, emergency instructions, and casualty reporting are outside this source scope.
The visual uses three relationship rules:
- A stable lane means the field had the same value in all three MyMap observations.
- A dated revision arrow means the preferred attached product has a later update time and a changed value.
- A status chip belongs only to the event or product that carries it; review does not transfer to neighboring nodes.
The current products object contains 11 product families, including origin, shakemap, dyfi, losspager, event-sequence, finite-fault, and moment-tensor. They share an event association but can use different methods, review states, and update clocks.
The stable lane: M7.7, 10 km, reviewed event, tsunami 0
All three observations show preferred magnitude 7.7 with magnitude type mww, preferred depth 10 km, and a top-level event status of reviewed. Those fields characterize and qualify the preferred event solution. They do not say that every location experienced intensity 7.7, predict one loss outcome, or transfer human review to every attached model.
All three observations also show tsunami: 0. USGS defines this property narrowly as a feed flag and warns that its value does not establish whether a tsunami did or will exist. The confirmed stable claim is only that this USGS routing field was 0 in all observed versions. A safety claim still belongs to the responsible tsunami-warning authority.
The ShakeMap lane: MMI 8.806 → 7.887
The August 15 observation exposed mmi: 8.806. The current preferred ShakeMap, version 6, exposes maxmmi: 7.887 and a processing timestamp of August 17 at 2:51:59 PM Pacific Time. The preferred ShakeMap product itself was updated at 2:53:57 PM.
This is a revision to an estimated maximum instrumental intensity, not a revision to magnitude. The current product says map-status: automatic, review-status: automatic, and reviewed-origin: True. Those fields show how a model can use a reviewed origin while its own map remains automatic.
The change also does not mean that observed shaking physically decreased three days later. It means the preferred model output changed as the product was recomputed. A newsroom graphic should label the value as “current preferred ShakeMap maximum” and retain the product version and observation time.
The DYFI lane: 38 → 47 → 50 reports, CDI still 7.9
The maximum reported Community Decimal Intensity remains 7.9, while the number of Did You Feel It submissions rose from 38 in the August 15 observation to 47 on August 20 and 50 in the current preferred DYFI product. That product was updated at 11:37:22 AM on August 22. Eight minutes later, the event-sequence and OAF products—not DYFI—advanced the top-level record time again.
USGS describes Community Decimal Intensity as an aggregate built from public responses and warns that the input is raw and unchecked. A higher submission count does not by itself mean stronger shaking, a larger affected population, or a representative survey. Here the response count changed twice while CDI stayed the same, making that distinction visible.
The PAGER lane: orange → yellow and reviewed → automatic
The August 15 observation carried an orange PAGER alert and a reviewed PAGER product. The current preferred losspager product carries alertlevel: yellow, review-status: automatic, and an August 17 update time of 2:56:48 PM Pacific Time. The top-level alert field is now yellow.
PAGER combines estimated shaking exposure with country-specific fatality and economic-loss models. Its color is therefore a modeled response-scale signal, not an observed casualty or damage count. Orange-to-yellow means the preferred model state changed; it does not prove that an earlier estimate was negligent, that losses physically reversed, or that the current yellow model is a final accounting.
The visual connects the PAGER change to the revised ShakeMap input clock but does not draw a causal arrow claiming that the MMI change alone produced the alert change. PAGER uses more than one input and its public record does not isolate a single cause for the color transition.
Later clocks expose rupture and aftershock states
The current preferred finite-fault product, version 3, carries an August 21 update time and review-status: reviewed. Its fields describe a modeled rupture, including one segment and a derived magnitude. Those are product-specific model fields, not replacements for the top-level preferred M7.7 origin.
The preferred DYFI product then updated on August 22. The OAF and event-sequence products updated eight minutes later; event-sequence carries a reviewed status and a forecast-region and time-window description. Their 11:45:15 AM timestamp became the top-level updated value. That does not mean the origin, ShakeMap, PAGER, moment tensor, and every other attached product were regenerated then. The preferred origin still carries its August 14 product time, while ShakeMap and PAGER still carry August 17 times.
That is why update detection must compare product updateTime values, not only the event's top-level timestamp. A single “updated” badge over the full card can make an aftershock-forecast refresh look like a new source solution, shaking estimate, or impact model.
Reviewed is a scoped label
The top-level event status remains reviewed. The current preferred origin says review-status: reviewed and evaluation-status: preliminary; ShakeMap says map-status: automatic and review-status: automatic; PAGER says review-status: automatic; and the finite-fault, OAF, and event-sequence products say review-status: reviewed.
These are scoped states, not contradictions. A human-reviewed event association can contain a preliminary evaluation and automatic model products. A breaking-news graphic should attach each status to its product rather than place one “verified” badge over the entire record.
Confirmed, derived, and unknown
The controlling source confirms the current event ID, preferred origin fields, 11 attached product families, current values, product update times, and scoped status labels. MyMap's dated August 15 and August 20 observations record earlier preferred values and clocks from the same mutable source.
MyMap derives the state-diff lanes, the “stable versus revised” grouping, and the rule that review labels stay on their own node. MyMap does not derive causality between the ShakeMap and PAGER changes.
The sources leave unknown the final event solution, final shaking pattern, complete damage and casualty facts, representativeness of the 50 reports, the reason each model value changed, and any current tsunami warning state. The mutable detail endpoint also does not expose the complete historical snapshot as a separate versioned download.
Reproducible mapping method
Start from a USGS summary feed, retain the event ID, follow its detail URL, and save the raw GeoJSON with an observation time before transforming it. Then:
- Store
mag,magType, depth, coordinates, origin time, top-levelstatus, andtsunamias event-level fields. - For every product family used in the story—including
shakemap,dyfi,losspager,finite-fault,oaf, andevent-sequencehere—select the preferred product and store its ID, value fields,updateTime, version, and review state. - Compare later data by event ID and product family. Mark a field stable only when its value is equal in both saved snapshots.
- Draw one revision arrow per changed product; do not attach the top-level
updatedtime to every node. - Preserve the old and new observation times and label any unavailable historical detail as unavailable rather than reconstructed.
Publish a correction only when a meaningful value, product, or state changes; do not create a second event because a title or preferred product ID changes. A MyMap concept map is a practical way to keep the lanes and update clocks visible while drafting. The editable map is a workflow handoff, not evidence.
Practical next step and limitations
Before publishing or refreshing a breaking-news card, write one sentence for each displayed field: what question it answers, which product produced it, its review state, and when that product and the full record were observed. If the sentence turns an estimate into an outcome, remove or relabel the field.
Use the USGS detail URL for seismological and product facts, and the responsible local or tsunami-warning authority for safety instructions. Re-fetch immediately before publication. The practical rule is simple: preserve the event ID, every snapshot, and every product clock—not just the biggest number on the page.