Factory Protocol: Structured Industrial Procedures

• Factory Protocol is a term for structured procedures that produce, transport, validate, or transform high-value outputs with strict resource and reliability targets.
• It spans diverse fields including URLLC in smart factories, 5G networking, in-factory 6G control, automated software benchmarking, robotic assembly simulation, and quantum resource production.
• The protocols integrate optimization, learning-based control, and automated validation to meet stringent performance, latency, and security requirements in various industrial applications.

“Factory Protocol” is not a single standardized protocol. In the arXiv literature, the term is applied to several domain-specific protocol constructions: a relay-aided two-phase uplink URLLC scheme for smart factories, a 5G industrial communication architecture in which NR, core, MEC, slicing, and SDN-controlled gateways collectively carry established factory traffic, a learned signaling-and-power-control protocol for in-factory 6G subnetworks, an automated pipeline for constructing and validating GitHub issue-resolution benchmarks, a contact-simulation-and-learning stack for robotic assembly, and quantum “factory” protocols for CCZ magic-state distillation and Bernoulli-factory randomness processing (Cheng et al., 2021, Ludwig et al., 2018, Uyoata et al., 9 May 2025, Guo et al., 12 Jun 2025, Narang et al., 2022, Kook et al., 23 Jun 2026, Patel et al., 2018).

1. Scope and principal usages

Across these works, “Factory Protocol” denotes an organized procedure for producing, transporting, validating, or transforming high-value outputs under stringent constraints. The outputs differ by field—uplink packets, network-control decisions, benchmark instances, contact-rich trajectories, distilled magic states, or transformed random variables—but each protocol couples a structured workflow with explicit resource or reliability objectives.

Domain	Protocol object	Primary objective
Smart-factory wireless	Relay-aided two-phase uplink URLLC	Minimize total transmit power under reliability and latency constraints
5G factory networking	5G NR, core, MEC, slicing, and SDN-controlled gateways	Provide transport, control, and isolation for industrial traffic
In-factory 6G subnetworks	Learned signaling and power control	Reduce signaling overhead while maintaining close-to-Genie performance
Software engineering	SWE-Builder, exit-code grading, fail2pass validation	Construct and vet issue-resolution task instances at scale
Robotic assembly	SDF-based collision, contact reduction, GS solving, RL tooling	Real-time or faster contact-rich assembly simulation and learning
Quantum information	CCZ magic-state factory; quantum Bernoulli factory	Distill non-Clifford resource states; transform Bernoulli sources

This suggests that the unifying feature is procedural structure rather than shared implementation. In industrial networking papers, the term refers to transport and control mechanisms deployed inside or around a plant; in software engineering, it refers to a benchmark-construction pipeline; in robotics, to a simulation-and-learning stack; and in quantum information, to resource-state production or randomness transformation (Ludwig et al., 2018, Guo et al., 12 Jun 2025, Narang et al., 2022, Kook et al., 23 Jun 2026, Patel et al., 2018).

2. Industrial communication architecture in factories

In “A 5G Architecture for The Factory of the Future” (Ludwig et al., 2018), the “factory protocol” is explicitly not a single fieldbus specification. It is the way 5G New Radio, the 5G core and edge-cloud functions, slicing, and SDN-controlled gateways collectively provide transport, control, and isolation so that established factory protocols and control patterns can run deterministically and securely. The paper grounds this architecture in concrete industrial use cases: motion/control loops and inter-PLC control, process automation and closed-loop control, mobile robots/AGVs and SLAM, condition monitoring and distributed sensing, AR/VR and mobile control panels, smart production and tracking across the supply chain, and infrastructure retrofit and wide-area industrial sensing (Ludwig et al., 2018).

The quantitative service targets are those of the paper’s 5G capability references: eMBB with up to 20 Gbit/s peak data rate and user-plane latency below 4 ms, URLLC with user-plane latency less than 1 ms, mMTC with up to $10^6$ devices per km$^2$, and battery life up to 10 years. For certain PLC-driven motion/control steps, the paper cites round-trip timing “in the range of several milli- to microseconds.” The proposed architecture uses gNBs with L2/L3 routing, firewalls, an SDN controller, and resource management for non-5G links; virtualized core functions including access/mobility management, policy and charging, authentication, subscription management, and user-plane breakout; and MEC/edge cloud for cloud-PLC logic, device clouds, and analytics (Ludwig et al., 2018).

A central architectural feature is the gateway layer. Edge PLCs and IIoT edge gateways bridge existing industrial Ethernet and fieldbus protocols—PROFIBUS, PROFINET, Sercos III, CAN, and Modbus—plus analog/digital I/O and non-3GPP radios such as Bluetooth LE and Wi‑Fi into 5G. Network slicing provides QoS separation among URLLC control loops, eMBB video and AR/VR, and mMTC telemetry. The paper also gives an implied end-to-end decomposition

$$L_{\text{total}} = L_{\text{radio}} + L_{\text{RAN}} + L_{\text{core}} + L_{\text{MEC}} + L_{\text{backhaul}},$$

and an implied segment-wise reliability composition

$R_{\text{total}} = \prod_{i=1}^{n} R_i.$

By colocating MEC with the plant and using local breakout in the private core, the design minimizes $L_{\text{core}}$ and $L_{\text{backhaul}}$ for URLLC paths (Ludwig et al., 2018).

The paper positions this architecture against RAMI 4.0, IIRA, and the 5GPPP reference architecture. A plausible implication is that “factory protocol” in this usage denotes an integration layer: traditional industrial protocols are not replaced, but encapsulated, scheduled, and isolated over programmable 5G transport (Ludwig et al., 2018).

3. Smart-factory radio protocols: optimization-based URLLC and learned 6G control

In “Relay Selection and Resource Allocation for Ultra-Reliable Uplink Transmission in Smart Factory Scenarios” (Cheng et al., 2021), the factory protocol is a relay-aided two-phase uplink URLLC scheme for a smart factory with one controller, $K$ robots, and $N$ fixed half-duplex decode-and-forward relays. Each robot must upload $B_k$ bits under a maximum packet error probability $\varepsilon_{\max}$ and a latency budget enforced by two short phases, $^2$0 and $^2$1. Exactly one orthogonal resource block is assigned per robot, with exclusivity constraints

$^2$2

Phase I carries either direct robot-to-controller transmission or robot-to-relay transmission; Phase II forwards relay traffic on the same RB, while remaining idle for direct mode (Cheng et al., 2021).

Reliability is modeled with the finite-blocklength normal approximation. In cooperative DF mode, the overall PEP is approximated as

$^2$3

using the ultra-small-error approximation $^2$4. The design objective is total transmit power minimization under coupled binary, RB, power, latency, and reliability constraints. The paper reformulates the problem using a big-$^2$5 decoupling of reliability, a relative-entropy transformation for terms of the form $^2$6, and two penalty-based SCA procedures—non-convex penalty and quadratic penalty—to enforce near-binary indicators without combinatorial search. Numerical results show nearly identical total power for NCP and QP, with QP converging faster in simulations; power consumption increases with the number of robots, decreases with more relays, falls as $^2$7 is relaxed, and is minimized by moderate relay placement, with a reported optimum around $^2$8 of the factory radius (Cheng et al., 2021).

In “Learning Power Control Protocol for In-Factory 6G Subnetworks” (Uyoata et al., 9 May 2025), the factory protocol shifts from model-based optimization to learned decentralized control. The setting is a dense In-Factory subnetwork environment in which access points autonomously learn both signaling and power-control behavior under partial observability. APs choose an environment action $^2$9, indicating transmit or idle, and a communication action $$L_{\text{total}} = L_{\text{radio}} + L_{\text{RAN}} + L_{\text{core}} + L_{\text{MEC}} + L_{\text{backhaul}},$$0, indicating Power Allocation Request or CSI report; a non-learning central controller responds with downlink power coefficients based on a GNN allocator when requested. The physical layer is summarized by

$$L_{\text{total}} = L_{\text{radio}} + L_{\text{RAN}} + L_{\text{core}} + L_{\text{MEC}} + L_{\text{backhaul}},$$1

with rate $$L_{\text{total}} = L_{\text{radio}} + L_{\text{RAN}} + L_{\text{core}} + L_{\text{MEC}} + L_{\text{backhaul}},$$2 and queue evolution

$$L_{\text{total}} = L_{\text{radio}} + L_{\text{RAN}} + L_{\text{core}} + L_{\text{MEC}} + L_{\text{backhaul}},$$3

The paper formulates the problem as a POMDP and trains with MAPPO under CTDE (Uyoata et al., 9 May 2025).

The reported result is that the learning-based method reduces signaling overhead by a factor of 8 while maintaining a buffer flush rate that lags the ideal “Genie” approach by only 5%. The simulation uses $$L_{\text{total}} = L_{\text{radio}} + L_{\text{RAN}} + L_{\text{core}} + L_{\text{MEC}} + L_{\text{backhaul}},$$4 subnetworks on a $$L_{\text{total}} = L_{\text{radio}} + L_{\text{RAN}} + L_{\text{core}} + L_{\text{MEC}} + L_{\text{backhaul}},$$5 floor, 6 GHz carrier, 10 MHz bandwidth, payload 64 bytes, latency budget 1 ms, and AP/device mobility up to 3 m/s. The emergent protocol avoids periodic CSI flooding, sends CSI sparingly, requests power updates only when needed, and keeps transmitting with the last known power allocation when local evidence indicates that current settings remain adequate. This suggests a contrast with the URLLC uplink protocol of (Cheng et al., 2021): the former assumes perfect CSI and solves a penalized convex approximation centrally, whereas the latter treats signaling itself as a learned control decision under CSI scarcity and overhead constraints (Uyoata et al., 9 May 2025).

4. SWE-Factory as an automated benchmark-construction protocol

In “SWE-Factory: Your Automated Factory for Issue Resolution Training Data and Evaluation Benchmarks” (Guo et al., 12 Jun 2025), the factory protocol is an end-to-end automated pipeline for constructing GitHub issue-resolution datasets. The input is raw GitHub issues collected via the SWE-bench pipeline; the output is a set of validated task instances packaged as a Dockerfile and evaluation script, with accurate grade signals and automated fail2pass verification. The pipeline integrates three components: SWE-Builder, a standardized exit-code-based grading method, and automated fail2pass validation (Guo et al., 12 Jun 2025).

SWE-Builder is a four-agent system. The Repository Explorer extracts environment and testing information from repository artifacts via APIs such as browse_file, browse_directory, and search_file_by_keyword. The Environment Manager generates a Dockerfile, preserving generation history and falling back to the previous Dockerfile on failure. The Test Manager generates an evaluation script eval.sh and appends the standardized grading snippet $\varepsilon_{\max}$2 The Test Analyst builds the container, applies the gold patch, runs the script, and either accepts the environment or issues targeted guidance to the other agents. The protocol also includes an environment memory pool keyed by repository id and version, storing validated Dockerfiles, evaluation scripts, and metadata for reuse on nearby versions (Guo et al., 12 Jun 2025).

The grading and validation formalization is intentionally minimal. Given environment $$L_{\text{total}} = L_{\text{radio}} + L_{\text{RAN}} + L_{\text{core}} + L_{\text{MEC}} + L_{\text{backhaul}},$$6 and state $$L_{\text{total}} = L_{\text{radio}} + L_{\text{RAN}} + L_{\text{core}} + L_{\text{MEC}} + L_{\text{backhaul}},$$7, the grading function is pass if exit_code(E,\sigma)=0 and fail otherwise; validation is true only when the pre-patch run fails and the post-patch run passes. On 2,085 judged runs, exit-code grading achieved 100% accuracy compared to manual inspection. Automated fail2pass validation on 1,030 instances after filtering reported $$L_{\text{total}} = L_{\text{radio}} + L_{\text{RAN}} + L_{\text{core}} + L_{\text{MEC}} + L_{\text{backhaul}},$$8 and $$L_{\text{total}} = L_{\text{radio}} + L_{\text{RAN}} + L_{\text{core}} + L_{\text{MEC}} + L_{\text{backhaul}},$$9, with totals $R_{\text{total}} = \prod_{i=1}^{n} R_i.$0, $R_{\text{total}} = \prod_{i=1}^{n} R_i.$1, $R_{\text{total}} = \prod_{i=1}^{n} R_i.$2, and $R_{\text{total}} = \prod_{i=1}^{n} R_i.$3. The paper identifies all false positives as “error2pass,” where pre-patch tests are unrunnable and post-patch tests run and pass; it recommends filtering such instances from benchmark construction (Guo et al., 12 Jun 2025).

The evaluation subset, SweSetupBench-lite, contains 671 issues across 12 repositories and four languages: Python, Java, JavaScript, and TypeScript. For valid instances confirmed by manual fail2pass inspection, the reported figures are 269/671 for GPT-4.1-mini with Valid Rate 40.1%, Success Rate 57.2%, Cost $R_{\text{total}} = \prod_{i=1}^{n} R_i.$40.024, 3.57, and 27.0 min; and 232/671 for DeepSeek-v3-0324 with 34.6%, 50.8%, $0.043, 3.45, and 22.5 min. The protocol is therefore notable not for a novel grading metric, but for the removal of bespoke log parsers and manual F2P inspection in favor of containerized execution, exit-code standardization, and iterative environment construction (Guo et al., 12 Jun 2025).

5. Factory in robotic assembly: contact simulation, control, and learning

In “Factory: Fast Contact for Robotic Assembly” (Narang et al., 2022), the protocol is a set of physics simulation methods and robot learning tools built into NVIDIA PhysX and Isaac Gym for contact-rich assembly, including threaded fasteners. The core technical components are SDF-based collision generation with local optimization, aggressive contact reduction into patches, and a Gauss–Seidel solver with small-step integration. The system demonstrates real-time or faster simulation for a wide range of scenes, including simultaneous simulation of 1000 nut-and-bolt interactions and a reported real-time execution of 1024–1000 parallel nut-and-bolt interactions on a single GPU; the paper contrasts this with a prior state of the art of at most $R_{\text{total}} = \prod_{i=1}^{n} R_i.$5 real time for a single pair (Narang et al., 2022).

The contact model uses precomputed voxel SDFs, typically at resolution $R_{\text{total}} = \prod_{i=1}^{n} R_i.$6 or higher, stored as 3D textures on the GPU. For each triangle face on one body, the engine finds the closest point on the SDF of the opposing body by projected gradient descent with adaptive stepping, producing one candidate contact per face. For an M4 threaded pair with detailed meshes of roughly 17.8k triangles, this yields about 16k raw contacts in less than 1 ms. Those contacts are then reduced in GPU shared memory by clustering proximal contacts with similar normals, penetration depth, and area. For nut-and-bolt scenes, reduction takes raw $R_{\text{total}} = \prod_{i=1}^{n} R_i.$7k contacts to about 200–300, with typical patch counts around 40–50 per pair (Narang et al., 2022).

Constraint solving follows standard complementarity and Coulomb-friction structure,

$R_{\text{total}} = \prod_{i=1}^{n} R_i.$8

with relative contact velocity $R_{\text{total}} = \prod_{i=1}^{n} R_i.$9. After reduction, GS converges rapidly and outperforms Jacobi on total wall time. Representative stable settings are: nut-and-bolt with substeps=1, Pos Iter=20, Vel Iter=1; peg-in-hole with substeps=1, Pos Iter=4; D-sub and gears with substeps=4, Pos Iter=4. The paper reports about 14 ms/frame for 1024 nut-and-bolt environments, about 12 ms/frame for a single-environment pile of 1024 M16 nuts, about 14 ms/frame for 1024 D-sub environments, and about 42 ms/frame for 1024 gear-assembly environments (Narang et al., 2022).

The learning stack comprises 60 simulation-ready assets from NIST Assembly Task Board 1, 3 assembly environments, and 7 classical controllers. The nut-and-bolt RL protocol uses PPO with a shared-trunk MLP of sizes $L_{\text{core}}$0, horizon $L_{\text{core}}$1, learning rate $L_{\text{core}}$2, $L_{\text{core}}$3, GAE $L_{\text{core}}$4, minibatch size 512, epochs 8, and clip $L_{\text{core}}$5. Three subpolicies—Pick, Place, and Screw—operate on controller targets rather than raw torques. The best Screw policy used 2-DOF end-effector $L_{\text{core}}$6-translation and yaw on an OSC controller with low proportional gains, reaching 85.6% success over 1024 episodes after 4096 updates. Pick achieved 100% success within randomized bounds, Place 98.4%, and simple sequential chaining of Pick→Place→Screw produced 74.2% end-to-end success. Contact-force validation against the DIM dataset yielded histogram alignment with $L_{\text{core}}$7 for the relevant tightening task (Narang et al., 2022).

The protocol’s limitations are also explicit: dense SDFs have a large GPU memory footprint, thin-shell meshes and low-tessellation flats remain difficult for one-contact-per-triangle generation, the simulator handles rigid-body contact only, and pretension, lubrication, wear, and full sim-to-real validation for nut tightening remain future work. Even so, the work establishes a “factory” in the sense of a scalable production pipeline for accurate contact interactions and learned assembly behavior (Narang et al., 2022).

6. Quantum-information usages: magic-state factories and Bernoulli factories

In quantum information, “factory protocol” refers to procedures that produce non-Clifford resources or transform unknown random sources into target distributions. The two papers here operate in different subfields but share the same factory logic: a costly primitive is converted into a higher-value output with explicit fault detection, resource accounting, and acceptance conditions (Kook et al., 23 Jun 2026, Patel et al., 2018).

CCZ magic-state factory

“Low Spatial Cost CCZ Magic State Factory” (Kook et al., 23 Jun 2026) reconstructs the gate-based [[8,3,2]] eight-to-three CCZ distillation protocol as a compact joint-measurement architecture implementable with the surface code. The protocol consumes eight noisy single-qubit T-type magic states $L_{\text{core}}$8, one auxiliary $L_{\text{core}}$9 per gadget, and four logical qubits initialized in $L_{\text{backhaul}}$0, and outputs one distilled three-qubit CCZ magic state

$L_{\text{backhaul}}$1

The original 12-qubit encoding/phase-injection/decoding circuit is converted into eight $L_{\text{backhaul}}$2-basis $L_{\text{backhaul}}$3 Pauli-product joint measurements on four persistent logical qubits. Each rotation is realized by two commuting joint measurements, $L_{\text{backhaul}}$4 and $L_{\text{backhaul}}$5, followed by Pauli-frame updates (Kook et al., 23 Jun 2026).

The fault-detection structure is preserved by the syndrome qubit. Every rotation fault has the form $L_{\text{backhaul}}$6, and acceptance is determined by the final $L_{\text{backhaul}}$7 measurement. Because $L_{\text{backhaul}}$8, any single faulty rotation flips the syndrome and is rejected; only weight-2 faults can evade detection, giving leading-order $L_{\text{backhaul}}$9 suppression. The paper reports first-stage and second-stage error expressions

$K$0

with $K$1 (Kook et al., 23 Jun 2026).

Architecturally, the spatial reduction comes from implementing the costly $K$2 step via a local “four-qubit twisted ZY measurement,” which lets the $K$3 and $K$4 ancillas remain one-tile patches at leading order. The proposed CCZ factory occupies 99 tiles, or 113 effective tiles including required empty spacing, has time 12$K$5 in the pipelined model or 22$K$6 in a conservative model, and has space-time volume 1356$K$7 or 2486$K$8, respectively. The reference Gidney–Fowler factory is quoted at 396$K$9 space, 5.5$N$0 time, and 2178$N$1 space-time volume. This corresponds to a 71.4% area reduction and, in the pipelined model, a 37.7% reduction in space-time volume (Kook et al., 23 Jun 2026).

Quantum Bernoulli factory

In “An Experimental Quantum Bernoulli Factory” (Patel et al., 2018), the protocol transforms an input source of i.i.d. Bernoulli$N$2 randomness—or, in the quantum version, coherently encoded “quoins”—

$N$3

into an output Bernoulli coin with target function

$N$4

The significance is that $N$5 reaches 1 at $N$6, so it is not classically computable on the full open interval $N$7 under the Keane–O’Brien conditions, whereas coherent quantum access lifts that restriction (Patel et al., 2018).

The first implementation is a single-qubit coherence protocol. Measuring $N$8 in the Pauli-$N$9 basis yields a $B_k$0-coin with

$B_k$1

A classical linear factory converts this to an $B_k$2-coin with $B_k$3, and squaring via two independent $B_k$4-coins yields $B_k$5. The second implementation uses a two-copy entangling measurement based on Hong–Ou–Mandel interference. By interfering $B_k$6 and $B_k$7, the coincidence rate is

$B_k$8

so the no-coincidence event directly realizes the target function. With HOM visibility $B_k$9, the realized function becomes $\varepsilon_{\max}$0 (Patel et al., 2018).

Experimentally, the single-qubit protocol achieved the same absolute accuracy with approximately three orders of magnitude fewer input resource uses than the best known classical method, while the entangling protocol reduced resource usage by a further factor of approximately 5 relative to the single-qubit protocol. The paper reports that state-preparation fidelity exceeded 0.99 across the tested $\varepsilon_{\max}$1 grid and that raw HOM visibilities were approximately 0.95–0.98 after background subtraction. In this context, the factory metaphor denotes a randomness-processing protocol with almost-sure halting, exact ideal functionality, and quantifiable quantum resource advantage (Patel et al., 2018).