Terminology

How to read the curated output of a processor run: the objects, how a variable’s identity is decided, and the fields that give it meaning.

Core objects

VariableStatVar: One curated statistical concept — e.g. “homicides, males 15–29”. Its meaning is fixed by its metadata (population, measured property, constraints…), never by its human-readable label.
GroupStatVarGroup: A theme node that organises variables into a browsable hierarchy — e.g. Economy → Exchange rate → …. The tree on the left of the explorer is built from these.
DCID: The variable’s stable identifier in the Data Commons graph. Curation records identity scope explicitly; namespace shape is retained as a consistency check.

Decision revision

The short hash beside a run identifies the exact canonical human decision catalog used to produce it. Saving a decision creates a new catalog revision and then a new immutable processor run; generated curation and Data Commons artifacts are never edited in place.

Identity scope — where a variable can be reused

Every emitted source-series mapping records one explicit scope. When evidence is insufficient, a narrower identity is preferred over a confident but wrong merge.

Global reuse Count_Person

The source series maps to a shared Data Commons concept after exact, property-by-property equivalence was established. Other sources and countries can reuse the same identity.

Brazil-local br/Amount_EconomicActivity_…

A curated Brazilian identity intended for reuse here, but not asserted to be globally equivalent. This avoids a false merge while preserving a semantic model.

Source-scoped br/source/ipea/<code>

The source code remains the identity because equivalence has not been established. This is a safe identity boundary that still preserves a semantic model.

Initial model origin

Origin records where the model started. It does not imply anything about current quality.

Human: Authored manually without a machine proposal.
LLM: Started as an LLM proposal; grounding remains a separate fact from origin.
Heuristic: Started from the rule fallback when no acceptable LLM proposal was available.

Output outcome

No-output records are split so expected omissions never hide processor failures.

Emitted: Produced one or more StatVar outputs and observation artifacts.
Expected no output: No output is correct, such as empty input or a place attribute rather than an observation.
Review-excluded: A curator deliberately excluded the series with a recorded reason.
Failed: The processor unexpectedly omitted a non-empty series or hit another actionable error.

Metadata that defines meaning

populationType: What is being observed — Person, MortalityEvent, EconomicActivity, Household…
measuredProperty: The property measured on that population — count, amount, income, area…
statType: The kind of statistic — measuredValue, meanValue, medianValue, growthRate…
measurementQualifier: A modifier on the measurement — Nominal, RealValue, Adjusted…
constraints: Properties that narrow the population — e.g. gender = Female, age = Years15To29. Two variables with the same population but different constraints are different concepts.

The generated data

Entity type: The subject level each observation is about — Country, AdministrativeArea1 (state), AdministrativeArea2 (municipality), BrazilianRegion, and a few local subject nodes.
Provenance: Origin attribution of the observations — provider → dataset → source series (e.g. “BCB — Boletim / BP — série BM12_CFCC12”).
Observation: A single (entity, date, value) data point, with its unit, observation period and measurement method. These are the generated data the metadata describes.
Obs files: The generated per-series CSVs that carry a variable’s observations — one variable per file, split by entity level.