Substitution and its limits

A consumer asking for convolution relies on the promised pixel behavior, result lifetime and failure rules. Another implementation can replace the original if it fulfills those requirements through a compatible interface. TTX calls that substitute a simulacrum.

An image-operation contract covers a particular computation. Replacing a game engine also requires agreement about lifecycle, events, resources and threading.

What has to agree?

The UUID identifies the intended meaning, and the canonical Representation describes the concrete API through which we can use it. The provider also has to supply the lifetime promised by that contract.

Behavior still needs its own evidence. A callable description can tell us how to pass the convolution arguments; it cannot tell us whether the implementation uses the agreed boundary conditions. Likewise, a release function's presence doesn't prove it releases the right resources.

The provider can perform quite different work behind that boundary. It might call a native library, enter a script runtime or send a request to another process. The synchronous interface still has to be fulfilled as promised. If an application wants futures, callbacks, retries or cancellation, those policies need an agreement of their own rather than being guessed from the receiver's implementation.

Taking the idea into an engine

A Unity-facing contract could be backed by a Godot adapter. Consuming code would call that interface while Godot supplied the implementation.

Method signatures are only the beginning of that exercise. An object might have to enter a scene tree before a callback is valid. A resource might belong to a particular thread. Event ordering, identity, physics behavior and error handling can all become observable parts of the promise. A bridge that gets the method names right but changes those rules will fail in ways that are difficult to explain from the signature alone.

Behavior required of a substitute

A consumer may know about an optimized native route, but it still needs the negotiated route when the implementation is unfamiliar. Otherwise the first substitution turns the optimization into a hidden requirement and we are back to sharing private types across the boundary.

The lab supplies image and compute providers, and a class bridge that emits registrations and retained runtime interfaces from declarations. Running arbitrary GDScript or Unity projects through interchangeable engines would require many more contracts and behavioral tests. Each extension has to establish another observable promise, such as when an instance is released or which thread may invoke its operations.

The lab shows the implemented case. The project directions describe where else this approach could be tested.