Workday’s case puts the vendor’s own conduct on the map

The June 22 ruling in Mobley v. Workday allowed California employment-discrimination claims to proceed based on allegations about Workday’s own conduct in California. That is a more precise development than saying hiring liability has moved to the vendor’s headquarters.

Duane Morris’s account of the order describes a split ruling. The California claims survived the dismissal motion; some new claims or theories failed because they exceeded the permitted amendments. This was a pleading decision, not a determination that the screening system discriminated.

My takeaway for an AI buying team is concrete: map the vendor’s actual role in each decision before accepting the contract’s broad division of responsibility.

The employer still has its own conduct to answer for. A vendor potentially facing direct responsibility does not make that responsibility disappear. The useful question is where each consequential choice occurs and whose evidence explains it.

Headquarters is an address; conduct is the mechanism

The California connection described in the ruling concerns allegations that the tools were designed, developed, maintained and controlled there. The analysis reaches conduct associated with the location. It does not establish that every applicant can invoke every law applying at a software supplier’s registered office.

That distinction changes the document I would ask for. A list of vendor subsidiaries is insufficient. I want a decision map showing who selects the screening features, who sets a rejection threshold, who changes the model and who decides whether an applicant advances.

Take a hypothetical recruiting workflow. The employer supplies minimum qualifications. The vendor supplies a scoring model. A recruiter configures an automatic rejection threshold. A later product update changes how an employment gap affects the score.

Those are four different actions, potentially taken by different people under different instructions. Calling the whole sequence an employer decision hides the update. Calling it vendor automation hides the threshold. Neither description helps reconstruct what happened to an application.

Make cooperation operational

In that hypothetical purchase, I would use one synthetic application to test the responsibilities before deployment. Walk it through the workflow, including a rejected outcome. Then ask each party to produce the record for the step it controls.

The employer should be able to explain the job criteria and configuration. The vendor should be able to identify the relevant product version and document the behaviour of its component. The reviewer needs a route to investigate a disputed outcome without receiving a circular referral between support teams.

This is a proposed procurement exercise, not a claim that Workday fails it. Its value is that it turns responsibility into observable cooperation. A clause promising assistance is much easier to assess when the parties have already agreed which records exist and who can retrieve them.

The same map helps legal review. Counsel can assess the actual allocation of decisions and the relevant jurisdictions, rather than infer them from a marketing label such as decision support. Contract language still matters, but it should describe a workflow that the technical teams recognise.

I would also version the map. A feature that changes from recommendation to automatic rejection changes the operational question even if the product name and supplier address stay the same.

Hiring accountability follows the decisions people and systems actually make; document those before relying on the labels in the contract.