Historical runtime profile — qualified October 27, 2026. This body preserves the earlier runtime-oriented framing. Its comparative descriptions of mainstream systems and statements of uncommon assurance are not established by this profile. Use the current README, continuity charter, and alignment audit for research positioning and evidence limits. Normative contracts and surface classifications remain unchanged.
T81 Foundation delivers bit-exact, policy-enforced deterministic execution for governed computation surfaces, with a ternary-native data model and immutable provenance substrate in CanonFS.
T81 Foundation is a deterministic, policy-gated runtime stack for auditable computation, with a long-term systems direction rooted in ternary-native design. The project should not be read as a conventional application framework or as a finished operating system. Its strongest current claim is narrower and more concrete: for explicitly governed surfaces, identical inputs, policy state, and configuration should produce identical outputs and evidence across supported platforms.
Today, the most credible reading of T81 is:
The problem class is deterministic execution under governance constraints. In practical terms, T81 concentrates on a set of concerns that are usually fragmented across unrelated tools:
This remains uncommon in mainstream stacks because most environments optimize first for throughput and convenience, then try to patch determinism, evidence, and governance afterward. That usually leaves output drift, policy gaps, and poor post-mortem auditability. T81 inverts that order: determinism, policy observability, and provenance are intended to be structural properties of the stack.
T81 also aligns philosophically with high-assurance engineering practices reflected in sources such as NIST SP 800-218 (SSDF) and NIST SP 800-53, but its value should be understood in implementation terms rather than compliance language alone. The practical question T81 is trying to answer is: can an AI-oriented runtime be made reproducible, governed, and inspectable by design?
T81 is organized as a layered stack with explicit authority boundaries and maturity labels.
The data model is centered on ternary semantics and canonical forms. In implementation terms, the codec layer includes balanced Base-81 packing and unpacking constraints, while the type system specifies deterministic canonicalization requirements for core numerics such as T81BigInt, T81Fraction, and bounded T81Float behavior.
Why this layer exists: deterministic systems fail when representational ambiguity leaks upward. Canonicalization at the data boundary reduces that ambiguity before execution begins.
The runtime layer provides the most important currently usable value in the project. T81 includes a deterministic VM/runtime surface, CLI tooling, and supporting tests intended to keep core execution behavior stable across platforms. This is the part of the project that is easiest to explain to a technically skeptical reader because it produces repeatable behavior, contract tests, and CI-visible outcomes.
Axion is the policy system that turns T81 from a deterministic runtime into a governed runtime. The project’s architectural stance is that policy should be able to deny or constrain actions before side effects occur, not merely annotate those actions after the fact. This policy-first stance is central to how T81 frames import/export, execution, and future networking work.
CanonFS is the immutable storage and provenance substrate. It gives T81 a way to talk about content identity, manifests, and evidence without depending on mutable host state as the sole source of truth. Recent work around RFC-00D1 moved this from a purely architectural idea toward a real interchange lane, with import/export flows, schemas, validation, and policy-profile recording.
The kernel, HAL, QEMU guest, and related subsystems represent the long-term systems direction. They matter strategically because they show how T81’s determinism, policy, and provenance ideas could extend below a user-space runtime boundary. They should still be understood as earlier and less stable than the core runtime story. They are real and increasingly demonstrable, but they are not yet the simplest way for a newcomer to understand or adopt the project.
The strongest current capabilities are:
This matters because T81 is no longer just a specification corpus. A newcomer will find code, tests, CI, workflows, RFCs, validation tooling, and concrete subsystem seams that can be extended.
A practical way to read this section is: T81 already supports a real governed interchange path. A contributor can import host content into CanonFS, attach policy, emit validated JSON artifacts, and export back out again through the same contract surface.
Recent progress has been especially meaningful in the CanonFS interchange lane:
canonfs import and canonfs export now exist as real CLI flows,RFC-00D1 status: partially implemented. Import/export flows, schemas, runtime validation, and policy-profile recording are live in the CLI and core interchange modules.
This is currently the clearest example of a T81 draft RFC turning into a buildable subsystem.
The following areas are the safest places for another engineer to start:
“Stable enough” here does not mean frozen forever. It means the project now has enough implementation and test weight in these areas that contributions can be made without re-litigating the whole architecture.
The most important active draft areas are:
RFC-00D1 is already partially embodied in code. RFC-00D0 is still primarily architectural and should remain design-led until a narrower implementation seed is chosen.
The following should still be treated as experimental:
This distinction matters. The project is most credible when it is explicit about what is proven, what is emerging, and what is still aspirational.
T81 is unusual because it combines several concerns that are often separated:
Many reproducibility efforts focus mainly on build artifacts, packaging, or container boundaries. Many policy systems are advisory or post-facto rather than pre-side-effect controls. Many provenance systems capture outputs after execution rather than making canonical representation and content identity structural from the start.
T81 is trying to close those gaps in one coherent stack. That ambition is what makes the project distinctive, but it is also what creates the main adoption challenge: the project is easier to respect than to classify quickly.
The main risks are not conceptual emptiness; they are transfer and execution risks.
These risks are manageable if the public story stays narrow and the next work remains focused on buildable lanes rather than constant breadth expansion.
If another engineer were picking up T81 today, the most productive path would be:
main operationally boring through strong CI discipline.That is the correct development shape for the project at this stage. T81 does not need maximum subsystem count. It needs a few finishable lanes that prove the broader architecture can be handed off and extended by someone other than the original author.
For someone discovering the project, the best reading order is:
README.md for the current public story and first-run paths,docs/HANDOFF.md for what is mature, what is draft, and how to approach the codebase,docs/ROADMAP.md for the current sequencing of work,docs/BUILDABLE_NEXT_STEPS.md for bounded contributor lanes,This order is important. T81 becomes easier to understand when it is approached as a governed deterministic runtime with a long-term systems direction, rather than as a bare-metal OS project first.