100,000 Hours Signed, 10,000 Hours/Month Delivered, 95%+ Acceptance: Real-Robot Data Finally Has Dedicated Suppliers — the Missing Link in Embodied AI
100,000 Hours Signed, 10,000 Hours/Month Delivered, 95%+ Acceptance: Real-Robot Data Finally Has Dedicated Suppliers — the Missing Link in Embodied AI
Part One: Turning “data” from a self-built cost center into purchasable capacity
On October 30, 2026, during the 2026 Physical AI and World Models Conference, RealMan Intelligent disclosed progress on its real-robot data business. The numbers are few, but each deserves a pause:
- Entered scaled delivery in June 2026;
- Cumulative signed orders approaching 100,000 hours;
- Monthly delivery capacity at the 10,000-hour level;
- Acceptance pass rate above 95% at delivery volumes of 10,000+ hours;
- Serving more than half of China’s embodied model companies with large-scale data purchasing capacity, covering the first tier, with repeat commercial orders already occurring.
Together, these sentences describe not how many orders one company booked, but something structural: the “data” of embodied AI has, for the first time, a dedicated supply layer.
Before this, there were basically three ways to get real-robot data:
- Each model company builds its own collection team — buys robots, builds sites, hires teleoperators. Heavy assets, slow, and every company’s data spec differs, so nothing is reusable.
- Buy public datasets — cheap, but uneven quality, narrow scenarios, no closed-loop QC, and usually missing proprioceptive signals like force feedback and joint states.
- Supplement with simulated data — cheap and infinitely generatable, but the sim-to-real gap remains a hard problem (which is exactly why Yuanshi’s 96.7% consistency metric on Genie Sim deserves its own article).
Whereas “purchasable, QC-closed-loop, real-work-scenario, multimodal-aligned real-robot data” was essentially nonexistent. What RealMan is doing is industrializing that — turning data collection from “a cost center inside every model company” into “capacity you can order monthly and price by the hour.”
The significance, in one sentence: embodied AI’s bottleneck is shifting from “models aren’t strong enough” to “data isn’t real enough,” and the latter finally has a market-based solution.
Part Two: The GLN remote labor network — why teleoperation beats demonstration
The core of this system is something called GLN (a remote labor network). It lets teleoperators dispatch robots distributed across frontline sites from anywhere, collecting multimodal real-robot data while performing real business tasks.
In practice, the Changzhou Embodied Intelligence Data Experiment Platform built an integrated collection architecture of “centralized remote dispatch + distributed real-robot operation.” Robots run through over 1,000 real work tasks spanning factory lines, warehousing and logistics, commercial services, and home eldercare.
There’s a key distinction the reporting nails: “unlike collection schemes that only do standardized demonstration, this data isn’t deliberately choreographed for recording — it’s the native record generated naturally when robots complete real work.”
Why does that distinction matter so much? A quick calculation shows it:
# Distribution coverage: standardized demo data vs real-work data
def coverage_analysis():
"""
Assume a grasping task has several success-affecting factors,
each with several possible values.
"""
factors = {
"workpiece deviation": ["centered", "left", "right", "tilt 5deg", "tilt 15deg"],
"material placement": ["neat", "cluttered", "stacked", "partially occluded"],
"lighting": ["standard", "strong", "dim", "side-lit", "flickering"],
"environmental interference": ["none", "people passing", "equipment vibration", "cable snag"],
}
# Standardized demonstration: usually only the "ideal combination"
demo_combos = 1 * 1 * 1 * 1
# Real work: factors combine randomly
total_combos = 1
for k, v in factors.items():
total_combos *= len(v)
return {
"factors": len(factors),
"total combinations": total_combos,
"demo coverage": demo_combos,
"demo coverage rate": f"{demo_combos/total_combos:.2%}",
}
for k, v in coverage_analysis().items():
print(f" {k:22s} {v}")
Four factor classes, a combination space in the hundreds, and standardized demonstration covers exactly one of them. That’s why a robot “trained ten thousand times in the lab still drops the bottle at the shelf” — the model learned the distribution of an ideal world, while the real world is long-tailed.
The value of real-work data is precisely that it naturally covers the long tail. When a teleoperator drives a robot remotely to do actual work, the robot inevitably has to handle: workpiece deviation, cluttered materials, lighting fluctuation, environmental interference. Those “hassles” aren’t noise in data collection — they’re the point of it. A robot working an 8-hour shift on a real production line produces a far richer data distribution than 8 hours of careful lab choreography.
And the “centralized dispatch + distributed operation” architecture solves another practical problem: cost.
# Centralized dispatch vs distributed self-build: a cost comparison (illustrative)
def cost_model(robots=100, hours_per_day=8, days=250,
operator_ratio=0.25, operator_monthly=12000):
"""
robots: number of robots
operator_ratio: robots one operator can cover in a distributed setup
"""
# Self-built: one operator watches one robot
self_built_operators = robots
# Network dispatch: one person rotates across multiple robots (not 1:1 all shift)
network_operators = int(robots * operator_ratio)
annual_self = self_built_operators * operator_monthly * 12
annual_net = network_operators * operator_monthly * 12
hours = robots * hours_per_day * days
return {
"annual collection hours": f"{hours:,}",
"self-built labor cost": f"{annual_self/1e4:.0f} x10k CNY",
"network labor cost": f"{annual_net/1e4:.0f} x10k CNY",
"cost/hour (self-built)": f"{annual_self/hours:.0f} CNY",
"cost/hour (network)": f"{annual_net/hours:.0f} CNY",
}
for k, v in cost_model().items():
print(f" {k:24s} {v}")
This model is illustrative, but it reveals GLN’s economic logic: teleoperation is labor-intensive, and “centralized dispatch” means one person isn’t bound to one machine — robots sit across frontline sites in multiple cities while the dispatch side schedules shifts, rotates operators, and assigns by task type. This is essentially using dispatch software to aggregate scattered, fragmented robot operating hours into continuous capacity.
Which is why it can credibly claim “10,000 hours a month” — those hours aren’t piled up by piling up people; they’re organized out of existing robot operating time.
Part Three: Data spec — what multimodal alignment actually aligns
There’s a sentence easily skipped in the reporting: the collection includes “robot joint states, force feedback, visual images, spatiotemporal timestamps, and other complete proprioceptive information.”
That sentence carries more technical weight than “1,000 tasks.” Because multimodal alignment is the most error-prone and least repairable link in embodied data.
# Typical specs and alignment requirements for multimodal real-robot data
def data_spec():
return {
"joint states": {
"typical rate": "100-1000 Hz",
"content": "joint angle/velocity/torque",
"alignment difficulty": "high rate; needs strict interpolation against video frames",
},
"force feedback": {
"typical rate": "500-1000 Hz",
"content": "6-axis end-effector force/torque",
"alignment difficulty": "latency-sensitive; contact force peaks must land on the exact frame",
},
"visual images": {
"typical rate": "30-60 Hz",
"content": "multiple cameras (head/wrist/third-person)",
"alignment difficulty": "cameras must be hardware-synced or parallax pollutes the policy",
},
"spatiotemporal timestamps": {
"typical rate": "per frame",
"content": "collection instant on a unified time base",
"alignment difficulty": "clock drift, dropped frames, cross-device time-base mismatch",
},
}
for modality, spec in data_spec().items():
print(f"\n[{modality}]")
for k, v in spec.items():
print(f" {k:22s} {v}")
Why is alignment so critical? Because embodied models learn a “state → action” mapping. If video frames and joint states are off by 30 milliseconds, the model learns “see the old picture, make the new motion” — an error nearly invisible in training loss (the numbers are still correlated) but a systematic offset on a real robot.
Force feedback is even stricter: contact force peaks often last only tens of milliseconds, and if force and video are misaligned the model never learns “when to let go.” Such errors are nearly impossible to catch in simulation, where everything is perfectly synchronized.
# Timestamp validation: dropped-frame and drift detection
def validate_timestamps(ts_list, expected_hz, tolerance_ms=2.0):
"""
ts_list: timestamps in milliseconds
expected_hz: expected sampling rate
tolerance_ms: allowed interval error
"""
nominal = 1000.0 / expected_hz
dropped, drift, ok = 0, 0, 0
for i in range(1, len(ts_list)):
gap = ts_list[i] - ts_list[i - 1]
if gap > nominal * 1.5:
dropped += 1
elif abs(gap - nominal) > tolerance_ms:
drift += 1
else:
ok += 1
total = len(ts_list) - 1
return {
"total intervals": total,
"normal": f"{ok} ({ok/total:.1%})",
"dropped": f"{dropped} ({dropped/total:.1%})",
"drift/jitter": f"{drift} ({drift/total:.1%})",
"verdict": "pass" if dropped / total < 0.01 and drift / total < 0.05 else "quarantine & rework",
}
# Simulate 10 seconds at 100 Hz with 3 dropped frames and some jitter
import random
random.seed(42)
ts = [0.0]
for _ in range(1000):
gap = 10.0
r = random.random()
if r < 0.003:
gap *= 2
elif r < 0.08:
gap += random.uniform(0.5, 3.5)
ts.append(ts[-1] + gap)
for k, v in validate_timestamps(ts, 100).items():
print(f" {k:18s} {v}")
This code doesn’t reproduce their implementation; it shows what a “quality closed loop” looks like in engineering terms: not the sentence “we do QC,” but a set of executable checks — sampling rate validation, timestamp integrity, dropped-frame detection, multimodal spatiotemporal alignment. Each requires code, thresholds, batch processing, then quarantine, rework, and re-collection of failing samples, with complete processing records retained.
Part Four: The six-stage loop and what a “95% pass rate” actually means
RealMan’s QC system covers six stages: collection prep, raw recording, format conversion, semantic annotation, dataset delivery, and model validation.
# Six-stage loop: failure modes and guards per stage
def six_stage_pipeline():
stages = [
("collection prep", "site/calibration/device state inconsistency", "calibration checks, device self-test"),
("raw recording", "dropped frames, clock drift, unsynced cameras", "timestamp validation, hardware sync"),
("format conversion", "inconsistent units, confused frames of reference", "schema validation, unit normalization"),
("semantic annotation", "annotation-action misalignment, wrong classes", "spot-check review, consistency comparison"),
("dataset delivery", "version chaos, missing metadata", "version locking, metadata manifest"),
("model validation", "data usable but trains nothing", "downstream training regression, effect comparison"),
]
return stages
print(f"{'Stage':<22} {'Failure mode':<40} {'Guard'}")
print("-" * 96)
for stage, failure, guard in six_stage_pipeline():
print(f"{stage:<22} {failure:<40} {guard}")
The last two stages are the most underrated.
“Dataset delivery” looks like packaging but actually determines reusability: is the version locked, is metadata complete (task type, scene, robot model, collection parameters, QC results), is there a change log. A 100-hour dataset without metadata may be worth less than half to a model team — you don’t know what it’s good for, or whether it duplicates existing data.
“Model validation” is the only stage linking data quality to model performance. The first five ask “is the data itself compliant”; this one asks “does training on this batch actually make the model better?” The hardest and most expensive step, because it requires a full training regression.
And “acceptance pass rate above 95% at 10,000+ hour volumes” is the output metric of this loop. But a caveat: the definition of “pass rate” determines how much that number is worth.
# Three possible definitions of a 95% pass rate, wildly different meanings
def pass_rate_framings():
return {
"A: sample-level pass rate": {
"definition": "share of individual data items (one trajectory) passing all checks",
"strictness": "highest",
"meaning": "every single trajectory holds up",
},
"B: batch-level pass rate": {
"definition": "share of delivery batches accepted on first pass",
"strictness": "medium",
"meaning": "a few bad samples don't sink the batch",
},
"C: hour-level pass rate": {
"definition": "share of billed hours confirmed usable by the client",
"strictness": "lowest",
"meaning": "reworked hours don't count in the denominator",
},
}
for name, d in pass_rate_framings().items():
print(f"\n{name}")
for k, v in d.items():
print(f" {k}: {v}")
print("\nNote: public information does not disclose which definition applies; 95% must be read with that caveat.")
This isn’t nitpicking; it’s necessary caution. In data delivery, “pass rate” is a core commercial metric — it directly determines rework cost, client trust, and repeat orders. The same 95% can correspond to actual quality differing by an order of magnitude across the three definitions. Any analysis citing this number should flag that the definition is unknown.
Part Five: Why a data business must be built on hardware
One easily overlooked detail: RealMan’s hardware is its own RealBOT series, with automotive-grade joint modules, CR L3 reliability certification, and mean time between failures (MTBF) of 50,000 hours.
Those three facts are the precondition for the data business, not optional extras:
# Why MTBF directly determines whether a data business is viable
def mtbf_impact(mtbf_hours=50000, robots=100, hours_per_day=8):
"""
Expected failures per day at a given MTBF
"""
daily_robot_hours = robots * hours_per_day
failures_per_day = daily_robot_hours / mtbf_hours
downtime_per_failure = 4
downtime_hours = failures_per_day * downtime_per_failure
return {
"daily robot hours": f"{daily_robot_hours} h",
"MTBF": f"{mtbf_hours:,} h",
"expected failures/day": f"{failures_per_day:.2f}",
"downtime hours/day": f"{downtime_hours:.1f} h",
"availability": f"{1 - downtime_hours/daily_robot_hours:.2%}",
}
for k, v in mtbf_impact().items():
print(f" {k:24s} {v}")
# Contrast: MTBF of only 5,000 hours (consumer-grade)
print("\nContrast at MTBF = 5,000 h (consumer-grade):")
for k, v in mtbf_impact(mtbf_hours=5000).items():
print(f" {k:24s} {v}")
This table says one thing: the data business model is fundamentally “trading robot uptime for data hours.” If robots break constantly, you’re not delivering data, you’re delivering repair logs. Going from 5,000 to 50,000 hours MTBF moves availability from the low 70s to 97% — that’s not a hardware spec improvement, it’s a precondition for the business model.
“Automotive-grade joint modules” and “CR L3 certification” point to the same thing: this hardware isn’t a lab prototype; it’s designed to industrial reliability standards. Which also explains why RealMan grew out of ultra-lightweight humanoid arms (its original business) rather than pivoting from a model company — the moat in the data business is half software (QC loop) and half hardware (can it run continuously).
Part Six: Covering over half the market — pricing power and lock-in at the data layer
“Serving more than half of China’s embodied model companies with large-scale data purchasing capacity, covering the first tier, with repeat commercial orders already occurring.”
Three separate information points:
First, “more than half” bounds the denominator — companies “with large-scale data purchasing capacity.” That qualifier is smart: it doesn’t claim “half of China’s robotics companies” (impossible, since most can’t afford data yet), but “over half of the customer base that actually spends money on data.” Honest and persuasive at once.
Second, “first tier” signals customer quality. First-tier embodied model companies have the strictest requirements on data spec, QC standards, and delivery cycles. Making that list is itself a capability endorsement.
Third, and most important: “repeat commercial orders already occurring.” This is the most substantive sentence in the entire disclosure.
# Unit economics of a data business: why repeat orders are the lifeline
def unit_economics(hours_per_batch=1000, price_per_hour=200,
cost_per_hour=140, rework_rate=0.05):
"""
price_per_hour: price in CNY/hour
cost_per_hour: collection + QC cost in CNY/hour
rework_rate: rework rate
"""
revenue = hours_per_batch * price_per_hour
effective_cost = hours_per_batch * cost_per_hour * (1 + rework_rate)
gross = revenue - effective_cost
margin = gross / revenue
# Repeat order: same client grows volume 50% in year two
year2_hours = hours_per_batch * 1.5
year2_gross = year2_hours * (price_per_hour - cost_per_hour * (1 + rework_rate))
return {
"first batch revenue": f"{revenue/1e4:.1f} x10k CNY",
"first batch gross profit": f"{gross/1e4:.1f} x10k CNY",
"gross margin": f"{margin:.1%}",
"gross profit after repeat": f"{year2_gross/1e4:.1f} x10k CNY",
"repeat increment": f"{(year2_gross-gross)/1e4:.1f} x10k CNY",
}
for k, v in unit_economics().items():
print(f" {k:28s} {v}")
This model is illustrative (real prices and costs aren’t public), but it captures the core feature: the first order is just the entry ticket; repeat orders are where profit comes from.
Why? Because data delivery carries a hidden upfront cost — the client spends time aligning specs with you, building trust, validating quality. That cost is heaviest on the first order and near zero on repeats. So:
- A supplier without repeat orders is permanently paying customer acquisition cost, and margin gets eaten;
- A supplier with repeats sees declining marginal cost, because specs are aligned, processes are磨合 (broken in), and QC standards are mutually agreed.
More importantly, repeat orders mean lock-in: once a model company’s training pipeline is built on this data spec (metadata format, annotation conventions, time-alignment standard), switching suppliers is expensive — not in money, but because the pipeline has to be rewritten. That’s why “repeat commercial orders already occurring” says more about the quality of this business than “100,000 hours signed.”
Part Seven: Judgment and boundaries
First, the significance isn’t RealMan itself but the emergence of a “data supply layer.” Every industry matures by moving core inputs from self-sufficiency to specialized division of labor — just as cloud computing turned server operations from a per-company build into an on-demand purchase. Real-robot data for embodied AI is walking that road. Once data can be purchased monthly, model companies’ competitive focus shifts from “who can get data” to “who can use data well” — good for the whole industry.
Second, “real work data > lab demonstration data” deserves a re-examination of every embodied team’s data strategy. Lab data’s problem is narrow distribution: choreographed scenes, ideal material placement, stable lighting. Deployed models face exactly the long tail. RealMan’s 1,000 tasks across four scenario classes is essentially using “the messiness of the real world” to hedge against “the cleanliness of the lab.” Not a new idea, but making it deliverable capacity is new.
Third, hardware reliability is the invisible foundation. MTBF 50,000 hours, automotive-grade joints, CR L3 — these read like hardware marketing but are actually cost-structure determinants for the data business. Any team wanting to do “data as a service” must realize: if the robots break constantly, the business model doesn’t exist. Which is why data suppliers tend to grow out of hardware companies, not model companies.
Fourth, the 95% must be read with its definition. Three possible framings (sample/batch/hour) with wildly different meanings have been laid out. Without an official definition, treating it as a qualitative “high quality” signal is fine; treating it as a precise yield is overreach. Not harshness — in data delivery, the definition of pass rate is itself part of commercial negotiation.
Fifth, and most important: once a data supply layer exists, embodied AI’s bottleneck moves. Today the scarcest thing is “real, plentiful, well-aligned” data; once data becomes purchasable, the bottleneck shifts to “how to train generalization from limited data” — data efficiency, world models, simulation augmentation. In other words, the success of companies like RealMan will accelerate the arrival of “data is no longer the bottleneck,” and then they themselves will face “clients no longer need that much data.” That’s the fate of every supply-layer business, and the reason they must move toward “data + tools + evaluation” as an integrated service.
A trackable framework: don’t just watch signed hours; watch four numbers — ① the share of orders from repeat clients (new vs returning structure says more about quality than the total); ② the per-hour price trend (falling means oversupply, rising means QC commands a premium); ③ delivery cycle time (days from order to acceptance — the real measure of capacity elasticity); ④ how much the models trained on this data improve on downstream benchmarks (the ultimate proof of data value, and the hardest number to obtain).
Sources: Science and Technology Daily, “This Company Targets High-Quality Data Supply for Physical AI” (2026-10-30, reporter Luo Yunpeng); NetEase Intelligence / Sina Finance, “RealMan Intelligent Signs Nearly 100,000 Hours of Real-Robot Data, Monthly Delivery Capacity at 10,000-Hour Level” (2026-10-30); disclosures at the 2026 Physical AI and World Models Conference. The data-volume conversions, cost models, timestamp validation logic, pass-rate framing analysis, unit economics, and MTBF impact calculations are inference and illustration based on public information, not official data; the specific statistical definition of the “95% pass rate” is undisclosed and should be cited with that caveat.