A site is a folder
Content is one JSON file per thing in data/. Templates are PHP files in theme/. Images and other served files sit in assets/. The site's own rules for the agents that work on it are markdown in guide/. Four roots, one kind of file each — that is the whole site.
Why not a database
A database is a second world with its own language, its own backups and its own failure modes — and it needs an interface in front of it. Files are the world your operating system, git, your editor, the web server and your agent already share. Loam put the content there. Everything it does — rendering, checking, history, access — reads from the files and never replaces them.
What files give you
- Recovery is copying. Restore, move or clone a site by copying a folder. No dump to import, no migration to run.
- History is free. Every change is a diff, every earlier state a commit. Undo, audit trail and backup are one mechanism.
- Nothing is hidden. List a folder and you see the entire state of the site. Every live entity is public at its own address,
/data/<type>/<name>.json— the file, served as it lies. - Ownership is literal. Your content is yours because it sits in a folder you can pick up.
Lists instead of queries
Without a database, order is something you choose. A menu, the featured services, the team in the order you want them: each is a list you keep by hand, and the page that shows it reads that list. For machines there is one index of everything live, /data.json, with a word search on it (?q=) — hits first, then the file. An overview of a type, newest first, comes from the same index.
When something goes wrong
Because the files are the truth, a wrong state is fixed by fixing the file, and wrong behaviour by fixing the engine. There is no table only the application can read and no cache that has to be warm: delete what the engine derived and the next request builds it again. That one distinction keeps a loam site understandable on its worst day.