Armakuni Contact us
← All case studies

Cameras weren't allowed in the room.
So we built a way to sense cheating without seeing anyone.

A U.S. testing network runs more than 24,000 court-mandated drug tests a day across 120 centers, and its only defence against cheating was a person watching, at an estimated $240,000 per center a year. There was no labeled data and no product to buy. We built a privacy-first sensor prototype with no RGB video, created the first labeled dataset from controlled scenarios, and trained models that had to beat explicit rules on sessions they'd never seen.

Before

A person watching was the only control.

The obvious fix was off the table.

After
Firstlabeled sensor dataset for this kind of testing, and a working prototype
  • Models evaluated against explicit rules on held-out sessions, with false-alarm rates within the agreed targets.

A person watching was the only control

The network runs court-mandated drug testing, where a result has to stand up. Oversight relied entirely on trained observers, with an estimated monitoring cost of $240,000 per center each year, fixed whatever the volume or the cheating rate.

And the cheating had moved on. Synthetic urine, concealed containers, prosthetics and chemical interference were all in use, and an observer couldn't reliably catch them without a direct view.

The obvious fix was off the table

A camera is what any other monitored environment would use. In a bathroom, privacy rules, HIPAA among them, ruled it out: any solution had to detect interference without capturing an identifiable image. There was no off-the-shelf product, and no labeled sensor data to train a model on. Hardware, edge firmware, cloud data, privacy compliance and machine learning all had to be solved at once.

Measure the session, not the person

We stopped trying to watch the session and measured it instead. A session has a physical signature (heat, sound, the presence of a cup) that differs when something is wrong, and sensors can record it without identifying anyone. A model can learn it, but only once someone has captured complete sessions and labeled them honestly.

How we built it

4 decisions, in the order we made them. Each one says what we did and why, with what it did drawn beside it.

  1. Three sensors, each for a different part of the session
  2. Upload without a key on the device
  3. Controlled sessions make the labeled dataset
  4. Machine learning had to beat explicit rules

Three sensors, each for a different part of the session

Built withRaspberry Pi
The room Thermal: heatAudio: soundsLight: presence no camera
The engineering

The edge prototype combined thermal, audio and presence measurements on a Raspberry Pi, with no RGB video capture:

  • Thermal readings represent heat patterns and flow continuity.
  • Audio processing extracts signal features such as RMS and MFCCs, to catch sounds like a plastic pop or rustling. Incidental speech is redacted during feature preparation.
  • A light sensor records whether the cup and the collection container are present, and when that changes during the session.
  • Local firmware exposes start, stop, status and health endpoints over local Wi-Fi and buffers readings during capture, so a network outage can't lose a session.

We built a cost, availability and performance matrix across sensor options, managed procurement, and 3D-printed prototypes to check the form factor before ordering hardware.

Why: each signal covers a weakness of the others, and none of them can identify a person.

Upload without a key on the device

Built withS3
The iPad asks for a linkA presigned S3 URLThe upload, no key kept
The engineering

An iPad application lets operators manage sessions and check device health. It assembles a manifest with timestamps, metadata and file hashes, then uploads through presigned S3 URLs, so no long-lived AWS credentials live on a device that sits in a testing center.

Controlled sessions make the labeled dataset

Built withS3KMSIAMLambdaDynamoDB
Staged sessions recordedAligned on one timelineLabelled, privacy reviewed
The engineering

No model could be judged without labeled examples, and none existed. So we created them: controlled baseline sessions and simulated interference scenarios covering synthetic urine, prosthetics, concealed containers and chemical interference. Observer notes and timestamps stay with each session record, so evaluation can refer to what actually happened:

  • S3 stores uploads with KMS encryption, versioning and restricted IAM access.
  • Lambda indexes incoming sessions and writes summaries and metadata into DynamoDB.
  • Thermal, audio and presence features are aligned to a common timeline.
  • Dataset preparation includes labeling, privacy review and an audit trail before any training.

The architecture was sized for the network's intended volume of 24,000 tests a day. The engagement itself was a sensor prototype and a machine-learning proof of concept (POC).

Machine learning had to beat explicit rules

Built withSageMakerIoT CoreS3API GatewayCognitoCloudTrail
The same recorded sessions Explicit rulesMachine learning
The engineering

It's easy for a model to look clever on its own. So the first detectors were explicit rules: temperature and flow thresholds, audio continuity and spike rules, and presence-transition checks. Machine-learning (ML) candidates were then evaluated against those baselines on held-out sessions, and judged on the extra detections they found against the extra false alarms an operator would have to review.

SageMaker handles processing, training and model serving, with a multi-model serverless endpoint, and data flows from IoT Core through S3 and ECR into the pipeline. A scoring API accepts a session package and returns an anomaly score with reason codes, and the demo records each output for inspection:

  • Confusion matrices, ROC curves and precision-recall analysis describe the trade-off between detection and false alarms.
  • Error analysis separates scenario types and the recorded test groups, so it's clear where performance differs.
  • A threshold playbook documents operating points meant for calibration at each site.
  • API Gateway and Cognito secure the scoring endpoint, with CloudTrail and CloudWatch keeping audit and operational records.

A model was only worth deploying if it beat a rule anyone could explain, in a test that has to stand up in court, and the reason codes say why each session was flagged.

The scores measure performance on controlled examples. Operators would need to confirm they're useful in real sessions during the pilot.

One session, end to end

  1. An operator starts a session on the iPad, and the Raspberry Pi starts buffering.
  2. The thermal camera, microphone and light sensor record heat, sound features (with speech redacted) and the cup and container's presence.
  3. The session ends. The iPad builds a manifest with timestamps and file hashes and uploads it to S3 through a presigned URL.
  4. Lambda indexes it, and the features are aligned on one timeline.
  5. The scoring API returns an anomaly score with reason codes, such as a temperature drop or a sound spike.
  6. The site's threshold decides whether a person takes a second look.

What we'd tell another CTO

1Heat, sound and presence describe a session well enough to score it without identifying anyone. Where there's no labeled data you can make it honestly, as the controlled scenarios with observer notes did here.
2Make the model beat explicit baselines and return reasons with its score, because a flagged session needs a cause a person can check. And keep credentials off the edge: with presigned uploads, a lost device gives nothing away.

What else changed

  • A data pipeline with encryption, versioning, least-privilege access and an audit trail, sized for 24,000 tests a day.
  • Models evaluated against explicit rules on held-out sessions, with false-alarm rates within the agreed targets, confusion matrices, ROC and precision-recall curves, and error analysis by scenario.
  • A scoring demo with reason codes, a threshold playbook and a pilot roadmap with success criteria, a timeline and a rough budget.

What comes next

A pilot at a subset of centers, with hardened firmware, more data collection and calibration of the thresholds at each site, before considering deployment across the network. The scoring demo isn't connected to production systems yet. Savings depend on the pilot's results, and privacy attestation scoping follows.

How we'd do it today

This project came before our current offers. Here's how we'd approach the same work now.

AK AI Factory's Prove would add a sealed set beside the held-out sessions, one no model builder sees, and treat each interference method as a critical case that must pass on every run, since an average can hide the method that matters most. Each site's operating point would become a decision the business signs, recorded with the model version and the evidence behind it, and a new model would go to a small share of sessions first and roll back on its own if false alarms cross a line agreed in advance.

As pilot sessions arrive, AI agents would try new features and thresholds against the golden set overnight, and only a change that catches more without raising false alarms, and fails nothing sealed, would reach the team for approval. Encryption, access and speech redaction would leave their evidence as they run, mapped to the privacy standards the network names.

Have a problem like this one?

A free workshop: a few hours with the architects who'd do the work, on your own systems. No cost.

Book a free workshop