Configuration model
===================

An mpylab application deliberately distributes configuration across several
formats:

.. list-table::
   :header-rows: 1
   :widths: 16 32 52

   * - Format
     - Purpose
     - Typical content
   * - Python ``conf.py``
     - Workflow configuration
     - Frequencies, filenames, name mapping, measurement and evaluation settings
   * - DOT
     - Device topology
     - Nodes, paths, conditions, and correction channels
   * - :doc:`INI <instrument-data>`
     - Device instance
     - Driver, bus parameters, channels, limits, and data references
   * - :doc:`DAT <instrument-data>`
     - Frequency-dependent measured data
     - Path loss, antenna factor, gain, and uncertainty
   * - TOML
     - Profiles and tool configuration
     - Reports, configuration inventory, and supplementary metadata

Search paths connect these layers. Resolve relative filenames against
explicitly documented search paths rather than accidentally against the
current working directory.

Direct entry points
-------------------

* :doc:`workflow` connects ``conf.py`` to input and output files.
* :doc:`dot` describes instrument topology and active signal paths.
* The :doc:`INI and DAT reference <instrument-data>` documents driver,
  channel, and correction data, including units and uncertainty.
* :doc:`validation` presents migration and checking tools to use before
  accessing hardware.

Conditions
----------

DOT conditions receive application values through an explicit mapping, for
example ``FREQUENCY -> frequency``. Looking up equally named variables in
outer Python frames is only a legacy fallback.

Validation
----------

Validate configurations before accessing hardware. Available tools include
DOT migration, graph validation, and NPORT checks. The following pages derive
their examples from the virtual configurations below ``script/conf``.

.. toctree::
   :maxdepth: 2

   workflow
   dot
   instrument-data
   validation