> ## Documentation Index
> Fetch the complete documentation index at: https://docs.poelis.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Properties - User manual

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.