Lifetime and publication

An interface can be perfectly described and still fail because we kept it longer than its provider. A copied function pointer is an especially convincing trap: the bits are still there after the module containing the function has gone away. The operation needed to release the receiver may have disappeared with it.

That is why ownership has to be part of the agreement. TTX doesn't require a script runtime, a native Arena and a GPU context to manage storage in the same way. It does require the caller to know what keeps an observed interface usable.

What a publication keeps alive

Abstract and Query are borrowed interfaces. Keeping their records doesn't retain the objects or executable code behind them. A Publication carries a provider lifetime together with its Query and release operation, so a consumer can retain the supplying owner while using the interfaces it exposes.

The release operation stays with the provider because that is where the private ownership model is understood. The caller shouldn't have to discover whether the result contains a C allocation, a script reference or a set of child publications before it can clean up correctly.

Executable-code lifetime is related, but it is a separate obligation. The module must remain available until every operation that depends on its code has finished, including destruction. Releasing the discovery graph doesn't necessarily mean we are finished with the module.

Emitting something that outlives discovery

The Godot class bridge makes the distinction concrete. During discovery, it inspects declarations, checks the callable surface and copies the metadata Godot will need. It also acquires an independent runtime factory. Once preparation has succeeded, the declaration graph can be released while the factory and its code remain available.

Creating an instance then uses that factory, and repeated method calls use the retained runtime interfaces. They don't have to revisit the Abstract tree that originally described the class. Instance state is released before the factory or module it needs for destruction.

A terminal emitting native code has a similar question to answer. Which facts must be copied into the result, and which implementation lifetimes must be retained? The answer depends on the product. The important part is making it explicit rather than letting a borrowed discovery pointer quietly become a runtime dependency.

Composing invocations and observations

A Monograph can own several child publications from nested dialect invocations. Its policy decides how their results are exposed, and its release path disposes of the children before the state that supports them. If an invocation simply forwards a child's result, it can transfer that Publication without adding another owner around the same obligation.

Data access has its own lifetime distinctions. Direct relies on an already stable publication. Shared acquires and releases a usable pointer. Block fills a supplied destination for one operation, and Fragment observes values individually. These are separate promises, so failure after choosing one cannot silently substitute a different access model.

Native deployment can add less obvious dependencies. In the current C++ fixtures, a private allocator's thread-local finalizers can keep a provider library loaded until the thread exits. Using the shared TTX runtime avoids that particular coupling. It doesn't make Perimortem a requirement for foreign providers; it is a choice about where the native implementation's runtime state belongs.

The Publication and Module contracts describe those boundaries. Their useful tests release discovery, keep using the emitted result, and check the eventual destruction order. That is where an ownership diagram has to become working behavior.