Skip to main content
Properties are the smallest unit of information in Poelis. They describe facts, values, or states of an item and are used to capture all measurable or declarative aspects of a system. Examples of properties include dimensions, parameters, limits, materials, operating ranges, statuses, dates, or configuration values. Properties always belong to an item and are versioned as part of the product lifecycle.

​
Property fields

Every property consists of a small set of core fields.

​
Name

The name is a human-readable label describing what the property represents. It should be descriptive and unambiguous, since it is what users see when navigating items.

​
Type

The type defines how the property’s value behaves. Supported types include:
  • Text – free-form textual information
  • Number – numeric values with unit
  • Matrix – structured tabular values with unit
  • Date – calendar dates
  • Status – discrete, predefined states
The type determines how the value is stored, displayed, and validated.

​
Value

The value is the actual content of the property. Depending on the type, this may be:
  • a number
  • a text string
  • a date
  • a status value
    • Draft
    • Under Review
    • Done
  • a structured matrix
Values are versioned together with the product and reflect the state of the system at a given point in time.

​
Category

The category defines for numbers and matrices what kind of physical or logical quantity the property represents, such as temperature, pressure, voltage, or resistance. Categories are used to:
  • validate units
  • enable conversions
  • ensure consistency across properties

​
Unit

The unit specifies how a numeric value is measured. Units must be compatible with the selected category. For example, a temperature category supports units like °C or K. Units make properties explicit and comparable, and are required for conversions. Numeric properties support unit conversion. You can convert a value to another compatible unit directly from the property view. Conversions do not change the stored value unless you explicitly update it; they are provided to help interpretation and comparison.

​
Dependencies

Dependencies describe explicit relationships between numeric properties. They are used to express constraints such as limits, comparisons, or consistency rules between values. A dependency makes an assumption or requirement visible instead of leaving it implicit in documentation or comments. For example:
  • a maximum value must be greater than a minimum value
  • an operating limit must be below a safety threshold
  • two properties must match or remain within a defined range

​
How dependencies work

A dependency links two properties using a comparison operator. One property is treated as the dependent property, and its value is compared against another property using operators such as:
  • less than
  • greater than
  • less than or equal to
  • greater than or equal to
  • equal to
  • not equal to
Dependencies are evaluated based on the current values of the properties involved.

​
What dependencies are used for

Dependencies help you:
  • document design constraints directly in the data model
  • detect inconsistent or invalid configurations
  • make assumptions explicit and reviewable
  • support validation and future automation
They turn relationships that are often buried in text into structured, traceable rules.

​
Scope and behavior

Dependencies:
  • belong to properties
  • are defined in the draft version
  • are included in versions and baselines
  • do not modify values automatically
They express relationships, not calculations. Changing a value does not propagate changes to other properties; it only affects whether a dependency is satisfied.

​
Best practices

When using dependencies:
  • keep them simple and explicit
  • prefer direct comparisons over complex chains
  • use them for constraints, not derivations
  • document intent with comments when needed
Dependencies are most effective when they reflect real engineering rules that must always hold true.

​
Creating and editing properties

Properties are created and edited in the draft version only. You can:
  • add new properties to an item
  • edit names, values, units, and metadata
  • remove properties that are no longer needed
Published versions remain immutable and are not affected by later edits in the draft.