https://github.com/omarish/metadata-enforcer

• No structure without freedom (a relational database is probably not the right place for free-form writing)
• No freedom without structure (otherwise you become MongoDB)

This is, in my opinion, something that Obsidian does really well. Fast and doesn't get in the way of what you're trying to do.

But metadata can be annoying to manage. And you'll never actually "find the time" to "correct" all your metadata.

$ journals ls -al | wc -l
     912

That's a lot of metadata. And metadata is a living/breathing thing. It also shouldn't get in the way of writing, that's why it's called meta. So the second best thing is to measure it, after all, what gets measured, might get managed.

Meet metadata-enforcer.

Folder with a lot of entries:

$ journals# ls
2026-07-19.md  2026-07-21.md  2026-07-23.md  2026-07-25.md  2026-07-27.md  2026-07-29.md
2026-07-20.md  2026-07-22.md  2026-07-24.md  2026-07-26.md  2026-07-28.md  2026-07-30.md

Make a columns.yaml file:

$ journals# metadata-enforcer init .
Wrote columns.yaml (11 field(s)). Review, then tighten as needed.

Run it whenever you want:

$ journals# metadata-enforcer .
Checked 12 file(s) against columns.yaml
All good.

https://github.com/omarish/metadata-enforcer

How it Works

json-schema 2020-12 under the hood

JSON-schema is a great idea, so metadata-enforcer uses the Draft 2020-12 spec under the hood.

I did make a few small modifications, like being able to specify column nullability in the column definition itself (foo.nullable: true), instead of having table properties (though I would like to add table-level constraints in the near future, like uniqueness and indexes).

Principles

• Sensible defaults (optional fields, type: string implied).
• Remain human in the config file; get to JSON Schema at runtime.
• Must be reliable. Our personal notes are sacred (v1 is read-only).
  • This is a project where if we had to choose between making a buggy release versus pushing back a ship date, we will push back the ship date.