Skip to article frontmatterSkip to article content
Site not loading correctly?

This may be due to an incorrect BASE_URL configuration. See the MyST Documentation for reference.

🖥️ Lecture slides — Session 27 (Fri Dec 4)

One result, N audiences. The discipline is deciding what changes between versions — and proving that what didn’t change is the truth of the claim.

What changes between audiences

Four audiences cover most of what a geoscientist meets. What varies between them is not “how smart they are” (never write down to anyone); it is what they already assume, what they will do with the information, and what kind of uncertainty statement they can act on.

AudienceVocabularyWhat you can assumeWhat to foregroundUncertainty framing
Domain peers (e.g., seismologists)Full technicalMethods, benchmarks, data quirksWhat is new relative to the state of the art; where it failsFull: metrics, confidence intervals, ablations
Adjacent-field scientist (e.g., civil engineer)Technical, but your jargon translated to theirsGeneral quantitative literacy; different benchmarks and normsThe quantity their models consume; the operating range where yours is validQuantified, in their units and conventions
Funder / policymakerPlain, numerateCost-benefit reasoning; no field backgroundThe decision this enables; the cost of the status quo; readiness levelRanges and scenarios; what would change the conclusion
Public / residentsPlain, concreteLived experience of the hazard; no formal backgroundWhat it means for them; what to do; what stays the sameHonest but not paralyzing: likelihoods in natural frequencies, actions that are valid either way

An earthquake early warning result illustrates why one summary cannot serve them all. To a seismologist, it is a detection-latency and magnitude-estimation problem. To a civil engineer, it is a number of seconds of warning at a given site, and whether that is enough to trip an automatic shutoff. To an emergency manager, it is a false-alarm rate they will answer for publicly. To a resident, it is whether the phone alert deserves attention. Same system, four different claims.

Worked example: one finding, four ways

The technical finding, exactly as it would appear in a report:

Our detector recovers 92% of M>2 events at 1 false alarm per day; recall drops to 60% below SNR 3.

For domain peers (stays close to the original; adds context peers will demand):

At an operating point of 1 false alarm/day, the detector recovers 92% of catalog M>2 events, a 15-point recall gain over the STA/LTA baseline at matched false-alarm rate. Recall degrades to 60% below SNR 3, i.e., most of the missed events are the small, noisy ones any picker misses; we have not evaluated below M1.5.

Why these choices: peers do not need “recall” explained; they need the baseline comparison and the failure regime, because their first two questions are “better than what?” and “where does it break?” The claim itself is untouched.

For an adjacent-field scientist (a hazard modeler or engineer):

The automated catalog is 92% complete for events above magnitude 2 under normal noise conditions, with roughly one spurious detection per day. Completeness falls to about 60% for the smallest, noisiest events, so the catalog underestimates rates near its magnitude floor — if you fit recurrence parameters to it, the magnitude of completeness should be treated as ~2, not lower.

Why these choices: “recall” became “completeness” — the analogous quantity in the neighbor’s field — and the consequence for their calculation (biased rate estimates) is stated explicitly, because they will not derive it from your metric. This is a claim translation: the scope (“above M2, normal noise”) travels with the number.

For a funder or policymaker:

The system now catches 9 out of 10 earthquakes above magnitude 2 automatically, with about one false alert a day for an analyst to dismiss — a workload one person can absorb. It misses mostly the smallest events during noisy periods. This is research-grade: reliable enough to build catalogs, not yet reliable enough to trigger public alerts without human review, and the next step (evaluation on two more networks, ~1 year) addresses precisely that gap.

Why these choices: the metrics became operational quantities (analyst workload, review requirement), and readiness is stated in terms of the decision at stake — funders are deciding what to pay for next, so the honest gap and its price are the payload, not a weakness to hide.

For the public:

Our software now spots most of the small earthquakes that people don’t feel — about 9 in 10 above magnitude 2. Tracking these small quakes helps scientists map which faults are active. It does not predict earthquakes, and it doesn’t change what you should do: quakes too small to feel are also too small to matter for your safety.

Why these choices: the false-alarm rate is gone — it is meaningless without the operational context — and two sentences preempt the two predictable misreadings (“they can predict earthquakes,” “should I worry?”). What the public needs foregrounded is what the result does not mean.

The common failure: jargon translation vs. claim translation

The failure mode to train yourself out of: swapping technical words for plain ones while silently broadening the claim. Compare, for the funder version:

✗ “Our AI detects 92% of earthquakes.”

Every word is plain; the claim is now false three ways: 92% was measured above M2, at a chosen false-alarm rate, on one network’s data. Jargon translation replaces vocabulary; claim translation re-scopes the statement so its truth conditions survive in the new vocabulary. “9 out of 10 earthquakes above magnitude 2” is exactly as plain and still true. The test for any translated sentence: could you defend it, standing alone, to the most skeptical member of that audience? If the qualifier is what makes it true, the qualifier stays — in whatever words the audience can carry.

The nearest audience is the hardest: adjacent subfields

Geoscience is a federation of subcultures — seismology, glaciology, hydrology, atmospheric science, geochemistry — that differ in vocabulary, in norms of evidence, and in open-science defaults (seismology shares waveforms through standardized services and expects it; other communities treat data as proprietary until publication; “model validation” means different procedures in each). Translation across a subfield boundary fails more often than translation to the public, because both sides assume shared conventions that are not shared.

A protocol that works, one afternoon per boundary. For each core concept in your result, find in the neighbor field:

  1. The analogous quantity. Your “recall at fixed false-alarm rate” is a hydrologist’s “probability of detection vs. false alarm ratio” (they verify forecasts with POD/FAR); your magnitude of completeness is a glaciologist’s minimum detectable calving event. Use their term and cite their canonical reference for it.
  2. The analogous benchmark. Every field has its “beat this or nobody cares”: persistence forecasts in hydrology and climate, STA/LTA in seismic detection, degree-day models in glaciology. State your improvement relative to the neighbor’s baseline or expect the result to be discounted.
  3. The analogous failure mode. Your “low SNR” is their “ungauged basin” or their “polar night data gap” — the regime where methods degrade and everyone knows it. Naming their hard regime, and stating honestly how your method behaves in its equivalent, is the fastest trust-building move available.

If you cannot fill all three rows, you do not yet understand the neighboring field well enough to collaborate with it — which is worth discovering before the kickoff meeting, not after.

Exercise: AI-assisted translation with a verification pass

Done outside CI, with the AI assistant of your choice; disclose per Chapter 6.4. This exercise is the rehearsal for the audience-translation deliverable in the final project.

  1. Take one quantitative finding from your project (or use the detector finding above). Write the technical version yourself, with every qualifier that makes it true.
  2. Ask an AI assistant to draft the four audience versions. Iterate on the drafting freely — this part is cheap.
  3. Now the graded part, the verification pass. List every claim in each draft. Mark each one:
    • preserved — same truth conditions as the technical version;
    • weakened — vaguer but still entailed by the technical version (acceptable, note it);
    • broken — asserts something the technical version does not support.
  4. Fix every broken claim, then submit: technical version, four drafts (final), and the verification table including what you fixed.

You will find broken claims. Models drop qualifiers under simplification pressure for the same reason hasty humans do: the sentence reads better without them.