Function kernel_rules 

pub fn kernel_rules(config: &WorkspaceConfig) -> Vec<FieldRule> 

prov’s own frontmatter keys — the ones every document may carry whether or not the workspace declared anything.

The fields block says what this workspace controls; the kernel is what prov reads regardless (spec §1). Without these, id and content_hash arrive at a schema-driven editor as anonymous text boxes beside mood, and the root’s whole prov: policy block arrives as an untyped nested map — a document schema that knows about audience and not about id has the story backwards.

Two of them are more than presentation:

• attachment is a boolean, and typing attachment: yes where prov wants true is a marker prov does not honour.
• prov: is the same vocabulary as the config document, nested one level (spec §3: “the identical keys sit at top level” in a config document, with no prov: wrapper). So it is governed by config_rules with every pattern prefixed — one vocabulary, stated once, reaching both of its homes. A workspace that inlines its policy gets the same pickers as one that keeps a prov.yaml.

What is not here is a Consequence on any of it. These keys are managed rather than costly — see Facet::managed, which is the question a frontend asks before offering an edit at all.