Substitution and its limits

If two implementations answer the same questions in the same way, how much do we need to know about the difference between them?

For a particular contract, often very little. A consumer asking for convolution needs the operation and its promised behavior. It doesn't need the provider's original class hierarchy or algorithm. TTX calls the substitute a simulacrum: an implementation that can stand in for another through the agreed surface.

The scope of that agreement does a lot of work. Substituting one image operation is manageable. Substituting everything a game engine can do is a rather different project, even if both begin with the same kind of interface.

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. Together, those facts let us make the call through an established interface.

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 behavioral tests are part of making the substitution credible.

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

The longer-term engine experiment would expose a useful part of one engine's surface and implement it through another. A Unity-facing contract could be backed by a Godot adapter, for example. Code on the consuming side would encounter the surface it understands while the provider arranged the work elsewhere.

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.

That suggests a practical progression: choose one useful capability, describe its observable behavior, implement it on both sides, and see what the replacement exposes. The current Godot image and class examples are small enough to review while still forcing us to deal with real ownership, refusal and engine adaptation.

Keeping the substitute honest

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 same discipline limits what we can claim from the lab. We have working 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. Otherwise the larger interface just gives us more ways to make an incompatible call.

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