What this is

This is a knowledge bundle in Open Knowledge Format (OKF) v0.2, an open, vendor neutral specification published by Google Cloud: v0.1 in June 2026 and v0.2 in July 2026, which added the provenance and trust fields this bundle now uses. OKF represents knowledge as a directory of markdown files with YAML frontmatter. Every file is a concept. The file path is the concept identity. Concepts link to each other with ordinary markdown links, which turns the directory into a graph. There is no required tooling: if you can read a markdown file, you can read this bundle; if you can clone a git repository, you can ship it.

Conformance

Every concept file opens with a frontmatter block with a required type field and usually title, description and tags. Provenance and freshness use the v0.2 trust fields. generated records who produced the content and when, with the spec’s actor convention: agents as producer/version, humans as human:<id>. sources lists the external material a concept draws on, each entry with an id, a resource URL and a title; where a page attributes individual claims, it uses markdown footnotes whose labels match those sources ids. The fast-moving reference concepts also set a stale_after date marking when their external facts are due a re-check. No concept yet has a verified record, which under the spec’s derived trust tiers leaves the bundle reading as unverified; a human review would be recorded as verified: { by: human:<id>, at: <date> }. The reserved filenames index.md (a directory listing for progressive disclosure) and log.md (a chronological change history) appear at the bundle root and in some subdirectories. Cross links are bundle relative, beginning with a slash.

Broken links are intentional

Broken links are permitted by the spec and simply mark knowledge not yet written.

Where the content comes from

This is a general practitioner reference for email, lifecycle and CRM marketing, synthesised from authoritative sources rather than copied from any single one:

  • Standards and regulators for the mechanics and the law: the IETF RFCs; Apple and Google platform documentation; the FTC, ICO and FCC.
  • Recognised industry and research sources for the practice: deliverability, design, benchmark and measurement references such as Litmus, Campaign Monitor, Klaviyo, HubSpot, Baymard and Word to the Wise, plus the academic literature on extraction, bandits and uplift.
  • The platform behaviours, research and regulations these draw on are mirrored into references as first-class concepts, with the specific sources cited in each concept.

How to navigate

The bundle is organised around the work: the principles that set the stances, the foundations that hold the cross-channel operations (data, segmentation, lifecycle, content, automation, tooling), the channels you send through and the measurement layer that proves incrementality and sizes experiments. The references hold the external platform behaviour, research, legislation and a glossary. The root index maps the lot; start with the layer your question sits in and follow the cross links.

Reading it in Obsidian

Nothing here requires an app: any text editor or the GitHub file view reads the bundle fine. A reader built for linked markdown makes the graph easier to walk, though. Obsidian, a free, local markdown application, fits the bundle’s conventions well: cross links become click-through navigation; a backlinks pane lists the concepts that link to the one you are reading; the graph view draws the whole bundle at once.

Clone the repository, then in Obsidian choose ‘Manage vaults’ and use ‘Open folder as vault’ to select the cloned folder itself, the one containing the root index.md.1 The folder choice matters. Because Obsidian resolves link paths from the vault root2 and this bundle’s cross links resolve from the bundle root, the two must be the same folder. Opening a parent directory instead points every cross link at a path that does not exist. So does nesting the bundle inside an existing vault.

Once the vault is open, each concept’s frontmatter displays as properties, with the callouts and footnotes rendering as written. Obsidian keeps its own settings in a hidden .obsidian folder at the vault root. That folder is local state, not part of the bundle; keep it out of any pull request, for instance by adding .obsidian/ to .git/info/exclude in your clone, which ignores it without changing the repository.

Footnotes

  1. Obsidian Help, Manage vaults. Creating a vault from an existing folder and the .obsidian settings folder.