01
the problem
Pharma planners must coordinate shortage pressure, inbound clearance, fleet constraints, approvals, and physical stock movements without losing auditability.
cd ..~/projects/pharma-control-tower
case study 03 / Backend & operations
Pharma Availability Control Tower
A working competition MVP that combines shortage forecasting, inbound prioritisation, candidate dispatch planning, planner approval, reports, and operational simulation.
- status
- Working MVP
- ownership
- Team of 4
- stages
- 06
- stack
- 06
- FastAPI
- Next.js
- SQLAlchemy
- MySQL
- Docker
- Render
Project overview
02
my contribution
Built substantial FastAPI route groups for inputs, orchestration, planner workflows, reports, dashboard data, and demo operations; also added simulation scripts, deployment configuration, and responsive shell improvements.
03
key decision
Keep planner approval separate from physical execution so approval creates reservations and transfers while explicit business events change stock.
Actual planner dashboard from the project repository.
04 / how it works
System flow
stage 01
Operational inputs
stage 02
Shortage forecast
stage 03
Inbound priority
stage 04
Dispatch candidates
stage 05
Planner approval
stage 06
Execution events & reports
Working FastAPI and Next.js MVP with database-backed planner state and audit records.
Oshadha-authored endpoints for dashboard data, inputs, orchestration, plan review, demo operations, mock ETA, and reports remain substantially present in main.
Oshadha-authored vessel and lorry arrival simulators exercise operational state transitions.
Oshadha updated the Render deployment manifest and made the planner shell responsive on smaller screens.
The team’s runtime includes mathematical prioritisation, XGBoost shortage forecasting, and OR-Tools candidate dispatch planning; those models are not claimed as Oshadha’s work.
What is implemented and what is not
The seeded scenario is a compact competition demonstration rather than a live supply-chain deployment.
The local documented database is MySQL; Oshadha’s PostgreSQL seed-compatibility commit remains outside main.
Model ownership belongs to the team and is intentionally not attributed to Oshadha.
Exposing a multi-stage planning pipeline as coherent, database-backed operations with state transitions that remain reviewable and repeatable.
Operational software needs explicit state boundaries and audit trails as much as it needs a correct model output.