Use Case: Recursive PURIS Anonymized Data

The recursive PURIS path is a partner-to-partner traversal for anonymized PURIS aspect models. The root caller starts a recursive job with a globalAssetId, an openingId, the recursive PURIS use case and the anonymized aspect bundle. This use case is different from the ESS recursive investigation described in the adjacent ESS runtime section.

The supported use case is PURIS_ITEM_STOCK_ANONYMIZED_RECURSIVE. It traverses SingleLevelBomAsPlanned version 3.0.0 and collects anonymized PURIS payloads. Only the asPlanned lifecycle is supported.

Participants

Participant	Responsibility
Root caller	Starts the recursive job and reads the final aggregated result.
Local IRS	Validates the chain opening grant, resolves the local digital twin, reads the local BOM, filters direct children by grant and coordinates child requests.
Child IRS	Receives a recursive REQUEST, validates the same chain opening, processes its direct children and returns a recursive RESPONSE to the parent.
EDC	Provides catalog, contract negotiation, data transfer and notification transport between partners.
Digital Twin Registry	Provides shell descriptors and submodel descriptors for BOM, PartTypeInformation and anonymized payload aspects.
Submodel provider	Provides the BOM and anonymized PURIS aspect payloads through the EDC data plane.

Participant

Responsibility

Root caller

Starts the recursive job and reads the final aggregated result.

Local IRS

Validates the chain opening grant, resolves the local digital twin, reads the local BOM, filters direct children by grant and coordinates child requests.

Child IRS

Receives a recursive REQUEST, validates the same chain opening, processes its direct children and returns a recursive RESPONSE to the parent.

EDC

Provides catalog, contract negotiation, data transfer and notification transport between partners.

Digital Twin Registry

Provides shell descriptors and submodel descriptors for BOM, PartTypeInformation and anonymized payload aspects.

Submodel provider

Provides the BOM and anonymized PURIS aspect payloads through the EDC data plane.

Overall flow

Processing steps

The sequence diagram shows the technical message flow. The following table summarizes it as ten business processing phases.

Phase Actor Action

Phase	Actor	Action
1	Root caller	Starts a recursive job via `POST /irs/recursive/jobs`.
2	IRS	Validates the request, resolves default values and validates the local chain opening grant before creating the root job.
3	IRS	Looks up the root shell in the Digital Twin Registry and selects the supported `SingleLevelBomAsPlanned` descriptor. If no BOM descriptor is present, the asset is treated as a leaf.
4	IRS	Reads the BOM submodel through the EDC submodel access flow and filters direct children by the local chain opening grant. Filtered partners are not exposed to the caller.
5	IRS	Creates and persists one direct child branch per valid, grant-allowed BOM child.
6	IRS	Sends recursive REQUEST notifications to allowed direct children through EDC.
7	Child IRS	Performs the same processing for its own direct children. It collects its own anonymized aspect payloads unless it is the root job.
8	Child IRS	Remains in `AWAITING_CHILDREN` until all expected child responses are available or the child response deadline is processed.
9	Child IRS	Aggregates its local node, child nodes and tombstones and sends a recursive RESPONSE to its parent.
10	Root IRS	Aggregates all received direct child results and exposes the final result via `GET /irs/recursive/jobs/{jobId}`.

Root caller

Starts a recursive job via POST /irs/recursive/jobs.

IRS

Validates the request, resolves default values and validates the local chain opening grant before creating the root job.

IRS

Looks up the root shell in the Digital Twin Registry and selects the supported SingleLevelBomAsPlanned descriptor. If no BOM descriptor is present, the asset is treated as a leaf.

IRS

Reads the BOM submodel through the EDC submodel access flow and filters direct children by the local chain opening grant. Filtered partners are not exposed to the caller.

IRS

Creates and persists one direct child branch per valid, grant-allowed BOM child.

IRS

Sends recursive REQUEST notifications to allowed direct children through EDC.

Child IRS

Performs the same processing for its own direct children. It collects its own anonymized aspect payloads unless it is the root job.

Child IRS

Remains in AWAITING_CHILDREN until all expected child responses are available or the child response deadline is processed.

Child IRS

Aggregates its local node, child nodes and tombstones and sends a recursive RESPONSE to its parent.

Root IRS

Aggregates all received direct child results and exposes the final result via GET /irs/recursive/jobs/{jobId}.

BOM descriptor handling

The recursive PURIS path supports exactly SingleLevelBomAsPlanned version 3.0.0. If no SingleLevelBomAsPlanned descriptor is present, the current asset is a leaf and no child branches are created. If a SingleLevelBomAsPlanned descriptor is present with an unsupported version, the branch fails with a sanitized tombstone. The branch also fails with a sanitized tombstone when the supported descriptor is ambiguous or does not expose a usable EDC endpoint. For a root job, these descriptor errors fail the root job itself because there is no parent branch.

Grant boundary

The recursive path does not discover and traverse the complete BOM without an explicit chain opening grant. Every hop validates a grant before it can continue. The grant only contains direct child partners for the local hop. This means a tier knows:

the parent that called it
its own direct children from its BOM
the direct children allowed by the local grant

It does not know the full upstream or downstream chain. Grant-filtered partners are local information and must not be represented in parent-facing tombstones or counters.

Payload boundary

Productive recursive PURIS jobs use anonymized PURIS aspect models. The IRS does not transform non-anonymized PURIS payloads into anonymized payloads. Instead, it requests only the allowed anonymized aspect semantic IDs from the provider.

The result model contains a material tree:

childItems for BOM child nodes
materialNumber and materialName from PartTypeInformation, if available
quantity from the BOM relationship
items for collected anonymized aspect payloads at the material node
tombstones for sanitized errors associated with the material node

Root-level tombstones are used for failures that cannot be assigned to a specific material node.

Timeouts

The root job has one overall deadline. Each child receives an expected response timestamp before that deadline. The safety buffer gives each tier time to aggregate and send its response upstream.

If a child does not answer before the child response deadline, the parent marks the child branch as timed out and continues aggregation. A timeout therefore results in a terminal response with a partial or failed business result instead of an indefinitely running job.

Job phases

The recursive path stores its own job phase and maps it to the generic IRS job state in the API response.

Recursive phase API job state Meaning

Recursive phase	API job state	Meaning
`GRANT_CHECKED`	`RUNNING`	The request and local chain opening grant have been accepted. BOM resolution, partner filtering and local processing are queued or running.
`AWAITING_CHILDREN`	`RUNNING`	Child requests were sent and the job waits for all expected child responses or for the child response deadline.
`COMPLETED`	`COMPLETED`	The recursive job is terminal and a recursive result is available. The business result can still be `COMPLETE`, `PARTIAL` or `FAILED`.
`FAILED`	`ERROR`	The recursive job is terminal because validation, grant handling, traversal, persistence or deadline handling failed the job.

GRANT_CHECKED

RUNNING

The request and local chain opening grant have been accepted. BOM resolution, partner filtering and local processing are queued or running.

AWAITING_CHILDREN

RUNNING

Child requests were sent and the job waits for all expected child responses or for the child response deadline.

COMPLETED

The recursive job is terminal and a recursive result is available. The business result can still be COMPLETE, PARTIAL or FAILED.

FAILED

ERROR

The recursive job is terminal because validation, grant handling, traversal, persistence or deadline handling failed the job.

Result status

Status Meaning

Status	Meaning
`COMPLETE`	The aggregation finished without tombstones. The material tree can still be empty, for example when the requested root asset is a leaf and root payload collection is not part of the supported PURIS use case.
`PARTIAL`	At least one tombstone is present and the material tree still contains usable data.
`FAILED`	No usable material tree could be produced, or the job was failed by validation or deadline handling.

COMPLETE

The aggregation finished without tombstones. The material tree can still be empty, for example when the requested root asset is a leaf and root payload collection is not part of the supported PURIS use case.

PARTIAL

At least one tombstone is present and the material tree still contains usable data.

FAILED

No usable material tree could be produced, or the job was failed by validation or deadline handling.

The technical job state and the business result status are intentionally separate. A job can be technically COMPLETED while its result.resultStatus is FAILED.

Operational limits

The recursive job store has no API delete operation, so persisted jobs must be removed through the configured blob-store retention. For MinIO this requires a lifecycle rule on the jobs bucket. The recursive path should be operated with one IRS replica unless an external mechanism serializes updates to the same persisted recursive job. Large chains can create large result trees because no recursive tree-size or payload-size limit is enforced by the recursive aggregation. The notification endpoint also has no recursive request-size limit; large incoming notifications should be limited by the surrounding runtime or ingress setup.

Cross-cutting contracts

State consistency, message correlation, notification validation, privacy and restart recovery apply across all recursive processing steps. They are described in Recursive IRS concepts.