3. Anatomy of the system
One picture of who feeds whom. The left column is the surface — the path a file’s metadata actually travels. The right column is the engine — internal machinery with no new public API of its own, exposed only through the small inspection and search surface at the bottom (in the real build, the experimental oiiotool --colorinfo / --colorspacesearch diagnostics).
Reading the arrows:
- The grammar parses every name and ID the priority list encounters — strict parsing is the list’s first tier.
- The registry (the built-in interop-identities config) supplies the published ID set to both identification and cross-config conversion.
- The cache underwrites everything: every process-global memo keys on OpenColorIO’s own config cacheID, so results are content-addressed and a config is immutable once constructed — any repair is a copy keyed by the source config’s ID.
- Transform-comparison identification probes what a space’s transforms actually do, through the interchange anchor, against the registry — and feeds two consumers: the priority list (evidence-based resolution on read) and the write planner (derived IDs on write).
- Cross-config conversion serves the harness whenever an operation names an ID the active config doesn’t contain.
- The write planner turns the verdict into per-format signs, and the harness keeps the verdict honest between read and write.
The same system lands upstream as one deliverable in six serial, individually reviewable steps:
