Storage model

How a Zorid vault lays out Markdown notes, .zbase view files, .ztype type definitions, plugin config, and the rebuildable SQLite index on disk.

Canonical user data

*.md                          # Markdown notes (canonical)
*.zbase                       # View definitions (canonical, YAML)
.zorid/types/*.ztype          # Type definitions (canonical, YAML)
.zorid/config.json            # Settings
.zorid/workspace.json         # Workspace state

Derived / disposable

.zorid/index/index.sqlite     # Derived index, rebuildable
.zorid/cache/**               # Disposable

Future / separate durable data

.zorid/history/**             # Backup / timeline
.zorid/sync/**                # Operation logs (next stage)
.zorid/plugins/<plugin-id>/** # Plugin-private data

Why not canonical SQLite for views?

A live SQLite file is awkward to sync through object storage (S3 / Google Drive) because conflicts happen at the whole-file level. Zorid view definitions are readable, sync-friendly, conflict-detected text files instead.

Embedding views

Markdown uses normal embed syntax with the vault-relative .zbase path:

Project dashboard

![[.zorid/views/project-tracker.zbase]]

.zorid/views/ is only the default creation location. Users may store .zbase files anywhere in the vault:

![[Dashboards/project-tracker.zbase]]

Storage diagram

Source

Full storage model on GitHub.