ML:T:TDB by Formal Foundry

Checker-backed infrastructure for data-centered systems

When data and reasoning are the institution, correctness becomes infrastructure.

MLTTDB turns formal claims, transformations, policies, proofs, and agent-generated reasoning into managed records that can be checked before they are used.

Managed identity

Every record has a stable identity

Deterministic order

Dependencies made explicit and reliable

Typed projections

Structured views for applications and humans

Checker status

Accepted or rejected by proof assistants

Application ready

APIs for discover, edit, verify, consume

See how it works View implemented scope

Your data estate

Warehouses, APIs, models, rules, reports, and more.

  • Databases & Warehouses
  • APIs & Services
  • Files & Documents
  • Models & Notebooks
  • Rules & Policies
  • Reports & Analytics

Formal candidates

Claims, transformations, policies, proofs, programs, and agent outputs.

  • Transformation
  • Invariants
  • Policy
  • Proof
  • Derivation
  • Agent Output

MLTTDB

  • UUID Identity
  • Deterministic Order
  • Typed Projections
  • Source-Linked Types
  • Checker Status
  • Application APIs

Managed term records Durable, ordered, and ready for validation.

Checker boundary

Proof assistants decide what is correct.

Checked operational artifacts

Trusted, auditable, and ready to use.

  • Verified RecordsUsed in operational systems
  • Auditable ReasoningTraceable from source to acceptance
  • Safe Agent OutputsAgents operate within verified boundaries
  • Proof-Carrying AnalyticsStatistical claims with checkable evidence
  • Policy & Rule EnforcementCorrect by construction, enforced in systems

Why now

Proof-assistant terms are becoming operational data.

AI systems, editors, and domain tools can now produce many formal candidates. The hard part is not just generating terms; it is giving those terms identity, order, editing, validation, and a route into real applications.

before Formal source lived mostly in repositories.

Proof-assistant data was edited and reviewed as files.

now Applications generate and edit formal candidates.

Rows, proofs, programs, and domain objects need checker feedback.

missing layer Terms need database behavior without losing semantics.

Identity, order, UI, APIs, and validation have to stay connected.

MLTTDB A store that keeps the proof assistant in charge.

The database stores text; the checker decides meaning.

Paradigm

Tables are types. Rows are terms. Columns are typed projections.

MLTTDB is intentionally small: source files declare tables, the store persists ordered row terms, and proof assistants validate those terms against the declared row types.

source schema entries :T: RowType
stored row { uuid, body, projectionValues, order }
proof assistant accepted application data
row type

A source-language type declared in Agda, Lean, or Rocq.

row body

An opaque source-language expression stored with a UUID.

projection values

Typed column values derived from the row decomposition contract.

Generated MLTTDB record model illustration showing source schema, stored record fields, row decomposition projections, and ordered dependency checks.
Generated raster illustration: the row model, projection views, and dependency order.

Operational workflow

A practical loop from source tables to checked records.

Applications can call MLTTDB directly: discover tables, insert or edit records, ask for verification, and consume records with a checker-backed status.

discover table definitions

Read qualified names, row types, and row decompositions.

store uuid, body, order

Persist records through the WebApp or Admin API.

verify ok true / ok false

Separate checker rejection from protocol errors.

consume checked records

Use accepted rows in application flows and reports.

Generated MLTTDB operational workflow illustration showing declare, discover, edit records, verify, consume, and result states for API error and checker rejection.
Generated raster illustration: the application workflow and result states.
discover

Create schema from source

POST /admin-api/v1/databases/demo/create-from-source
  • stores language and source path
  • creates table definitions before records exist
edit

Create or update records

POST /admin-api/v1/databases/demo/tables/.../records
body
identity-decomposition row term
projectionValues
projection-aware row storage
verify

Ask the checker

POST /admin-api/v1/databases/demo/verify
  • custom Agda for Agda verification
  • preprocessor output for Lean and Rocq

Checker paths

One term-store contract, two validation styles.

Custom Agda gives direct row-context operations. Preprocessors give portable ordinary source artifacts for existing checker pipelines.

custom Agda Direct modes for schema, tables, data, and eval.

Agda reads MLTTDB tables directly, fetches records, and can evaluate expressions in the checked context before a selected row.

  • typed row context
  • row evaluation for structured editors
  • finite table lookup in stored bodies
shared contract Tables are types. Rows are terms. Order matters.

UUID identity, deterministic order, language metadata, projection values, and checker result boundaries stay consistent across both paths.

types terms UUIDs order projections
preprocessors Generated ordinary Agda, Lean, or Rocq source.

The preprocessor path materializes records as checker-facing definitions and lets the unmodified proof assistant accept or reject the generated artifact.

  • ordinary source output
  • clear audit artifact
  • Lean and Rocq integration path
Generated MLTTDB checker paths illustration comparing custom Agda direct modes with preprocessor generated source for Agda, Lean, and Rocq.
Generated raster illustration: custom Agda and preprocessor paths sharing one term-store contract.

Operational surface

Use APIs and a WebApp to manage formal records without hiding the checker.

The WebApp and APIs expose databases, table definitions, UUIDs, record bodies, projection values, structured editors, row evaluation, and verification triggers.

Validation API
GET /term-store/v1/databases/{db}/records
Admin API
Create schemas, insert records, configure editors, and trigger verification.
Structured editors
Use Agda generic helpers to render record-specific editing widgets.

Working artifact

Switch between Agda, Lean, and Rocq to see the same term-store idea become checker input.

language switcher Agda Lean Rocq Source convention Schema checking Data checking
Multi-language widget Original Agda widget Source Agda example Transformation snapshot

Implemented scope

The current demo includes the store, preprocessors, custom Agda support, and copied validation evidence.

SQLite term store

HTTP store, WebApp, database metadata, table definitions, ordered records, discovery, verification, row evaluation, and editor configuration.

Preprocessor paths

Agda, Lean, and Rocq preprocessors emit ordinary checker-facing source for schema, table discovery, and data validation.

Custom Agda

Agda supports direct --tdb-mode schema|tables|data|eval operation for MLTTDB source files.

Bundled evidence, not a live badge

Copied validation run 20260609T222403Z

The copied report records passing checks for the SQLite store, preprocessor paths, and custom Agda MLTTDB path.

3passed
0failed
0skipped
9.40stotal
Open bundled evidence