Attributes & schemas
Attributes are the structured fields on a resource - rarity, alignment, population.
Lore is the prose on a resource. Attributes are the structured part: a character's alignment, a city's population, an item's rarity. Attributes are what lists filter and facet on, so they are worth setting up well.
A schema per kind
A schema defines which fields a kind has. This page covers fields, validation, and the ad-hoc fields that let you go off-script.
Each kind has a schema: the set of fields a resource of that kind can hold. You author the schema in the chronicle's taxonomy. A field has a name, a type, and a set of presentation choices. When you add a resource of that kind, its attribute editor is built from the schema.
A field's value is a string or a list of strings, typed by the field. A single-value field holds one, a multiple-value field holds several.
Field types and presentation
A field carries more than a datatype. It also carries how the value looks and how it is authored:
- an accent colour and an icon,
- whether it takes multiple values,
- whether it pins to the sidebar on the resource page,
- whether text is multi-line,
- for a select field, the options, each with its own label, icon, and colour,
- a default value, or a locked value the author cannot change.
Because presentation lives on the field, the same attribute looks the same on every resource that has it.
Colour is a name, not a hex
A field's colour is chosen from a named palette, such as violet or sky, not a raw hex code. The app resolves the name to the right value for the current theme, so your worlds stay legible in light and dark mode.
Values validate against the field
A field with a fixed set of options only accepts those options. Setting a value that is not in the set is rejected. Validation also respects family inheritance, so a value inherited from a family root counts as present on a variant.
Ad-hoc fields
A schema can never predict every field you will want. So a resource can carry ad-hoc fields of its own, outside its kind's schema. An ad-hoc field is a full, rich field, as capable as a schema field, but it belongs to the one resource rather than the whole kind.
A resolved attribute always tells you where it came from:
| Origin | Meaning |
|---|---|
schema | The field is defined on the kind's schema. |
adhoc | The field is defined on this resource only. |
orphan | The value exists but its field is no longer defined. |
Strict schemas
A kind can be marked strict, which forbids ad-hoc fields entirely. Use it for worlds that want every resource of a kind to share exactly one shape.
Promotion and rebinding
When an ad-hoc field proves useful across many resources, a config author can promote it into the kind's schema, so it becomes a shared field. A resource can also be rebound to a different schema of its kind. The escape hatch has a path back to structure.
Filtering and facets
A resource list can filter and facet on attribute values. A facet counts how many resources fall in each bucket, and the count honours inheritance, so it matches what the resource cards actually show. Select and boolean fields return facet buckets. Text fields are filter-only.
Where to go next
- Attributes live on the resources in Resources & kinds.
- See how the attribute model was designed in Resources & attributes.