01
The application is the database.
Atlox does not connect application code to a separate persistence layer. The program defines one living world of facts, relations, actions, processes, effects, authority, and history.
Atlox
Write what the application means. Atlox turns that meaning into a running system—and keeps it correct as code and data evolve.
Application meaningRunning system
One application model
State, behavior, views, authority, and operational goals live together instead of being repeated across schemas, APIs, jobs, and infrastructure.
Derived systems stay derived
Caches, indexes, replicas, search documents, and client state are maintained from authoritative facts, without separate synchronization logic.
Evolution is continuous
Atlox preserves identity and intent across revisions, verifies unresolved obligations, and generates migration, rollout, coexistence, and cleanup.
Declare what must remain true. Atlox decides how to maintain it.
type Ticket {
title: Text
open: Bool
}
var tickets: Map<Int, Ticket> = {}
fn openTickets() -> Map<Int, Ticket> {
tickets.filter((_, ticket) => ticket.open)
}
fn main(path: Text, query: Map<Text, Text>) {
<main>
{for (_, ticket) in openTickets()}
<p>{ticket.title}</p>
{/for}
</main>
}
02
Everything else is a materialization.
Tables, indexes, APIs, client replicas, caches, search documents, analytics, and compiled code are replaceable physical realizations selected for the workload. They do not define application meaning.
03
Change is part of the program.
A revision is a semantic edit to one continuing world, not a new snapshot dropped over the old one. Stable identity and explicit obligations let the runtime generate coexistence, rollout, rollback, and cleanup.
Up. Down. Sideways. Still forward.
We build a model, throw harder problems at it, abandon what fails, and bring good ideas back for another round. Research is messy on purpose. That is how we are making Atlox the dope show.
Follow the research