On this page
Start with dimensions, rank, and variable identity
Create one worksheet row per variable. Record group path, variable name, data type, rank, dimension names in order, declared shape, and whether dimensions are fixed or unlimited. The cited convention says the dimensions of a variable must have different names and recommends an order for time, vertical, latitude, and longitude dimensions where those axes exist Climate and Forecast Metadata Conventions, (opens in a new tab). Treat a dimension name as structure, not as proof that its values are complete or physically meaningful.
| Field | Record | Stop if |
|---|---|---|
| Variable path | Group and variable name | Same name resolves to multiple paths |
| Data type | Stored type and signedness where relevant | Reader coerces type without a record |
| Dimensions | Ordered names and lengths | Names repeat or length is unavailable |
| Coordinate links | Coordinates attribute and coordinate variables | Referenced variable is absent |
| Axis role | Declared axis or unresolved | Name alone is treated as an axis claim |
| Coverage | Known range, source, and exclusions | Shape is mistaken for coverage |
Use a synthetic variable with dimensions such as time, lat, and lon to exercise the worksheet. Do not expose a real coordinate or event just to demonstrate rank. If a dimension is shared by many variables, retain that relationship because it is part of the file’s data model.
Compare coordinate variables with their dimensions
A coordinate variable is a one-dimensional variable whose name is the same as its dimension name. Auxiliary coordinates can be listed through metadata. The Climate and Forecast Metadata Conventions, (opens in a new tab) convention makes these relationships explicit, but an axis label or standard_name is still metadata evidence rather than a guarantee that values were generated correctly.
| Comparison | Safe observation | Open question |
|---|---|---|
| Dimension and coordinate length | Equal declared length | Are all values present? |
| Coordinate units | Units attribute present or unknown | Are units compatible with the intended axis? |
| Latitude or longitude order | Dimension order recorded | Did a reader reorder axes? |
| Bounds variable | Bounds attribute and target shape | Do bounds cover each coordinate cell? |
| Auxiliary coordinates | Names resolved to variables | Why are they auxiliary rather than coordinate variables? |
| Monotonicity | Observed increasing, decreasing, mixed, or unavailable | Is monotonicity required by the consumer? |
Synthetic variable metadata
{
"variable": "fixture_temperature",
"dimensions": ["time", "lat", "lon"],
"coordinates": ["time", "lat", "lon"],
"units": "fixture-units",
"calendar": "unknown",
"state": "structure only"
}This fixture records a shape and references, but it does not claim that the values represent a particular phenomenon. Keep a missing coordinate variable, a duplicate dimension name, and an unexpected order as separate findings.
Treat time units and calendars as one contract
A numeric time coordinate is not self-describing. Record the exact units string, reference date, timezone marker if present, calendar, and any bounds variable. A reader may have a default calendar, but a default is not evidence that the producer intended it. Preserve the source string before normalization so a later reviewer can distinguish parsing from a business or scientific interpretation.
| Time field | Record | Stop if |
|---|---|---|
| Units | Exact string such as a duration since reference | Reference date is missing or ambiguous |
| Calendar | Declared name or unknown | Reader default is the only evidence |
| Reference | Reference timestamp and timezone context | Local and UTC assumptions are mixed |
| Bounds | Variable, shape, and units | Bounds use a different basis |
| Ordering | Increasing, decreasing, duplicate, or unavailable | Duplicate values are collapsed |
| Conversion | Formula and reader version | Converted values replace the source |
Do not convert dates to a familiar calendar and discard the original numeric coordinate. A conversion can be useful for a derivative report, but the original units and calendar remain required evidence. Keep time ordering separate from event ordering, which may require a source-system sequence or provenance log.
Check fill values, packing, and valid ranges together
The Unidata, (opens in a new tab) documentation distinguishes _FillValue from missing_value, explains type matching, and notes that packed data keeps sentinel and range attributes in the stored domain. Record each attribute’s type and value, then state whether the variable is packed with scale_factor and add_offset. Never replace a sentinel with zero or a blank without recording the transformation.
| Check | Worksheet observation | Interpretation boundary |
|---|---|---|
| _FillValue | Present, absent, type, exact value | Default behavior is not a producer statement |
| missing_value | Scalar or vector, type, exact value | Application-specific use may differ |
| valid_range | Attribute and stored type | Range is not a quality score |
| scale_factor | Stored and intended domains | Do not compare sentinel after scaling |
| add_offset | Stored and intended domains | Do not overwrite packed evidence |
| Actual range | Declared or computed with method | Computed sample is not full coverage |
Stop conditions
- Stop if dimension names repeat, coordinate references are unresolved, or declared lengths disagree.
- Stop if time units, reference date, or calendar are missing or conflict with the intended conversion.
- Stop if
_FillValue,missing_value, valid ranges, or packed types do not match the stored domain. - Stop if a reader default or computed range is being used as a substitute for producer metadata.
- Stop before interpreting scientific values when source, coverage, or handling authority is unknown.
Close with an evidence packet and a qualified next step
Keep the variable worksheet, source metadata, reader/version, conversion notes, and unresolved questions together. Pair this guide with the data provenance log for source and transformation history and the data card template for collection context. CF conformance can make metadata more legible; it does not establish accuracy, completeness, privacy clearance, or rights.
For a supported non-health collection, after the owner has authority to describe the scope and a controlled metadata packet, the qualified appraisal request path may be a preparation step. It does not read netCDF files, choose calendars, interpret scientific variables, create a quote, match a buyer, issue a legal opinion, or grant a license.
Takeaways
- Record dimensions and coordinate references in order, including unresolved links.
- Keep the exact time units and calendar beside any derived timestamp.
- Compare fill, missing, valid-range, and packing attributes in the stored domain.
- Use synthetic metadata fixtures and stop when reader defaults replace source evidence.