The titlebase formatVersion 1.0Open
One open standard
for every title plant.
titlebase is a standard format for exporting, creating and changing title plants. One file holds a whole plant, described in a public, versioned spec, so every team and every system can read it, write it and hand it on.
01 What it is
Export, create,
and change a plant.
A title plant lives in many systems over its life. titlebase gives it one standard shape to travel in, and a safe way to work on it while it is there.
- Export
Take a plant out of any system
A whole plant leaves its system as one titlebase file: every document, legal description, vocabulary entry and land validation.
- Create
Build a plant from sources
Start an empty plant and fill it from a conversion, a clerk index or another system, with the same rules every file follows.
- Change
Work on it safely
Edit records, run mass updates and clean up vocabulary. Every change is journaled and can be undone before it is saved.
02 Why it is open
Your plant
belongs to you.
A title plant is years of keying. The format it lives in should never lock it into one vendor, one tool or one machine.
No lock in
The spec is public. Any team can write a reader or a writer, and any standard tool can open the file.
One target for every conversion
Each system needs one adapter to titlebase, not one to every other system. Plants move between systems through the format.
Rules, written down
Every rule is stated as MUST, SHOULD or MAY. Two tools that follow the spec produce the same file.
Proven, not promised
A round trip check parses and rewrites every row. On eight real plants, up to 6.3 million documents, every row came back byte-identical.
03 What it holds
The whole plant.
Nothing left behind.
A titlebase file keeps every key a plant carries, including the ones a tool does not understand, byte for byte.
- Documents
Every recorded instrument: number, type, dates, book and page, images and about 60 fields in all.
- Parties
Grantors and grantees exactly as recorded, with names split into their parts.
- Legal descriptions
Named by industry-standard type, so a subdivision legal means the same thing in every plant.
- Vocabulary
The plant's auto completes: additions, book types, instrument types, surveys and parties.
- Land validations
Plats, replats, vacates and comments by addition, with lot, block and unit ranges.
- Change history
Every edit journaled beside the file, by who made it, and exported as a change batch of only what changed.
Standard legal types
Plants can define their own types on top of these.
| Subdivision | Addition, lot, block and unit, with the plat book and page |
|---|---|
| Unit and condominium | Addition, unit and block |
| Tract | Addition and tract ranges |
| PLSS | Section, township, range and quarters, with acres |
| Government lot | Section, township, range and lot |
| Acreage | Acres within a named tract |
| Abstract | Survey, abstract number, section and block |
| Parcel | Parcel, PID and ARB |
| Free text | The legal as written on the instrument |
04 How it is built
Built on
SQLite.
A titlebase file is a single SQLite 3 database with a .titlebase name. Three core tables hold the plant, one JSON document per row, each keyed by a stable UUID. Version 1 is PropertySync compatible, so every PropertySync plant export opens as it is.
-- The plant. Three core tables, one JSON document per row. CREATE TABLE documents (id INTEGER PRIMARY KEY, data JSON); CREATE TABLE landvalidations (id INTEGER PRIMARY KEY, data JSON); CREATE TABLE autocompletes (id INTEGER PRIMARY KEY, data JSON); -- titlebase additions. Optional. Dropped on PropertySync export. CREATE TABLE tbase_meta (key TEXT PRIMARY KEY, value TEXT NOT NULL);
- Stable identity. Rows are keyed by the UUID inside them, so diffs, merges and change batches line up across snapshots.
- Byte faithful. A changed row is written in the exact style of the original. A row you did not touch is never rewritten.
- Room to grow. Additions go in reserved
tbase_tables that every reader can ignore. - Sidecar, not inside. Search indexes and the journal live in a folder beside the file and can always be rebuilt.
05 Import and export adapters
Between systems,
through one format.
titlebase includes import and export adapters for PropertySync and a host of other industry standard formats, so teams can move plants between systems through the titlebase format. Every import produces a file that meets the spec, and every adapter documents its field mapping.
06 For developers
Toolkits to read
and write the format.
titlebase provides developer toolkits that read and write titlebase files and keep every rule in the spec for you. Script it from the command line, or hand it to an agent.
titlebase-formatThe reference toolkit
The Rust toolkit is the format's reference implementation: streaming readers, faithful writers, PropertySync style serialization and the round trip check.
use titlebase_format::{Export, Table}; let plant = Export::open_read_only("plant.titlebase")?; println!("{} documents", plant.count(Table::Documents)?); // Stream every document, 10,000 rows at a time. plant.scan_batches(Table::Documents, 10_000, |rows| { for row in rows { let stored = row.data.bytes(); // the row, byte for byte } true })?;
Every titlebase toolkit follows the same spec and passes the same round trip check. Any language with SQLite and JSON can also read a titlebase file directly.
tbaseScript any plant
Every command takes the plant file first and prints one JSON document with --json. Inputs and outputs carry JSON Schemas.
tbase --json file info plant.titlebase { "file": "plant.titlebase", "rows": { "documents": 2400, "landvalidations": 4, "autocompletes": 11 } }
tbase mcpHand it to an agent
The MCP server exposes every command as a typed tool, so an agent can read and change a plant with the same rules.
MCP server07 Versioning
Versioned.
Built to last.
The spec is versioned as MAJOR.MINOR. A minor version only adds optional tables or keys, so a 1.0 reader can read any 1.x file. Every change to the spec is reviewed and recorded in its history.