Assuming launch-cost collapse plus moderate standardization make multi-tenant orbital platforms feasible, which specific contract or governance choices around robotic labor (e.g., who owns trained task libraries, who bears collision/repair risk, how robot-hours are billed) most strongly accelerate or delay Wright’s-law cost declines for orbital manufacturing and servicing, and how could operators deliberately structure these to push robot-hour cost below launch cost as the dominant cheap input?

starship-orbital-economy | Updated at

Answer

Key levers are: (1) IP ownership and sharing of robot task libraries, (2) allocation of collision/repair risk, and (3) how robot-hours are priced and reserved. Structures that maximize reuse of the same robots and software across many tenants while keeping downside risk bounded for early adopters will steepen Wright’s-law curves for robot-hours and let them undercut launch as the cheapest marginal input.

Most impactful choices and preferred structures

  1. Ownership and sharing of task libraries
  • Accelerate learning:
    • Default: platform owns a pooled “base library”; tenants keep narrow product IP.
    • Structure: "IP split" terms – generic motion/handling routines and perception models go to the pool; process-specific tweaks can be private or time-limited exclusives.
    • Offer discounts for contributing tasks back to the pool and for choosing from a catalog of existing tasks instead of bespoke ones.
  • Slow learning:
    • Per-tenant, fully proprietary stacks; non-disclosure of task data; no obligation to generalize or share.
  1. Collision, damage, and repair risk
  • Accelerate learning:
    • Platform carries baseline hull and robot damage risk; tenants pay a simple robot-hour fee plus a transparent, low-friction incident surcharge schedule.
    • Clear, standardized fault trees and “no-fault” repair pools so tenants aren’t exposed to catastrophic robot replacement costs.
    • Mandatory logging and data rights so every incident feeds back into shared reliability models.
  • Slow learning:
    • Tenants fully liable for any damage during their slot; bespoke fault negotiation; unclear standards; incentives to under-use or over-spec robots.
  1. Billing and access to robot-hours
  • Accelerate learning:
    • Fine-grained metered robot-hours, with:
      • Deep volume discounts tied to cumulative hours, not single contracts.
      • Off-peak pricing to keep robots busy and data flowing.
      • Short, low-commitment starter contracts so many tenants try small jobs.
    • Allow “robot SLAs” instead of fixed robots: tenants buy outcome tiers (throughput/reliability) so the platform can flexibly schedule fleets for maximum utilization.
  • Slow learning:
    • Large, long-term, rigid reservations by a few anchors; weak spot pricing; limited access for small tenants; per-mission engineering fees that dominate robot-hour price.
  1. Multi-tenant coordination for robots
  • Accelerate learning:
    • Standard workcells and fixtures across tenants so the same robot configurations can repeat similar tasks.
    • Platform-level scheduling control; no strong tenant veto on sharing robot types, as long as safety and data-isolation guarantees hold.
  • Slow learning:
    • Tenant-specific tooling and cell layouts; robots effectively dedicated to single customers; little cross-tenant repetition.
  1. Data rights on telemetry and errors
  • Accelerate learning:
    • Platform holds non-personal, non-product telemetry and error logs as a common asset.
    • Contracts guarantee anonymization but allow global model improvement.
  • Slow learning:
    • Telemetry treated as proprietary; strict restrictions on cross-tenant training; fragmented datasets.

How to push robot-hour cost below launch cost

  • Make robot-hours the default flexible input:
    • Price robot-hours low, with visible automatic declines as cumulative hours double (explicit Wright’s-law pass-through).
    • Keep per-mission engineering and certification costs small relative to usage; bundle setup into a flat “onboarding” fee.
  • Maximize cumulative experience per robot:
    • High utilization via off-peak discounts, campaign pricing, and shared workcells.
    • Aggressive reuse of generalized task libraries across industries (e.g., generic pick-and-place, cable routing, valve ops).
  • Bound tenant downside:
    • Use platform-level insurance, shared repair pools, and simple penalty schedules so tenants perceive robot risk as manageable and are willing to push automation.

Net effect on orbital manufacturing and servicing

  • With pooled task libraries, shared telemetry, and high-utilization pricing, robot-hour costs can follow a steeper Wright’s-law curve than launch.
  • That pulls robot-heavy services—servicing, debris mitigation, flexible manufacturing cells—earlier in the cost-crossover queue and shifts orbital platforms toward fully robotic or sparsely crewed architectures.