Module frontmatter 

Typed, order-preserving access to a concept’s YAML frontmatter.

OKF frontmatter is an open mapping: a few well-known keys (§4.1 of the spec) plus arbitrary producer-defined extensions that consumers MUST preserve when round-tripping. Frontmatter therefore stores the full Mapping verbatim and layers typed accessors on top, rather than deserializing into a fixed struct that would drop unknown keys.

v0.2 adds four families of well-known keys on top of the v0.1 core, all of them optional:

Family	Keys	Section
Core	type, title, description, resource, tags	§4.1
Provenance	sources, usage_window	§5.1
Trust	generated, verified	§5.2
Lifecycle	status, stale_after	§5.4/5
Computation	runtime, parameters, computation, executor, attester	§10.2

Absence is meaningful but never fatal: Frontmatter::status defaults to stable, Frontmatter::trust_tier to unverified, and a concept carrying nothing but type is fully conformant (§11).

Structs

Frontmatter

A concept’s frontmatter: an ordered key/value mapping with typed accessors for the well-known OKF fields.

Constants

KNOWN_FRONTMATTER_KEYS

Every frontmatter key the specification gives a meaning to, across all families. Anything else is a producer extension (§4.1).

LEGACY_FRONTMATTER_KEYS

Keys v0.2 retired but consumers may still encounter in v0.1 documents (§13.1). timestamp is superseded by generated.at.

PREFERRED_KEY_ORDER

The key order the reference implementation writes documents in (its _PREFERRED_KEY_ORDER): identity first, then lifecycle, trust, and provenance.

RECOMMENDED_FRONTMATTER_KEYS

Keys a producer should fill in before publishing, in the order Document::missing_recommended reports them.

REQUIRED_FRONTMATTER_KEYS

The only frontmatter key OKF always requires (§4.1): a concept carrying nothing but type is fully conformant (§11).