Platform Evolution
Assessment run-2026-07-27-1 · 213 of 213 repos assessed
Repos / tc-phenix-dynamicmargin

tc-phenix-dynamicmargin

.NET 8 FastEndpoints API recommending a gross-margin percentage for Phenix travel quotes, with dual prediction paths (the legacy tc-ml-margin service and Snowflake) and MongoDB-persisted predictions.

88 · greenlowloosely attachedAWSZDD: no excuseapi

Health score

88

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.


Runtime currency / 25
25
Runs on supported modern .NET
Legacy transport / 15
15
No legacy WCF or SOAP surface
Test posture / 15
8
Some tests, coverage is thin
Security hygiene / 15
15
No credentials found in source
Dangerous coupling / 15
11
depends on pinning component(s): phenix-feature-service
Activity / 10
10
Actively maintained
Deployment hygiene / 5
5
CI in place
Health over time
2026-07-27 (run-2026-07-27-1): 88
Baseline 88 recorded 2026-07-27. The trend fills in with each monthly assessment run.

Facts

Languagescsharp
FrameworksASP.NET Core 8, FastEndpoints, FluentResults
Runtimes.NET 8
Tests / CIsome / CI in place
Last commit2026-06-24
OwnerOwner unknown (mapping to be curated)
DomainSelling and quoting (system generated; curate in repo-owners.json to override)
Product areaShared platform
HostedAWS Deployed to AWS
  • build "tc-phenix-dynamicmargin-api" (build-dynamicmargin-api.yml): AWS signal "useTFVarsDeployment: true"
Releases0 release pipeline(s):
Integrationrest, jwt
SourceOpen in Azure DevOps

Risk flags

Each flag links to its glossary definition.

Dependencies in context

Laying out the graph…
greenamberreddata store (square, dashed link)Node size follows fan-in. Click any node to open it.

Entanglement

loosely attached Bound into the core by 1 mechanism(s).

Detaches when its pinning dependencies are cut or multi-targeted (phenix-feature-service).

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

No excuse

Nothing technical is holding this repo on the three-week release. It either already deploys without downtime (AWS) or is a modern, well-tested service the automated stealth path can carry today. Already deploys as a container to AWS, which releases without downtime today. Separating it from the three-week release is a process decision, not a technical one.

Dependencies and gotchas
  • Feature flags come from phenix-feature-service (WCF-only): flag reads themselves are a legacy dependency to watch
Steps
  1. Adopt the four-stage discipline from the ZDD engineering standard: pre-deployment compatibility, deployment, feature activation behind a flag, post-release cleanup.
  2. Raise automated test coverage first: ZDD trades the end-of-sprint manual gate for continuous automated confidence, so the tests are the entry ticket.
  3. 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.
  4. Audit serialized data: anything in Redis, queues or shared caches must deserialize cleanly across adjacent versions.
  5. Wrap behaviour changes in feature flags so code deploys dark and release becomes a business decision, not a deployment event.
  6. Use ECS rolling deployments with health checks gating traffic, and take this service off the three-week release train.
  7. 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 applicable

No SQL Server dependency is recorded for this repo. Nothing to migrate.

Containerisation

Already containerised

Its 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-phenix-dynamicmargin

Purpose

Serves ML-based gross-margin recommendations during Phenix quoting. Clean Architecture around a sealed MarginRecommender that orchestrates two prediction paths — the legacy internal ML container (GrossMarginMLClient over HTTP, i.e. tc-ml-margin) and a Snowflake-hosted model (SnowflakeClient) — switched per environment by Prediction:UseSnowflakePrediction (Snowflake is enabled in QA through Live; the flag started as an A/B test). Recommendations are cached and refreshed in the background when a quote's component mix changes; every prediction is persisted to MongoDB with request/response metadata. A NuGet Api.Client/Client.Models package is published for consuming services, plus a CompanyConfiguration package.

Tech stack

Modern C# on .NET 8: FastEndpoints with Swagger, FluentResults result pattern throughout, PhenixAuth/Phenix.Auth.JWTBearer and TC.Cognito.Auth.Client, TC.ConnectionBroker (Api/HttpClient/Mongo), TC.ScriptRunner.Mongo index initialisation on startup, AWSSDK SSM for secrets, Nerdbank.GitVersioning. Notably has a maintained CLAUDE.md documenting architecture and commands (instead of a README) and a margin-predict.rest request file.

Deployment

No classic release pipelines (release_count 0); build pipeline tc-phenix-dynamicmargin-api from build-dynamicmargin-api.yml uses the shared InternalOSS/azure-pipelines-templates ci.yml (SDK 8.0.x) building the API container in namespace dynamicmargin, ECS via aws-phenix-tc-apps Terraform tfvars, functional area phenix. build-dynamicmargin-api-client.yml packs the client NuGet. Eight per-environment appsettings (Development to Live/Training).

Dependencies

Internal: TC.ConnectionBroker.* (tc-connectionbroker), TC.Phenix.CompanyInfo (company-info-api), TC.Phenix.Feature (phenix-feature-service), TC.Diagnostics.HealthChecks (tc-diagnostics-portal); runtime HTTP to the tc-ml-margin prediction container. External: Snowflake (second prediction path, JWT key-pair auth), AWS SSM, Cognito.

Data stores

MongoDB PackageValidation database for GrossMarginPredictionDocument records (request + response + metadata) — a database name shared with the package-validation domain rather than a dedicated store.

Integration points

Inbound REST (FastEndpoints, JWT via PhenixAuth); outbound HTTP to tc-ml-margin and Snowflake. No message bus.

Code health

Fair: three test projects (Application, Api.Client, plus fixtures) with 37 xUnit tests focused on the recommender and client; xUnit + Moq/AwesomeAssertions. No README — CLAUDE.md is the de-facto documentation and is genuinely good, but non-standard. Actively developed (last commit 2026-06-24).

Modernisation risks

Low. Modern .NET 8 stack on ECS with YAML CI. Watch-items: the dual prediction paths double the operational surface until the Snowflake migration completes and the legacy tc-ml-margin path (EOL Python 3.8 container) is retired; predictions land in the shared PackageValidation Mongo database; and test coverage is modest relative to the business impact of margin recommendations.

Data store follow-up (2026-07-28)

The service's Terraform definition (aws-phenix-tc-apps, ecs/tc.phenix.dynamicmargin.api.tf) wires SNOWFLAKE_ACCOUNT_IDENTIFIER and a Prediction__UseSnowflakePrediction toggle: margin predictions are read from Snowflake, now recorded as snowflake:Prediction.