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 any row opens 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, with structured fields in the frontmatter and free-form prose in the body. Records keep their identity when moved between collections, so references follow a note wherever it goes.

Subcollections

A record can own a folder of the same name next to it: clients/dora.md owns clients/dora/. Folders inside an owned folder are the record's subcollections, and the record's panel lists them. Each subcollection keeps its own schema. An owned folder holds subcollections only, so a Markdown file placed directly in it is flagged in the needs-attention inbox, and the agent's write operations refuse it as a target. Renaming or moving the owner record moves its owned folder in the same journaled operation.

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).
`url`	An http or https web address, opened in your browser when clicked.
`wikilink`	A typed relation to another record. `client: "[[Acme]]"` is stored as a link to the Acme record.

Schema is inferred from your notes

You don't 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 (for example, a banner notes that destination appears in 9 of 12 records and asks whether to make it an official field). Pinning a field records its type in the collection's schema, stored in .intabula/schema.json. The agent can do this too, via the pin_field operation. Pinning a field is unrelated to pinning a record or collection to Home, which is described in Getting started.

Once fields are pinned, Intabula and the agent both know that records in this collection have a status and a destination, so new records get the same fields, spelled the same way.

Soft enforcement

Problems go to a needs-attention inbox. Intabula doesn't reject, block, or silently rewrite anything. It flags the problem, and you or the agent decide how to fix it. The inbox collects seven kinds of item:

Parse errors: frontmatter that can't be read.
Schema violations: a value that doesn't fit its pinned type, such as a date field holding "next spring".
Broken links: a wikilink to a record that doesn't exist.
Duplicate slugs: two files with the same name in different folders.
Records in an owned folder: a Markdown file placed directly in a folder that holds a record's subcollections.
Conflict copies: a file such as note 2.md that a sync service created inside a shared external collection.
Links that leave an external collection: a wikilink that will be broken for other people who open that shared folder.

Most items come with one-click fixes in the inbox. Depending on the problem, these add a value as a new select option, edit the field, relink a broken link to a suggested record, create the missing record, move the record to a suggested collection, open the original of a conflict copy, or rename one of two records with the same slug. A conflict copy can also be deleted from there. The agent sees the same suggestions through list_needs_attention.

The index

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. Records stay plain Markdown files with YAML frontmatter that any editor can open.