Skip to content

Temporal Multiplexing Schedule

Scheduling method — instantiates Internal Capacity Deepening

Multiplies a position's capacity by sharing the same asset across time — more shifts, users, or demand windows — while keeping handoff and setup cost from eating the gain.

Some positions are not empty — they are busy at some hours and idle at others. Temporal Multiplexing Schedule harvests that idle time by sharing one asset across time: successive shifts, alternating users, or different functions rotated through the same space or machine. Its axis is time, not function — the asset keeps existing, and the schedule packs more distinct uses into its calendar. The gain is real but never free: every switch between users or functions carries a setup and handoff cost, and the whole craft of the schedule is arranging the rotation so the added throughput clearly beats the changeover overhead — and so quality does not drift as the asset passes from hand to hand.

Example

A commercial kitchen sits idle between its dinner-service peaks. A ghost-kitchen operator time-multiplexes it: a breakfast brand runs 6–10, a salad brand 11–3, the resident dinner restaurant from 4. One kitchen now yields roughly three tenants' worth of throughput. The schedule earns its keep by modelling the net gain — added covers minus the changeover between brands: deep-cleaning the fryer between a doughnut daypart and a salad daypart is slow, so those two are deliberately not placed adjacent, and a 45-minute buffer separates each brand. A shared cleaning-and-reset checklist keeps every brand handing the line over in the same state, because the fastest way to wreck time-sharing is to let one tenant's mess become the next tenant's problem.

How it works

The distinguishing calculation is the yield net of changeover. Raw idle time overstates the prize; what the schedule actually captures is added usable time minus the setup, teardown, and handoff each transition costs — which is why reducing changeover time is often worth more than adding another slot. The schedule sequences uses to minimise expensive transitions (group compatible functions, avoid back-to-back deep resets) and standardises the handoff so the asset arrives in a known state each time. Push the packing too tight and the buffers vanish, at which point one overrun cascades down the whole day.

Tuning parameters

  • Packing density — how tightly the slots abut. Tighter packing extracts more capacity but shrinks the changeover buffer, so a single overrun ripples into every later slot.
  • Changeover investment — money and design spent to make switches fast (pre-kitted setups, quick-change tooling, standard handoff state). Cheaper switches make finer time-sharing pay.
  • Slot heterogeneity — how different the rotated uses are. More heterogeneous uses find more idle demand windows but raise per-switch cost and quality-drift risk.
  • Handoff strictness — how rigidly each user must return the asset to a defined baseline. Stricter handoffs protect the next user but add per-transition overhead.

When it helps, and when it misleads

Its strength is extracting capacity from an asset that is already there with almost no capital — the cheapest yield on the intensify side when demand is genuinely time-staggered.

It misleads when the changeover math is ignored. Setup and handoff cost is the silent killer: a schedule that looks like a tripling on paper delivers far less once real transition time is counted, and past some density the setup overhead exceeds the capacity gained.[1] Time-sharing also couples formerly independent users — one tenant's overrun is now everyone's delay — and invites quality drift, as each successive user inherits the last one's shortcuts. The discipline is to model yield net of changeover, hold a real buffer rather than packing to the theoretical maximum, and enforce a handoff standard so shared use does not quietly degrade what the asset delivers.

How it implements the components

This schedule fills the temporal-yield and handoff-quality slice of intensification:

  • capacity_yield_model — the model of usable capacity gained from time-sharing, stated net of setup, teardown, and handoff overhead.
  • quality_consistency_guardrail — the handoff standard and reset discipline that keeps output consistent as the asset passes between users and functions.

It reuses time, not space — repurposing the asset itself is the Infill and Adaptive-Reuse Program — and it owns no support-system ceiling or reserve floor; those are the Infrastructure-Load Simulation and Slack-Erosion Test.

References

[1] SMED (Single-Minute Exchange of Die), Shigeo Shingo's method for cutting changeover time on shared equipment, is the discipline that makes fine-grained time-sharing pay: the more you can compress setup, the tighter you can multiplex before the overhead swallows the gain. ↩