Development and review
A useful change usually starts with something another participant needs to do. A renderer needs an image operation, a terminal needs an execution fact, or a dialect needs a way to retain the result of a nested invocation. Working from that concrete relationship makes it easier to decide who should own the behavior and what actually needs to cross the interface.
Finding the owner
The project is split across a few layers and repositories. The distinction is mostly about which questions each one has enough information to answer:
| Owner | Responsibility |
|---|---|
| Perimortem | Low-level C++ facilities, storage and platform support |
| TTX Data | Concrete descriptions, canonical compilation and access protocols |
| TTX Semantic | Contract negotiation, established transport and explicit ownership |
| TTX Concept | Abstract queries, policy and substitution |
| Tetrodotoxin Source | Source observations, provenance and portable invocation boundaries |
| Type and Execution models | Semantic type/storage capabilities and execution structure |
| Dialects | Interpretation of an authored command stream |
| Terminals and adapters | Realization for a consumer such as native code or Godot |
A pair of similar implementations can suggest a shared abstraction, but it helps to ask what agreement their consumers actually share. Otherwise a lower layer can end up owning a policy simply because it was a convenient place to put common code.
The Tetrodotoxin repository contains Perimortem, TTX and the source-toolchain work. The Godot repository contains the engine adapter and demonstration. CUDA compilation and execution are also being isolated through their own provider contracts. Each repository owns its build and tests, even when a local development setup connects sibling trees.
Using the explanation as part of the review
The comments beside an interface should explain why it exists, what its caller can rely on and which tradeoff gave it that shape. The compiler specification is a substantial example: a reader can follow the normalization rules before examining how the implementation performs them.
That explanation is useful while the design is changing. A reviewer can question whether a lifetime belongs to the provider, or whether a piece of state is really part of a persistent object, without first rewriting the implementation. If the comment and code disagree, we have a model question to settle rather than a prose problem to smooth over.
The website gives the larger context, while the local contract carries the facts needed to work on that owner. Keeping those explanations connected is part of making the boundaries usable by another implementer.
Testing another participant's view
A native caller can accidentally hide a broken boundary by sharing private types, allocation machinery or assumptions with its provider. C/C++ fixtures and the Godot/script examples help expose that coupling because the consumer has to use the published interface.
For performance work, decide what the request should have to do before interpreting its duration. The overlay example counts the upload it needs and the background work it should avoid, then checks the resulting pixels independently. Timing an operation that accidentally recomputes its input can make the kernel look slow when the dependency policy is the real problem.
Some of the most useful checks have come from asking what survives a change:
- An incompatible callable description should fail before invocation.
- A refusing or unsettled policy should keep its answer through the adapter.
- An emitted result should remain usable after the discovery graph is released.
- Provider state should be destroyed while the code needed to release it is still loaded.
- Repeated calls should use an established interface where its lifetime permits that reuse.
- A wider or differently shaped input should reveal hidden scans and allocation assumptions.
The native integrations can share the TTX runtime without requiring foreign implementations to adopt Perimortem. That deployment choice matters when private allocator finalizers would otherwise keep a provider library loaded after its explicit results are gone.
Focused foundation checks include:
bazel run //validation/unit_tests/ttx/data:data_tests
bazel run //validation/unit_tests/ttx/semantic:flow_tests
bazel run //validation/unit_tests/ttx/concept:concept_testsRun them from the owning repository and use its current configuration. A focused fixture establishes the behavior it exercises; an application check adds evidence about how those pieces compose. Keeping that distinction visible makes it easier to see what a new integration still needs to test.
The research page explains how independent coding-agent sessions and human review fit into this process. The contracts provide a place for that work to meet, and the examples tell us where the agreement is still incomplete.