ArchitectureA supervised JVM-class runtime — OLTP on seven engines, OLAP on three. AI-native, MCP-native, observable as plain SQL.Read the architecture
Está viendo la edición Perú. Está viendo la edición Colombia. You're viewing the Pakistan edition. Cambiar a la edición global →Cambiar a la edición global →Switch to the global edition →

The dictionary gets a journal: history, diff, status and restore for every write

Every authoring write records a changeset inside the caller's transaction, deletes keep the full document, and tools list history, show a diff, report status and emit a restore plan that never writes.

An agent that writes application code needs what an engineer has had for decades: a history, a diff, and a way back. This release gives the dictionary a journal and the tools to read it.

The journal

  • In the caller's transaction Every object or filesystem write records a changeset header and one item per write. A rolled-back apply leaves no journal row. A delete carries the full document it removed.
  • Only real changes A write whose canonical document did not move journals nothing.
  • Waves A task opens a wave with a description and its writes group into one changeset; an apply takes a comment. Waves are session-scoped and undo is author-only.

The tools

  • History and diff History capped at two hundred rows with images on request, a structural diff per changed path for objects and a line diff for code, previews truncated.
  • Status Clean, modified by an outside writer, deleted, or recreated. Objects never journalled are not reported.
  • Restore as a plan The restore tool never writes: it emits an apply plan with a verdict per item, no-op, applicable, conflict, recreate or refused. A restore is itself journalled.
  • In Studio A changeset browser with decoded operations, and a cache flush that evicts dictionary caches without a restart.

The audit says what an agent ran. The journal says what it changed, and how to put it back.