Relling

AI right now is a digital phenomenon. Models are writing code, handling customer support, doing legal research, and running real parts of real companies, but almost none of this has made it into the physical world in any meaningful way. A factory floor in 2026 runs more or less the same way it did 30 years ago, and the gap between what software can do and what a robot can do keeps getting wider rather than closing.

IClassical robots, current production

Current day product environments are filled with thousands of "classical robots." Classical robots are narrowly preprogrammed for specific tasks: they execute the same task thousands of times a day with a high amount of repeatability and precision. When the task changes (like putting glue on a 10-inch plate vs. a 5-inch plate), these classical robots are manually reprogrammed. The process of bringing up these robots into new environments without flexibility of the task they can complete often leads to a lot of deliberation and ROI calculations around the automation of tasks; even tasks that look automatable may not economically make sense to automate given the volume of task and the bring-up time and maintenance of the robot.

Robots that learn from demonstrations sit inside the research world. They are impressive, but they have not yet crossed into manufacturing. The unit economics of running them on a real floor do not close, and the operational challenge of coexisting with humans on a production line is the same one autonomous vehicles spent a decade learning.

IIThree categories of deployment company

Robotics deployment companies today have primarily been:

1. Capability sellers who sell models or skill-specific robots to someone else who runs the operation. The customer takes the integration risk. Ex: Physical Intelligence, Skild, Dyna, Covariant.
2. Deployers who drop robots and service into existing customer facilities. They own the deployment and the customer keeps the shop. They convince the customer that their deployment will save them money. Ex: Formic, Path Robotics, Chef Robotics, Symbotic.
3. Vertical operators who own the shop and compete with legacy incumbents on end-product margin. Ex: Hadrian and Senra in software-and-automation; Foundry Robotics, Divergent, and Machina Labs in robotics.

The axis that separates these three categories is proximity to the end customer: how much of the stack between the model and the finished good a company chooses to own. Every step closer absorbs more risk and captures more margin.

Fig. IThe risk–margin trade-off

Position on the value chain · Three categories of robotics companyDirection, not magnitude

Fig. IThree positions on the risk–margin trade-off in robotics. Each is useful in its own right, and several companies in each category already build pieces of the deployment layer as a byproduct of their core business, but none of them treats the deployment layer itself as the primary product, and that is the gap this paper is about.

IIIWhat is this deployment layer?

The deployment layer is the set of tools, infrastructure, and operating practices required to take a learned-policy robot from a paper claim of capability to a paid hour of work on a customer floor, and to keep it producing once it is there. It is what sits between a model-card metric and a part in a bin. Critically, it is only useful for tasks that have meaningful variance between them; repetitive automation that wires the same stator a million times does not need it, and the rest of this paper is about the task envelope that does.

Specifically, the layer has to solve six problems:

• Edge-compute distillation. The best models are too big to run on the compute inside the robot, so what actually ships to the floor are the smaller, worse models that were never the point of the research. Compressing a foundation policy into something that runs in real time on a cell controller, without losing the behaviors that matter, remains unsolved for most task families.
• A plant-technician interface for learned policies. Learned-policy failures have no readable cause; there is no line of code to inspect, only weights, and a technician cannot interrogate weights the way they interrogate a program. Failure attribution, recommended-action surfaces, and the runbook that lets a non-ML technician resolve incidents do not yet exist as products that ship with the cell.
• Productized safety bring-up. The certification work that has to clear a robot for production around humans (ISO 10218 dossier, validated runtime monitor, incident-response procedure) takes four to eight weeks of specialist time on every new deployment, because no one has productized it as a reusable artifact that travels with the cell.
• A skill library. A versioned, reusable set of primitive motions (pick, place, insert, screw, weld, pour, route) that can be composed for a new task without retraining the underlying model from scratch. Every team builds its own version today, and none of them ships as shared infrastructure that another team can pick up.
• A data pipeline back from the floor. When a deployed policy fails, the demonstration or correction that would fix it has to make its way back to the training stack so that the next deployment is easier than the last one. Today the loop is broken at the seam between operator and model provider, with no productized path that closes it.
• Unit economics that actually close. The ROI on deploying and maintaining robots into someone else's factory does not work today against an honest labor baseline, even though a lot of people will tell you it does. Cost-per-cell, payback period, and specialist-intervention rate are the three numbers that have to move before the business becomes durable.

The $30B integrator market is a symptom of this layer being artisanal: customers pay for engineer-hours instead of buying a productized stack, because the productized stack does not yet exist.

IVWhy no one has built it

Robotics research itself is advancing quickly. VLAs are getting better at generalization, sim-to-real is working in ways that would have been hard to imagine three years ago, and there's real evidence that scaling laws hold for robotic actions the same way they do for text. Hardware platforms are mature in the categories that matter for industrial work; tactile sensing remains the obvious open frontier, but most of what blocks throughput sits above the silicon. The thing that gates the next decade of robotic deployment is not science.

The thing that gates throughput is the deployment layer described above, and the three existing categories of company each have a different reason for not making it their primary product. The keyword in what follows is primary, because many of these companies build real pieces of the layer in the course of their day jobs, but none of them treats the layer itself as the product they sell.

Capability sellers are commercially incentivized to produce the best model and license it, not to solve deployment for any specific customer. They build evaluation harnesses, fine-tuning APIs, and demonstration pipelines (real pieces of the layer) because their customers need those tools to consume the models, but building the full layer would dilute their focus and require them to become a services company, which breaks their licensing model. They are structurally forced to assume the rest of the layer will be solved by someone else.

Deployers install robots into customer facilities and capture a slice of the labor savings, and they are extremely good at the narrow task envelopes they have already productized. Getting there has required them to build real safety frameworks, real edge-compute distillation, and real data pipelines for those specific tasks. The unit economics of their business are built around amortizing those tools across a fixed set of tasks they sell repeatedly, so extending to a new task family means redoing most of that work from scratch, and their margins do not support funding that work without a buyer in hand. The deployment layer they build is sized to their task envelope, not to the open problem.

Vertical operators compete on end-product margin and run repetitive tasks within their own four walls (Hadrian winds stators, Senra builds harnesses, Foundry casts parts, Divergent prints structures). Once a cell is tuned for that one task, marginal task variance is low and the deployment layer they need is correspondingly thin. Productizing it would require building a separate business that competes with their own operations for attention and capital, and it would solve a problem (cross-task generalization across deployments they do not own) that they simply do not have. Their operating knowledge stays inside their walls because there is no commercial reason to ship it.

None of them is building the deployment layer itself, meaning the layer as a primary product, sold to other operators, with the central operational loop being to deploy across many tasks and many sites and to learn from every one of them. That is the gap, and it is the work this company exists to do.

Broadly, the problems that actually block deployment are operational rather than scientific, and the corollary is that if you identify and lift this layer, throughput improves system-wide.

VProcess knowledge

None of these problems are intellectually hard in the way that training a frontier model is hard, and each of them, individually, is the kind of problem a competent engineering team could solve in a few months if they were sitting inside an active production operation with real technicians, real failure modes, and real integration constraints. The reason they remain unsolved is not that the industry lacks talent or capital, but that solving them requires a form of knowledge that only accumulates inside engineers who have spent years inside real production watching what actually breaks and building the tools that make it not break, which the existing structures of the robotics industry are not set up to produce from where they sit.

What unites these problems is that they are all, at root, process-knowledge problems, and the distinction between product knowledge, by which we mean the blueprints and specifications that describe what a thing is, and process knowledge, by which we mean the tacit, diffuse, locally-held competence that describes how it actually gets built, is what makes that statement meaningful. Process knowledge is not a commodity that can be bought and sold, and you cannot acquire it by licensing it, by buying a company that has it, or by hiring one person who has it, because it is the product of sustained market interactions and only accumulates through sustained operational presence on a real floor over time.

Fig. IITwo shapes of knowledge

Two shapes of knowledgeProduct knowledge vs process knowledge

Fig. IIProduct knowledge moves through markets. Process knowledge does not. It is built only by standing on the floor, and that is the only door open to building a deployment layer.

The connection to the six problems in §III is concrete rather than abstract:

• Distillation is gated by knowing which behaviors of the big model actually matter on a real cell, and that answer is not in the model card; it is in the failure log of a policy that has run 10,000 hours of production and been corrected by a technician 600 of those times. You learn what to keep in the small model by watching what breaks when it is not there, and that data only exists if you operate the floor.
• Fine-tuning on a specific task requires a labeled corpus of corrections and edge cases for that task in that environment. The corpus does not exist as a public dataset and cannot be assembled from a lab, because it is generated demonstration by demonstration by the operators standing next to the cell on a real production line, which is process knowledge converted into bytes.
• Learned-policy failure attribution is the work of turning "the robot did the wrong thing" into "the robot did the wrong thing because state X triggered policy mode Y, and here is the recommended action". The taxonomy of failure modes is not in any paper, but rather accumulates in technicians' heads over months on the line, and productizing it means standing next to those technicians and writing the taxonomy down as it forms.
• Safety bring-up, the skill library, the technician interface, and the unit-economics work are each downstream of the same fact, which is that the artifact you need to ship is shaped by problems you do not see until you have stood on the floor for long enough to see them. Every team that has tried to build these from the outside has had to relearn this lesson by buying a floor or partnering with one.

This is why ownership of an active production operation is not a nice-to-have for building the deployment layer, but rather the only path that has ever produced one, and the next section is what that operation looks like in our case.

VIFuselage

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. IIIFuselage, the floor we own

Top-down · battery-assembly plant · 8 production cells5 live · 3 deployment R&D

Live production cell, classical robot Deployment R&D cell, learned-policy retrofit Building wall Operator station

Fig. IIIFuselage 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:

1. ROI closes within 12 months.
2. The cell is brought online in days, not months.
3. The cell stays running without specialist intervention.
4. Safety is solved as productized infrastructure.

Fig. IVCapability gap: what doesn't exist today

Six capabilities the integrator stack does not produceEach is a teabag-string problem

Failure attribution
by plant technicians

TodayOpaque without ML expertise

FuselageNatural-language attribution + recommended action

Behavioral adjustment
without retraining

TodayDays–weeks of retraining cycles

FuselageSteering vectors applied at runtime in minutes

Cross-cell primitive
transfer

TodayEach cell is bespoke

FuselagePrimitives accumulated at one cell deploy across the fleet

Heterogeneous fleet
coordination

TodayRequires identical embodiment + shared programming

FuselageDifferent vendors, different policies, single layer

Edge-deployable
frontier-quality models

TodayProduction lags frontier by 1–2 generations

FuselageDistilled models retain frontier behavior on edge compute

Deployment data
flywheel

TodayDoesn't exist at scale; most lack volume or infrastructure

FuselageEvery operational hour produces data that improves the next deployment

Fig. IVEach capability looks small. The cumulative absence is the reason robotic deployment is artisanal.

The Primitive Library

The mechanism that lets these four problems be solved as a coherent product rather than as four separate engineering campaigns is what we call the primitive library, which is the layer of named, composable sub-skills such as grasp, insert, wipe, probe, stack, align, and inspect that every cell uses to execute its work. The policy that runs the cell does not learn a monolithic task end-to-end and then fail opaquely when something drifts in the operating environment, but instead composes these primitives into a task graph, and the primitives themselves are the named building blocks that a plant technician can interrogate, swap, retune, and reuse without having to retrain the model that selects among them.

Primitives matter operationally because they decompose what would otherwise be opaque failures into localized ones, which is the precondition for the legibility argument that lets a maintenance technician interrogate a learned-policy cell at all. They matter strategically because they compound across deployments, with every primitive built inside Fuselage available to every subsequent cell that leaves it, regardless of the operator who runs that cell, the embodiment of the robot that executes it, or the specific task it has been retasked to perform. The library is the substrate on top of which the four problems are solved, and the marginal cost of each new deployment falls as the library grows.

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. VThe deployment cost stack collapses from $500K–$2M to <$200K

All-in cost per cellIntegrator hours absorbed by productized assets

Integrator hours (today) Hardware Safety bring-up Productized layer (Fuselage)

Fig. VThe 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. VIDependency chain: serial today, parallel under Fuselage

Bring-up timeline · weeks6–12 months → < 30 days

On-site engineering today Safety bring-up Acceptance + first unit Fuselage on-site work

Fig. VIThe 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 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. VIIWhere the 168-hour week goes

One week of a deployed cell, 168 hoursToday vs. Fuselage target, with the mechanism that recovers each block

Running Down (no fix path) Slow / rework Changeover

Fig. VIIThe 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. VIIIOEE band & MTTR distribution

Two distributions, one shiftIndustry today vs. Fuselage target

Industry today Fuselage target Threshold

Fig. VIIIThe 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.

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. IXSafety dossier: once, vs. every cell

ISO 10218 / ISO TS 15066 certificationSpecialist hours per cell, by approach

Today · 4–8 weeks of bespoke characterization, repeated per cell Fuselage · review dossier & sign off (≈ 5 days) 5-day target

Fig. IXToday'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.

VIIWhy Fuselage

We think vertical integration is the wrong way.

The Air Force has begun describing the central manufacturing problem of the coming decade as the problem of affordable mass, by which it means the ability to produce useful capability at industrial scale under battlefield-relevant timelines, and the deployment layer is the technical precondition that determines whether affordable mass is achievable at all. The four problems Fuselage exists to solve are the four constraints that keep manufacturing scale and battlefield timeline from being achievable together in the current industrial base.

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 American industrial base is not bottlenecked at the prime contractors that get most of the attention, but at the Tier 2-N suppliers underneath them, the sub-tier shops that produce a single component for a single program, often inside a single facility staffed by a single skilled operator who learned the process from someone now retired. Productized deployment is the technology that lets those shops modernize without rebuilding the operations they have spent decades getting right, and it is the layer that compounds across the deep tiers of the supply chain rather than only at the visible top. The procurement infrastructure to fund this layer is already in place in the form of the roughly thirty DoD Other Transaction Authority consortia and the no-year appropriations of Defense Production Act Title III, both of which are structured precisely to underwrite surge industrial capacity, and what is missing is not the financial vehicle but the productized integration layer that the vehicle would otherwise be funding.

Fig. XVertical → modular: the unbundling

Industry structure as interfaces stabilizePCs (1980 → 1995) · Robotics (today → 2030+)

Deployment layer · Relling Models Firmware Hardware / apps

Fig. XInitially 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.

The 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 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. Just-in-time inventory and globally distributed sourcing were the right answers for a supply chain that could be ordered from anywhere on a week's notice, and that world is no longer the world the next generation of factories has to operate in. The factories that have to be built now have to absorb surge demand and SKU shifts on their own, without the option of pulling slack from a global supplier base whose reliability is no longer a peacetime constant. 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. Strategic reserves of finished systems are expensive to maintain and perishable in relevance, and the systems that get stockpiled are often the wrong systems by the time they are needed. Strategic reserves of deployment capacity, by which we mean cells that can be retasked to whatever the operating environment demands, are both cheaper to hold and more relevant when the demand finally arrives. The closest existing analog is the Civil Reserve Air Fleet, which keeps commercial airliners on retainer for Department of Defense activation in wartime and works precisely because the underlying asset retains commercial productivity in peacetime, and the deployment layer is what makes the same arrangement viable for general-purpose manufacturing cells rather than only for airlift capacity.

Fig. XIFour manufacturing dimensions: what classical automation gave up

Skinner / Hayes & Wheelwright · cost · quality · dependability · flexibilityClassical automation vs. learned-policy cell

Classical automation · sacrifices flexibility Learned-policy cell · all four

Fig. XIClassical automation chose cost and dependability fifty years ago and treated flexibility as a luxury. Markets changed. The new diamond fills the axis the old one gave up.

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.

Fuselage 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, and the geographic dispersal that such operations produce becomes a resilience property the existing industrial base structurally does not have. 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.

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, and the same playbook applies to allied manufacturing operations in which supply chain resilience under contestation is the binding strategic concern alongside cost. 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.

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:

1. The goal of Fuselage is to answer the first question: Is the cost of deployment declining?
2. 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. XIITwo paths: replication or playbook

Post-Fuselage scalingThe bet is not on a configuration; the bet is on the layer

Fig. XIIThe deployment layer is the asset in either case. Which path scales it is a question Fuselage exists to answer against evidence, not speculation.

---

VIIIValues

We started this company with the idea that robots should be abundant. Along the way, we've come to a small set of beliefs that every person on this team holds. They are not the only things we believe, but they are the things we will not compromise on.

1. 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. This is non-negotiable, and it is the reason we exist.
2. Genchi genbutsu (go and see). You cannot solve a factory problem from an office, a lab, or a Zoom call. You solve it by standing on the floor, watching the work, and understanding why the thing that should work doesn't. Every hard problem in robotics is a process knowledge problem, and process knowledge lives on the floor.
3. 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. We measure ideas against reality, not against each other, and we change our minds when reality tells us to.
4. Make stuff happen. Vision without execution is decoration. When we commit to something, we move whatever needs moving (calendars, budgets, egos, ourselves) until the thing exists in the world. We are biased toward action and allergic to ceremony.
5. Festina lente (make haste, slowly). Move with urgency, but never at the cost of doing it right.

TL;DR

For operators evaluating robotic deployment, investors evaluating the category, and engineers thinking about where their work has leverage.

1. The deployment layer is the set of pieces (distillation to edge compute, a plant-technician interface for learned policies, productized safety bring-up, a reusable skill library, a data pipeline back from the floor, and unit economics that close against an honest labor baseline) that together take a robot from a paper claim of capability to a paid hour of work on a customer floor.
2. It is unbuilt, not because companies cannot build it (many of them build pieces of it as a byproduct of their core business), but because none of them makes the layer itself their primary product. Capability sellers build evaluation tooling and fine-tuning APIs, deployers build a stack sized to a narrow task envelope they have already productized, and vertical operators do not need a layer that generalizes outside their own walls.
3. Building it requires standing on a real production floor for long enough to see what actually breaks. The artifacts that make up the layer (failure taxonomies, runtime monitors, technician runbooks, distilled policies) are products of process knowledge that only accumulates inside an operating cell, and that kind of knowledge cannot be licensed, acquired, or hired in a single round of recruiting.
4. Fuselage is that floor, a working battery-assembly plant Relling owns and operates. Five cells run production today, three are being retrofitted with learned-policy systems, and the deployment layer is being built inside the plant, with the cells as the laboratory and the customers as the deadline.
5. The bet is that the company that owns the deployment layer captures the value integrators have been extracting through engineer-hours for thirty years, and that the deployment layer eventually modularizes the way data infrastructure modularized in software in the 2010s.