Catching a compliance gap before it shipped

Validating a minimum-wage compliance check against real data surfaced an assumption that would've let non-compliant offers ship.

Product Team Lead2025–2026Compliance · Data Validation

Context

StaffingNation, TCWGlobal's staffing platform, places workers across many U.S. states — and multi-state employment means multi-state minimum wage law. Checking whether a worker's pay complied with the right jurisdiction's minimum wage used to be a manual audit: someone on Operations looked up each offer against wage tables by hand before it went out. That doesn't scale, and it's exactly the kind of process where a missed case is a real compliance exposure, not just an inconvenience.

Problem

A large client had many remote workers, and the existing manual audit checked wage compliance against a worker's home address — the location tied to their employment record. As I scoped an automated compliance check to replace the manual audit, I needed to validate that assumption before building on top of it.

My Role

I owned this end-to-end: scoping the compliance logic, building the address-based wage check, and validating it against real onboarding data before it shipped.

Team & Stakeholder Dynamics

This sat between Operations, who ran the manual audit and felt the time cost directly, and Compliance, who owned the actual legal requirement. I worked closely with Operations to understand exactly what they were checking for and why — the automated version needed to replace their judgment call, not just their data lookup.

Process & Decisions

I built the first version to flag addresses where wages weren't compliant based on home location, matching the existing manual process. But while testing and validating the feature against real records before shipping, I found a second compliance issue the "one size fits all" home-location assumption missed: onsite workers need minimum wage compliance checked against their onsite location, not their home address. Those are the same field in most records, but not always — and the gap was exactly the kind of edge case that doesn't surface until you're checking real data against the actual rule, not the process someone described to you.

I caught it during validation, before launch, which meant fixing the underlying logic before any offer went out on the wrong assumption, rather than after.

Outcome

The compliance check now flags non-compliant job offers pre-send, based on the correct location for each worker type — home or onsite. It reduced audit time 25% for Operations and closed a real compliance gap that predated the automation. Left unaddressed, that gap would have meant potentially non-compliant offer letters, incorrectly paid workers, and cost exposure for the client.

Reflection

The lesson wasn't really about wage law — it was about not trusting an inherited assumption just because it's how the manual process always worked. The original audit ran on the home-location rule for a long time without anyone flagging it as wrong, because a human doing it case-by-case could informally account for exceptions without ever writing the rule down. Automating it forced the assumption into the open, and testing against real data — not just the described process — is what actually caught it.