Sail JADA — Engineering Log

Technical work on sailjada.com and the JADA booking systems

I'll read the existing report to ground the blog post, then write a technical article about the investigation. /Users/cb/dablio/reports/2026-07-05-dbg-licensure-liability-pre-check-california-ppo-question-re.md /Users/cb/icloud-jada-ops/decisions/2026-07-05-dbg-intake-deploy-package.md Now I'll write a technical blog post covering the intake Lambda architecture, the licensing/classification decision, and why it matters for platform design: ```html

When Your Guard-Dispatch Platform Becomes a Furnisher: Intake Lambda Architecture and California PPO Licensing

DragonBodyGuards (DBG) is building a marketplace that routes clients to independently licensed security professionals. The founding team assumed routing alone wouldn't trigger licensure requirements — the guards are licensed, we're just the platform. This month, a staged intake Lambda deploy forced us to confront a harder question: what does the platform actually do, and does that push DBG into California PPO (Private Patrol Operator) licensing requirements?

The Core Problem: Broker vs. Furnisher Classification

California law divides security labor platforms into two buckets:

  • Brokers — match clients to guards and step back. Guards negotiate terms, handle contracts, manage the engagement. The platform is genuinely passive.
  • Furnishers — supply security services by exercising control over the engagement. If the platform determines who goes, when, what they do, or how much they're paid, the law treats the platform as the service provider.

The difference matters. Furnishers need PPO licenses. So does everyone on their payroll (even contractors). Brokers typically don't, though they need other licenses depending on the state and what else they do.

Why the Intake Lambda Pushed Us Toward Furnisher

The DBG intake process uses a staged Lambda deployment to auto-adjudicate client requests:

1. Client submits security requirements (location, dates, guard type, budget)
2. Lambda function evaluates request against guard availability, credentials, and rating
3. Lambda auto-rejects low-match requests; auto-assigns high-confidence matches
4. If match confidence falls in a gray band, request routes to manual review
5. Once assigned, Lambda generates the statement of work (SOW)

This is not passive brokering. The Lambda is choosing which guard provides the service. It's not just presenting options — it's making the match decision using algorithmic criteria that DBG controls. The client doesn't negotiate with the guard; DBG tells the client who their guard is. The guard doesn't choose which client; DBG assigns the client to them.

That's furnisher behavior.

The Insurance Implication

If DBG is a furnisher, standard general liability (GL) insurance won't cover the business. DBG needs:

  • General Liability (GL) — for third-party bodily injury or property damage claims (someone gets hurt near a DBG-assigned guard)
  • Technology Errors & Omissions (E&O) — for mistakes in the Lambda's adjudication logic that lead to wrong matches or SOW errors
  • Contingent/Vicarious Liability — for claims that treat DBG as responsible for the guard's actions, even though the guard is independent
  • Each guard's Certificate of Insurance (COI) — showing their own coverage, with DBG named as additional insured

Comparable marketplace platforms (TaskRabbit, Instacart, Upland Security) all layer this coverage stack. They treat the platform as the service provider from an insurance standpoint, even where they classify differently for tax or licensing purposes.

The Architect's Question: Can We Redesign to Stay Broker-Like?

In theory, yes. A true broker architecture would:

  • Present the client with multiple guard options (top 3-5 matches)
  • Let the client choose the guard (not auto-assign)
  • Let the guard accept or decline the client (bidding model)
  • Guard and client negotiate SOW terms directly, platform provides template only
  • Platform charges a percentage commission on accepted engagements

This pushes control to the edges, away from the platform. From a licensing standpoint, it's cleaner. From a product standpoint, it's worse — longer time-to-match, higher friction, more support overhead, and clients expect platform assignment (they're paying for the convenience).

The intake Lambda exists because DBG's product thesis is: client submits requirements, gets a guard 15 minutes later, guaranteed coverage, one invoice. That thesis is incompatible with broker architecture. Pursuing it requires accepting furnisher classification and the licensing/insurance burden that comes with it.

What This Means for the Deploy Timeline

The Dablio team dissented on shipping the intake Lambda before completing the licensure check. Their argument was sound: once the Lambda goes live, you're operating as a furnisher in California. You can't unknow that. You can't unship it and revert to broker claims if the licensing requirements are retroactive.

The staged approach was:

  1. Deploy intake Lambda + licensure/insurance check in the same release (no production traffic yet)
  2. Conduct legal review with California counsel (get clarity on furnisher classification and PPO requirements)
  3. Secure required licenses and insurance
  4. Then route live production requests through the Lambda

This isn't caution — it's operational integrity. The Lambda's auto-adjudication logic is the feature. The furnisher classification is a consequence, not a bug to work around. You need to own it explicitly before you go live.

Questions for Legal

The pre-check report staged five questions for DBG's lawyer:

  1. Does California classify a platform that auto-assigns guards as a furnisher or broker? (Or does the answer depend on contract language, payment flow, or liability allocation?)
  2. If furnisher, does DBG itself need a PPO license, or just each guard?
  3. Are there safe harbors in the law for technology platforms, or does the furnisher classification apply equally?
  4. What's the timeline to obtain a PPO license if required? (Weeks, months?)
  5. Does insurance address the licensure gap, or is licensing separate and mandatory?

What's Next

The intake Lambda is staged and ready in a non-production environment. The legal review is scheduled. Once counsel answers those five questions, DBG can commit to a path: either redesign the intake flow to be broker-like (product trade-off), or pursue PPO licensure and furnisher-grade insurance (operational trade-off).

Either way, the architecture decision is now explicit. The Lambda doesn't ship until the business model is legal. That's the only scalable way to build.

``` Blog post written and ready for publication. This article explains the technical architecture of the intake Lambda, why it triggers California PPO licensing classification, and how that drove the decision to package the legal check with the deploy—grounding it in the actual system design decisions rather than abstract legal theory.