Mobi (Mbi) Logistics Standard
Quantifying the invisible cost of IVA movement in microgravity.
Problem
As we transition from single-station outposts to commercial space habitats, internal logistics are becoming a critical budget line item. In microgravity, mass doesn’t weigh anything, but it still has inertia. Moving cargo consumes the most valuable resource on a station: crew attention.
Current baseline metrics measure volume (m^3), mass (kg), and time, but they fail to capture labor intensity.
- How much crew time does it take to move a 50kg payload across a module?
- Is a direct route with three manual hatches “closer” than a longer route with auto-doors?
- How do we prove the ROI of a robotic transport system before we build it?
Without a standardized unit of measure, these critical layout and operational decisions are made on intuition rather than data.
Solution
I’ve developed Mobi (Mbi) to create a quantitative language for mobility. It is a mode of translation-agnostic metric that allows architects and operators to compare completely different conveyance methods- anything from from hand-carrying to autonomous drones- on a level playing field.
The core formula normalizes crew effort against “haul” (the work performed):
Mbi = 10^5 * Crew-Hours per Payload-Distance (kg*m)
By scaling the result, Mobi provides a human-readable “efficiency score” (e.g., an Mbi of 42.1) that serves as a KPI for habitat design and transport mode decision-making.
Design Challenges
Creating a standard for space logistics requires solving unique constraints that don’t exist on Earth. This is a human factors problem applied to facility architecture and operations.
1. Defining “Distance” in Variable Gravity
In a standard logistics model, “distance” is simple. In orbit, there are many complications introduced by microgravity.
One way I account for this is with the concept of Traversable Distance (Dt) as a “gravity-agnostic” normative basis. The traversable distance is equal to the shortest route that is physically navigable in at least one gravity profile.
Why it matters: This decouples the facility’s geometry from the method of travel. Variance from geodesic distance becomes a measure of traversable route efficiency.
Mbi uses traversable_m (Dt) in the denominator.
When provenance is path-based: W = Dt/Dg, S = Dp/Dt, PDI = Dp/Dg = W × S.
2. Isolating the “Why” of Inefficiency
Knowing that a route is slow isn’t enough. We need to know why. I designed the schema to categorize crew time into three mutually exclusive buckets:
- Progress: Active movement (Handling, Escorting, or Monitoring)
- Staging: Hands-on manipulation at endpoints (Strapping, Unpacking, etc.)
- Gated: Time blocked by layout or policy (Waiting for airlocks, safety holds, etc.)
This taxonomy allows the metric to act as a diagnostic tool, ex: high “Staging” time may point to an interface design problem.
Normative flow for classifying sprint minutes into Mbi buckets.
3. Accounting for Blocked Time
- Layout – Geometry/throughput constraints (doors, airlocks, traffic queues, chokepoints)
- Policy – Required verification, escort rules, lock/unlock procedures, clearances
- Conveyance – Typical rest or recovery periods intrinsic to the method (needed crew break or thermal cooldown)
- Exogenous – External environment factors (visiting vehicle ops, power/comms outages)
- Sprint Incident – Anomalies, faults, corrective actions, emergencies
crew_gated_min is broken into Layout / Policy / Conveyance / Exogenous / Incident.
Each stack’s sum equals crew_gated_min.
4. Beyond Mass: Drag and Friction
A non-normative companion matrix accounts for physical constraints not captured by mass alone. In microgravity, a 5kg bag of sloshing water is significantly harder to control than a 5kg solid brick, yet their mass input is identical. Mobi solves this by splitting difficulty into Transit Drag and Terminal Friction.
Transit Drag Coefficient (Tdc) accounts for the difficulty of movement. It applies a physics-based multiplier (1.0 + vc + df) to the mass based on two factors:
Vision & Control (vc): Field-of-view obstruction and lack of handholds (0.0-1.0).
- Dynamics & Fragility (df): Field-of-view obstruction and lack of handholds (0.0-1.0).
Terminal Friction accounts for the difficulty of interfaces. This isolates Staging time- the “interface tax” paid at endpoints to strap, unstrap, scan, or connect cargo. By separating the drag of the journey from the friction of the destination, Mobi ensures that a team moving hazardous fluids isn’t unfairly compared to a team moving trash, and clearly distinguishes between a slow hallway and a clumsy latch.
Bottom Line
Each cargo run is tracked as its own sprint- with primary variables of a route’s total time, its traversable distance, and the mass of the payload. Several further attributes including geodesic distance, conveyance used, policies in place, total crew involved, and others combine to tell a complete story.
Lower is better. Values are illustrative for design comparison under consistent policies and similar traffic.
Crucially, you can’t hide the “why” of inefficiency- that’s guaranteed by the “Conservation of Inefficiency” principle embedded into the fabric of Mobi. If Mbi is consistently high, it’s either built into the architecture, it’s inherent to the conveyance or policies of the station operator, or it’s the habits of crew. Proper implementation of Mobi will reveal it.
Adoption Ecosystem
Mobi is designed for use by space station architects, purchasers, operators, and crew alike. It’s meant to inform decision-making across the industry and a shared, evolving understanding of what makes for good orbital mobility architecture.
To ensure immediate applicability in current and future space stations, I’ve developed a comprehensive suite of tools catering to every stakeholder in the loop- from the astronaut running sprints, and the operator reviewing data logs, to the CFO approving the budget.
I have proposed the business case for trialing Mobi in the design phase, with full instruction on how to get started. I created technical artifacts including JSON schema, a Python validator, and a reference architecture for running logistics audits in a CI/CD pipeline: I’ve tried to think ahead about what could go wrong, what may seem complex, and how issues might be mitigated. I’ve called those out and addressed them and more where I can. The entire Mobi system is available here:
Looking Forward
I would like to put forth this standard for rigorous review and optimization in collaboration with subject-matter experts. The goal is to eventually offer it for consideration of adoption in future-generation orbital habitat design and operations design.
My hope is that Mobi may enable improvements in orbital logistics across the industry, so I aim to make it available via CC by 4.0, published and maintained on GitHub with a DOI.