×

MLTTDB

MLTTDB / Architecture

One contract, two validation paths

MLTTDB persists ordered row terms; proof assistants validate them against declared row types through direct Agda modes or generated checker-facing artifacts.

Custom Agda

  • Direct modes: schema, tables, data, eval
  • Row-context operations and structured evaluation

Preprocessors

  • Generate ordinary Agda, Lean, or Rocq source
  • Portable artifacts for existing checker pipelines

Shared contract

  • UUID
    identity
  • Deterministic
    order
  • Projection
    values
  • Language
    metadata
  • Checker result
    boundaries
  • Agda
  • Lean
  • Rocq
Skip to content

Works

MLTTDB

A typed operational term-store system for proof-assistant workflows.

MLTTDB, displayed as ML:T:TDB when the wordmark needs the visual rhythm, is a typed operational term store for proof-assistant workflows.

The product idea is deliberately simple:

A table is a type.
A row is a term checked at that type.

In ordinary applications, operational records change frequently while the schema and validation logic are maintained separately. MLTTDB adapts that pattern to proof-assistant-backed systems. Row types and table declarations live in proof-assistant source. Ordered row data lives in a SQLite-backed term store. Validation is delegated back to Agda, Lean, Rocq, or generated proof-assistant source.

Runtime Pieces

The implementation has five main surfaces:

  • a SQLite store that persists databases, table definitions, records, editor configuration, and metadata;
  • a narrow validation API at /term-store/v1 for fetching ordered records for one qualified table;
  • an administrative API for schema discovery, CRUD, verification, row evaluation, and editor setup;
  • preprocessors that turn MLTTDB-flavored Agda, Lean, or Rocq into ordinary source;
  • a custom Agda executable with direct modes for schema checking, table discovery, data validation, and row evaluation.

The store does not parse or typecheck record bodies. It owns persistence, UUIDs, ordering, database language metadata, and stored table definitions. The proof assistant owns semantic validation.

Why It Matters

MLTTDB gives Formal Foundry a path from a checked formalization to operational tooling. A rule or record model can start as proof-assistant source, but the day-to-day data can still be edited through an API or web app. Validation is not lost when data moves out of a static source file.

The most important public explanation is the responsibility split:

Responsibility Lives in
row types and table declarations proof-assistant source
ordered row data term store
semantic validation proof assistant or generated source

Good Artifacts To Feature

  • the local CRUD web app;
  • a table-discovery flow where empty tables appear before records exist;
  • Agda, Lean, and Rocq preprocessor examples;
  • custom Agda schema, tables, data, and eval modes;
  • finite table lookup by UUID in Agda;
  • structured editors driven by ff-generics;
  • procurement, finite-record, Lean, and Rocq example fixtures.

MLTTDB should be treated as a platform component as well as a product. It is the bridge between static formal schemas and data operations that can actually change.

Book a meetingStart a scoped conversation

Cabinet index

Explore Formal Foundry

Search the archive

Find a page

Type to search the published content.