euromod_linking.registry
========================

.. py:module:: euromod_linking.registry

.. autoapi-nested-parse::

   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.

   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.



Exceptions
----------

.. autoapisummary::

   euromod_linking.registry.MethodLookupError


Classes
-------

.. autoapisummary::

   euromod_linking.registry.MethodSpec


Functions
---------

.. autoapisummary::

   euromod_linking.registry.available_names
   euromod_linking.registry.code_fingerprint
   euromod_linking.registry.list_specs
   euromod_linking.registry.register
   euromod_linking.registry.resolve
   euromod_linking.registry.resolve_for_channels


Module Contents
---------------

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



   Mapping key not found.


   .. py:attribute:: available


.. py:class:: 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.


   .. py:attribute:: addon_requirements
      :type:  tuple


   .. py:attribute:: cell_variables
      :type:  str


   .. py:attribute:: channels_consumed
      :type:  tuple[str, ...]


   .. py:attribute:: dataset_requirements
      :type:  tuple[str, ...]


   .. py:attribute:: description
      :type:  str


   .. py:attribute:: factory
      :type:  Callable
      :value: None



   .. py:attribute:: injected_columns
      :type:  tuple[str, ...]


   .. py:attribute:: metrics_consumed
      :type:  tuple[str, ...]


   .. py:attribute:: min_model_release
      :type:  str | None
      :value: None



   .. py:attribute:: name
      :type:  str


   .. py:attribute:: params_schema
      :type:  dict


   .. py:attribute:: restructures_rows
      :type:  bool
      :value: False



   .. py:attribute:: summary
      :type:  str


.. py:function:: available_names() -> list[str]

.. py:function:: 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.


.. py:function:: list_specs() -> list[MethodSpec]

.. py:function:: register(spec: MethodSpec) -> MethodSpec

.. py:function:: resolve(name: str) -> MethodSpec

   The method registered under `name`.


.. py:function:: resolve_for_channels(channels: set[str], metrics: set[str]) -> MethodSpec

   Dispatch: the unique registered methodology covering the given shock
   channels (and 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.