Properties and the Type System
Properties are what transform Farkitect models from simple diagrams into structured, queryable data. They bridge the gap between “a box on a canvas” and “a data record with typed fields.”
The M2/M1 Property Flow
Section titled “The M2/M1 Property Flow”Properties follow the same M2-defines, M1-fills pattern as everything else in Farkitect:
- At M2, you define a property on an element type — specifying its name, data type, whether it’s required, and optionally a default value
- At M1, every instance of that element type carries the property — users fill in values
This means property structures are consistent across all instances of a type. Every Application Component has the same set of properties. Every Business Process has the same set. The M2 definition guarantees this.
Data Types
Section titled “Data Types”Properties can be one of these primitive types:
| Type | Stores | Example values |
|---|---|---|
| String | Short text | “FQ Vessels”, “Active”, “High” |
| Integer | Whole numbers | 42, 0, -1 |
| Real | Decimal numbers | 3.14, 99.99 |
| Boolean | True/false | true, false |
| Date | Calendar date | 2026-03-15 |
| DateTime | Timestamp | 2026-03-15T14:30:00 |
| UnlimitedNatural | Non-negative integer or unlimited (*) | 0, 1, * |
Properties can also use an Enumeration type — a controlled set of named values defined at M2.
Enumerations
Section titled “Enumerations”An enumeration is a property type with a fixed list of allowed values. Each value has a display name (shown to users) and a machine value (stored in the model).
For example, a “System Status” enumeration:
| Name | Value |
|---|---|
| Planned | planned |
| Active | active |
| Retiring | retiring |
When a property uses an enumeration type, the UI renders it as a dropdown — users select from the predefined list rather than typing free text. This ensures data consistency across the model.
Enumerations are defined in the M2 metamodel’s Enumerations package and can be referenced by any property in the same metamodel.
Multiplicity
Section titled “Multiplicity”Every property has a multiplicity that specifies whether it’s required or optional:
| Multiplicity | Meaning |
|---|---|
| 1..1 | Required — must have a value |
| 0..1 | Optional — may be empty |
Required properties are visually indicated in the Properties panel. A model element with missing required properties may trigger validation warnings from the integrity checker.
Default Values
Section titled “Default Values”Properties can specify a default value at M2. When a new M1 instance is created, the property is pre-filled with this value. Users can change it, but the default provides a sensible starting point.
Defaults are especially useful for enumerations — for example, defaulting a System Status to “Active” so users only need to change it when something is planned or retiring.
Format Hints
Section titled “Format Hints”String properties can include format hints that affect how they’re displayed and edited:
| Hint | Effect |
|---|---|
| multiline | Renders as a textarea instead of a single-line input |
| url | Renders as a clickable link |
| Renders as a clickable mailto link |
Format hints don’t change the stored data — the value is still a string. They change how the UI presents and interacts with it.
Properties on Relationships
Section titled “Properties on Relationships”Properties aren’t limited to elements. Relationship types can also define properties — useful for capturing metadata about the connection itself.
For example, a “Belongs To” relationship might have a “Start Date” property recording when a person joined a team. A “Serving” relationship might have a “Service Level” property.
Relationship properties appear in the Properties panel when a relationship edge is selected on the Canvas.
Where Properties Appear
Section titled “Where Properties Appear”Property values are visible and editable in multiple places:
| Surface | How properties appear |
|---|---|
| Properties panel | Full edit form when the element is selected |
| Catalogs | As table columns with inline editing |
| Diagram nodes | In property compartments (if the M2 notation includes them) |
| Exported .farki files | As propertyValues objects on each element |
This multi-surface visibility is one of the key benefits of structured properties — the data you enter in the Properties panel is immediately available in catalogs for analysis, on diagrams for visual context, and in exports for sharing.
Validation
Section titled “Validation”Farkitect validates property values against their M2 definitions:
- Type checking — a Date property rejects non-date values
- Required checking — required properties flag incomplete elements
- Enumeration checking — enumeration properties only accept defined values
Validation happens in the UI (immediate feedback when editing) and in the integrity checker (model-wide sweep for violations).