Definition
When you write the same metadata (title · description · date · tags and other info about a post) separately into multiple search- and share-oriented outputs, the values inevitably drift apart from one another; this is the principle you use to prevent that. The core idea is to keep that information in exactly one place (a single source).
The principle: keep metadata only in one authoritative source (e.g., the frontmatter at the top of the content file — the block of meta info written between --- at the very top of the file), and automatically generate the outputs derived from it at build time from that source. Derived outputs are things like the sitemap (the XML that tells search engines the list of pages), RSS (a feed listing posts for subscription), OG (meta tags like og:title · og:image used to show a link as a card on social platforms), and JSON-LD (structured data that Google understands). This way, editing just one thing always regenerates the rest with the same values ("deterministic" generation — the same input always yields the same output).
Why it matters
If you store the same meta redundantly in multiple places (a runtime DB, a separate config, hardcoded), drift creeps in over time as the values diverge, and it becomes ambiguous which one is the truth. Keeping a single source structurally guarantees consistency, and the derived outputs become the result of a regenerable, deterministic function. In a static-generation (SSG) environment, you can scan the content and settle the meta at build time even without a runtime DB.
How it works
- Treat the content file's frontmatter as the single source and validate it with a schema.
- At build time, scan
content/→ parser (gray-matter, etc.) → normalize with a schema (Zod, etc.). - From the normalized meta, a build-time function generates page metadata · sitemap · robots · RSS · JSON-LD.
- Use auxiliary generation like AI only to suggest fills for blanks such as an empty description, and write the finalized value back into the source so it's re-absorbed deterministically.
Practical application
Setting an invariant that keeps the directory structure and the frontmatter aligned (e.g., directory category === frontmatter category) lets you block classification drift at build time too.
Tradeoffs
A single source has high consistency · reproducibility, but a build-time decision doesn't fit meta that changes frequently and dynamically (real-time counts, etc.). A runtime DB is strong at dynamism but takes on drift · non-determinism if it breaks the SSOT. SSOT suits static content meta; a runtime source suits truly dynamic data.
When not to use
Don't put inherently runtime-changing values — view counts, stock, real-time prices — into a build-time single source. Keep such values in a separate runtime source, apart from the static meta.
Common mistakes
- Keeping the same meta in both the frontmatter and a runtime DB without agreeing which one is the truth.
- Promoting AI-generated values to the source without review, polluting the single source.
- Not wiring schema validation into the build pipeline, so missing required fields leak through to runtime.
Related concepts
- serverless-stateless-execution — adjacent to the choice of avoiding a runtime-resident DB and settling things via build outputs.