Python Pro Portfolio Trilogy

## The scenario The Activity team has asked you to **productionise** the monthly reconciliation work into something an oncall analyst can rely on: scheduled, observable, and able to fail gracefully without dropping a month's commissioning view. ## Deliverables A Python project structured as a real service: 1. **Input validation** with pydantic (or attrs + cattrs) for the four CSV schemas. Bad files reject cleanly with a structured error report. 2. **Idempotent monthly run** — replay any month without producing duplicate spell records. 3. **Structured logs** (JSON Lines via stdlib `logging` is fine) with run-id correlation across stages. 4. **A small HTTP surface** (FastAPI or `http.server` — your call) exposing `/runs/latest`, `/runs/{id}`, `/health`. No frontend. 5. **A scheduled-run script** (`cron`-style or APScheduler) that picks up the next month when its files land. 6. **Tests** with pytest: at least the lookup, the audit-flag rules, and the idempotency guarantee, with fixtures. 7. **A README and an OPS runbook** — "the file didn't arrive, what do I do?" / "a row failed validation, where do I look?" ## Acceptance criteria (summary) pydantic-style schema validation · idempotent re-runs · structured logs with run-id · pytest suite passing locally · README + OPS runbook · containerised (Dockerfile + compose) · ≥15 conventional commits. Full brief, dataset orientation, and architecture rubric appear inside the lesson once enrolled.

## The scenario The Claims team wants the monthly reconciliation reframed as a **pricing service**: FNOLs arrive throughout the month, the service prices them using whichever cover-rule version was in force on the loss date, and produces both an exception queue (rule-required intervention) and an auto-paid queue. ## Deliverables 1. **Versioned cover-rule lookup.** Rules carry `valid_from` / `valid_to`. The service uses the rule in force at the loss date, not at FNOL date. 2. **Validated FNOL ingestion** with pydantic — bad records go to a quarantine table with the validation error attached. 3. **Idempotent pricing** — same FNOL twice produces the same priced row; reprocessing on a rule-version change is explicit and audit-trailed. 4. **HTTP surface** — `POST /fnols` (ingest), `GET /fnols/{id}` (status + priced amount + rule version used), `GET /runs/latest`, `/health`. 5. **Structured logging** with FNOL-id and rule-version on every log line. 6. **pytest** covering the rule-versioning logic, ingestion validation, idempotency, and at least one end-to-end happy path. 7. **README + OPS runbook.** ## Acceptance criteria (summary) rule versioning correct under date-edge cases · quarantine path works · idempotent re-pricing · structured logs · pytest passing · containerised · ≥15 conventional commits. Full brief, dataset orientation, and architecture rubric appear inside the lesson once enrolled.

## The scenario Operations wants the SLA report turned into a **weekly close**: scanner events arrive throughout the week (some late, some corrected), the service computes outcome category at the moment a consignment becomes decidable, and produces a customer-compensation payable file when the week closes. ## Deliverables 1. **Event ingestion** — `POST /attempts` accepts new scanner events. Late events that change a consignment's outcome trigger a recompute. 2. **Decidability** — a consignment is "decided" when either (a) DELIVERED, or (b) the breach window has passed and no further attempts can change the outcome category. 3. **Weekly close** — `POST /closes/{week}` finalises that week, snapshots the SLA breakdown, and produces `compensation_payable.csv`. Re-running a close is allowed (audit-trailed) until 28 days after week-end. 4. **Structured logs** with consignment-id and route-id on every line. 5. **HTTP surface** — `GET /consignments/{id}`, `GET /closes/{week}`, `GET /runs/latest`, `/health`. 6. **pytest** covering late-event recompute, decidability boundaries, weekly close idempotency. 7. **README + OPS runbook** including "a customer is disputing their compensation, where do I look?" ## Acceptance criteria (summary) late-arriving events handled · decidability rule correct under edge cases · idempotent weekly close · structured logs · pytest passing · containerised · ≥15 conventional commits. Full brief, dataset orientation, and architecture rubric appear inside the lesson once enrolled.