4.8 The inspection machinery

Everything above is internal machinery, and the inspection layer is more of it — the same engine made queryable, with zero new public C++/Python symbols: one record of a space’s properties (ID, encoding, image state, chromaticities, transfer characteristic — singly or in batch), search over those same properties, the canonical interop-ID list as data, and resolution over an ImageSpec’s metadata (“what does this image resolve to, and why?”). Its only surface is a pair of experimental oiiotool diagnostics — --colorinfo and --colorspacesearch; a public inspection API is deferred until a demonstrated consumer arrives, and the internal record is shaped so promotion would be additive.

The shape matters more than the size: the machinery reports what the engine concluded and how confident it is (declared vs. computed vs. derived per field), and it never returns a guess dressed as an answer — a search with no honest match is empty, and an unresolvable spec says so. In the demo, ColorConfig.derive_info() returns a ColorSpaceInfo record with per-field status, the pure-Python sketch of that contract.

The same engine is also exposed over HTTP in a single file — see resolution as a service.

TipRun it
just edit 08                                          # from a checkout
uvx marimo run --sandbox notebooks/08_api_bundle.py

Or straight from GitHub, nothing cloned:

uvx marimo run --sandbox https://raw.githubusercontent.com/zachlewis/color_interop_demo/main/notebooks/08_api_bundle.py