tc-ml-margin
Python Flask container serving an XGBoost machine-learning model that predicts a suggested margin percentage for a booking from its component/cost features.
Health score
0 to 100 across seven weighted factors; nothing is hidden. Green is 75 and above, amber 50 to 74, red below 50. How scoring works.
Facts
| Languages | python, csharp |
| Frameworks | Flask, scikit-learn, XGBoost |
| Runtimes | Python 3.8 |
| Tests / CI | none / CI in place |
| Last commit | 2025-05-20 |
| Owner | Owner unknown (mapping to be curated) |
| Domain | Data and insight (system generated; curate in repo-owners.json to override) |
| Product area | Shared platform |
| Hosted | AWS Deployed to AWS
|
| Releases | 0 release pipeline(s): |
| Integration | rest |
| Source | Open in Azure DevOps |
Dependencies in context
Entanglement
loose No binding mechanisms apply: this system needs no untangling work.
Depends on / used by
Migration playbooks
Generated from this repo's assessment data: what is feasible, what blocks it, and the steps in order. Ratings: green means actionable now, amber means sequence other work first, red means blocked, grey means not applicable.
ZDD adoption
Ready with guardrailsClose: the deployment path exists, but specific checks are needed first, typically raising tests, auditing serialized data, or respecting a shared schema with expand and contract. Already deploys as a container to AWS, which releases without downtime today. No automated tests: at-will release without a safety net is bravado, not capability.
- 1 system(s) depend on this repo; during a rolling deploy they will talk to old and new versions at once, so responses must stay compatible
- Adopt the four-stage discipline from the ZDD engineering standard: pre-deployment compatibility, deployment, feature activation behind a flag, post-release cleanup.
- Raise automated test coverage first: ZDD trades the end-of-sprint manual gate for continuous automated confidence, so the tests are the entry ticket.
- Make every change dual-version safe: backwards-compatible APIs (new major version for breaking wire changes), expand and contract for any schema change, and consumers tolerant of unknown fields.
- Wrap behaviour changes in feature flags so code deploys dark and release becomes a business decision, not a deployment event.
- Use ECS rolling deployments with health checks gating traffic, and take this service off the three-week release train.
- Verify with area-scoped regression rather than the whole-platform cycle, and watch error rates after rollout with automated rollback on alert.
SQL Server exit
Not applicableNo SQL Server dependency is recorded for this repo. Nothing to migrate.
Containerisation
Already containerisedIts pipelines already build containers and deploy to AWS. Nothing to do here.
Recommended actions
No specific actions for this repo. It either needs only normal maintenance, or its work is covered by an estate-level action. See the full programme.
Assessment notes
tc-ml-margin
Purpose
Hosts the margin-suggestion ML model for Phenix bookings: a single-file Flask app loads GM_Perc_Mod_XGB_v7.pkl (a 227 MB XGBoost pipeline committed to the repo) and exposes /predict, which takes 18 booking features (dates, durations, component volumes, nett costs, booking type/package/location, TC-score status) and returns a predicted margin percentage. The README states the model is trained outside this repo and changes 1-2 times a year; committing a new pkl triggers redeployment.
Tech stack
Python 3.8-slim Docker image with pandas 1.3, scikit-learn 1.1, xgboost 2.0.3, joblib and Flask, run via Flask's built-in dev server (app.run on port 80 — no gunicorn/uwsgi). A small C# TestConsole project (MarginMLClient, sample payload) exists for manual exercise of the endpoint; it is not an automated test suite.
Deployment
No release pipelines (release_count 0); build pipeline tc-ml-margin from build.yaml uses the shared InternalOSS/azure-pipelines-templates ci.yml with the docker template (templateType: ecs, image ml-margin, namespace phenix), deploying to AWS ECS via Terraform tfvars in aws-phenix-tc-apps, functional area phenix.
Dependencies
None internal — no TC packages, no estate API calls. The likely consumer is tc-phenix-dynamicmargin (dynamic margin API), which fronts pricing decisions; this repo itself calls nothing.
Data stores
None. The model is a static file baked into the container; no database, cache or bus.
Integration points
Inbound REST only: /predict (POST, JSON pred_request feature array), plus /ping and /ping_deep health endpoints.
Code health
Weak by estate standards but proportionate to a ~40-line app: no automated tests, no linting, boilerplate-plus-two-lines README (with typos), model provenance and training pipeline undocumented. Last commit 2025-05-20 — dormant, though the README says infrequent change is expected.
Modernisation risks
Medium. Python 3.8 is past end-of-life (base image no longer receives security fixes) and the pinned pandas/scikit-learn versions are similarly old — an image/runtime bump is the single most valuable fix. Serving via Flask's dev server is a robustness concern under load. The 227 MB pickle in git history bloats clones and pickle-loading ties serving compatibility to exact library versions; feature-name coupling in app.py means any upstream schema change breaks predictions silently. The offline training process lives outside source control entirely.
Data store follow-up (2026-07-28)
Follow-up scan of project files, configuration and the central Terraform repos confirmed the empty data_stores list is correct. Calls other services through the connection broker; no data store packages or configuration found.