Building blocks
Attributes
Attributes describe the runtime context fields that Messagevisor conditions can read. They give your conditional logic a shared schema instead of leaving it as unstructured ad hoc data.
What attributes are for#
Attributes help Messagevisor:
- lint segment and override conditions (catching wrong attribute names and type mismatches early)
- explain context usage in the Catalog
- keep conditional logic consistent across definitions
- make runtime context easier for humans to reason about
Attribute keys#
Like messages, attribute keys come from file paths relative to the attributes/ directory:
attributes/plan.yml -> planattributes/country.yml -> countryDescription#
Attribute files can have a description field to provide a human-readable description of the attribute. This is used in the Catalog and other UIs.
description: Country attributeType#
The type field is required for every attribute file. It defines the kind of value allowed for this attribute. The following examples show canonical combinations of type and relevant schema fields:
string#
description: Country codetype: string# below properties are optionalenum: - US - GB - NLminLength: 2maxLength: 2pattern: "^[A-Z]{2}$"boolean#
description: Whether user email is verifiedtype: booleaninteger#
description: User age in yearstype: integer# below properties are optionalminimum: 0maximum: 120double#
description: User's high-precision scoretype: double# below properties are optionalminimum: 0maximum: 100.0date#
description: User birthdatetype: dateobject#
description: Postal addresstype: object# below properties are optionalrequired: - street - cityproperties: street: type: string minLength: 1 city: type: string postalCode: type: string pattern: "^[A-Z0-9]{4,10}$"additionalProperties: falsearray#
description: User permission listtype: arrayitems: type: string enum: # optional - read - write - admin# below properties are optionalminItems: 1maxItems: 5uniqueItems: trueArchived#
When set to true it removes an attribute from normal lint and list operations:
description: Pro plan usersarchived: truePromotable#
When set to false it prevents this attribute from being copied during promotion:
description: Pro plan userstype: stringpromotable: falseUsing attributes in conditions#
Attributes are referenced by key in segment conditions and message override conditions. See Conditions for the full operator and composition reference.
description: Pro plan usersconditions: - attribute: plan operator: equals value: prodescription: Adult usersconditions: - attribute: age operator: greaterThanOrEquals value: 18For nested object attributes, use dot notation to reference sub-fields:
description: Dutch account usersconditions: - attribute: account.country operator: equals value: NLWhy this matters for conditions#
Most conditional authoring pain comes from context mismatch:
- wrong attribute name
- wrong value type
- one team thinks a field is a string while another uses a boolean
Attributes make those mistakes easier to catch during authoring instead of after runtime behavior drifts.
Attributes and tests#
Attribute behavior is usually tested indirectly through:
- segment tests (which test conditions that use attributes)
- message tests and target evaluation tests that pass
context
That is usually enough. You do not typically need attribute-only tests.
Examples#
Simple string attribute with enum values:
description: Runtime platformtype: string# optional: list of allowed valuesenum: - web - ios - androidInteger attribute with minimum:
description: User age in yearstype: integerminimum: 0String attribute with enum-restricted values:
description: Subscription plantype: stringenum: - free - pro - enterpriseObject attribute with nested properties:
description: User account metadatatype: objectproperties: country: type: string locale: type: stringArray attribute:
description: User permission listtype: arrayitems: type: string enum: - read - write - adminEdge cases and behavior notes#
Describe vs populate#
Attributes describe context, they do not populate it.
The schema tells Messagevisor what runtime context is supposed to look like. Your application, tests, or CLI inputs still supply the actual values using the SDK.
Simplicity over complexity#
If a condition can be expressed clearly with a few simple attributes, that is usually easier to review than one large nested object with lots of path-dependent logic.
For documentation purposes#
At runtime, the SDK does not validate context against attribute schemas. Attributes are purely authoring-time documentation and linting infrastructure.

