Core concepts
A consumer that wants to use another system has several questions to settle. What does the operation mean? What does its interface look like in memory? How long can the consumer keep it? Trying to answer all of those through one universal type model tends to make every new participant part of everybody else's problem.
TTX separates the work into three layers:
| Layer | Responsibility |
|---|---|
| Data | Concrete descriptions, canonical representations, storage and access protocols |
| Semantic | Contract identity, support and binding, transport agreement and explicit ownership |
| Concept | Abstract questions, policy and substitution |
Data builds on Perimortem's low-level facilities. Semantic uses the concrete forms to negotiate interfaces, and Concept uses those interfaces to expose richer questions. The separation lets a participant contribute at the level it needs.
Describing the data
An owner authors a Schema containing the primitives, structure, repetitions, pointers and callable signatures it wants to expose. Compilation publishes a canonical Representation that consumers can compare and traverse without retaining those schema objects. Storage supplies bytes conforming to the representation.
Normalization removes irrelevant differences in how the owner constructed its description. Three adjacent U8 fields can agree with a repeated U8 description when their admitted geometry and other format facts match. Structural boundaries, primitive identity, byte order and calling facts remain where they affect the agreement. Comparing canonical descriptor bytes can then establish the format without another walk of the producer's source objects.
The comparison concerns the description. It doesn't make payloads equal, and it
doesn't make padding byte values canonical merely because their positions are
known. Compilation can happen at runtime or through the C++ Compiled<schema>
owner during constant evaluation; both publish the same consumer form.
Asking for an interface
A Query is the bootstrap surface that a provider has already made available. Its owner establishes the initial callable interface and lifetime, giving the consumer somewhere to send its first UUID request.
supports(UUID) asks whether the provider accepts a semantic contract. It supplies
no operation table. bind(UUID, requested Storage) also asks the provider to
establish the complete API representation and populate the caller's storage with
the resulting record.
These questions can have different answers. A provider might recognize an operation while disagreeing with the caller's description of its arguments. Supports can succeed in that case, while binding rejects the incompatible API. A consumer that intends to use the operations can bind directly without a separate support query.
The UUID identifies the contract's meaning. A receiver pointer remains a borrowed address under the supplying lifetime, rather than a durable identity across processes or permission to inspect private state.
Establishing data access
Flow negotiates a common access protocol and retains the selected interfaces and usable state. It tries the protocols in this order:
| Protocol | Agreement |
|---|---|
| Direct | A compatible pointer remains usable under the publication's stable lifetime |
| Shared | A compatible pointer is acquired and released under an explicit lifetime agreement |
| Block | The provider fills caller-supplied storage as a whole operation |
| Fragment | The consumer requests individual typed values at ABI coordinates |
The preferences reflect the guarantees available, not an implementation hierarchy. Direct support says nothing about whether Fragment is also offered. Unsupported or incompatible candidates can permit another attempt during negotiation; Pending or Rejected bindings stop it. An operation failure after selection remains a failure of the selected agreement.
Copy uses the Flow to create a concrete observation in supplied Storage. Swizzle adds an admitted mapping for its output arrangement. A policy can resolve names or decide which conversion is meaningful before formulating that operation. The lower transport layer can then carry it out without learning what a color channel or an assignable variable means.
Exposing a conceptual question
An Abstract supplies observations, binding, resolution and concept navigation. A C++ object, a C module or a script adapter can answer through that surface while keeping its own implementation. The questions are owned by the provider rather than fields reserved in a universal node.
A policy can contribute an answer, restrict a capability or delegate a question. Consumers keep asking the policy they encountered, since resolving past it could remove the very restriction that made the observation meaningful. An Alias expresses transparent forwarding, which is a different relationship.
Concept also needs to distinguish completed absence from an unsettled answer. None establishes absence, Unknown preserves uncertainty, and Constant supplies an explicit invariance promise. Those are conceptual facts. Binding's Satisfied, Unsupported, Pending and Rejected statuses describe the negotiation operation. A successful query may quite legitimately return None or Unknown.
Neither Unknown nor Pending describes an async completion mechanism. The base operations are synchronous, leaving a contract that needs callbacks or futures to state their scheduling and ownership separately.
A simulacrum supplies an agreed surface in place of another implementation. It needs to preserve the observations promised by that agreement, without copying the original's private class hierarchy. The image providers give us a concrete example of that relationship.
Applying it to Source and execution
Tetrodotoxin's source tooling builds on these interfaces. A selected tokenizer interprets a Source observation and publishes tokens. A Cursor carries a local position and access to that provider, so copying one can fork traversal while keeping the same underlying source observations.
A Dialect executes a range of the command stream and publishes the retained result of its invocation as a Monograph. Monographs can contain or forward other Monographs. They don't have to be file roots or share one allocation domain.
The Library dialect adds authored Source policies to Type and Execution models. A Shader or App implementation can consume those model contracts without adopting Library's parser. A Terminal uses the facts it understands to emit a result with its own lifetime. The Godot class bridge and native code emission both exercise use after the discovery graph has been released.
Conceptual Layout and Pack describe higher-order value organization. Their fitting and language behavior are part of the model work; Data's Schema, Representation and Storage describe the concrete transfer. Keeping the names and responsibilities distinct helps avoid putting a second semantic compiler in the data engine.
Following the contracts in code
The Godot walkthrough connects those pieces in a running application.