Introducing Dotlanth v26.2.0-alpha
Why artifact-first execution matters for reliable AI-native systems
Try it on GitHubWhy artifact-first execution matters for reliable AI-native systems
Try it on GitHubAI systems do not fail cleanly. A single run can validate an input, start a service, touch local state, emit logs, deny a capability, and leave the operator with five partial stories about what happened.
That is a telemetry problem on the surface, but it is really an evidence problem. Logs can hint. Metrics can summarize. Traces can reconstruct. None of those automatically become the unit you hand to an engineer and say: this is the run, this is what it was allowed to do, this is what it did, and this is what survived after it finished.
Dotlanth v26.2.0-alpha is the first release built around that unit of truth. The headline is not the new TUI by itself. The headline is that Dotlanth now treats the artifact bundle as the product surface of execution, and the Capability Lab TUI is the workbench that makes that model usable.
Conventional observability assumes the primary job is to watch a service from the outside. That is often good enough for throughput-oriented systems. It is not good enough for AI-native execution where a run may contain intent, validation, capability checks, local state mutation, and externally visible effects that all matter to debugging and trust.
When something goes wrong in that environment, operators need more than dashboards. They need a portable execution record that preserves inputs, ordered evidence, and the security posture of the run itself.
Artifact-first means
The question stops being “do we have some logs?” and becomes “do we have the run?”
That distinction is why v26.2 matters. Dotlanth already had a VM boundary, DotDB, and record-first execution. This release makes those ideas composable as an operator workflow: validate, run, inspect, export, replay.
The visible surface is dot tui, a ratatui-based capability lab that exercises the Dotlanth stack from one CLI entrypoint. But the important part is what sits beneath it.
The evidence loop
parse -> validate -> run -> record
|
v
artifact bundle + DotDB index
|
inspect -> export -> replay -> compareThat loop is what makes the release interesting for infrastructure builders. The TUI is not mocking the runtime. It is driving real subsystem execution against deterministic demo fixtures under .dotlanth/demo/, which means the product is increasingly being exercised the same way operators will use it.
A durable bundle forces architectural discipline. Once the platform promises that every run yields the same required sections, the runtime can no longer treat inspection as a best-effort side effect. That changes behavior all the way down the stack.
In v26.2, the bundle format is intentionally plain: a directory with a manifest and well-known files like trace.jsonl, state_diff.json, and capability_report.json. That is not accidental minimalism. It keeps the artifact inspectable by humans, streamable for tooling, and portable outside the original machine.
Just as importantly, the artifact is not stored as an opaque blob buried in one database row. DotDB keeps the index and integrity metadata, while the bundle remains a normal on-disk object that can be copied, exported, or scrubbed. That separation keeps the lookup path fast without sacrificing portability.
An artifact-first runtime is not saying “files are nice.” It is saying that evidence has to outlive the process in a form other humans and tools can actually work with.
This is the same reason capability reporting matters in the bundle. A run should not only say what happened. It should also say what was declared, what was used, and what was denied. For agent infrastructure, that is the difference between observability and auditability.
The new TUI matters because it collapses the distance between architecture and practice. One surface now drives parse and validate workflows, real run and serve flows, artifact inspection and export, capability review, and input replay into fresh run IDs.
That sounds like tooling polish, but it is more foundational than that. A platform starts to become operationally legible when the shortest path through it reinforces the real model. In this release, the shortest interactive path is no longer “run a script and hope you know where the outputs landed.” It is “open the lab, exercise a capability, inspect the evidence, replay the run.”
Quickstart
just tui # or cargo run -p dot -- tui
Inside the workbench, the release deliberately centers capability-first navigation: parse and validate, run and serve, security inspection, artifacts, and replay. That keeps the create-name capabilities visible while you test the runtime instead of burying them behind generic product labels.
The near-term value of v26.2 is not that Dotlanth suddenly proves full determinism across environments. It does not. The value is that it stabilizes the contracts that future determinism work will depend on: run identity, bundle shape, trace schema, capability accounting, state-diff scope, and replay semantics.
That last point is easy to understate. Capability systems often weaken once tooling drifts away from enforcement. Dotlanth is trying to do the opposite: the run that is denied is the same run that yields the evidence explaining the denial.
This release is careful about what it does and does not claim. Replay is input replay, not a proof of full determinism across environments or side effects. HTTP serving remains intentionally minimal. Bundle creation begins only after Dotlanth resolves a concrete .dot file path. And the resulting bundles, along with .dotlanth/dotdb.sqlite, should still be treated as sensitive runtime artifacts.
Those limits are not admissions of weakness. They are signs that the release is stabilizing contracts before broadening scope. For a system that wants to support reliable autonomous execution, that sequencing matters.
Dotlanth v26.1 established the runtime posture. Dotlanth v26.2 starts turning that posture into an operating surface.
For AI-native systems, reliability will depend on more than smart models and fast runtimes. It will depend on whether each run can leave behind enough structured evidence to be inspected, exported, replayed, and trusted. That is the transition this release begins.