Distribution and assembly, in one tenant. Canonical-model first.
You're not just a distributor and you're not just a manufacturer. You move pallets, you build kits, you repair returns, and you ship custom-configured systems. Distribution AI misses your assembly side; manufacturing AI misses your distribution side; you end up with two half-fits and a reconciliation problem. OpsATC.AI is canonical-model first — SalesOrder, WorkOrder, InventoryLevel, and PurchaseOrder are first-class regardless of business lane. Two lane-native dashboards (Distribution and Assembly) plus one exec roll-up, all reasoning on the same objects in the same tenant.
"We don't fit either bucket cleanly."
Hybrid operators move pallets and build kits and repair returns and ship custom-configured systems. The distribution-AI vendors miss the assembly side. The manufacturing-AI vendors miss the distribution side. The operator ends up with two half-fits running in parallel, two reconciliation problems at the exec layer, and a Friday-afternoon spreadsheet that nobody trusts. The architectural fix is to start at the entity level — make SalesOrder, WorkOrder, InventoryLevel, and PurchaseOrder first-class regardless of business lane, and reason on the canonical objects rather than the lane-specific schemas.
The five drains that consume a hybrid operator's week.
In the discovery conversations we've had with value-add distributors, service-and-repair shops, and light-assembly operations, a recurring pattern keeps surfacing — different industries, different mix between distribution and assembly, the same five drains. The Captain is designed around exactly these.
Two systems, two dashboards, two truths
The distribution side runs in the WMS and CRM. The assembly side runs in the MES and shop-floor systems. The reconciled view exists nowhere — except in a spreadsheet your ops director rebuilds every Friday. By Monday, the spreadsheet is already stale.
Cross-lane handoffs nobody owns
A service-and-repair work order consumes parts that came in on the distribution side. The kit you're building pulls inventory that was reserved for a distribution PO. Nobody owns the handoff between lanes — so the inventory shows allocated in one system, available in the other, and your buyer makes the wrong call.
Value-add margin invisible in distributor reporting
Imagine the chunk of revenue — say, 38% — that comes from kitting, configuring, and assembling: it shows up as a single line on the distribution P&L. Nobody can pull "what's my Value-Add Revenue Ratio by customer segment, by quarter, by program" without a finance ticket — and finance pulls it from a query that takes a week.
Service TAT competing with distribution OTIF
The customer who needs the repair turned around in 48 hours and the customer who needs the OTIF hit at 96% are competing for the same warehouse pickers, the same buyer attention, and the same exec airtime. Whichever lane shouts loudest wins.
Exec roll-up that doesn't reconcile
The board deck pulls distribution KPIs from one source, assembly KPIs from another, and service KPIs from a third. The numbers don't reconcile because the underlying definitions don't — and the exec spends thirty minutes of the QBR explaining why the lanes don't add up instead of running the business.
All five run through the same canonical model
The Captain doesn't replace your distribution buyer, your assembly planner, or your service lead. She reasons across both lanes on the same canonical objects, in the same tenant, with the same audit trail — so the exec roll-up reconciles by construction.
Read · reason · cite · draft. Operator approves.
The Captain reads your live systems via MCP — one Captain watching both lanes, the distribution side and the contract-manufacturing side, with hard tenant boundaries between customers but lane-aware reasoning across the two so a distribution exception can cross-reference an in-flight CM build for the same customer when appropriate. She reasons across the canonical model, drafts cited recommendations for the Distribution Buyer, the Shop-floor Lead, the Customer Operations Lead, and the Tier-1 Account Manager, and stops at the operator. Every commit happens in your existing ERP, WMS, MES, or CRM, with the source records cited and the audit log captured.
Two lane-native views, one exec roll-up, one canonical model.
Distribution Buyer · OTIF, fill rate, EDI exception triage
The full distribution-lane experience documented on the For Distributors page — OTIF watching, exception ranking, EDI rejection triage, "where is my PO" customer-facing answers. Same Captain, same audit trail, same orchestration layer.
Assembly Planner · OEE, first-pass yield, WO sequencing
Lane-native view for the assembly side — OEE drift, first-pass-yield exceptions, scrap rate alerts, work-order routing recommendations, kit-completion-rate tracking. The Process Intelligence Engine identifies which line, shift, or work-order pattern is driving the yield drop.
Service-and-Repair · Service TAT against parts availability
Service work orders aren't separate — they consume parts the distribution side allocated. The Captain surfaces the cross-lane handoff in one place: when a repair WO is waiting on a part that's allocated to a distribution PO, the buyer and the service lead see the same conflict in the same queue, ranked by customer-revenue impact.
Hybrid Exec Roll-up · Value-Add Revenue Ratio, cross-lane health
One executive summary that reconciles by construction because the underlying entities are canonical. Value-Add Revenue Ratio, Service TAT, Kit Completion Rate, distribution OTIF, and assembly OEE all roll up off the same SalesOrder / WorkOrder / InventoryLevel objects — no spreadsheet glue, no Friday reconciliation.
Per-persona outcome targets — measured against your baseline.
Design-stage targets, not promised magnitude. The first design-partner pilot is where the delta gets measured against your operator baseline. Below: where The Captain is built to move the needle, by role.
OTIF and exception queue, in the same tenant
Designed to deliver the full Distribution-lane experience (OTIF, fill rate, EDI exception triage, "where is my PO") inside the same tenant as the assembly lane — one canonical model, one audit trail.
Traces to: Distribution Buyer workflow
OEE drift named before it becomes an escalation
Designed to surface assembly-lane OEE drift, first-pass-yield exceptions, and kit-completion patterns days before the next customer escalation — the same Captain that watches distribution watches the shop floor.
Traces to: Assembly Planner workflow
Cross-lane parts conflict, in one queue
Designed to converge service work-order parts demand and distribution allocation into one ranked queue — the buyer and the service lead see the same conflict in the same place, ranked by customer-revenue impact.
Traces to: Service-and-Repair workflow
Roll-up that reconciles by construction
Designed to deliver a Hybrid Exec roll-up (Value-Add Revenue Ratio, Service TAT, Kit Completion, distribution OTIF, assembly OEE) that reconciles by construction — no Friday spreadsheet, no QBR autopsy.
Traces to: Hybrid Exec Roll-up workflow
Pre-built MCP connectors for both lanes.
OpsATC.AI sits on top of your existing investments — your ERP, your WMS for the distribution lane, your MES for the assembly lane, your service-management platform, your EDI gateway, and your CRM. Nothing gets retired. Read-only connectors via Model Context Protocol, with audit trails at the protocol boundary.
Reference adapter implementations are scaffolded for these platforms and validated against synthesized fixtures from public API documentation. Partner-sandbox re-records are pending; production validation happens during the first design-partner pilot. See platform integrations for the full reference-vs-scaffolded breakdown.
ERP & FinancialsOrder management, AR/AP, item master, value-add costing
Warehouse ManagementDistribution lane — inventory, fulfillment, ASN
Manufacturing ExecutionAssembly lane — work orders, routing, OEE
Service & RepairField service, depot repair, parts pull
EDI, B2B & CRMTrading partners, customer relationships
The IT lift is one tenant — not two.
No data lake. No two-tenant deployment. No reconciliation layer for you to maintain. The Captain reads your existing ERP, WMS, MES, service platform, and CRM live via MCP — and reasons across both lanes on the canonical model in a single tenant. See the Day 1 to Day 90 timeline →
What we need
- ✓Read-only credentials per system you want orchestrated
- ✓Service accounts on both your distribution and assembly stacks
- ✓Allow-list approval for OpsATC.AI's egress addresses
- ✓One-time mapping of customer and item identifiers across the lanes
- ✓A scoping conversation on your Value-Add Revenue Ratio definition and your cross-lane prioritization rules
What we don't need
- ✗Two tenants, one per lane
- ✗Custom reconciliation layer for you to maintain
- ✗Replatform from your current WMS or MES
- ✗Historical extraction from your data warehouse
- ✗A choice between "distribution AI" and "manufacturing AI"
Your hybrid-operation data is dirty when we start — customer masters split across multiple ERPs, contradictory inventory between distribution and OEM channels, partial truths in the integration view versus the manufacturing view, parts numbered differently in each system, financial entities that don't reconcile between subsidiaries. The Captain Data Quality Detection Layer runs continuously: baseline at MCP connect, inline on every read, scheduled per record type, on-demand when an operator asks. Six issue classes, four detection modes, all surfacing through the Trusted Advisor card. No six-month cleanup project. See the full Data Governance architecture →
Bring your worst week from both lanes. We'll walk through how it reconciles.
Thirty minutes, one distribution exception and one assembly exception that today live in different systems and different conversations. We'll walk through how the canonical model makes them the same conversation. Written diagnosis within one business day.