Treat, assess, reuse — every step with its evidence

A removed airbag looks flawless. So does a belt tensioner. The condition grade “very good” is correct and completely irrelevant to the question of whether the part may be refitted. Keeping both in one field eventually sells a safety-relevant part because it looked good.

The treatment stages are therefore built as a sequence with prerequisites: the permit is verified before treatment; parts are separately assessed for reuse safety; and the remaining body can only be compacted once the prerequisite tasks are done.

What this case requires

• A valid treatment permit for the site. It is verified, not assumed; the verification records time and method.
• Tasks kept as tasks. A depollution completed only in someone’s head produces no material flows.
• Measured values wherever quantities arise. The task completions take quantities and measurements — without them the material flow lacks its basis.
• An attestation for the compaction. That no parts remain to be removed has to be declared by somebody.

The sequence

The table names the responsible call per stage and what exists afterwards. The reasoning for why a stage cannot be skipped follows below it.

Why each stage is needed

1. Verify the permit. POST /compliance/facilities/{id}/treatment-permits/{permitId}/verify records time and method of the check. A permit sitting in a folder is not a verified permit — and in an audit what counts is when somebody last looked.
2. Complete the treatment task. POST /compliance/treatment-tasks/{id}/complete takes result, quantities, measurements and outputs with assetType and, where applicable, positionCode. Depollution thereby produces the material flows to be accounted for later itself — instead of estimating them afterwards.
3. Assess the part. POST /compliance/parts/{id}/assessments carries result, reuseSafetyStatus, condition, defects and the tests performed. Reuse safety is its own field, separate from the commercial grade. Precisely this separation prevents selling a safety-relevant part on the basis of its appearance.
4. Triage the battery. POST /compliance/batteries/{id}/triage takes battery type, damage indicators, measurements and decision. This stage comes before any movement: a damaged high-voltage battery is not stored first and assessed afterwards.
5. Compact the remaining body. POST /compliance/bodies/{id}/compact requires the prerequisite tasks and an attestation that no parts remain to be removed. Compaction is irreversible, which is why it comes last and not wherever space is needed.

curl -X POST \
  -H 'Cookie: __Host-tapinomahub_session=<SITZUNG>' \
  -H 'X-CSRF-Token: <CSRF_TOKEN>' \
  -H 'X-Compliance-Organisation-Id: <ORGANISATION>' \
  -H 'If-Match: "<etag>"' \
  -H 'Idempotency-Key: verdichtung-karosse-88213' \
  -H 'Content-Type: application/json' \
  -d '{"compactedAt":"2026-09-12T15:00:00Z","areaOrFacilityId":"<facilityId>","noFurtherPartsAttestationId":"<attestationId>","prerequisiteTaskIds":["<taskId>"],"evidenceIds":["<evidenceId>"]}' \
  'https://api.tapinomahub.com/compliance/bodies/<id>/compact'

What you end up with

In the end a vehicle is treated, and every removal, every release and every irreversible action knows its person and its time. The parts going into sale carry their own statement on reuse safety.

Where to find this in the documentation

The binding field lists, error codes and sample responses live in this surface’s OpenAPI contract at docs.tapinomahub.com (tapinoma-compliance). All use cases arranged by surface and role: overview of the use cases.