Changelog

Actors left the source kernel. Mutable closures keep logical owners while the runtime may inline, serialize, persist, or remotely activate them without changing behavior.

The model checked lexical execution, closure conversion, immutable copying, routed mutation, site movement, and a typed nested closure running in Chrome.

Versioned definitions, captured function values, invocations, continuing runs, logical owners, and physical activations remain separate semantic categories.

The kernel named thirteen missing semantics instead of inventing them, including durability, effects, maintained values, collections, lifecycle, and evolution. Read the function-kernel validation.

One workboard combined durable structures, maintained queries, occurrences, effects, cancellation, browser materialization, and imports without adding another fundamental binding form. See the [integrated results][integrated-results].

Revocable capabilities are authorized when governing authority admits the operation: admitted work may finish after revocation, while work still in transit is rejected.

Equal keys remained isolated across tenants; deleted incarnations stayed tombstoned; recreated actors rejected old references and checkpoints. Read the [authority results][authority-results].

A root-owned durable counter drove browser patches, denied browser write authority, and resumed the same logical state after server restart. See the counter results.

The model distinguished one-time facts, replaceable places, and maintained laws. Bounded schedules checked sharing, temporal reads, atomic assignment, provider fencing, and live replacement. See the [fundamental results][fundamental-results].

Records and lists remain ordinary values. Materializing a copy gives the target fresh member identities rather than aliasing equal source values.

Function-composed queries lowered to revision-pinned plans that stores could execute, recover, or reject without silently loading entire collections. See the [structural-plan results][structural-plan-results].

Further gates exercised occurrences, nested edits, code shipment, joins, uncertainty, cancellation, recursion, and live-cycle rejection. Read the generality results.

The research asked what remains identical as state, execution, placement, and representation change. Actors were a continuity hypothesis, not a thread-per-value design.

Authors keep ordinary values, functions, relations, views, and workflows. The compiler may introduce actors, protocols, scopes, and subscriptions where identity requires them.

Each application incarnation received one runtime-created root. External work begins only after its startup topology commits and readiness is published.

Every identity, lifetime, communication, and persistence distinction must survive executable counterexamples. Follow the language and runtime foundation.

Sixteen semantic slices tested everything from transactions and dataflow to heterogeneous execution and compiler readiness. The [completion audit][completion-audit] records what composed.

Reference models, broken alternatives, bounded exploration, and selected Lean proofs kept retained claims tied to witnesses and rejected claims tied to counterexamples.

The website now presents accepted, researching, returned, and abandoned ideas as one timeline, making architectural changes and reversals visible.

The completed work reopened the source-language question instead of declaring a universal model. The reopening rule defines what later foundations must earn.

Enter, Vim o or O, renames, fields, and HTML edits now start the appropriate structured change at the cursor. See Semantic Editing.

Incomplete or invalid text remains as a persisted draft without replacing the last working application. A valid edit refreshes the preview without moving the cursor.

Independent edits can stay open together, survive renames by identity, and commit as one revision. Larger refactors no longer collapse into fragile file replacement.

Research tested 47 data-intensive workloads. One familiar function language remained promising, provided history, ordering, retry, and freshness stay explicit. Read the data-systems result.

The first proposal hid critical guarantees in library code and failed under crashes, concurrency, evolution, and offline updates. See the falsification record.

A project joined semantic history, immutable definition revisions, source projections, workspace drafts, and application worlds. The checkpoint defined how these parts coexist.

The isolated prototype parsed and type-checked type, var, and fn, then ran a persistent calculator from ordinary Atlox source. Its behavior was not hard-coded into the Rust harness.

Removing or adding durable fields produced structured obligations. Answers such as rename or prior-value interpretation were stored in semantic history and generated reconciliation behavior.

Version-pinned clients, workflows, effects, rollback, and roll-forward operated over the same durable application state. Target-only fields were preserved when older clients wrote.

Developers could initialize, compile, run, serve, inspect, deploy, roll back, back up, restore, and package a terminal client. Stages 1–10 and their limits are documented in the prototype guide.

Create, relabel, split, merge, retire, forget, and replace operations recorded what a developer meant. Stable identities and localized obligations could therefore survive source rearrangement.

An experiment briefly modeled record types as revision-pinned subject views over assertions. The minimal checkpoint instead separated the versioned program semantic model from ordinary durable application state. See the checkpoint decision.

let, var, and durable state separated detached logical values from assignable places. Maps remained ordinary values while indexed state could still have independently addressable coordinates.

Prototypes covered online field splitting, relation and view changes, structural evolution, public function protocols, workflows and effects, physical planning, authority movement, and reclamation. The consolidated findings are in the semantic-model decisions.

A model pane and direct commands created revisions and deployment obligations without pretending that arbitrary invalid text had known meaning. The editor result connected source artifacts to canonical semantic history.

Immutable predecessor relationships, stable identities, and typed forward or reverse transforms defined deployment evolution. Ambiguous paths were rejected rather than chosen by convention.

Authorized forget created logical unreconstructability, invalidated incompatible history and rollback promises, and recorded the loss. Ordinary compaction could never cross a protected frontier. The details are in the retention.

Records, maps, exports, authorization, queries, releases, and forgetting compiled into one closed database plan. Recovery returned ready, rebuilding, or quarantined rather than silently guessing.

Scan, atomic-image, journal, replay, incremental, and indexed realizations were required to match one semantic oracle. The Stage 21 decision states the exact boundary.

The new campaign asked whether canonical meaning should be a causal history of semantic operations, subjects, assertions, and evidence. It was a reality check, not an automatic replacement of Unity.

Collection operations described logical results over typed records. Predicate transactions protected inferred query footprints, preventing a concurrent write from invalidating a decision between read and commit.

Ordinary function results could be observed through initial values, updates, progress, checkpoints, and reset. The protocol made gaps, compaction, and resumption explicit without turning functions into a special query language.

The reference meaning of a query remained recomputation. The runtime could maintain the same result incrementally when a certified plan was available, or fall back without changing application code. See the materialization decision.

Indexes, logs, replicas, and layouts became replaceable realizations constrained by observable equivalence. A later boundary audit limited native code to sealed physical capabilities rather than letting a foreign database own semantic policy.

Immutable releases pinned definition identities and creator-supplied transformations. Old and new code could coexist over one logical history, setting up generated rollout and rollback instead of handwritten migrations.

An authenticated Principal came from the runtime, while @authorize named an ordinary read-only policy. Policy and protected function ran against the same pinned state, closing a common time-of-check/time-of-use gap. See the Stage 9 decision.

Each invocation ran on a snapshot and committed only if its inferred write footprint still matched. Conflicts retried the whole pure invocation, avoiding user-authored compare-and-swap loops.

Writes to several keyed values committed together or not at all. Nested calls joined the same scope, and results were released only after the complete change was durable.

Typed keyed records were introduced without embedding storage handles or partial loading into values. The compiler could understand fields while the runtime retained control of physical representation. The selection is captured in the Stage 12.

Scalar algorithms, structured transformations, recursion, and parallel batches shared one semantic evaluator. Workers, queues, and schedules remained realization choices rather than concepts in business code.

One cell and ordinary functions replaced explicit transition packages. An external export fn opened the atomic scope, while reads, writes, rejection, and durability were inferred from the body.

The same application passed both atomic-image and commit-log crash campaigns. Success could become visible only after recovery was guaranteed, proving durability as a runtime contract rather than a code annotation.

Cells gained qualified revisions, historical reads, and append-only restore branches. Recorded transitions defined history; rerunning current code could verify it but could not rewrite it.

Generated handles, registries, lifecycle, and mutable names were initially selected, then rejected as premature. Sparse keyed cells preserved independent history and durability with fewer concepts. The final Stage 7 decision records the replacement.

The generalization gate replayed 10,000 histories for each system. It checked changes in keys, namespaces, values, interleavings, and fault schedules against the frozen public traces.

Generated variation alone could not widen a corpus built from a small number of original executions. A second gate therefore ran new source-system witness families. The generalization certificate states both levels.

Rust-style blocks and last-expression returns, methods on collection values, PascalCase type and variant names, String, and camelCase members removed research notation that obscured the model.

SQLite kept an old reader frontier during a new commit; etcd made a lagging watch unavailable after compaction; Kafka made transaction visibility depend on partition frontiers. One logical program survived different realizations in the live-relation prototype.

Parallel work was tested as independent lives that can propose evidence, not as automatically trusted clones of state. The resulting common-problems model kept acceptance and reconciliation explicit.

SQLite, etcd, and Kafka supplied transaction, consensus, watch, log, partition, and visibility pressure. Their source, public behavior, scenarios, and evidence were pinned by the database-core method.

The experiment targeted the chosen version's observable semantics, not historical bugs or every legacy format. Protocol encoding and bit-level mechanisms stayed in Rust so Atlox could concentrate on database-domain logic.

Typed scoped histories, proposals, acceptance, frontiers, observations, authority, and physical refinement formed an evidence-led core. compute described deterministic calculation; derive described logical recomputation at a consistent frontier.

The original witness closures contained only a few relevant source nodes. A promised tenfold reduction was therefore mathematically impossible for that corpus. The record kept the denominator visible instead of claiming a misleading compression win.

A parser, type checker, evaluator, native boundary, and multi-file SQLite, etcd, and Kafka programs turned the semantic proposal into a runnable research language. The language reference records its bounded surface.

Reusable view instances could survive reevaluation instead of being replaced wholesale. Props, local adapter state, and lifecycle became part of one browser runtime model.

The client program described reusable view plans and reconciled their changing bindings. This was a step away from page replacement and toward a persistent application graph in the browser.

Erlang, Orleans, Unison, Bloom, CRDT systems, Hydro, Temporal, tierless languages, and other models were analyzed for the problems they solve and the concepts they expose to developers.

The investigation selected Governed Algebraic Transitions: typed information spaces produce proposals, while trusted acceptance decides authority and atomic visibility.

An executable kernel lab compared candidates and native information models. This established the practice of carrying evidence and rejected alternatives alongside a selected design.

Remote updates now preserve the CodeMirror selection and scroll position. An acknowledged save no longer reconstructs the editor or moves the cursor away from active work.

The adapter compared the visible document with the acknowledged server value before clearing its dirty state. Queued edits continued saving instead of being forgotten behind an earlier response.

A stale save returned a real conflict response and explained that another tab had changed the project. The browser could distinguish concurrency from an ordinary validation failure.

Tests proved that a project could retain its previous active snapshot after invalid input and then activate again when the same file was repaired. The behavior lives in the project store.

Cursor movement was removed from round trips through application state. Editor navigation could remain an immediate CodeMirror action while project updates continued through the durable path.

A trusted web control plane, project store, runner, and CodeMirror adapter formed the first hosted editing path. The editor gained Atlox highlighting and a workspace designed around project files.

Imports and semantic identities were extended across multiple project-relative files. Email, todo, components, and icons demonstrated that applications no longer had to be assembled into one editor document.

The hosted runner moved to a shared, always-running runtime with lazy project loading and atomic activation. This replaced a fragile fixed-port process per preview and improved local macOS and production Linux behavior.

File revisions and activation were separated. A user could keep editing invalid source and see diagnostics while the last valid application continued serving traffic.

Runtime images, system services, Caddy configuration, environment examples, and release scripts formed the first production path. The operational model is recorded in the deployment guide.

Several competing foundation drafts were reorganized into one foundation document. It described the application as a live, versioned graph that can be inspected, changed, activated, and repaired.

Projects received tracked semantic identity files. A definition could keep its identity when its name or source location changed, creating the basis for semantic comparison and future evolution.

The semantic application kernel introduced snapshots, activation, operation runs pinned to exact definition versions, and commit metadata. Running behavior could now be connected to the exact program that produced it.

Executable examples moved to project folders with a fixed app.at root. That made imports, runtime data, and semantic identity project-relative instead of depending on a loose source file.

Collection key and row types, together with ordinary function return types, could be inferred. The language kept checked types while removing annotations already established by the program.

The page adopted a luminous cyan, violet, pink, and warm palette, stronger typography, layered gradients, and a graph-centered hero. Atlox now looked like the live system it was describing.

Nodes, orbits, connections, and runtime regions made the product idea visible: data, computation, and presentation belong to one connected application rather than separate stacks.

The research notes proposed that the compiler place database queries, authorization, server projections, browser replicas, and form drafts from semantic constraints instead of handwritten API boundaries.

Application state defines where the interface must end up; animation controls how a local renderer gets there. This avoided forcing ephemeral presentation time into durable application history.

The direction rejected arbitrary fetches, subscriptions, global stores, cache invalidation, and hydration protocols in application code. The complete argument survives in the July research notes.

The new export path wrote rendered application pages as static output. This made landing pages and other read-only experiences deployable as ordinary files.

Static output did not introduce a separate template system. It reused the same parsed application and renderer, keeping server execution and exported pages aligned.

The public Atlox page moved into a real application project. It demonstrated that the language could express product content and layout, not only CRUD screens.

The landing example was tightened so the visible program emphasized application state, derivation, and view composition. The surviving project can be read in the Atlox example.

Store declarations were separated from backend implementations. Application logic could describe a relation without fixing whether its realization was SQLite, memory, or a browser replica.

The runtime began producing a client program rather than treating hydration as an ad hoc script. Implicit browser relations let views depend on replicated data without manually declaring a second frontend store.

Shared expressions, component slots, attribute forwarding, utility styles, and predicate lowering made larger interfaces possible. Email and todo examples exercised the same component path that applications would use.

A Chrome render harness and component assertions turned visual behavior into repeatable evidence. That harness remains documented in the render-test guide.

The language was renamed, Lucide icons and shared components were added, and development hot reload removed the restart loop. The accompanying vision reframed Atlox as a governed application platform rather than a collection of UI conveniences.

The first executable examples combined application declarations, operations, and SQLite-backed state. This established the original promise that an Atlox application should be more than a UI layer over a separately designed database.

Views could render application state directly with server-side HTML. Derived collections were maintained incrementally, so a change could update a result without rebuilding the whole application.

Incremental joins allowed a change in either source collection to propagate through a composed relation. This was the first important proof that the graph could express more than filtered lists.

Named stores gained relation storage, while the hydrated browser applied server-produced patches. Together they formed the first complete path from a durable write to an updated interface. The current architecture still documents this lineage in the runtime model.

Structured explain output exposed definitions and dependencies instead of hiding them inside the runtime. That decision survives in the current language surface.