Why Dotlanth Is Record-First
Designing a runtime where execution explains itself
Designing a runtime where execution explains itself
Most software is harder to understand in production than it should be.
When a system fails, engineers usually need answers to three basic questions:
In most stacks those answers are scattered across logs, dashboards, traces, and tribal knowledge. Each tool captures part of the picture, but none of them is the runtime's own source of truth.
Dotlanth starts from a different premise. Observability and security should not be layers added later. They should follow directly from how execution works. That is the idea behind record-first execution in v26.1.0-alpha.
Traditional runtimes let side effects happen from many places. A library writes directly to a logger. A module opens a socket. A framework starts a server. The outside world gets touched from all over the process.
That architecture creates familiar problems. Policy enforcement becomes inconsistent. Auditing becomes expensive. Debugging turns into reconstruction.
Dotlanth narrows that problem by forcing external effects through a single syscall boundary. Programs described in dotDSL run inside a register-based VM. The VM handles computation and control flow, but it does not reach into the host environment directly.
If a program wants to write a log line, listen on an HTTP port, or respond to a request, it has to cross that boundary. The syscall layer is the only bridge between execution inside the VM and the outside world.
Design rule: side effects should have one doorway, not many hidden exits.
That constraint is not cosmetic. It gives the runtime one place to enforce policy, one place to record what happened, and one place to reason about behavior under load or failure.
Once all side effects cross the same boundary, capability security becomes much simpler to enforce. Dotlanth starts from deny-by-default. A program declares the capabilities it needs, and the runtime grants only those capabilities.
That matters for two reasons. First, the allowed behavior is visible in the program definition instead of buried in ambient credentials or framework defaults. Second, the check happens at the same boundary where the effect occurs, not as a scattered convention that each module must remember to apply.
A runtime becomes easier to trust when its permissions are explicit and its enforcement path is narrow.
The same syscall boundary that enforces permissions also gives Dotlanth a natural place to observe execution. Rather than treating recording as a debugging feature, the runtime writes structured run history by default.
In v26.1.0-alpha that history includes lifecycle events, logging activity, and HTTP server interactions, stored locally in DotDB. The important point is not the exact event list. The important point is that the record exists whether or not someone remembered to enable extra instrumentation.
That is what record-first means here: a run should leave behind a durable, queryable account of what happened. Debugging starts from evidence, not guesswork.
The alpha does not try to prove every future Dotlanth feature at once. It proves the core path end to end.
That path is deliberately small because it is architectural validation, not a feature race. If this model is solid, richer tooling, broader syscall coverage, and stronger replay workflows can be built on top of it without changing the foundation.
Record-first execution is not the final product. It is the prerequisite. Replayable run history, better runtime introspection, and stronger debugging tools all depend on the same foundation: a clear effect boundary and consistent event recording.
Build those primitives first, and the rest of the system gets easier to inspect, audit, and evolve.
Dotlanth is an argument about how runtimes should behave. Permissions should be declared. Side effects should cross a visible boundary. Execution should leave behind a usable record.
v26.1.0-alpha is the first step toward that goal: software that can explain what it did, while it is still fresh enough to matter.