Skip to content
← Explainers

Explainer

Reading an Atlas Analysis

An entity atlas is a committed collection of descriptive entity cards, not a single score or a current feed.

An entity atlas is a published collection of entity-level records arranged so a reader can inspect the same committed measurements in several views. The atlas does not manufacture one universal ranking. It starts with the fields recorded for each entity, preserves the published units, and lets the reader select a field for a ranked list, scatter view, table, or distribution. The view changes the arrangement of the same measurements; it does not change what the fields mean.

The ranked view answers a narrow question: which published rows sort highest or lowest on the selected scalar field? That is useful for locating a record, but it is not a general quality judgment. A field such as median velocity and a field such as pitch share describe different things. Sorting a pitch-type share orders published usage frequency, while sorting velo_p50 orders the middle recorded velocity. The selected field, its unit, and its cohort determine the interpretation.

The scatter view places two selected scalar fields on separate axes. It can show whether the published rows occupy a broad cloud, a narrow band, or a small cluster. It cannot establish that one field causes the other. The table is the audit-friendly alternative: it displays each row's available scalar fields, retains unavailable values as unavailable, and allows a reader to compare exact values. The distribution view shows the selected cohort spread and percentile ranks for the selected field. A percentile rank is within that field's available cohort, not a cross-field score.

The MLB pitch atlas illustrates the distinction. Its committed manifest contains 61 entries from a 2025 pull: 19 pitch types, 30 teams, and 12 count states. Each entry can carry scalar fields such as n_pitches, pct_of_all_pitches, and velocity percentiles, plus nested objects for count-state and outcome mixes. The derived atlas analysis intentionally ranks only finite scalar key_numbers fields. Nested objects remain on the entity card rather than being flattened into a misleading single measurement. This is a design choice that keeps a card's structured context intact.

Consider the pitch type CS. The manifest records 393 pitches, a median velocity of 72.4 mph, and pct_of_all_pitches of 0.06. That last field is already expressed as a percentage. The atlas field definition marks it as an already-percent value, so the analysis normalizes it for percent display without multiplying its meaning. The displayed result remains 0.06%, not 6% and not 0.0006%. Moving the decimal would turn a published frequency into a different measurement. The card and analysis preserve the source unit exactly.

Identifiers require similar care. pitch_type:CS is an identifier: it names the row. It is not a numerical measurement, so the atlas does not place it in the numeric cohort, assign it a percentile, or draw it as an axis value. Labels, card paths, and as-of dates identify provenance and navigation. They are vital context, but they are not competing measurements. Separating identifiers from scalars prevents a technically sortable field from being treated as an analytic one.

A percentile rank is therefore field-specific. If a reader selects n_pitches, the rank answers where a pitch type sits among available pitch-type rows by recorded count. If the reader then switches to velo_p50, the cohort is still the atlas's available pitch types, but the ordered variable has changed. One rank cannot be carried from the first field to the second. Missing or non-finite entries should remain outside the applicable numeric comparison rather than receiving an invented low rank.

The atlas also retains source floors and caveats. The MLB pitch manifest states that all 19 pitch-type codes in the 2025 pull are included and identifies the smallest category as n=7. That broad inclusion supports completeness of the manifest, not certainty that every small category is equally stable. A row with a small count can be displayed for completeness while still requiring cautious comparison. The field view and the source note belong together.

Read an atlas by choosing one concrete question. Select the relevant field, inspect its unit, then read the ranked, scatter, table, or distribution view as an arrangement of that field's published cohort. Open the entity card for nested measurements and the recorded floor. The result is a reproducible descriptive comparison, not a shortcut from an identifier to a conclusion.

Inspect the worked example

Open the MLB pitch type atlas analysis

Where to go next

Sources

webapp/public/data/showcase/atlas_mlb_pitch_manifest.json -> generated_at, entries[]webapp/public/data/showcase/atlas_mlb_pitch_manifest.json -> entries[1].entity, key_numbers.n_pitches, key_numbers.pct_of_all_pitches, key_numbers.velo_p50, floors, as_ofwebapp/lib/analytics/researchAtlasPacks.ts -> scalarKeys, displayedValue, buildAtlasResearch

Next explainer
Calculation Inputs: How a Derived Row Is Reproduced →