How Dotabases Work

A Dotabase is the foundational primitive of the platform — everything else is built on it. It is a typed collection of rows. Every row carries a title, a body, a set of declared properties, and a place in a knowledge graph.

What A Dotabase Is Made Of

• Rows. The records. Each row is a DOT — an atomic unit of knowledge.
• A schema. The typed properties a row may hold, drawn from thirty-three built-in property types.
• Behaviors. Rules that run as rows are written, enriching each row on its way in.
• Edges. Typed, directed links between rows that form the knowledge graph.
• Views. Saved lenses over the rows — a table, a board, a graph, a dashboard.
• An Operation Manual. Per-Dotabase guidance that tells a person or an agent how the Dotabase is meant to be used.

Rows And Their Properties

The built-in property types are: text and rich text, number, currency, duration and progress, select and multi-select, date and date range, checkbox, URL, email and phone, relation, person and assignee, file, rating, status and tags, plus computed types like formula and rollup that derive their value from other properties.

Storage is split for query speed. A handful of properties the platform itself depends on — tags, the DIIICE type, the created and updated stamps, the authorship and verification fields — are physical columns on the row, so filtering and sorting on them is cheap. Everything else lives in a typed envelope on the row, and any property can be bridged onto a column when a Dotabase needs it to be.

Every row also gets a readable identifier of the form PREFIX-N, where the prefix belongs to the owning Dotabase — PROJ-7, TASK-42. Suffixes are allocated above the current maximum rather than by counting rows, so a hard delete never causes an identifier to be handed out twice.

Behaviors

Thirty-nine built-in behaviors ship with the platform, and each Dotabase binds the ones it wants; the set is per-Dotabase configuration, readable and writable from the CLI. They fire on six lifecycle hooks — row create, update, archive and restore, plus schema change and a general event hook — and a failure in one is isolated rather than allowed to fail the write.

Several of them enrich the row as it is written. Classification assigns the DIIICE type. Embedding produces the vector that makes a row findable by meaning. Auto-summary writes a short summary into a declared property. Version history snapshots the previous state of a row on update, coalescing an editing session so autosave does not mint a version per pause. Relation edges turn a relation or dependency property into real graph edges, both directions where the relation is bidirectional. Word count updates a word-count property from the title and body; tag inference generates suggested tags into a multi-select tags property.

Edges, Views, And The Operation Manual

Rows connect to each other through typed, directed edges, and those edges are what make the collection a graph instead of a list. Views are saved on the Dotabase and belong to it, so a Dotabase carries its own set of lenses rather than depending on whoever is looking. The Operation Manual is a stored purpose plus authored judgment, versioned on every edit, and it rides along to agents on the CLI and MCP surfaces — that is how an agent knows how a Dotabase is meant to be worked in.

Three Readings Of The Same Rows

Because a Dotabase keeps its structure, the same rows are readable three ways at once: as a table you scan, as a graph you traverse, and as context an AI reads. Working in one does not foreclose the others, and no export or conversion step sits between them.

Creating Your Own

Four foundational Dotabases ship with every workspace, alongside always-seeded internal ones such as Context Cabinet and Glossary; Foundational and Internal Dotabases lists the whole seeded estate. You create your own on top of those, and a schema is not required up front — create the Dotabase first and add properties to it afterwards. Create a Dotabase covers the steps.