Skip to content

Overriding a reserved key

A few standard Pandoc keys carry the wiring behind the layout your target selects, so Keystone reserves them. Set one in pandoc.yaml and the build stops while resolving configuration, naming the key.

What it looks like

Bringing your own stylesheet by setting css:

# pandoc.yaml
css:
  - assets/my-styles.css

ERROR: pandoc.yaml overrides Keystone-owned metadata
  These keys are owned by Keystone and wire the build — remove them from pandoc.yaml:
    - css

Override more than one and the message lists each:

ERROR: pandoc.yaml overrides Keystone-owned metadata
  These keys are owned by Keystone and wire the build — remove them from pandoc.yaml:
    - documentclass
    - header-includes

What it means

css and header-includes pull in the core stylesheet and LaTeX preamble; documentclass is the class the target owns. Pandoc reads pandoc.yaml last, so a value there wins — overriding one drops that wiring and ships broken output or fails with an opaque LaTeX error. Keystone rejects it up front. Presence alone triggers the error: an empty css: still counts.

How to fix

Remove the named key from pandoc.yaml. Choose your layout with target (see Targets); the reserved keys are listed under Reserved keys.

There is no author stylesheet hook. Style through the levers you do have: metadata for the book's overall look — fontfamily, fontsize, linestretch, the link colors, code-theme (see Typography) — and shortcuts for styling specific content, which compose into reusable styled blocks.

  • Missing or invalid metadata — the other stop while resolving configuration: a field the target requires, an unknown target, or a value Keystone can't interpret.