> ## 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.

# Items - User manual

Items are the fundamental elements used to describe a product.
They represent concrete parts of a system—such as components, subsystems, functions, interfaces, or logical groupings—and are where most engineering data lives.
Items exist inside a product’s **draft** and are included in versions and baselines through the product lifecycle.

## Item hierarchy

Items are organized in a **tree structure**. This hierarchy lets you model systems top-down:

* root items represent high-level parts of the system

* sub-items represent decomposition into smaller or more specific elements

The hierarchy is purely structural. It helps with organization and navigation, but does not impose behavior or semantics by itself. You are free to model systems at any depth and in any structure that makes sense for your domain.
Items can be:

* added at the root level

* added as sub-items of existing items

* moved to a different parent at any time

## Duplicating items

Duplicating an item creates a copy of it inside the same product. When duplicating, you can choose whether to copy:

* sub-items

* properties

* documents

* dependencies

The duplicated item is independent from the original. Changes made after duplication do not propagate between them.
Readable IDs of duplicated items are automatically adjusted to remain unique.

## Attachments

Attachments let you associate external files with an item. They are typically used to store:

* datasheets

* drawings

* specifications

* reference documents

You can upload PDFs and images, which are previewed directly in the interface. Other file types can be uploaded and downloaded, but are not previewed inline. Attachments belong to the item and persist across versions. They do not change the structure or behavior of the product, but provide essential context and supporting evidence.

## Comments

Comments allow discussion directly on an item. They are used to:

* document decisions

* ask or answer questions

* clarify assumptions

* leave notes for reviewers

Each comment is associated with an author and timestamp. Comments do not affect versioning or baselines, but they provide important context around *why* data exists or changed.

## Items’ activity

The activity view shows a chronological log of actions related to an item. This includes events such as:

* item creation

* property changes

* comments

* other relevant updates

The activity log helps you understand how an item evolved over time and who was involved, without needing to inspect version diffs.

## Best practices

A few general guidelines when working with items:

* Keep items focused on a **single concept**

* Use hierarchy for structure, not meaning overload

* Store decisions and rationale in comments

* Use attachments for source material, not raw data

* Treat readable IDs as stable references, not labels

Clear item modeling makes versioning, reviews, and traceability significantly easier later.