Mixed-crew safety OS for solar EPCs deploying autonomous construction machines on active sites without blanket exclusion zones.

1. Field data volume is no longer the blocker because 50,000-plus operating hours and 40-plus active sites show autonomous construction has enough real-world evidence to support a safety operating layer.
2. The category's hardest unsolved issue is now worker edge cases like occlusions and unusual body poses, which makes mixed-crew safety software more urgent than another task-specific autonomy demo.
3. Academic and industry partners are explicitly focused on closing the gap between controlled validation and operational robustness, creating a clear budget and credibility opening for field-governance software.
4. Safety is being framed as an industry-standard layer and the data pipeline is extending beyond one machine class, so buyers will soon need one workflow that spans multiple autonomous vehicles on the same site.

Catalyst. Built and Penn's edge-case data partnership signals that the category's bottleneck has moved from proving a robot can do the task to proving it can operate safely around people on real construction sites.

Mixed Crew Autonomy Safety OS would sit above machine OEM telemetry and below field operations. It would combine autonomy perception events, site boundaries, crew assignments, traffic plans, and supervisor observations into a site-specific safety case that refreshes daily as conditions change. The product would flag where visibility, occlusion, or personnel-behavior risk exceeds approved thresholds, recommend tighter or looser operating envelopes, and produce auditable shift-ready approvals for EHS and site leadership. A near-miss review workflow would turn every stop, override, or detection failure into structured training data and operating-rule updates across sites. Over time, the company would build the deepest cross-site dataset on safe mixed-crew autonomy in outdoor construction.

What's different. OEMs can ship perception models and emergency-stop logic, but contractors still need a neutral operating layer that decides where, when, and under what conditions machines should run near human crews. The differentiator is not just detecting people; it is turning cross-site near-miss evidence, work-plan context, and vendor-agnostic telemetry into daily operating envelopes and sign-off workflows. That creates defensibility through a proprietary dataset of mixed-crew edge cases and site-level policy outcomes that no single OEM or contractor sees in aggregate.

Jobs to be done

flowchart LR
  Buyer[Solar EPC safety leader] --> Pain[Autonomous machines cannot safely scale on active mixed-crew sites]
  Pain --> Product[Mixed Crew Autonomy Safety OS]
  Product --> Outcome[Faster autonomy rollout with auditable human-machine safety approvals]

Executive takeaways

• The wedge is real but narrow: construction autonomy is moving from isolated task automation toward mixed-crew operation, and the hard problem has shifted to worker edge cases, operating rules, and proof of safe coexistence [1][2][4].
• The best entry point is not “better autonomy,” but a neutral evidence layer above OEMs and generic EHS tools, because OSHA still relies on general duties and risk assessment rather than robot-specific construction rules [10][13][14][15][18][19].
• Beachhead economics look specialty-scale rather than huge; solar alone appears to be a sub-$100M annual software segment at current deployment density, so expansion into broader outdoor autonomy is essential [1][8][9].

Market definition

The product sits between machine OEM autonomy stacks and contractor safety software: a vendor-neutral operating-envelope, near-miss review, and deployment-approval layer for mixed human-machine work on active utility-scale solar and adjacent outdoor construction sites [1][4][25][28][30].

Customer and buyer

Primary users are VP-level EHS, construction operations, and field-technology leaders at large solar EPCs or self-perform civil contractors; site superintendents and safety managers are daily operators, but budget authority likely emerges only when autonomy expands from pilot zones into production work [5][28][30][37].

Buying triggers

• A pilot expands into active mixed-crew production work and leadership needs auditable shift-by-shift approval evidence before more machines or sites go live. [1][37][38]
• Persistent labor shortages and project delays raise willingness to use robots and remote-operation tools on live jobsites. [5][36]
• Multiple machine vendors or machine types appear on one site, making OEM-specific dashboards too fragmented for EHS sign-off. [1][21][25][39]

Willingness to pay

There is evidence of budget pressure, but not yet evidence of a mature standalone category budget. Contractors already pay for safety workflow tools and are spending against labor and schedule pain; the most plausible budget source is an autonomy-expansion or enterprise safety digitization line item rather than a greenfield “AI safety OS” budget [5][28][30][31][36][37]. [5][28][30][31][36][37]

Category dynamics

Growth signal ≈20.9% annualized growth in U.S. utility-scale solar generation (2025-2027)

Validation signals

• Built and Penn xLAB explicitly frame mixed-crew edge-case data as the next bottleneck in construction autonomy.
• Rosendin is testing autonomous solar-panel installers in Texas, indicating contractors are willing to run robots alongside field crews.
• Mortenson’s DOE-backed solar robotics trial suggests large contractors will pilot worker-adjacent automation when the workflow benefit is clear.
• Teleo’s Tomahawk case shows contractors want autonomy options and value one operator managing several machines.

Regulatory & technical constraints

• OSHA has no robotics-specific standard for construction, so employers still must prove safe operations via general provisions, hazard analysis, and recognized controls.
• Struck-by risk remains a top construction hazard, so any mixed-crew product must show strong personnel detection, geofence enforcement, and stop logic.
• Autonomy standards for off-road equipment are still being coordinated through AEM-led processes rather than through one settled procurement checklist.

Competition comes from three directions: OEM and autonomy vendors that own machine control (Built, Teleo, Pronto), incumbent contractor workflow systems (Procore, HammerTech, Safesite), and AI safety-monitoring vendors such as Intenseye. None obviously owns the cross-vendor, shift-approval workflow for mixed-crew heavy-equipment autonomy yet, but buyers can stitch together “good enough” substitutes from these layers [1][21][25][27][28][30][31][35][39].

Why incumbents do not win by default

• Cloud platforms. Procore can absorb observations and incidents, but it does not natively ingest autonomy telemetry or encode machine-specific stop conditions.
• Autonomy OEMs. Built, Teleo, and Pronto already own perception and control surfaces, but each optimizes its own machine stack rather than a contractor-neutral approval layer spanning multiple vendors.
• EHS workflow suites. HammerTech and similar tools already digitize pre-task plans, JHAs, and permits, so a new entrant must complement those systems rather than ask buyers to restart safety administration from scratch.
• Vision safety AI. Intenseye points toward real-time hazard detection, but it is not a site-specific autonomy-governance product for heavy equipment fleets.

Utility-scale solar contractors are starting to move autonomous piling, trenching, and material-handling machines from isolated pilots into active mixed-crew production work, but they still lack a neutral way to prove when those machines can safely operate near people. The first customer is a large North American solar EPC or self-perform civil contractor running multiple active sites and deploying its first 3-10 autonomous machines across one or more vendors. The product should start as a mixed-crew autonomy safety OS that ingests machine events, site maps, work plans, permits, and near-miss reviews to generate auditable daily operating envelopes, stop conditions, and shift approvals. Go-to-market should center on the pilot-expansion moment when a VP of EHS or construction operations must sign off before more machines or sites go live, because that is when pain, budget urgency, and measurable ROI align. The pricing and implementation model should stay tightly linked to that workflow: a paid first-site deployment plus annual per-site software priced against avoided stoppages, narrower blanket exclusion zones, and faster rollout of approved mixed-crew shifts. The near-term market is real but modest, with research supporting roughly $12.0M SAM and $1.5M year-3 SOM in the solar beachhead, so disciplined expansion into broader outdoor autonomy is required for venture scale. The main execution risks are unclear budget ownership, OEM feature creep, and services-heavy deployments that prevent software margins from emerging. Research also leaves three material gaps to close early: named buyer proof, insurer acceptance of software-backed approvals, and practical cross-OEM telemetry access.

Problem

• Solar EPCs expanding from isolated robot pilots to active mixed-crew work cannot defend daily human-machine operating rules with OEM dashboards, paper JHAs, static exclusion zones, and supervisor judgment alone.
• Safety-related stoppages, oversized buffers, and inconsistent near-miss learning slow autonomy rollout across sites and vendors, even when the underlying machines can perform the task.

Solution

• Build a contractor-side safety OS that combines perception events, machine stop and override logs, site boundaries, crew plans, and permit workflows into a daily mixed-crew operating envelope for each active site.
• Generate auditable shift approvals, near-miss reviews, and reusable rule updates so EHS and field leaders can expand autonomy with evidence instead of blanket exclusion zones.

Why we win

• The wedge sits in the buyer-owned approval workflow above OEM control stacks and alongside incumbent EHS systems, which creates value precisely when customers run multiple sites, machine types, or vendors.
• The defensible dataset is the linkage between site context, edge-case detections, approved operating rules, and actual outcomes, not just raw telemetry or generic safety observations.
• The product can complement Procore- or HammerTech-style workflows instead of asking contractors to replace existing safety administration systems during a live rollout.

Milestones

flowchart LR
  Wedge[Mixed-crew solar approval wedge] --> MVP[First-site approval packet MVP]
  MVP --> Proof[Approved shifts and fewer stoppages]
  Proof --> Expansion[Multi-site fleet governance]

Founding team

Experiment roadmap

Risk assessment

What must be true

• At least 5 of the first 10 ICP interviews confirm mixed-crew approval is a budgeted problem this year, not just a future concern.
• At least 2 design partners can provide enough machine-event and safety-workflow data to automate a useful first approval packet.
• One live pilot demonstrates at least a 15% increase in approved mixed-crew shifts or a 20% reduction in safety-related stoppages without higher near-miss recurrence.
• At least 50% of paid first-site deployments convert to annual subscriptions within 6 months of go-live.
• At least one customer running multiple machine types or vendors says contractor-side neutrality matters more than buying another OEM dashboard.

Open diligence questions

• Which function actually owns budget at pilot expansion: EHS, construction operations, or field technology?
• How much of the required telemetry is accessible by API or export across the first two target machine stacks?
• Will insurers or risk advisors treat the approval packet as credible decision support for narrower exclusion zones?
• Why will Procore, HammerTech, or the leading OEMs not absorb this workflow once demand is proven?
• How many autonomy-ready solar EPC accounts can realistically buy in the next 24 months before the company must expand beyond solar?

Model sanity

• Revenue engine. The base case is driven by expanding from 2 recurring active sites in Y1 to 10 by Q4Y3 at roughly $150K annual software value per site.
• Must go right. The first paid deployments have to convert into repeatable multi-site subscriptions before the company adds headcount beyond a 6-FTE core team.
• Model breaks if. If budget ownership and insurer acceptance stay unresolved, sales cycles lengthen and the downside case burns most of the remaining cash buffer before scale proof arrives.
• Next-round proof. A seed-ready story appears once the company shows at least one multi-site customer expansion and about 6 recurring live sites with evidence that solar can generalize into the next outdoor-autonomy wedge.

Scenarios

Sensitivity

flowchart LR
  Trigger[Pilot expansion trigger] --> PaidDeployment[Paid first-site deployment]
  PaidDeployment --> RecurringSites[Recurring active sites]
  CACSpend[CAC spend] --> PaidDeployment
  RecurringSites --> Revenue[Subscription revenue]
  Revenue --> GrossProfit[Gross profit]
  GrossProfit --> EBITDA[EBITDA]
  EBITDA --> Cash[Ending cash]
  Churn[Churn and site loss] --> RecurringSites

Flags: The modeled solar-only base case reaches the research-backed 10-site SOM by Q4Y3, so venture upside still depends on proving the workflow transfers into adjacent outdoor-autonomy verticals. · Revenue per FTE reaches about $213K in Y3, which is only the low end of healthy SaaS efficiency and reflects a still-deployment-heavy go-to-market motion. · The base P&L excludes paid implementation revenue to stay conservative, but that also means near-term cash conversion depends heavily on subscription timing rather than services invoices. · Insurer and risk-advisor acceptance is still unproven; if software-backed approvals do not narrow exclusion zones in practice, churn and sales-cycle assumptions likely deteriorate together.

• OEM feature creep. Construction machine vendors may add their own safety dashboards and argue that contractors do not need an independent layer. Mitigation: Focus on cross-vendor contractors that need neutral approval workflows and benchmarking across multiple machine types and OEMs.
• Weak initial budget owner. Safety, operations, and innovation teams may all care, but none may own a standalone software budget early on. Mitigation: Sell into pilot-expansion moments where autonomy capex is already approved and tie pricing to faster utilization and lower site-delay costs.
• Services-heavy deployments. Early customers may demand custom site setup and incident review that turns the company into a consultancy. Mitigation: Constrain the beachhead to repeatable solar-site workflows and productize telemetry adapters, approval templates, and rule libraries from the first few rollouts.