Conformance model

Three hard conditions

The spec defines conformance in section 9, and okf validate implements it exactly. A bundle is non-conformant when any of these fails:

1. 9.1 a non-reserved file has no parseable YAML frontmatter block;
2. 9.2 a frontmatter block has an empty or missing type;
3. 9.3 a reserved file breaks its rules: a nested index.md with frontmatter, a root index.md carrying more than okf_version, or log.md date headings that are not ISO YYYY-MM-DD.

That is the whole list. Everything else the spec recommends is a warning: missing title, description, or timestamp, tags that are not a list, an unparseable timestamp, and broken cross-links.

Why broken links cannot fail validation

Section 5.3 requires consumers to tolerate broken links, and that is a feature. In a living bundle, a link to a concept nobody wrote yet is recorded demand: okf lint counts those references and ranks the missing concepts as a backlog. A validator that rejected them would punish exactly the writing behavior the format wants to encourage.

Legal is not the same as good

validate and lint stay strictly separate, in the spec and in the gem:

Question	Verb	Nature
Is this legal OKF?	okf validate	binary, three hard errors, exit 1 on failure
Is it well curated?	okf lint	advisory findings across six categories, exit 0 by default

lint never emits conformance errors, and validate never rejects for curation problems. New checks land on the right side of that line, and exit codes keep the contract: 0 ok, 1 failing bundle, 2 usage error. The curation model covers the other half.

Conformance in the library

The same gate runs in-process. OKF::Bundle#validate returns the result object the CLI prints, and OKF::Bundle::Folder#save validates before publishing, so the library API never writes a bundle that fails section 9 to disk.