euromod_linking.registry

Method registry — the named linkage methodologies.

A method is a reviewed implementation that turns external-model shocks (the canonical shock table) into a transformed EUROMOD input DataFrame plus run parameters. Methodology lives in code; a scenario can only select a method and supply scenario-semantics params validated against the method’s own params_schema.

Each method consumes one kind of shock — a channel — and dispatch is per channel: a shock table carrying several channels is handled by several methods, one each, run in stage order. A method’s stage says what kind of transformation it is, and that is what fixes the order when methods share a scenario. There is no method for a combination of channels; the combination is a property of the scenario, and the scenario engine composes the methods.

Methods carry no version number. What guards against an edit to the modelling silently serving results computed by earlier code is code_fingerprint, which hashes a method’s own source into the scenario fingerprint — a content-derived identity that cannot be forgotten the way a hand-maintained version integer can.

Attributes

STAGE_PEOPLE
STAGE_VALUES
STAGE_WEIGHTS

Exceptions

MethodLookupError

Mapping key not found.

Classes

MethodSpec

A methodology's published contract: what it consumes, what it needs, and

Functions

available_names(→ list[str])
code_fingerprint(→ str)	Content hash of the methodology's own source.
list_specs(→ list[MethodSpec])
pipeline(→ list[MethodSpec])	The given methods in the order they run: by stage, then name; each once.
pipeline_fingerprint(→ str)	One fingerprint for every method a run uses, in run order.
pipeline_name(→ str)	The reference for a run's methods: scale_variables+lma_labour_alignment.
register(→ MethodSpec)
resolve(→ MethodSpec)	The method registered under name.
resolve_for_channel() → MethodSpec)	Dispatch for one channel: the unique registered methodology consuming it
resolve_for_channels(→ list[MethodSpec])	Dispatch for a whole shock table: {channel: metrics} -> the methods
resolve_pipeline(→ list[MethodSpec])	The methods a scenario's methodology pin names, in run order.

Module Contents

exception euromod_linking.registry.MethodLookupError(message: str, available: list[str])

Mapping key not found.

available

class euromod_linking.registry.MethodSpec

A methodology’s published contract: what it consumes, what it needs, and what it does to the input.

name is how a methodology is referred to everywhere else — in dispatch, in a scenario’s methodology pin, and in results.

addon_requirements: tuple

cell_variables: str

channels_consumed: tuple[str, ...]

dataset_requirements: tuple[str, ...]

description: str

factory: Callable = None

injected_columns: tuple[str, ...]

metrics_consumed: tuple[str, ...]

min_model_release: str | None = None

name: str

params_schema: dict

preview_by_applying: bool = False

restructures_rows: bool = False

stage: int = 10

summary: str

euromod_linking.registry.available_names() → list[str]

euromod_linking.registry.code_fingerprint(spec: MethodSpec) → str

Content hash of the methodology’s own source.

Results are cached on the scenario fingerprint, but a scenario document does not change when the methodology does — so without this, editing a method’s modelling silently serves results computed by the earlier code. Hashing the implementation makes any code change invalidate its cached runs, the same content-addressed discipline used for shock tables and scores. Empty string if the source cannot be read, which leaves caching keyed on the methodology name alone.

euromod_linking.registry.list_specs() → list[MethodSpec]

euromod_linking.registry.pipeline(specs: Iterable[MethodSpec]) → list[MethodSpec]

The given methods in the order they run: by stage, then name; each once.

Refuses two methods claiming one channel — a scenario in which the same shock would be applied twice, or in which which of them applies depends on iteration order.

euromod_linking.registry.pipeline_fingerprint(specs: Iterable[MethodSpec]) → str

One fingerprint for every method a run uses, in run order.

The order is part of what a run does, so it is part of the hash: the same two methods in the other order would be a different transformation. Empty when there are no methods (a constants-only scenario).

euromod_linking.registry.pipeline_name(specs: Iterable[MethodSpec]) → str

The reference for a run’s methods: scale_variables+lma_labour_alignment.

In run order, so the name says what happened first. Accepted back as a pin.

euromod_linking.registry.register(spec: MethodSpec) → MethodSpec

euromod_linking.registry.resolve(name: str) → MethodSpec

The method registered under name.

euromod_linking.registry.resolve_for_channel(channel: str, metrics: set[str] = frozenset()) → MethodSpec

Dispatch for one channel: the unique registered methodology consuming it (and these metrics, where the spec constrains them).

Users never select a methodology — it is resolved from the shocks and echoed in the response; an explicit scenario pin exists only for reproduction and for the day two methodologies claim the same channel.

euromod_linking.registry.resolve_for_channels(channels_metrics: dict[str, set[str]]) → list[MethodSpec]

Dispatch for a whole shock table: {channel: metrics} -> the methods that handle it, one per channel, in the order they run.

Each channel dispatches on its own, so a mistyped metric on one channel is refused here, by name, whatever else the table carries.

euromod_linking.registry.resolve_pipeline(reference: str) → list[MethodSpec]

The methods a scenario’s methodology pin names, in run order.

A pin is a single name, or several joined with + — the form pipeline_name produces and results echo, so a pinned reproduction can be pasted back from an earlier response.

euromod_linking.registry.STAGE_PEOPLE = 20

euromod_linking.registry.STAGE_VALUES = 10

euromod_linking.registry.STAGE_WEIGHTS = 30