Data / MLOps Engineer. I build the chain from raw operational data to a decision served in production — and, more to the point, I can prove the decision is a good one.

Engineering degree (Diplôme National d'Ingénieur) from INSAT Tunis — Networks & Telecommunications, ML/AI specialisation.

Standard supervised metrics cannot tell you whether a recommendation that was never executed was better than the action actually taken. This library builds the device that can: a posterior oracle over the candidates genuinely exercised, a regret metric against it, and the temporal splits and leakage locks without which the resulting number is optimistic — and an optimistic offline evaluation is more dangerous than none, because it licenses a deployment.

24 tests · 94% coverage · CI on Python 3.10 / 3.11 / 3.12 · MIT

An end-to-end data platform on synthetic telecom routing events: dlt ingestion into a DuckDB warehouse, a dbt star schema, and data quality tests wired in as a merge-blocking gate rather than a dashboard. The generator injects real defects on purpose — a missing purchase rate, duplicated deliveries — so the gate can actually fail. A test that cannot fail proves nothing.

7 dbt models · ~50 dbt tests · 26 Python tests · ADR-documented decisions · MIT

Built in the order a real platform has to be built. Steps 2 to 7 — Airflow, PySpark at scale, a Delta Lake medallion, AWS + Terraform + Kubernetes, MLflow, and an MCP server — land in the same repository as it grows.

Six months building a routing decision-support system for a wholesale telecom carrier, in production. It ran in passive mode: it recommended which partner to send traffic to every fifteen minutes, and a human approved. 30 million calls, 201,396 fifteen-minute aggregates, 461 automated tests, four containerised services.

Three things I learned there, and they shaped everything above:

Predicting well is not deciding well. The first model estimated a quality rate by regression and ranked by predicted value. Its prediction error looked fine. Compared on regret against a deliberately naive reference — carry forward yesterday's best partner, no learning at all — the heuristic won. That result reoriented the project into a learning-to-rank problem, and it is why regret-eval exists.

The data comes before the model. An audit at the start found the purchase rate missing on 20.5% of billable calls, concentrated on particular carriers. A model trained on that learns those carriers have no cost, therefore infinite margin, and recommends them systematically — while every training metric looks fine. Fixing the billing chain and replaying history brought it to 0.14%. That is why carrier-iq puts the quality gate before the model.

A gain you cannot measure is not a gain. The final mechanism was validated by an off-policy protocol with four anti-leakage locks, five evaluation splits including a reversed one, and a random control: +5.8% to +35.0% of regret removed, positive on all ten measurements.

Daily — Python · SQL · dbt · DuckDB · dlt · XGBoost · scikit-learn · pandas · FastAPI · Docker · pytest · Elasticsearch · Git · GitHub Actions · ruff · uv

Also shipped with — Neo4j and LangChain/LangGraph for RAG & GraphRAG · Next.js · Keycloak/OIDC · Docker Swarm + Traefik · MLflow · ONNX · Optuna

Learning in the open, inside carrier-iq — Airflow · PySpark at scale · Delta Lake · AWS · Terraform · Kubernetes · Model Context Protocol

I'd rather list this honestly than pad it. Everything in the first two rows is in a repository or was in production; everything in the third is being built where you can watch it happen.

• Email — louay.mejri44@gmail.com
• LinkedIn — louay-mejri

Open to Data Engineer / MLOps roles in France, Ireland and Germany.