Good stuff and great to this see coming!

I would also like to see a schemaVersion attribute so that we can version this up for future updates. This would force having everything nested under a new field, for example:

{
    "schemaVersion": "1.0.0",
    "transformsData" : {
        "v2.0.0+2025.04.04" : { ...
        },
        "v1.3.1": { ...
        },
        "v1.3": { ...
        }, ...
    }
}

Not attached to transformsData, only given as an example!

Another minor annoyance I have is with the file field that is actually a url. Could it be something along the lines of transformUrl rather? At least people know that it should always be of url type.

LGTM!

Thinking about the equivalentTransformIds field - I think semantically we're thinking of it as a field for a transform saying "This transformId is equivalent to and supersedes any usage of the transforms in equivalentTransformIds".

So I think making this field only include transform IDs from releases previous (and maybe even some IDs we've spotted "in the wild" where an official ID should be used) lines up with that. One thing is that since all these things exist in a file that contains all the releases and the precedence of bidirectional linking inverseTransformId establishes, it could be quite confusing - especially for new people coming in when the URNs settle down a bit and this problem of multiple IDs for the same thing becomes less of an issue.

It might make sense to use a name that makes the semantic meaning a bit more explicit - something like supersededEquivalentTransformIds or deprecatedEquivalentTransformIds. Those convey a bit more that for that particular ACES version any of those transform IDs should be upgraded to transformID and can be done so without risk of impacting the color pipeline's integrity.