Integrating new technology into an established manufacturing operation is rarely a plug-and-play exercise. We face a compounding set of challenges that begin long before a system goes live and persist well after. Justifying return on investment is usually just the first hurdle: capital expenditures have to be weighed against uncertain payback periods, and benefits like flexibility or quality improvements are notoriously difficult to quantify against the concrete costs of disruption.
Once a system is approved, cell bring-up consumes significant engineering hours with fixturing, calibration, integration with existing PLCs and MES systems, and tuning to the specific tolerances of the line all demand specialized expertise that many of us lack in-house. Even after commissioning, the burden does not even begin to end. Ongoing maintenance, spare parts management, operator training, and troubleshooting create a long tail of technical debt, and any change to upstream processes or production targets can trigger costly reconfiguration of machines and technology. Compounding these issues, directly threatens throughput commitments, making manufacturers understandably risk-averse toward unproven technologies even those with clear theoretical benefits · like robotics.
1Non-automation
The 40-40-20 rule, articulated by Wickham Skinner forty years ago, holds that 80% of manufacturing competitive advantage comes from structural and technological change, and only 20% from conventional productivity work. The integrator market sells almost exclusively into the 20% bucket, engineer-hours optimized against existing structure. The four problems below are what it means to actually move the 80%.
The case for moving now is not that the technology has arrived. It is that the conditions under which your floor has operated for the last forty years are ending, and the operators who position themselves before that ending becomes obvious will be the ones who set terms when it does.
Three things are happening at once, and each one alone would be a reason to look at flexible automation seriously.
2Labour
A new industry · like electronics manufacturing or motor / actuator bring up, needs an effective ecosystem in which technology knowhow accumulates, experience builds on experience, and close relationships develop between supplier and customer. When you lose the people, you lose the commons, and once the commons is gone you can't get it back by hiring individuals.
When the U.S. lost batteries thirty years ago, it lost them because it stopped making consumer electronics, and whoever made batteries then gained the exposure and relationships needed to learn to supply batteries for laptops, and after that for cars. U.S. companies didn't participate in the first phase and consequently weren't in the running for all that followed. The technicians who learn to run flexible automation in 2026 are the ones who will know how to run whatever comes after it in 2032. The capability / capacity compounds. The operators who host the work to build it now are the ones whose floors will still have people on them in ten years who know how the equipment actually works.
Fig. IThe labor pressure that drives U.S. manufacturers toward automation has not eased. Open postings settled above pre-2020 baseline, time-to-fill skilled roles nearly doubled, voluntary turnover sits in the mid-twenties percent, wage inflation outran the rest of the economy through 2022 and stayed elevated.
Fig. IIWhat the U.S. lost in consumer electronics in the 1990s, it lost the commons for: laptops in the 2000s, EV batteries in the 2010s, and increasingly, the deployment infrastructure for whatever physical industry comes next. The capability compounds wherever it sits. The operators who host the work now are the ones whose floors will still have skilled people on them in ten years.
3Shape of demand
Product cycles that used to run for years now run inside the calendar. Customer specifications that used to be locked at the start of a program now change inside the program. SKU counts that used to be manageable on a fixed line now exceed what fixed automation can handle without constant retooling. Classical industrial automation optimized cost and dependability, accepted high quality as a cost of admission, and treated flexibility as a luxury. The work held up because the products that ran through the line did not change often enough for flexibility to matter. Markets and the speed of innovation have stopped cooperating with that bargain.
The demand profile of aerospace and defense manufacturing was built around long programs, stable specifications, predictable volumes, and decade-long platforms amortized over thousands of identical units. That profile has come apart.
Fig. IIIThe demand profile aerospace and defense manufacturing was built around has come apart along five separate axes. Each one alone would force a rethink of fixed automation. Together, they make flexible automation the primary axis of competition.
The threat environment changed faster than the acquisition cycle. Ukraine demonstrated, in public, that the side that can produce attritable systems at volume beats the side that produces exquisite systems at low rate. The 2024 National Defense Industrial Strategy and the Replicator initiative are explicit about it. The programs that are getting funded now require thousands of units, fast, with specifications that will iterate inside the production run because the threat is iterating inside the production run. Replicator, the DoD initiative announced in 2023, explicitly committed to fielding "thousands of attritable autonomous systems" within 18-24 months.
The customer base diversified. For forty years the prime contractors knew who they were selling to: a small number of Pentagon program offices with predictable budgets and slow procurement cycles. A generation of commercial defense companies are buying components, subassemblies, and finished systems on commercial timelines. Allied procurement (Australia, Japan, the UK, NATO) has accelerated. The supplier base that could deliver one program office's annual buy on an eighteen-month lead time now has to serve five different customer types whose lead-time expectations vary from quarters to weeks.
Production volumes have to scale in directions the existing industrial base was not built for. The munitions stockpile drawdown from Ukraine alone has forced the U.S. to attempt production rates on artillery shells, Stinger missiles, Javelin missiles, and 155mm rounds that the existing supplier base cannot hit with its existing equipment, regardless of how much capital is thrown at it. The constraint is not money. Congress has appropriated the money. The constraint is that the lines that produce these systems were sized for a peacetime drawdown and cannot be retooled fast enough to meet the surge. Every prime is being asked to triple or quintuple output on systems that were running at low rate three years ago, and the answer has to come from the supplier base, which is to say from facilities like yours.
Most importantly, program iteration itself has accelerated. The block upgrade cycle that used to run every five to seven years now runs continuously. Software-defined platforms push hardware revisions on the cadence of software releases.
The combination of these four shifts has done something that classical aerospace and defense manufacturing was not designed to handle. The industrial base was optimized fifty years ago for a different problem: build exquisite systems at low rate, amortize tooling over decade-long programs, accept long lead times as the cost of high reliability, treat flexibility as a luxury because the program would not change much over its life.
The cells that can be retasked from one variant to the next do not yet exist as productized infrastructure. They are what we are building. The supplier base that hosts the work to bring them up first will be the supplier base the primes route the surge through. The supplier base that waits will be watching the surge route around them.
The line that has to be built now is one where flexibility is the primary axis and the others have to follow it. The cells that can deliver this do not yet exist as productized infrastructure and as a result, whoever installs them first sets the cost curve everyone else has to match.
4Deployment layer
For thirty years, robotics in American manufacturing has meant programmed cells; the reason this has not changed is similar to the defense industries' way of acting on a cost plus basis. Their revenue model is engineer-hours, which means every hour an integrator spends building a tool that would reduce future engineer-hours is an hour of revenue the integrator chose to forgo. Thirty years of this incentive has produced a $30B integrator market that sparsely ships reusable infrastructure.
The deployment layer that would replace it is what we're building. It's being built now because the underlying models are finally good enough that the deployment layer is the binding constraint, and because the operators who will host the work it takes to build it are the ones we are looking for.
Fig. IVEvery wave of factory tech arrived with a payback story. PLCs delivered. The next thirty years are a more complicated picture. ERP rollouts ran years long; MES adoption fragmented; IoT generated dashboards; predictive-maintenance ML pilots rarely cleared fleet-wide deployment; cobots delivered for some labor-tight tasks and left others alone; vision/ML still has more demos than deployments. Foundation-model robotics is the latest wave, walking into the same skepticism the last seven walked into.
The reason these three lines matter together, rather than separately, is that the operators who address them piecemeal will spend the next decade running into each one in turn. The labor situation does not wait for the demand-shape problem to resolve. The demand-shape problem does not wait for flexible automation to be commercially mature. The flexible automation does not wait for the labor situation to ease.
Forty years ago Wickham Skinner wrote that the American manufacturers losing market share were the ones who had spent the previous decade optimizing within the wrong frame which was chasing productivity gains inside a structural setup that had stopped working. The ones who recovered were the ones who recognized that what they needed was not a better version of what they were doing, but a different way of doing it.
The honest position is that flexible automation is not going to look turnkey for another two to three years. The honest position is also that the operators who wait for it to look turnkey will be buying a commodity at commodity prices, and the operators who help build it will own a capability their competitors cannot match.
5Deployment
Relling is a deployment company. We work with the best AI and robotics companies to deliver the latest and greatest models to the factory floor.
The models today have not been tested inside deployment environments. Relling exists to bring the rigour of the engineering to the capability of the best models.
6What we can do today
The perfect candidate for tasks to automate with us fit at least 2 of these criteria. We will not work with you to automate tasks that do not fit at least one of these criteria (and if not at least 2, we will try very hard to work with you to find a classical automation solution).
Geometric variability that exceeds fixturing tolerance. When parts arrive in poses that vary by more than a few millimeters or a few degrees, programmed waypoints fail. The operator on the floor compensates visually, by hand.
Examples: cable harness routing into avionics enclosures where the cable bend varies between units; component placement on a circuit card assembly where the board flexes during handling; deburring a casting where the flash geometry differs across pours; sealant application along a fastener row where the row position drifts within build tolerance.
Contact-rich interactions with deformable or compliant materials. When the task involves materials that bend, stretch, compress, or settle under their own weight, geometric models break down.
Examples: composite layup where the ply has to be smoothed against a curved tool; wire harness installation where the wires have to be coaxed through a clamp without kinking; gasket placement where the gasket deforms during seating; seal pressing into a groove that requires force feedback to seat correctly.
Tight tolerances against an imperfect feature. When the target tolerance is tighter than the perception system's measurement error, the cell has to close the loop visually rather than open-loop against a calibrated position.
Examples: insertion against a hole whose position is known to ±0.5mm but whose required insertion clearance is ±0.1mm; precision fastener placement where the hole has been drilled in an earlier op and is not exactly where the CAD model says; tip alignment for soldering, brazing, or laser operations where the target feature is too small or reflective for reliable depth sensing.
High mix, low volume, frequent changeover. When the cell has to run dozens of part variants on the same line, and the variants share a common process but differ in geometry, programmed cells require a separate program per variant and weeks of integrator time to add a new one.
Examples: machining or finishing a family of brackets that share a geometry pattern but differ in size; harness build for a family of avionics boxes where the routing is similar but the connector positions differ; surface finishing on a family of forgings where the contour pattern is shared but the dimensions vary.
The deployment layer handles tasks that compose from a stable library of manipulation primitives. Each primitive is a learned-and-classical hybrid, built once, validated across multiple deployments, and configured against a specific task. Adding a new task to a deployed cell is configuration, not engineering. This is what makes the unit economics work.
The library today:
- Pick. Grasp from an unstructured pose. Visual servoing for orientation.
- Place. Into a fixture or onto a surface, within tolerance.
- Insert. Push under tight clearance, with force-feedback fallback when geometry drifts.
- Align. Tool tip to target feature, soldering, brazing, dispensing, fastening.
- Trace. Follow a surface contour, sealing, coating, finishing, deburring.
- Press. Controlled force on a compliant surface, seating, consolidation, gaskets.
- Inspect. Verify against a reference, QC, defect detection, presence.
If your task decomposes into these, we can deploy on the timeline our economics are built around. If it requires a primitive we have not yet built, we will tell you what it would take to add it. The honest answer is no somewhat more often than the marketing answer would be, and the operators who hear no from us have generally appreciated hearing it.
by plant technicians
without retraining
transfer
coordination
frontier-quality models
flywheel
Fig. VEach capability looks small. The cumulative absence is the reason robotic deployment is artisanal.
Fig. VIThe cells are economic above roughly 1,500 hours of annual task volume per cell, with the exact crossover sensitive to local labor rate, variant count, and the fixturing complexity of the manual alternative. Below that volume, manual labor is usually the right answer, and we will tell you so.
We aim for classical wherever possible, learned wherever necessary, never both at the same time on the same subtask. A typical cell we deploy will have more classical motion than learned motion. The learning enters at the specific subtasks where the variability bites (the contact, the alignment, the finishing), and the rest of the cell remains the kind of programmed automation your team has been running for decades. This is what makes the cells legible to the people who have to maintain them, and what makes the cycle times competitive with skilled humans.
Cycle time and volume
A learned-policy cell runs about ten to fifteen percent slower than skilled human operation on per-unit takt. In our reference data and in the published literature on hybrid automation, a task a skilled operator completes in 140 seconds is a task a learned-policy cell completes in roughly 160 seconds. The reason a cell is still economic, despite the gap, is that the eight-hour shift is not eight hours of work. A skilled operator works through a fifty-minute-on, ten-minute-off cycle structure mandated by labor practice, takes longer breaks for meals and shift change, and has a per-unit cycle time that varies more than the cell's does. The volume threshold below which the math stops working depends on the task, but as a rough rule, the cells are economic at task volumes above roughly 1500 hours per year per cell, with the exact crossover sensitive to the prevailing fully-loaded labor rate, the variant count the cell has to handle, and the fixturing complexity of the manual alternative. Below that volume, manual labor is usually still the right answer, and we will tell you so.
Fig. VIICumulative throughput projection over an eight-hour shift. Despite a 12% slower nominal cycle, the robot-alone line overtakes the human line near the one-hour mark and stays ahead. The break-constrained human schedule reduces effective production time. P20–P80 spread on human cycle times is wider than on robot cycle times.
Quality regimes and inspection integration
The deployment layer's first generation is targeted at AS9100-controlled work and the contact-rich, dispensing, finishing, and assembly operations within it, the regime where downstream QC is performed by a human inspector or a downstream automated station, not the regime where the cell itself is a flight-critical certified process. Reference deployments under hybrid learning architectures have demonstrated 99.4 percent first-pass yield on downstream QC for cable insertion and soldering operations, with first-pass yield holding above 99 percent across multi-hundred-unit continuous runs. We're targeting first-pass yield above 99 percent and Cpk values above 1.33 on the operations within our envelope, which is the threshold most aerospace QC plans are written against. The cells hand off to your existing inspection rather than replacing it. They produce parts on your existing line cadence, in your existing handoff format, with traceability data that maps onto your existing quality system. We are not asking you to re-architect your quality flow to accommodate the cell. The cell sits inside the flow you have. If your operation is flight-critical and requires the cell itself to be a certified process, DO-178 software certification, NADCAP-controlled special process certification, or equivalent, that is a regime we are not yet operating in.
Footprint, environment, division of labor, and consumables
A typical cell sits in roughly forty to sixty square feet of floor space, which is comparable to the manual workstation it augments and meaningfully smaller than a programmed automation cell of equivalent capability. The cells are designed to operate in standard factory environments, including ESD-controlled zones common in electronics assembly. Cleanroom-rated deployment requires additional engineering on the end-of-arm tooling and is something we scope on a per-deployment basis rather than offering as a standard configuration.
Atypical deployment looks like the following: a human loads parts and consumables into the cell at the start of a batch and at intervals during the shift, the cell executes the inner-loop manipulation work, the cell hands the completed part to either the next station on the line or back to a human for inspection and downstream handling. The human is needed roughly every ten to twenty minutes during normal operation, depending on consumable capacity and batch size, and the cell is designed so that during the intervals between human interaction the operator can perform downstream work like inspection or material handling on a different unit rather than standing idle waiting for the cell to finish. This parallel-work arrangement is where most of the labor productivity gain actually comes from.
The pattern is consistent across the industry: the cells that survived are the ones that were designed to operate as semi-independent islands of automation rather than as nodes in a fully synchronized line.
The deployment layer is built around this lesson rather than against it. A cell we deploy is designed to operate as one of those islands, it does its task, hands the part to the next station (which may be another cell, or a human, or the existing line), and continues. The cells are not synchronized through a master controller that stops the line when one cell drifts. The cells are synchronized through the same buffering and handoff protocols your existing line already uses, which means a cell going down does not stop the line; it stops the cell, and the line works around it the way the line already works around any individual workstation that has gone down. This is operationally identical to how a manual workstation behaves when an operator has to step away. The cell is, from the line's perspective, an operator that does not take breaks but does occasionally need maintenance, on roughly the same cadence and with roughly the same impact as a human operator with a competent supervisor.
Jigs and fixturing
Classical waypoint automation requires precise fixturing because the robot is moving open-loop to a pre-programmed pose. The fixture has to hold the part within micrometer tolerances of the position the program assumes, or the program fails. This is why classical cells have such expensive fixturing, typically 30-50% of the cell's total capex is in the fixturing alone, and changing what the cell does often means rebuilding the fixturing from scratch.
Visual-servoing and imitation-learning approaches close the loop visually rather than open-loop against a fixture. The cell can adapt to a part that has arrived in a different position than the program expected, because it is looking at the part rather than assuming where it is. This means the fixturing requirements are substantially relaxed, but not eliminated. We still need:
- Some way to hold the part roughly in place during the operation (a jig, a clamp, a vacuum table, but coarse, not precision)
- Some way to present the tool or consumable to the robot (a holder, a feeder)
- Some way to constrain the workspace so the robot knows where to look
Retasking the cell to a new part within the same family typically does not require a fixturing change. This is the single largest source of the deployment cost reduction described above, and it is the reason the cells can be retasked in minutes rather than weeks.
7What we will do for you in the future
The cells we deploy in 2026 and 2027 are not the cells we will deploy in 2030. The deployment layer is being built across this window, against real production conditions, in our own facility and in the facilities of a small number of strategic partners who are helping us build it. What you would be working with us on now is not a finished product. What you would be helping shape is the version that becomes one. Three things change between now and the version that ships at scale.
The cells get faster, because the per-unit takt that runs ten to fifteen percent behind skilled human operation today closes against and then crosses the human curve as the underlying models improve and the deployment layer absorbs more of the operational variance. The cells get cheaper, because the integration work that currently absorbs most of the all-in cost is the work being productized.
The honest framing of the relationship is this: during the bring-up window, your facility, your operators, and your operational knowledge are worth more to us than the cell hardware is worth to you. That asymmetry is real, and it shapes the commercial terms we are willing to offer.
The reason is that the deployment layer cannot be built in a vacuum. It cannot be built in our own facility alone, no matter how realistic we make the production conditions there, because every floor is different and the patterns that matter are the patterns that emerge across multiple operational contexts. The operators who let us deploy on their floors during this window are not customers in the conventional sense. They are co-builders. The variance of their lines surface, the failure modes their technicians catch that ours do not, the operator instincts they bring to bear on cells that our engineers built, this is the input the deployment layer requires to compound, and it is not a thing that money buys. It is built one floor at a time, with operators who let us learn alongside the work they are already doing.
Concretely, what this means is that we are willing to deploy cells at substantially below our own all-in cost during the bring-up window, and in some cases at no capital cost to you, with the understanding that the hardware on your floor is part of how the layer gets built.
What we are asking from you in return is not money, and it is not a heavy lift on your team. It is access to the work that is already happening on your floor. The operators we have talked to have generally found the time we ask for to be less than they expected, because most of what we need to learn is learned by watching, not by interrupting.
The operators we are looking for are the ones who hear this framing and recognize it as honest. We are not asking you to host us. We are asking you to let us learn from the floor you have already built.
8On technical automation
There are two ways automation lands on a floor, and the difference is not in the technology. It is in who, after the cell goes in, can still answer the question of why it stopped.
In the first way, the operator gains something. More visibility into the line. More ability to fix the cell when it drifts. More leverage when the next round of capex comes up, because the people who run the floor understand what they are running. The cell is still a machine someone else built, but it is a machine the floor has taken into its own hands. When it fails at three in the morning, the technician on shift can read what it is doing, see where it has gone wrong, and put it back. The vendor's phone number is in the binder somewhere, but most weeks it does not get dialed.
In the second way, the operator loses something. A job leaves the floor and a black box arrives in its place. The cell runs, until it does not, and when it does not the technician stands in front of it with no purchase on the problem. The lid is sealed. The fasteners are the kind that require a tool nobody on the floor owns. There is no schematic in the binder because the manufacturer has decided the schematic is proprietary. The technician calls the vendor. In the meantime the line is down, the customer is calling about a delivery date, and the plant manager is explaining to corporate why a piece of equipment whose payback story was eighteen months is now, in its second year, the single largest source of unplanned downtime in the building.
Several large, well-respected automation deployments arrived in the second mode. The operators who hosted them have been quiet about how it worked out. The ones who will talk are emphatic that they will not do it again.
We are designing for the first mode. Not because it is a more attractive marketing position, it is not, it commits us to harder work, but because the alternative produces a floor where the people who actually run the line have been demoted to spectators of equipment they are nominally responsible for. That arrangement does not hold. It does not hold operationally, because a cell whose only competent maintainers are three time zones away will not deliver the OEE the capex model assumed. It does not hold commercially, because the operator who has been through that cycle once is not buying another one. And it does not hold on its own terms, because the technician on the floor at three in the morning is the person whose judgment the line actually runs on, and a cell that cannot be interrogated by that judgment is a cell that has been built for the wrong customer.
The commitments below follow from this– the consequences of deciding that the floor is the place the work happens, and that any cell we ship has to earn its place there on the floor's terms.
| Dimension | Mode B · operator loses | Mode A · operator gains |
|---|---|---|
| MTTR per failure event | 24–72 hrs (vendor escalation) | <2 hrs (technician on shift) |
| Schematic / dossier on the floor | Vendor-proprietary, sealed | Ships with the cell |
| Behavioral fix at runtime | Requires a model release | Steering vector applied in minutes |
| Vendor calls per shift | 5–15 (current learned-policy cells) | <1 |
| Plant-tech resolution rate | <20% | 90%+ |
| Steady-state OEE | 30–50% | 85%+ |
| Switching cost | Real, plus contractual lock-in | Real, but no contractual lock-in |
| Vendor's leverage on you | High · roadmap, support, IP | None · cells continue to deliver or you replace them |
9Why us? Why now?
You have read this far, which means the case for the conversation is clear enough. The harder question is why this conversation is with us, rather than with the integrator your facility has worked with for fifteen years, or with one of the better-funded robotics companies that have been pitching aerospace and defense suppliers since 2022. The honest answer is that we are positioned differently, in a way that matters for the specific kind of work the deployment layer requires.
The layer can only be built by a company whose primary product is the layer itself, whose primary revenue eventually comes from serving other operators' deployments, and whose primary operational flywheel is sustained immersion in real production under conditions the company controls.
The next section of this document describes how we have arranged to live inside them. The short version is that we bought a factory. We are running it. The cells we ship to your floor have been stress-tested first against our own production, against our own customers, against our own margin pressure, and that arrangement is what gives us the standing to make the commitments we made in the previous section.
What follows is the structural argument for why the deployment layer is the unowned position in robotics today, why owning it matters more than owning any individual vertical, and why the work to own it has to be done in the next eighteen months rather than the next five years. We have included it because the operators we have talked to have generally wanted to know who they would be working with before they committed to the work, and the strongest answer to that question is not our team page or our investor list. It is the structural position we have taken in the industry, and the reasoning behind it.
10Process knowledge
The distinction between product knowledge (the blueprints and specifications that describe what a thing is) and process knowledge (the tacit, diffuse, locally-held competence that describes how it actually gets built) matters here. Process knowledge is not a commodity that can be bought and sold. You cannot acquire process knowledge by licensing it, by buying a company that has it, or by hiring one person who has it. You can only build it through sustained operational presence over time.
Every one of the deployment problems listed above is, at root, a process knowledge problem. They will be solved by engineers who have spent years inside real production, watching what actually breaks and building the tools that make it not break. That work hasn't happened yet, not because it is impossible, but because the existing structures of the robotics industry are each structurally unable to produce it from where they sit.
It is useful to frame process knowledge as tacit, diffuse, locally-held knowledge that is the product of market interactions. It can only be built through sustained operational presence over time.
Fig. VIIIThe Welding Procedure Spec captures every parameter the regulator wants captured: filler material, current, voltage, travel speed, joint geometry. It can be photocopied, licensed, sold. The bead in the metal is the work that the spec describes but does not contain. Two journeyman welders can read the same WPS and lay visibly different beads. The spec is the product knowledge. The bead is the process knowledge. Manufacturing competence lives in the second category and ships only with the people who built it.
11Fuselage
Fuselage is a factory we are buying. We are not buying it because we want to be in the assembly business. We are buying it because it gives us a production line that runs today, ships to real customers, and has real consequences when it stops running. Those consequences (tight margins, uptime that has to hold, SKU changes you didn't plan for, a customer who's unhappy one day for reasons that have nothing to do with robotics) are the same ones that make robot deployment hard. We believe we can not get good at solving them from a research lab but we can get good at solving them by running a factory. So we are running one. Relling is not selling robots into other people's factories– we are running our own. Owning the factory rather than renting time on someone else's gives us:
- Day-one revenue and cash flow, not a burn-financed R&D facility.
- Real customers, real SKUs, real volume pressure. The only environment where the four problems actually bite.
- A defensible reason the process knowledge can't be replicated: you own the floor, not rent time on someone else's.
- Direct research relationships with the leading private foundation-model labs in robotic manipulation. Our cells run on the current frontier, not the generation that was production-ready eighteen months ago when an integrator started the project.
Fig. IXFuselage is a working battery-assembly plant Relling owns and operates. Five cells run production today; three are being retrofitted with learned-policy systems. Material flows in a snake pattern from the receiving dock through eight cells in sequence, exits at the shipping dock, with an observability spine running underneath the floor. The cells are the laboratory and the customers are the deadline.
Fuselage exists to solve four problems that the rest of the robotics industry has either failed to address or has tried to solve from the wrong position. Each one is a process knowledge problem in the sense that it is solvable only through sustained operational presence, and structurally impossible to solve from a research lab, a systems integrator's office, or a customer's running production line. Each one is also a problem we cannot solve by writing better code or training better models. They have to be lived through, on a real floor, until the patterns that resolve them emerge from the work itself.
The goal of Fuselage is to solve four foundational problems:
- ROI closes within 12 months.
- The cell is brought online in days, not months.
- The cell stays running without specialist intervention.
- Safety is solved as productized infrastructure.
ROI Closes Fast
The unit economics of robotic deployment fail today for a reason that is structural rather than incidental. When an operator buys a cell, they are buying engineer-hours of work that will be performed inside their facility over the next six to twelve months, of which less than a third produces hardware with any continuing use beyond that single deployment, and the rest is consumed by an integration process that will be repeated, almost identically, the next time another operator buys another cell from another vendor. The integrator captures most of the value in this transaction, and the integrator's revenue model is built on engineer-hours rather than on productized infrastructure, which means every hour the integrator spends building a tool that would reduce future engineer-hours is an hour of revenue the integrator is choosing to forgo. This is the central reason that thirty years of robotic deployment in American factories has produced almost no reusable infrastructure for deployment itself.
Fuselage is built to break that pattern by treating cell bring-up as configuration against stable interfaces rather than as engineering against a blank slate, and by building the integration tooling, the data infrastructure, and the safety framework as productized assets that get developed once inside our facility and amortize across every subsequent deployment we run. The target is a representative cell deployed for under two hundred thousand dollars all-in, IRR above thirty percent against the operator's labor baseline, and a payback period inside twelve months that a finance team can defend through their standard capex framework rather than through narrative or analogy. The wager is that the company that builds the integration layer captures the value integrators have been extracting through engineer-hours for thirty years, and that the deployment layer will modularize the way data infrastructure modularized in software in the 2010s.
Fig. XThe integrator's engineer-hours block is what compresses. Productizing it once and amortizing across deployments is the bet.
Cell Is Brought Online in Days, Not Months
A cell takes six to twelve months to bring online today, and the reason is not that the work is intellectually difficult or that the engineers performing it are slow. The reason is that the bring-up process is serial, the dependencies between stages are circular, and the work cannot begin until the cell is physically present in the deployment environment. Mechanical integration cannot finish until the cell layout is locked, the cell layout cannot lock until perception is calibrated against the actual environment, and perception cannot calibrate until the lighting and surface conditions of the customer's facility are characterized in situ. Safety bring-up sits on top of all of this and cannot start in earnest until the cell is in something close to its final configuration, which puts it on the calendar at the end of the bring-up window when the customer is most impatient and the integrator is least focused. The result is that adding people to a deployment does not compress the timeline, because the dependency chain is what is binding, and the dependency chain cannot be parallelized in a customer's facility no matter how much labor is thrown at it. The bring-up timeline that incumbent U.S. integrators treat as standard has already been beaten by an order of magnitude under battlefield conditions in Ukraine, where new manufactured capabilities have reached initial operational use inside ninety days, and the fact that this is achievable under fire by a country with far less industrial base than the U.S. is the strongest available evidence that the timelines integrators quote are constraints of business model rather than constraints of physics.
Fuselage breaks the dependency chain by performing the work that currently happens inside the customer's facility against a real production environment that we own. Most of what an integrator does on-site for six months is not work that has to happen in the customer's building; it is work that has to happen against a working production line, and a working production line is a thing we have. Cells get configured, calibrated, validated, and safety-characterized inside our facility, against the operational reality of an actual factory rather than against a benchmark, and what arrives at the customer's site is a cell that has already done the work the customer's site has historically been the place to do. The handoff is configuration against a stable interface, not engineering against a blank slate. The target is purchase order to first production unit in under thirty days, with specialist engineer-hours per cell driven below one hundred, and the calendar time the customer's facility is occupied by integration work measured in days rather than in quarters. The wager is that the bring-up timeline is the variable that determines whether robotic deployment is a custom service or a buyable product, and that compressing it by an order of magnitude is what unlocks the deployment volume the rest of the business depends on.
Fig. XIThe serial dependency chain compresses because the work moves to a place where it can run in parallel (Fuselage's own line), and the customer's site sees only configuration.
The thirty-day bring-up target is not theoretical. Recent initial operational use of new physical-AI systems in Ukraine has moved from prototype to first field deployment inside ninety days under contested conditions, which is the order-of-magnitude compression the deployment layer needs to deliver inside a working factory. The benchmark is not whether the work is possible. It is whether each subsequent deployment costs less than the one before it.
The Cell Stays Running Without Specialist Intervention
A learned-policy cell fails differently than a programmed cell, and the operational implication is that the customer's plant technicians cannot resolve those failures with the diagnostic workflows they have spent fifty years developing. When a programmed robot fails, the cause is attributable to a specific line of code or a specific sensor reading, and the technician follows a deterministic chain backward from symptom to cause. When a learned-policy robot fails, the cause is encoded in model weights, the proximate symptom typically appears several steps after the originating distribution shift that produced it, and the diagnostic path requires interpretive tooling that plant staff have neither the training nor the access to use. A grasp angle that drifts by two degrees because of seasonal lighting changes in the customer's facility will not present as a missed grasp; it will present as a downstream insertion error six steps later, after the part has been transferred to another station, and the technician diagnosing the insertion failure has no mechanism to trace it backward to the grasp because the model does not expose its own intermediate state. Current learned-policy deployments respond to this by depending on a constant background of remote engineering support, with mean time to repair running between twenty-four and seventy-two hours per failure event, and the cumulative effect drags steady-state OEE into the thirty to fifty percent range that makes the cell economically marginal regardless of how impressive the underlying model is.
Fuselage is where the technician-facing infrastructure that closes this gap gets developed. The target is steady-state OEE above eighty-five percent, mean time to repair under two hours, ninety percent of incidents resolved by the customer's plant technicians without external escalation, and specialist intervention rates below one event per shift across the deployed fleet.
The wager is that the binding constraint on operator trust in learned systems is not model quality alone but model legibility, and that a learned-policy cell becomes buyable at the moment a maintenance technician can ask it what went wrong and get an answer they can act on. The observability spine that surfaces drift in production also surfaces drift under deliberate attack, which means that cyber hardening of a learned-policy cell ends up being downstream of the same observability surface that makes the cell operationally legible to its plant technicians, rather than a separate workstream the operator has to fund.
Fig. XIIThe jump from 30% to 85% is not a single fix. It is five separate blocks of lost time, each closed by a specific piece of infrastructure shipped with the cell. The numbers above are illustrative of a mid-complexity cell on a mid-complexity line; the breakdown shape holds across the deployments we have studied.
Fig. XIIIThe binding constraint on uptime is not model quality alone but model legibility. Move MTTR by an order of magnitude and the OEE band moves with it.
The same observability spine that handles telemetry and safety monitoring is also where cyber hardening lives. A cell that exposes diagnostic data to a plant technician has to expose nothing else, because the surface that lets the floor see what the cell is doing is the only surface the cell offers. Productizing the deployment layer means productizing that boundary alongside everything else, so that the resilience properties the operator depends on do not have to be re-engineered cell by cell.
Safety Is Solved as Productized Infrastructure
The robotic safety standards that govern industrial deployment in American factories (principally ISO 10218 covering robot system design and ISO/TS 15066 covering collaborative operation) were written for robots whose behavior is fully specified in advance through deterministic programming, and the certification process built around them assumes safety can be verified by analyzing the program against the hazard model. Learned policies break this assumption at the foundation. Their behavior is not specified in advance, their state space is too large to be exhaustively enumerated, and their failure modes cannot be characterized through the static analysis that programmed robots permit. The field has not converged on a reusable framework for certifying learned systems, so safety bring-up for a learned-policy cell today is performed as ad hoc behavioral characterization, augmented by additional risk-mitigation hardware, and accompanied by documentation of the operating envelopes the cell is allowed to occupy. This work consumes between four and eight weeks of specialist engineering time per cell, depends on safety engineers who are individually expensive and collectively rare, and exists as tacit practice in the heads of a small number of consultants rather than as productized infrastructure that ships with the cell.
What shippable safety looks like in practice is a cell that arrives at a customer's site with a complete certification dossier already assembled, characterized against thousands of operating hours of identical-architecture cells running inside our facility, with a runtime monitor that has already been validated against the failure modes the architecture is known to exhibit, and an incident response runbook that the customer's risk management team can adopt as written rather than reconstruct locally. The customer's safety engineer reviews the dossier, runs the standard acceptance tests against the runtime monitor, and signs off; they do not perform a four-week behavioral characterization study because that study has already been performed. Fuselage is where that study lives, and where the framework that makes it transferable across deployments gets built. The target is safety bring-up under five days per new cell, a reusable framework that applies across deployments rather than being rebuilt from zero, and incident rates that meet or exceed the ISO 10218 baseline that programmed robots achieve. The wager is that corporate risk management is the gating constraint on deployment scale, that no operator above mid-market will install learned systems at volume until the safety story is shippable rather than custom, and that the company that productizes safety for learned policies in industrial environments captures a position no incumbent in the standards-and-certification ecosystem is structurally able to take.
Fig. XIVToday's certification work runs from zero on every cell. Fuselage's reusable framework (dossier template, validated runtime monitor, incident runbook) collapses each cell to acceptance review.
12Why Fuselage
We think vertical integration is the wrong way to deliver affordable mass. The question American manufacturing now has to answer is one of producing industrial volumes at industrial prices, and the layer that decides whether that is possible is the one that makes flexible automation deployable into the factories that already exist.
The pattern: an initially vertically integrated industry unbundles into horizontal layers when the interfaces stabilize. In PCs, initially integrated (DEC, IBM), then modular (Intel + Microsoft + OEMs + peripherals). In robotics: currently vertically integrated (every robotics company builds hardware + firmware + models + integration), but it will modularize as interfaces stabilize. Relling is betting that the deployment layer will become one of those horizontal layers, and that owning it early is more valuable than owning any single vertical stack.
The SpaceX/Tesla/Anduril pattern was the right shape for the category when no platform existed, but the emergence of a platform changes the game. The full-stack companies in robotics may still exist and win (Figure, 1X, Skild as full-stack apps), but the larger structural opportunity is now the platform layer itself.
The industrial bottleneck below the primes sits at the Tier 2-N suppliers, the sub-tier shops that produce the components the primes assemble. These are the operators that classical automation never reached, because per-part volumes do not justify a programmed cell, and they are where flexible deployment infrastructure compounds fastest. The procurement vehicles for getting work into those shops already exist: roughly thirty Other Transaction Authority consortia operate inside the DoD acquisition system, and Defense Production Act Title III no-year appropriations remain the standing funding authority for industrial-base surge capacity. The vehicles are in place. What is missing is the deployment layer that makes any of them actually deliver on the floor.
Fig. XVInitially integrated industries unbundle when interfaces stabilize. PCs went modular in fifteen years. Robotics is in the early decade of the same trajectory, and the deployment layer is the layer worth owning.
13The Critical Bet
Manufacturing strategy has organized itself around four dimensions that any factory has to trade against: cost, quality, dependability, and flexibility. A factory cannot maximize all four at once, and the choice of which dimension to optimize defines what kind of factory it is. Classical industrial automation made its choice fifty years ago by optimizing for cost and dependability, accepted high quality as a cost of admission, and treated flexibility as a luxury that could be sacrificed because the products that ran through the line did not change often enough for flexibility to matter. The robots were programmed for a specific task, the cell was built for a specific product, and the line ran the same operation for years before being retooled. This bet was correct for its time. Markets in the late twentieth century rewarded long production runs of standardized products, and the cost-and-dependability optimum produced the manufacturing economy that the United States and Japan built their industrial bases on.
Product cycles have collapsed, customer specifications change inside the calendar year, and the operations that need to be automated are increasingly the ones that classical automation could never handle precisely because they require flexibility that programmed cells cannot deliver. The just-in-time inventory and globally distributed sourcing patterns that organized the last forty years of manufacturing strategy are being unwound in real time, and the operators who depended on them now have to answer surge demand with surge capacity that sits inside the country that needs it. The factories that have to be built now, and that the American industrial base has to build at scale to remain competitive, are factories where flexibility is the primary dimension and the others have to follow. Relling's central bet is that this shift has already happened in the market and is waiting for the deployment infrastructure that makes flexibility achievable without sacrificing the cost, quality, and dependability.
The reason flexibility has been treated as a luxury is that the only way to deliver it historically was through human labor, and human labor is expensive, scarce, and dependent on tacit skill that takes years to develop. A cell running a learned policy can handle product variants the cell was never explicitly programmed for, can adapt to changes in input materials without re-engineering, and can be retasked through a primitive library and a steering surface rather than through weeks of integrator labor. The four problems Fuselage exists to solve are the four constraints on letting that flexibility actually express itself in a production environment. The math has to close so that flexibility is not a premium product. Cells have to come online fast so that flexibility extends to new deployments rather than being trapped inside the one cell that already exists. Cells have to stay running without specialist intervention so that flexibility does not collapse the moment something drifts. Safety has to be productized so that flexibility does not stall at the corporate risk approval stage. The same conditions that make flexibility a manufacturing requirement make deployment capacity a strategic asset: the standard strategic-reserves logic of stockpiling finished systems cannot hold for industries whose technology cycles inside two years. What needs to be reserved is the capacity to produce, not the inventory produced. The Civil Reserve Air Fleet, peacetime commercial aviation that activates into military airlift on call, is the working analog. The deployment layer is what lets the same arrangement live on the factory floor.
Fig. XVIManufacturing strategy organizes around four trade-offs: cost, quality, dependability, flexibility. Classical industrial automation chose cost and dependability fifty years ago and treated flexibility as a luxury. Markets changed. Flexibility is now the primary axis. The other three have to follow.
Relling does not sell into manufacturing facilities. Relling owns one. The deployment layer is built inside the floor we run, against the deadlines and customers we are accountable to, and that is the only way the work compounds.
14Fuselage Works. What Now?
What Fuselage proves, when it works, is not a factory. It is a deployment layer. The four problems Fuselage exists to solve produce, when solved together, an integration substrate that did not exist before in any form. Fuselage is where that substrate gets built and proven. What happens after it is built is the question of how the substrate scales beyond the building it was created in, and the honest answer is that we do not yet know which scaling path is the right one.
The goal is not to operate thousands of factories. The goal is to enable the thousands of existing factories that already constitute the American industrial base to produce the volumes the next industrial revolution requires them to produce. The distinction matters because the standard tech-meets-manufacturing playbook of the last decade has been to build a vertically integrated operator that competes with incumbents on end-product margin, and the standard outcome has been that companies with tens or hundreds of millions of dollars of funding find themselves unable to compete on margin with family-owned operators who have been running their lines for forty years. Forceful additions of technology to manufacturing operations rarely produce the efficiency they promise on paper, because the operations the technology is being added to are themselves the product of decades of process knowledge that the technology has not yet earned. The factories that already exist do not need to be replaced. They need a deployment layer that lets them automate what classical automation could not.
Two paths run from Fuselage toward that goal, and the period after Fuselage is operational is when we will learn which one is the right one to scale through.
The first path is replication. The blueprint that gets produced inside Fuselage, comprising the integration tooling, the safety framework, the technician interface, the data infrastructure, and the playbook for how a deployment actually gets stood up against real operational conditions, is designed from the beginning to be transferable to other facilities that Relling owns and operates. The argument for this path is that the deployment layer is only as general as the operational conditions it has been exercised against, and operating across multiple industrial contexts ourselves is the most direct way to extend that generality. The risk is that owned facilities are capital-intensive, and the rate at which the deployment layer can scale through them is fundamentally constrained by how fast we can stand up new operations. Geographic dispersal becomes a property of the deployment layer itself rather than a logistical afterthought: every facility Relling stands up is a node that produces locally, and the failure modes that come with single-point manufacturing concentration retreat with each new node added.
The second path is the playbook leaving our walls. The deployment layer, by the time it is mature enough, is operable by someone other than us. Other operators get access to the infrastructure Relling has built and use it to stand up cells inside their own operations at the cost and timeline Fuselage has produced. Forward-deployed engineering teams from Relling or from integrators acquired by Relling continue to embed inside those operations, but the work being done has been replaced by configuration against productized infrastructure rather than engineering from scratch. The argument for this path is that scaling the deployment layer through existing operators reaches the thousands of factories that already constitute the American industrial base, which is the goal the company exists to serve in the first place. The risk is that selling into industrial facilities is, in our experience and in the experience of essentially everyone who has tried it, a deeply difficult sales process. Industrial buyers are conservative for legitimate reasons, their procurement cycles are long, their risk tolerance for new technology is low, and the people who sign capex approvals are often several layers removed from the people who will operate the equipment. None of these are problems that better engineering solves on its own. They are problems that have to be worked through one operator at a time, with the kind of trust and patience that no amount of capital can shortcut. From an allied-industrial-base perspective, the second path is also the answer to supply chain resilience under contestation: distributed deployment capacity sitting inside thousands of existing factories is structurally harder to disrupt than concentrated capacity inside a small number of large ones.
The honest position is that we do not yet know which path is the better one, and the period after Fuselage is operational is when that question gets answered against actual evidence rather than against speculation. We expect the answer will come from the texture of the work itself: the rate at which the playbook compounds across deployments, the durability of the deployment layer when it operates outside our direct control, the actual difficulty of selling into industrial operators at scale, and the unit economics that emerge once the integration work is genuinely productized. The bet is not on a particular scaling configuration. The bet is that the deployment layer is the thing that captures value, that whoever builds and owns it captures the position the rest of the industry runs on top of, and that the configuration through which it scales is downstream of evidence we are still in the process of generating.
The position the company is structurally building toward is the same in either case. The deployment layer is the asset. Fuselage is where that asset gets proven. The factories that exist in 2035 are not the factories that exist now, but the work of bringing those factories into existence is not the work of replacing the operators who run American manufacturing today. It is the work of giving them a deployment layer that classical industrial automation never produced, and letting them put it to work against the operations they understand better than we ever will.
In short, we will continue asking ourselves two questions:
- The goal of Fuselage is to answer the first question: Is the cost of deployment declining?
- Post-Fuselage, we are answering the second question: Is the improvement of yield rate higher; does the deployment layer compound?
Fuselage will allow us to cross the chasm: the specific challenge infrastructure companies face in moving from early adopter customers (who will tolerate rough edges) to early majority customers (who need a complete, polished product).
Fig. XVIIThe deployment layer is the asset in either case. Which path scales it is a question Fuselage exists to answer against evidence, not speculation.
15Values
We started this company with the idea that robots should be abundant. Along the way, we've come to a small set of beliefs every person on the team holds.
- Safe deployments, above all. A robot that is unsafe is a liability. Every cell we ship clears the safety bar before it clears any other bar.
- Genchi genbutsu (go and see). You cannot solve a factory problem from an office, a lab, or a Zoom call. You solve it on the floor.
- Seek truth. We would rather hear the answer we don't want than the answer we do. Disagreement is a gift; flattery is a tax.
- Make stuff happen. Vision without execution is decoration. We move whatever needs moving (calendars, budgets, egos, ourselves) until the thing exists in the world.
- Festina lente (make haste, slowly). Move with urgency, but never at the cost of doing it right.