Federal Trade Commission v. Uber Technologies, Inc., No. 25-cv-03477-JST (TSH) (N.D. Cal. July 2, 2026), full opinion (PDF)
Courts have never settled how much of the TAR training process a producing party must show the other side. Magistrate Judge Andrew Peck flagged the problem in Rio Tinto PLC v. Vale, S.A. in 2015, observing that "where the parties do not agree to transparency, the decisions are split and the debate in the discovery literature is robust." Last week, in the FTC's case over Uber One subscriptions, Magistrate Judge Thomas Hixson gave the question a concrete answer. Uber must hand the FTC a random sample of 300 documents that its reviewers coded non-responsive while training its TAR model. The work-product objection did not survive the encounter.
What Happened
Uber is producing custodial documents against a court-ordered July 13 deadline. Its first production was about 18,000 documents, which Uber represented was 25 percent complete. The FTC extrapolated a final production of roughly 72,000 documents, called that "a shockingly low figure," and blamed Uber's TAR protocol. Uber answered that the math excluded Slack materials and that the more likely end result was around 156,000 documents.
The FTC asked the court to raise the recall rate in Uber's TAR protocol from 75 percent to 85 percent and to order a random sample of the training documents marked non-responsive. The court denied the recall request, because changing the recall rate eleven days before the production deadline "is not practical or feasible." The sampling request came out the other way.
The Court's Analysis
Judge Hixson began with what was missing. "Sometimes when parties use TAR they exchange training sets, so each side can see what the other is calling responsive." No such transparency existed here. Uber's reviewers train the model with their responsiveness calls, and the FTC never sees those calls. A random sample of the non-responsive training documents "would let the FTC see if the model is being trained improperly, and if it is, the Court could order Uber to retrain it."
Both sides relied on Winfield v. City of New York, a 2017 decision addressing a challenge to New York City's responsiveness coding during TAR training. The FTC cited it for the sampling remedy. Uber cited it for the proposition that documents used to train a TAR model are work product. That reading did not hold up. Winfield directed the City to provide a sample of 300 non-privileged documents pulled randomly from its corpus of non-responsive documents, the very relief the FTC sought here. Winfield "does not stand for the proposition that the training documents coded as non-responsive are work product, as it ordered random samples of them produced."
The court then took the work-product argument on its own terms. "Under Uber's reasoning, every document review should result in no documents being produced. That doesn't make any sense."
What remained was a factual stalemate. Uber read its 10 percent responsiveness rate as proof that the search terms were broad. The FTC read it as proof that the responsiveness calls were too narrow. "There is no real way to answer that question without data." The FTC, which had doubted the 10 percent rate from the beginning, asked that the sample come from the initial seed set, to see whether the training went wrong from the start and because Uber could produce that sample by July 10 rather than after the production deadline. The court so ordered. The order also resolved routine production, privilege log, and interrogatory disputes.
Why It Matters
Work product is a thin shield for the coding calls behind a TAR model. Winfield treated the City's in camera description of its predictive coding process as protected work product, yet still ordered samples of the non-responsive documents themselves. A party that trains a TAR model with human responsiveness calls should assume a court can order those calls tested by sampling.
The sharper lesson concerns agreements. Two days before this order, in Crowder v. LinkedIn Corp., another magistrate judge in the same district declined to compel further disclosures about LinkedIn's AI document review, treating the request as disfavored "discovery on discovery" that requires a "specific deficiency" in the production rather than skepticism about document counts. LinkedIn could point to an ESI order that required disclosure of technology assisted review, and it had disclosed. Uber had no agreed transparency terms to stand on, and its production numbers alone put its review process in play. Whether you audit the other side's review or have your own review audited may turn on what the ESI protocol says.
The practical move for producing parties is to write the validation story into the protocol before review begins. Decide what will be disclosed, what may be sampled, and which metrics will demonstrate that the review was reasonable. Transparency negotiated at the protocol stage is a term you can live with. Transparency imposed mid-production, on the requesting party's theory and timeline, usually is not.
The full opinion is available as a PDF.
