# Fulfillment — auditability and traceability

## Allocation traceability

- Every **reserve / release** stores: `actor_user_id`, `correlation_id`, `idempotency_key` + `source`, link to **sales order line** (or allocation id) in metadata.
- Replay of the same allocation request returns the **same** reservation movement id in idempotency payload.

---

## Fulfillment traceability

- Every **consume + stock_out** pair shares one **`correlation_id`** per ship attempt.
- Shipment / pick records store: `inventory_stock_movement_id(s)`, `reservation_movement_id` (consume), `tenant_id`, `warehouse_id`, `item_id`, **qty**.

---

## Correlation IDs

- One correlation id per **user gesture** or **API submit**; propagated to reservation, stock, and logs.
- Child jobs inherit parent correlation; optional `parent_fulfillment_id` for trees.

---

## Customer / order references

- Stable **customer id** and **order number** on headers; **external marketplace order id** in metadata for integrations.
- Never log secrets (tokens); log **opaque** partner ids only.

---

## Correction traceability

- Cancellations, short ships, and **re-ships** use **new** movements with links to `corrects_*` ids and **reason codes**.
- No silent overwrite of posted fulfillment facts.

---

## Observability

Structured events (examples):

- `sales.allocation_failed`
- `sales.fulfillment_posted`
- `sales.fulfillment_mismatch_detected`
- `sales.reservation_replay`

Each includes `tenant_id`, `correlation_id`, `order_id`, `severity`.

---

## Critical stance

**Outbound operations must remain fully traceable** — if an operator cannot answer “which stock movement shipped this line?” the design is not done.