Validation

Every document is checked against its type on each save and on each publish. A problem is an error, which stops the action, or a warning, which is shown as advice and stops nothing. Each problem has a path (stages[2].title, meta.description) so the admin, the content API and the MCP point at the exact control, inside collapsed repeater items too.

Save and publishCopy Anchor Link

A draft must be able to stop mid-work, so a save checks less than a publish.

Publishing in one locale checks that locale’s view of the document.

Required fieldsCopy Anchor Link

fields:
  - { name: title, type: text, required: true }
  - { name: summary, type: text, required: true, required_in: all }
  - { name: legalNotice, type: portable_text, required: true, required_in: [en-GB, cy-GB] }

required: true makes a field necessary to publish. required_in says in which locales, and applies only with required: true:

The default is deliberate: requiring every locale blocks publishing until everything is translated.

A value is empty when it is missing, a string of only spaces, an empty list, or an empty object. false is a value, so required on a boolean does not force it to be true. The message is This field is required with code required.

Conditional fieldsCopy Anchor Link

fields:
  - { name: bookingRequired, type: boolean }
  - name: bookingUrl
    type: link
    kinds: [{ of: url }]
    visible_when: "bookingRequired == true"
    required_when: "bookingRequired == true"

They are separate on purpose: a field can be visible and optional, or required by a condition while visible for another. Both read sibling fields only: a top-level field reads other top-level fields, and a field inside a repeater item or a block reads the other fields of that item.

The expression languageCopy Anchor Link

visible_when, required_when and validation rules share one small language, parsed and type-checked when the configuration loads.

• Operators: ==, !=, <, >, <=, >=, in, not in.
• Literals: strings in single or double quotes, numbers, true, false, and empty (with == and != only). A list after in holds literals only.
• |length is the only filter: a string’s length in characters, or a list’s length. It compares with a number.
• No function calls, no arithmetic, no paths into other documents.

engine-dmo check type-checks every expression once all schema files are read:

Comparisons between two values are numeric when both are numbers and textual otherwise. Two date fields compare correctly as text (YYYY-MM-DD). A datetime is a structured value, so compare datetime fields only with == empty or != empty, and use date fields where a rule must order two moments.

Validation rulesCopy Anchor Link

Rules check several fields together. They sit in the type’s validation: list:

validation:
  - rule: "endDate == empty or endDate >= startDate"
    message: { en-GB: The end date must be on or after the start date. }
    fields: [endDate]

  - rule: "isAccessible == false or accessibility != empty"
    message: { en-GB: Describe the surfaces and gradients before marking the walk accessible. }
    fields: [accessibility]
    on: publish

  - rule: "summary == empty or summary|length >= 60"
    message: { en-GB: A summary under 60 characters reads poorly in search results. }
    fields: [summary]
    severity: warning

Rules read the document’s top-level fields. A type with variants runs a rule only in the variants that have every field it names. The code of a rule’s problem is cross_field. Rules may be spread across the files of a type split over several files.

What a problem looks likeCopy Anchor Link

Through the content API and the content MCP, each problem is reported with:

Each field type’s codes are on its page under Fields.

Checking without savingCopy Anchor Link

engine-dmo content create --type walk --data '{...}' validates as the admin’s save does and refuses on an error; add --publish to run the publish checks too. Both need a database. The content MCP can report a document’s publish checks without publishing (Content MCP).