> ## Documentation Index
> Fetch the complete documentation index at: https://help.polygon-one.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Re-use systems (Art. 26)
> Document re-use systems under Art. 26/27 PPWR, link packaging units, confirm participation, admit members and report circulation figures
## Overview
As soon as a packaging unit is marked **reusable**, **Art. 26 PPWR** requires it to circulate in a **re-use system** — and **Art. 26(2)** requires a **written participation confirmation**. In Polygon One you document that system once and link your units to it.
You will find the area in the sidebar under **Packaging → Re-use systems**. The page is always visible, even when no system exists yet — the first system is created from there.
> "Re-use systems under Art. 26/27 PPWR — classification, evidence, circulation figures and the written participation confirmation for your packaging units."
**What makes a unit reusable** is the **Reusable packaging** toggle on the packaging unit: "Designed for reuse (Art. 3(6), Art. 11). Triggers the reuse-design duty and sets the conformity documents' retention period to 10 years." Only that toggle triggers the Art. 26 duty — and the unit then says so: "This unit is reusable. Art. 26 PPWR requires it to circulate in a documented re-use system."
## Your role in the system
Every system carries a role: **Own system** (you operate it yourself and there are as yet no other members), **Operator** (you operate it and have admitted members — you maintain the master data, publish versions and author the pool units) or **Member** (another company operates it: "This system is maintained by its operator. You are seeing the published version.").
## Documenting a system
**New system** opens **Document re-use system** — "Describe the system your reusable packaging circulates in. These details become part of your technical documentation (Annex VII)."
| Field | Guidance |
| ---------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **System name** | Required. |
| **Operator** | "Leave empty if you operate the system yourself." |
| **Ownership position** | "Describe who owns the reusable packaging while it circulates." |
| **Intended ownership transfer** | Where the system provides for a transfer. |
| **Loop type** | Open loop, closed loop or undetermined (see below). |
| **Established before 11 Feb 2025** | "Historical fact. The partial Annex VI exemption additionally requires an open loop." |
| **Description** | "Annex VI guidance: describe who takes part, how packaging is returned, collected and cleaned, and how it is inspected or reconditioned before refilling. Add the handover or ownership arrangements if they matter." The description may stay empty — "leaving it empty will leave an Annex VI guidance gap." |
### Save & adopt — the participation confirmation
At the end Polygon One asks you to **Confirm participation**:
> "With "Save & adopt" you declare in writing that you participate in this re-use system (Art. 26(2) PPWR). The confirmation is recorded with its date and shown in the technical documentation."
You have two options:
* **Save & adopt** — the details are frozen as a **version** and the participation is recorded with its date (**Participation confirmation (Art. 26(2))** → "Self-declared on …"). Only an adopted state is evidence.
* **Save only** — the details stay a draft. The system then shows **Not yet adopted**, and: "Saved changes are an operator draft. Members and DoCs use the last published version until you publish."
## Loop type and the Annex VI exemption
The **loop type** has three values: **Open loop** ("The packaging circulates between several market participants that are not a fixed group."), **Closed loop** ("The packaging returns to the same group of participants that placed it on the market.") and **Undetermined** ("The loop type remains undetermined until the participant group and ownership transfers are reliably established.").
The **partial grandfathering exemption under Annex VI Part A point 1** is only stated when **all five** conditions hold:
1. The loop is **open**.
2. The system was **established before 11 Feb 2025**.
3. The system is **self-managed** — the **Operator** field is empty.
4. The published system documentation contains an operational report on the **"Documented exemption"** documentation path.
5. That report is substantiated — it carries a **source reference** or **attached evidence**.
The app states the same conditions on the field: "An exemption is only valid for an open, self-managed system established before 11 February 2025 and needs substantiating evidence or a source reference." The establishment date alone is not enough — and neither is ticking "Open loop".
The exemption does **not** appear on the system page. It appears in the participating unit's [technical documentation (Annex VII)](/en/ppwr/dokumentation/technische-dokumentation), as the row **Partial grandfathering exemption (Annex VI)** with the value "Exempt from Part A point 1(a), (b)(i) and (ii), (e), (f) and (h)". What counts there is the **frozen** system documentation, not the current live state.
## Linking packaging units
A unit is linked **on the packaging unit itself**, in the **Roles & obligations** section: there you pick an existing system under **Re-use system**, create one via **… or create a new system**, or remove the link again (**Remove link**). For many units at once, the system page offers **Manage pool units**; every row gets an outcome there — **linked**, **already linked to this system**, **already linked to another system**, **not reusable**, **not found or no longer live**, or **pool copy — operator manages this link**.
Only units marked **reusable** can be linked, and a unit always belongs to **at most one** system.
### Status per unit
The packaging-units table shows a **Re-use system status** column per unit:
| Status | Meaning | Action |
| ------------------------------------- | --------------------------------------------------- | ---------------------------- |
| **Re-use system missing** | A reusable unit with no system. | **Assign a re-use system** |
| **System evidence incomplete** | A system is linked but the evidence still has gaps. | **Complete the evidence** |
| **Participation documented** | Everything is in place. | **Open the system evidence** |
| **Managed by GDB pool** | A pool copy from another operator. | **Open the pool evidence** |
| **System evidence outdated** | The system has changed since issuance. | **Review / re-issue** |
| **Not reusable** / **Not applicable** | The duty does not apply to this unit. | — |
## Versions, dossier and exports
Changes to the system only take effect through **Publish version**. The dialog says what that means:
> "The new version takes effect for N members. Declarations of conformity already issued will then read "documentation outdated" and should be re-issued. If nothing about the content changed, no new version is created."
The **Versions** section lists every version as **Active** or **Superseded** with its publication date.
Under **Exports** there are two documents, each in **German** or **English**: the **Participation confirmation** ("Standalone record of the written confirmation under Art. 26(2).") and the **Dossier version**, which is generated from an immutable frozen snapshot rather than from current live data. With no published version it reads "Publish a dossier version before exporting it."
## Members: two-sided consent
If you run a system for other companies, you admit them in the **Members** section — "Members receive design-locked copies of your pool units and read the published version of this system."
**Which of two paths applies is decided by the email address.**
**A new address** creates a workspace via **Add member**, invites its owner and distributes the pool units. You enter the **Company**, the **Contact email** and optionally the **Contact name**, and send with **Create and invite**; for many members at once there is **Paste list** (one line per member: company; email; contact name).
**An address that already belongs to an account** gets no second workspace. Instead you send a join request with **Request existing workspace**, which that company decides in its own workspace under **Participation requests** with **Approve** or **Decline** — "Approving records your participation, creates the membership and distributes design-locked copies of the current pool units." Under **Requests to existing workspaces** you track the status (**Pending**, **Approved**, **Declined**, **Cancelled**, **Expired**) and stop an open request with **Cancel request**.
**Nothing is linked without consent.** An operator cannot unilaterally make an existing company a member — participation is a declaration that company makes itself. Requests also expire after a deadline ("Expires on …").
The member list shows a status per company: **Active**, **Invite pending**, **Access disabled**, **No user account**, **No access (PPWR not enabled)** or **Removed**.
### Ending a membership
**End membership?** is explicitly not a data clawback:
> "Participation ends immediately. The member keeps its copies of the pool units — they become ordinary units, become editable again, and stop receiving updates. Declarations of conformity the member has already issued will then read "documentation outdated"."
If the same company later re-joins: "Re-joining reconciles the current pool design and bill of materials. Your own references, suppliers, articles, target markets and evidence stay unchanged; deleted copies stay deleted."
## Pool units at the member
As a member you receive copies of the operator's pool units. They carry the badge **Pool unit · system name** and are **design-locked** — as are the copy's **bill of materials** and its **component data**: "These details are set by the re-use system … and cannot be changed here. Internal reference, target markets, supplier, articles and your own placement volumes remain yours." Your component code and your own evidence stay yours as well.
**When the operator updates a pool unit, your copy is overwritten automatically.** Polygon One says so up front: "If the operator changes this pool unit, your copy is updated automatically. Declarations of conformity already issued will then read "documentation outdated" and must be re-issued — until then this unit's technical documentation is not available for download."
A mere **dossier publication** by the operator has a weaker effect: it marks the Declaration of Conformity **outdated** but does not block the technical documentation download.
If the operator retires a format from the pool, your unit stays: "The operator no longer runs this format in the pool. Your unit and its data remain — it simply stops receiving updates from the system."
## Evidence, circulation figures and reports
**Documents.** On the system page you file the evidence for the system. Members see it read-only with the provenance note "Published by … in dossier version …. Read-only pool evidence."
**Circulation figures.** Per **Year** you record **Trips**, the **Return rate (%)**, the **Calculation method** (**Measured** or **Estimated**) and, for an estimate, the **Estimation basis** ("Why estimation was necessary").
**An empty field means "not recorded" — not zero.** A missing entry is never read as "no trips".
**Operational reports.** Under **Operational reports** you record aggregate values "by system, category and period". Every report records **where** the figure came from — the **Documentation path**:
| Documentation path | When |
| --------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Structured data** | You enter the metrics yourself, in structured form. |
| **Uploaded authoritative report** | An existing evidence document is the source. |
| **External authoritative source** | An external source, named via the **Source reference**. |
| **Average estimate** | An estimate — requires a rationale ("Why was an estimate needed?"). |
| **Documented exemption** | "An exemption is only available for an open, self-managed loop before 11 February 2025 and needs substantiating evidence or a source reference." |
You record the **Period** (**Start** / **End**), the **Category**, optionally the **Material**, and the metrics — among them **Trips**, **Rotations**, **Return rate**, **Fillings**, **Reuses**, **Rejects** and **Sales units**. "Trips and rotations are different values."
A report may also be saved **without** a metric, to record the documentation path. And: "Art. 11 evidence coverage is informational and does not block DoC issuance."
## What a re-use system changes elsewhere
| Effect | Behaviour |
| ------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Retention period** | The **Reusable packaging** toggle sets the conformity documents' retention basis to **Reusable (10-year retention)** — the [Declaration of Conformity](/en/ppwr/dokumentation/konformitaetserklaerung) derives it from there rather than offering a choice. |
| **Technical documentation** | Where the unit participates in a system, the [Annex VII documentation](/en/ppwr/dokumentation/technische-dokumentation) gains a **Re-use system (Art. 26)** section with the system name, operator, system type, participation confirmation, system documentation and circulation figures. |
| **Declaration out of date** | When the operator publishes a new version, or participation ends, the card reports: "Cause: the re-use system moved on — a new system documentation was published, or the participation ended." |
| **Family Declaration of Conformity** | **Reusable (Art. 3(6))** and **Re-use system (Art. 26)** are equality dimensions: units in different systems — or partly linked, partly unlinked — cannot share one family declaration. |
| **Volume reporting** | Reusable packaging is **not subject to system participation** and is excluded from the [LUCID volume report](/en/ppwr/epr/mengenmeldung). |
| **Obligation catalogue** | Participation under Art. 26(2) is one of the few reuse duties Polygon One actually **assesses** — a live participation in a documented system whose operator has published its documentation satisfies it. The Art. 11 design duty is only **listed**, never assessed. |
## Deleting a system
**Delete re-use system?** — "The system and its evidence move to the trash. Linked units lose their participation record." A deleted system shows the badge **Deleted** and the note "This re-use system is deleted. Restore it to make changes."
**The members' design lock is released while it is deleted.** As long as the system sits in the trash, the members' pool copies are ordinary, editable units; they are not taken away from them. **Restoring** re-applies the lock — changes a member makes in the meantime are not protected from the operator's next update.
Where the system details appear in your Annex VII documentation.