I turn ambiguous, high-stakes operations into decision systems people can trust.
Afsar Ali (Ali) · Data Scientist, Uber · Professorial Lecturer, George Washington University · San Francisco Bay Area
That has been the same job since 2007 — U.S. Air Force financial operations, enterprise business intelligence at Amazon Web Services, data science and applied AI at Uber, and now AI products that ship with the evidence for their own claims. The domain keeps changing. The question never does: how would we know if this were wrong?
I started in Air Force accounting and operations — six years of financial operations, resource planning, and leading a frontline team, in an institution where a number that is merely plausible is a number that hurts somebody. That is where I learned to reconcile before I report, and it never wore off. I then spent nearly six years doing financial work in a lot of different rooms: consulting engagements that took a client to 100% audit readiness, program and client-account management at JPD Financial, where I reached 210% of quota and my accounts produced 48% of company revenue, a GAO financial-audit internship where I made the audit model ~40% more efficient, startup finance, and PrintXMed — a biomedical 3D-modeling and 3D-printing venture I built and led.
At Amazon Web Services, I worked as a Business Intelligence Engineer from 2018 through 2021, owning the reporting behind a managed-services business’s weekly operating review and its 24 customer-delivery managers. I launched eight dashboards that cut ad-hoc reporting requests ~80%, took over three ETL pipelines and added 32 scorecard measures, and cut a monthly finance reconciliation from about three days to three hours and an 8-hour cleanup to about 20 minutes. I also drove sign-off on automated accounting across 11 settlement currencies for a Japan expansion and a Kindle launch. It reinforced a principle I still use: a reporting system is not a deliverable — it is a promise you have to keep every month.
Then Uber, where I have been a Data Scientist since December 2021. I stepped up — from building the report to owning the surface people decide on, and from “is this number right?” to “do several teams agree this is the number?” I own the executive reporting portfolio for spend pacing and performance across marketing channels and multi-billion-dollar verticals; I have cut reporting time ~40% and hold my reporting products at 99.9% uptime. I consolidated overlapping analytics products onto one governed path, which meant proving metric-level parity before cutover and keeping a rollback ready rather than asking anyone to trust the migration. I reduced monthly and quarterly business-review decks to one click with an AI automation that refreshes the slides and writes data-grounded narratives through layered queries and review. I built the monitored, failure-aware integration that brought an AI service into a live workflow — deliberately behind the decision rather than in front of the user, so a bad generation surfaces as a visible failure instead of a confident answer. I built an evaluation program for local models before trusting any of them, and turned the delivery lessons into controls that run whether or not anyone remembers them. And I built the usage measurement that showed how the products were actually used, so the keep-improve-retire calls came from evidence rather than from whoever asked loudest; one brand scorecard alone saves a team about 100 hours a year.
Internal product names, architecture and anything under the hood are my employer’s and stay there. The results are mine to stand behind, and so is the method — which is the part that transfers anyway.
Along the way I earned a Doctor of Engineering in Engineering Management at George Washington University. GW asked me back; I am now a Professorial Lecturer in Engineering Management and Systems Engineering and a doctoral praxis advisor — three candidates now, five successful Doctor of Engineering defenses as advisor or committee examiner — which in practice means I spend a lot of my time telling accomplished engineers that their evidence does not support their claim yet. Look at the whole list and the through-line is not subtle: I have spent my career on the seam between a system and the person who has to trust it. AI moved that seam. It did not move me.
How I’m useful
Three things, and they are the same thing.
Different layers of one job: making an answer safe to act on.
01 / Definition
Making one number the number
Competing definitions, three pipelines, four teams, and a meeting that cannot start because nobody agrees what “active” means. I own the hard part — reconcile the sources, settle the definitions, and build one governed path from raw data to the decision, keeping the old path alive until the new one has proven itself.
02 / Judgment
Putting AI in the workflow without putting it in charge
The interesting design question in an AI product is never the model. It is the split: what the system does, what the human does, what happens when the model is confidently wrong, and who finds out. I design that split first, then the failure states, then the thing itself.
03 / Proof
Earning the word “reliable”
My standard is simple and slightly annoying to live with: a control counts only after it has caught a representative failure. Until then it is a good intention with a dashboard. That is why everything below this line comes with the case list attached.
Proof
Two things you can go check right now.
One is open source with its benchmark attached. One you can click through yourself.
Open source · deterministic benchmark
Most data pipelines don’t fail. They just stop.
The worst failure in a data system is the one that never raises an error. A scheduled job or a feed quietly stops updating, nothing throws, and every dashboard downstream keeps rendering yesterday’s number as though it were today’s. So I built a deterministic Python detector that checks freshness instead of waiting for an exception, and I open-sourced it.
I published the benchmark rather than the claim: 105 cases, 83.8% accuracy, 81.8% recall, 86.0% specificity. Every error it made landed inside the threshold gray zone I deliberately built to be hard — the clear-cut cases were all correct, which is the honest way to read that accuracy number and the reason the full case list is in the repository. Go disagree with my thresholds.
Live product · the public demo is entirely synthetic
It runs on real residents’ records. The demo runs on none.
I defined the product and, with AI coding agents, built, tested, and hardened it: a live multi-role property-management web app with public, resident, manager, and owner workflows, each scoped to what its role should see, plus a local-model assistant that answers only from the records the signed-in user may see. It is in production.
The thing I am proudest of is a bug I found in my own system. During hardening I discovered that signed-in-only contact data was still reachable inside public JavaScript. I moved retrieval behind authenticated server logic, widened the scanning to cover build artifacts as well as source, and verified that the known private markers were gone from current and previously exposed bundles. That is what I mean when I say a control counts once it has caught something.
Because the production system holds real residents’ records, it is not the thing I show people. I built a separate synthetic walkthrough of the same resident → manager → owner path: no real people, no property records, no messages, no uploads, no financial data, and nothing sends. The demo walks the same boundaries I designed the product around, and I would rather demonstrate a rule than describe it.
Doctor of Engineering (D.Eng.), Engineering Management — George Washington University
Professional MBA and M.S. in Business Analytics — Seattle University, 2018 · Certificate in Quantitative Economic Analysis
B.S. Business Administration, Accounting, cum laude — Hawai‘i Pacific University, 2012
In my doctoral praxis — Optimizing Robotaxi Deployment Through Behavior-Based Demand Clustering: A Case Study in Urban Mobility, published via ProQuest in 2025 — I clustered ~70K rows of public Boston ride-hailing data by rider behavior, then tested whether those clusters were real rather than assuming it, using silhouette scores and Kruskal–Wallis analysis, and benchmarked them against geographic segmentation. I turned what survived the testing into hub, fleet-mix, staging, scheduling, and pricing choices an operator could actually make.
Teaching & service
Professorial Lecturer, Engineering Management and Systems Engineering; Doctoral Praxis Advisor — George Washington University, November 2025 – present
Commissioner, Richmond Economic Development Commission, 2026 – present
Global Co-Chair, Vets @ Uber, March 2022 – December 2025
U.S. Air Force, Accounting and Operations, 2007 – 2013
Current work
I run a lab whose job is to tell me no.
Everyone in 2026 is asking which model to use. I think that is the second question. The first one is: how would you know if it were wrong, and what happens to the work when it is?
So I built a qualification protocol for deciding whether a model may do real work, and I built it fail-closed — nothing gets promoted by default. I separate the actor from the evaluator, so the model that produced an output never grades it. I freeze conditions before the output exists, so a test cannot be quietly retuned toward a result. I use a deterministic grader wherever one is possible, because models are generous to themselves: my graders repeatedly overturned the models’ own self-scores.
I learned that the hard way. In an earlier run I let an AI evaluator design, run, and grade a benchmark it was also competing in, and it produced a confident winner. When I removed the evaluator from the contest, the winner did not survive. I made verification cost a line item in the protocol, and promotion requires repeated no-write shadow runs plus my approval.
Where it stands
No route has been promoted. I blocked the most promising one — live web research — because it could not prove safe network behavior, privacy boundaries, verifiable citations, or independent evaluation. A protocol that never says no is not a protocol, and I would rather report a blocked route than defend a promoted one.
Civic
I caught the drift before the demo, and pulled the demo.
I serve as a Commissioner on the Richmond Economic Development Commission, where I won the chair’s backing for an AI-assisted economic-reporting framework, introduced it to the commission, and led its build — six pillars, forty metrics, a source-traced data dictionary, a plain-language explainer for every metric, and a working prototype. I left the places where the data is missing visibly missing on purpose.
Then, before the demo, I found that the live data source and the application had drifted out of parity. I withheld the demo and paused redeployment until I could reconcile the two. The gap was small enough that a room of reasonable people would have accepted the walkthrough and moved on. That is precisely the case the check exists for — and the reason the check has to be mine to fail.
If that sounds like your problem, I’d like to hear about it.
I do my best work where the decision matters, the data is contested, and somebody has to be accountable for the answer — analytics products, applied AI with verification that actually verifies, and the governance that lets both survive contact with a real organization.