A template should show you the finished thing, not the skeleton
Empty headings under empty headings teach you nothing. Nex ships templates filled in, and keeps built-in ones as code rather than rows.
Most built-in templates are an outline: a few headings, an empty table, a bullet list with one placeholder in it. They are fast to write and they answer the wrong question. You can already make headings. What you wanted to know is what a good version of this document looks like when it is done.
The templates in Nex are filled in. Open the meeting notes template and there are attendees, an agenda with real items, decisions with owners, and follow-ups with dates. Open the decision record and there is an actual decision, the options that were considered, and why the other ones lost.
You delete the example content and write yours. That takes ten seconds and you have seen the shape you are aiming at. An empty outline makes you invent both the structure and the standard, at the moment you least want to.
Built-in templates are code, not rows
The templates that ship with Nex are not seeded into your account. They live in the codebase and are merged into the list you see.
Seeding a copy into every account sounds harmless and quietly makes every future improvement a migration. Fix a typo in the project plan template and you have a choice between leaving it wrong for everyone who signed up before today, or writing a script that edits rows in people’s accounts. Neither is a good position, and neither is necessary: nothing about a built-in template is per-account.
The ones you save yourself are rows, and they hold a copy of the body. Not a pointer to the page they came from — because then editing that page would silently rewrite every document made from it since, which is the opposite of what saving a template means.
The bug this design caught
There is a test in the repo that builds every shipped template against the real editor schema and asks the editor to validate it. It exists because of a specific failure.
A callout in Nex takes inline content. The helper that built template bodies was wrapping the text in a paragraph first — which produces a structure the schema does not allow. Nothing complained: the document parser accepted it, the block rendered, and the page only exploded later when something asked the editor to modify that node. Three templates and three starter pages shipped that way.
Type checking could not catch it, because the template files hand-write JSON and the schema lives in an unrelated module with no type relationship between them. What catches it is asking the actual editor whether the actual document is valid, which is now a test, and which is a good rule generally: content that ships as code should be validated by the thing that will have to read it.