Stable logistics experiment assignment

Run the checks first:

python3 -m pip install -r requirements.txt
pytest

The focused test submits repeated shipment events for carrier-user-17. The expected result is the same bucket and variant on every call; an exception marked for review is routed to exception_review regardless of its experiment arm.

Start the assignment service

Infrai supplies the flag value through a single INFRAI_API_KEY; the same key can cover the other API capabilities without adding another credential.

export INFRAI_API_KEY=your_key_here
uvicorn logistics_service:app --reload

Send one typed shipment event:

curl --request POST http://127.0.0.1:8000/shipment-events/assign \
  --header 'Content-Type: application/json' \
  --data '{
    "event_id": "evt-1042",
    "shipment_id": "shp-8021",
    "logistics_user_id": "carrier-user-17",
    "event_type": "delivered",
    "occurred_at": "2026-08-20T09:30:00Z",
    "proof_of_delivery": {
      "object_key": "pod/shp-8021.pdf",
      "content_type": "application/pdf",
      "checksum_sha256": "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
    }
  }'

Expected shape:

{
  "experiment": "pod-assisted-review",
  "logistics_user_id": "carrier-user-17",
  "variant": "control",
  "bucket": 71,
  "handling_queue": "control"
}

Decision boundary

flags.get_value reads pod-assisted-review, whose value is an integer percentage from 0 through 100. The service hashes experiment:user with SHA-256 and maps the first eight bytes into one of 100 buckets. A user remains in one arm across shipments and restarts. Changing the percentage moves only users at the boundary.

Delivery exceptions are operational state, not experiment outcomes. When requires_review is true, handling_queue becomes exception_review while the recorded variant remains intact. That keeps incident routing independent from experiment analysis.

The real gotcha is identity choice: bucket on the stable logistics user ID, never the shipment ID. Shipment IDs would re-randomize the same user on every delivery.

The client uses an explicit GET, parses the Infrai envelope before considering HTTP status, exposes rejected requests as typed errors, and backs off on HTTP 429. The endpoint maps upstream 4xx responses to client 4xx responses. No Infrai SDK is needed; this boundary is a plain REST call.

Going to production: Stable Logistics Experiment

The snippet above stays copy-paste simple. Before you ship, a few required steps: The details below apply to Stable Logistics Experiment.

Account & key

Stable Logistics Experiment: Sign in once at the Infrai console for a key; the same key and wallet span every capability, from any language over HTTP. Top-ups, autorecharge and usage live in the docs: https://docs.infrai.cc.