Skip to content

All Systems Nominal

More than one in three California cannabis recalls are paperwork failures.

Not contamination. Not pesticides. The COA, the label, the Metrc package, the data flow between them. That gap is my job.

The pattern, in numbers

175
California cannabis recalls in the last 30 months.
Source: California DCC public recall portal.
~40%
Cited a label or cannabinoid-pipeline failure.
Source: DCC recall database, recall reasons coded.
+95%
Year-over-year growth in label-pipeline recalls (2024 → 2025).
Source: DCC recall counts, 2024 vs. 2025.

See the full recall trend →

Beyond product recalls, DCC has published 830+ enforcement actions against California cannabis licensees in the public record — citations, suspensions, revocations, license denials. See the enforcement tracker →

Three things I have actually caught

The places evidence falls out of the chain.

Each of these is a real failure I documented during a real engagement. Vendor names included. Dates and outcomes are on the case page.

A printer firmware update kept failing. Vendor support's diagnosis pointed at a faulty SD card.

The DataFlex 6330 has no SD card. It uses onboard memory only. The vendor's diagnosis was likely templated from a different DataFlex variant or a generic Videojet response. Following it would have produced no progress. Trusting it would have produced months of stalled tickets. The fix was to physically open the hardware and verify what was actually inside it.

How it surfaced. Disassembled, inspected, and cleaned a spare unit instead of trusting the diagnosis.

How it got fixed. Spare upgraded cleanly. Production unit upgraded the same way. Both units now match the rest of the fleet, without ever ordering the part the vendor said was the problem.

Whenever the printers were spooling, Acumatica was reported as running slow. Strong intuitive explanation; blame had been on the printer pipeline by default.

The correlation between spooling and Acumatica slowness was confirmation bias, not causation. The team's experience of Acumatica speed tracked their belief about whether spooling was happening, not whether it actually was. Without the blind test, the wrong system would have continued to be blamed indefinitely.

How it surfaced. A controlled blind test. Spooling stopped both phases. Phase one: team aware, reports Acumatica "a bit faster." Phase two: team unaware, reports Acumatica "slowed down again" and blames spooling.

How it got fixed. Spooling formally ruled out as the Acumatica perf cause. Root-cause analysis became defensible. The next vendor call didn't waste an hour on a false trail.

Disk space, SQL Express, and the hosting server had each been blamed and addressed in sequence.

The Acumatica-to-BarTender integration dispatched one HTTP request per label. A 5,000-label job became 5,000 sequential HTTP round trips with full TCP setup, headers, payload, and response wait between each. Math gave the exact ceiling that had been observed every day on the floor: 16–17 labels per minute. Every prior fix had been correct in scope and irrelevant to the bottleneck.

How it surfaced. Walking the joint vendor call through the math: 5,000 labels × ~3.5 second round trip, sequential, equals exactly 16–17 per minute.

How it got fixed. Stopped waiting for the vendor fix. Six days later: a Chrome extension talking ZPL directly to the printers over LAN. BarTender and the hosted server out of the critical path.

More real failure modes, in detail →

What I do, plainly

Diagnostic first. Build last.

  • I embed on your floor for a week or two.
  • I find where evidence falls out of the chain.
  • I fix it inside your existing stack first. Custom code only when waiting is more expensive than building.

How an engagement works →

From the field

Real problems. Real results.

Five weeks of embedded work for a Sacramento-area distributor. Sixteen labels per minute became eighty, sustained. Concept-to-production on a direct-ZPL pipeline in six days.

Read the full case →

Common questions

What operators ask before the first call.

What does a cannabis distribution compliance consultant actually do?
Diagnose the failure modes between Metrc, the ERP, the COA, the label generator, and the printers. The places where data falls out of the chain and a label ships with the wrong number on it. The work is half engineering and half floor-time. The deliverable is a label pipeline you can defend to the DCC.
Why are more than one in three California cannabis recalls paperwork failures?
Of 175 recalls issued by the DCC over the last 30 months, roughly 40% were cited as label or cannabinoid-pipeline failures and another large share were Metrc/inventory mismatches. Contamination and pesticide hits make up a much smaller fraction. The recall surface in California is data integrity, not lab chemistry.
When should a distributor bring in a compliance consultant?
Before the recall, not after. The leading indicators are: label runs that fail mid-batch, Metrc tags that don’t reconcile against the ERP at end-of-month, COAs that get re-pulled after labels print, or vendor support tickets that have been open more than two weeks without progress. Any of those is the conversation.
Do you only work with Sacramento-area distributors?
The practice is Sacramento-based and most embedded engagements are within driving distance of Sacramento. Remote diagnostic work is possible for distributors elsewhere in California; the embedded portion is where the value is, so geography matters.
What is the first step in working with Phenominal?
A 30-minute call. No slides. We talk through which failure patterns you’re seeing on the floor right now and whether the gap belongs to a vendor or to me. If an engagement doesn’t make sense after that conversation, I say so.

If a recall scenario is on your mind right now, the conversation is free.

Thirty minutes. No slides. If an engagement does not make sense, I will tell you on the call.