Data model
In Intabula, folders are collections, Markdown files are records, and the YAML frontmatter keys at the top of each file are columns. A plain folder indexes into a soft-typed database with table and Kanban views on top — and clicking through any row lands you in the full note.
Collections and records
Collections follow your directory tree: every folder in the vault is a collection, nested as deep as your folders go. A record is one Markdown file — structured fields in the frontmatter, free-form prose in the body. Records keep their identity when moved between collections, so references follow a note wherever it goes.
Field types
| Type | Meaning |
|---|---|
string | Plain text. |
number | Numeric value. |
boolean | True/false. |
date | Calendar date. |
list | A list of values. |
select | One of a defined set of options (e.g. a status). |
wikilink | A typed relation to another record — client: "[[Acme]]" is a link, not a string. |
Schema is inferred, never imposed
You never design a schema upfront. Write a few notes with the same fields and Intabula notices the recurring keys and offers to promote them to official columns ("destination appears in 9 of 12 records — make it an official field?"). Pinning a field records its type in the collection's schema. The agent can do this too, via the pin_field operation.
A pinned schema acts as a contract: Intabula and the agent both know a record in this collection has a status and a destination, so new records get the same fields, spelled the same way.
Soft enforcement
Schema violations, broken wikilinks, parse errors, and duplicate slugs route to a needs-attention inbox. Nothing is rejected, blocked, or silently rewritten — drift gets flagged, and you (or the agent) decide what to do about it.
Files stay the source of truth
The index is a SQLite cache derived from your Markdown; it rebuilds from the files and can be deleted at any time without losing data. There is no proprietary format and no export step.