The replacement could be seen but not used.
Its name appeared in the Structure inventory, exactly where the movement report said it would be. The pilot who needed it could reach the Structure and open the relevant Corporation division. The item sat among the other stock, apparently proving that Home was prepared.
When the pilot tried to take it, the preparation vanished. The Character could view the contents but could not remove what the next task required. Its arranger was offline. Another pilot had broad Structure responsibility but not the specific Corporation access needed to release the item. Nothing had been lost. Nothing had moved. Capability was nevertheless absent at the moment it was counted.
Storage can preserve an object while hiding the conditions of its use. A hangar, container or Structure answers where something is. Location alone does not answer who owns it, who can move it, which Service can transform it or what happens when the surrounding Structure state deteriorates. Replacement exists only when those conditions can be followed from need to action.
Storage Is Risk
Accumulation gives Home endurance and gives failure a concentration.
The same location that makes materials easy to find can place several capabilities behind one access path and one Structure outcome. The same container that separates critical stock from ordinary output can depend on a person nobody named. The same inventory total that reassures the group can mix usable items, reserved inputs, personal property and material already promised to another job.
Storage risk is therefore not an argument against storing value. The term names the operational shape created by the chosen location. Describe that shape through purpose, ownership, access, concentration and recovery.
Purpose explains why the stock remains. A replacement reserve has a different release rule from material awaiting movement. Industry inputs should not be counted as free stock when an approved job already depends on them. Output with no intended user may be value, but it is not yet a replacement capability. Clear purposes keep the same item from being promised twice.
Ownership identifies whose asset path contains the object. Personal and Corporation assets are not interchangeable merely because they occupy the same Structure. A Character’s hangar can remain inaccessible to the group. A Corporation division can remain unusable to a Character without the specific role or access. The inventory should say which context contains the stock instead of reporting only a combined total.
Access asks what actions are possible. Seeing an item does not prove the ability to take it. Depositing does not prove later retrieval. Managing a Structure is not the same permission as moving Corporation property. The exact rights should be tested with an unimportant item before essential stock relies on them, as Chapter 7 established.
Concentration asks what disappears from the plan under one failure. Chapter 3’s recovery boundary for Wormhole Space turns that question into a storage concern. Inventory visible inside a Structure now is not guaranteed later recovery. The field manual does not turn that boundary into a combat scenario. It uses it to reject the assumption that storage inside a Structure automatically creates later recovery.
Recovery asks how the group recognises and reduces that concentration before a crisis. Some replacements may remain in distinct ownership or locations. Critical knowledge about stock must survive the person who arranged it. Material no longer serving a current purpose can leave rather than deepen the pile. The correct distribution depends on the group, but every location needs an owner and an intended ending.
An inventory becomes more truthful when it separates states instead of adding all names into one total. Usable reserve is present, accessible and not already committed. Reserved stock belongs to a named job or movement. Incoming stock is still dependent on a route or receiver. Unverified stock has been reported but not tested through its access path. Surplus has no present operational purpose. These labels can be maintained without attaching prices or universal quantities. They show which part of the pile can answer a need now.
Age belongs beside the state. A record from the previous month may correctly describe what was deposited and still fail to describe what remains. The owner sets the next check according to the consequence of error. Critical replacement needs a shorter path to confirmation than optional surplus. When no person owns that confirmation, downgrade the claim rather than carrying the old confidence forward.
The visible replacement in the opening scene failed at access, not at quantity. Counting one item was accurate and still misleading. A useful inventory must count the conditions that make the item releasable.
Ownership Shapes Access
Corporation storage joins asset ownership to role design.
The official role model distinguishes abilities rather than granting one universal level of trust. Query allows a Character to view relevant Corporation hangar contents. Take permits removal of items where it applies. Container Take concerns removing containers themselves. Industry roles and Structure-management abilities answer other questions. These permissions should not be treated as synonyms.
This section does not reproduce the role list. Its purpose is to show why the path to a replacement can break even when each person appears “authorised.” Visibility was available to the opening pilot. Another person could manage parts of the Structure. Neither fact granted the missing action on the stored item.
Model the path from the user’s perspective. The person needs to reach the Structure, open the correct ownership context, identify the stock, remove or use it and place any resulting object where the next task can reach it. Each verb may depend on a different permission. Test the complete path rather than confirming one impressive role at the start.
Least privilege still matters. Solving the problem by giving every maintainer every Corporation role would make the access path easier to remember while making the consequences of error or departure much larger. Grant only the abilities required by the responsibility. Record who holds them, and keep an explicit escalation path for actions that remain separated.
Separation also needs availability. If only one Character can release critical stock, the reserve inherits that person’s schedule. A second path need not mean duplicating all authority. It can mean a tested delegate for the relevant division, a smaller accessible reserve or a procedure that moves a replacement before the sole holder becomes unavailable. The design should match how long the capability can tolerate waiting.
Containers deserve the same verb test. They can organise stock, mark a purpose and reduce accidental mixing. They can also add another object whose access or removal behaves differently from the items inside. Do not infer container behaviour from the ability to see its name. Test the action the operation will actually need.
Personal stock has a simpler permission path but a narrower social one. Direct use remains available to its owner, yet the group cannot assume access during absence. Calling a personal item “our replacement” creates shared expectation without shared control. It can still serve the plan if the owner and availability are named honestly.
Access should be reviewed before a role holder departs, changes responsibility or leaves a critical verb dependent on one person. The review starts from stored purposes rather than from the full role catalogue. Identify reserves that only this Character can release and jobs that only this installer can continue. Find containers that would become visible but immovable. The answers guide a narrow transfer or a reduction of dependency while the current holder can still test the result.
A transfer is not complete when a role is assigned. The receiving Character performs the same path with an unimportant test item and confirms the outcome. The previous holder can then be removed from the dependency without remaining the undocumented fallback everyone expects to contact later.
Once the missing Take path in the opening scene is identified, the group has two tasks. It releases the immediate replacement through an authorised person, and it changes the storage design so that the next need does not depend on reconstructing the same permission. Restoring the item solves today. Making its path visible restores preparedness.
Industry Needs Continuity
Replacement may begin as material rather than as an item.
Manufacturing converts materials and components into an output using a Blueprint at a suitable facility. The Industry interface separates the Blueprint, input materials, selected facility, input and output locations, duration and cost. Optimisation remains outside this chapter. The dependency chain they reveal is its concern.
A manufacturing plan needs more than sufficient total material. The inputs must be in the location and ownership context the job can use. The Blueprint must be available to the Character installing the job. The selected facility must offer the appropriate Service. The output location must be accessible to the person who will receive and distribute the result. Time must fit the moment when replacement is needed.
Every one of these conditions can be true separately while the whole chain fails. Materials may exist in a personal hangar while the approved inputs were counted as Corporation stock. A Blueprint may be visible but unavailable to the installer. A Service may be fitted to the Structure but offline. An output may complete into a location the intended user cannot access. An inventory total cannot expose these discontinuities.
Write the job as a path. Begin with need, Blueprint and input set. Then name ownership, input location, installer and facility. Finish with Service, output location, receiver and intended use. Each step has current evidence and an owner. The path is not a permanent recipe; it is the operational state of this replacement.
A fallback should change the dependency rather than repeat the same assumption. If the local Service cannot support the job, moving identical inputs to another unsupported location is not an alternative. Instead, the group may secure a completed item, choose a facility whose access has been tested or accept a period without the capability. The correct choice depends on the current Chain and purpose. The fallback must name a different workable path.
The path should also reveal the decision that cannot be reversed cleanly. Materials may remain flexible while held in accessible storage and become committed once the job is installed. A movement may make an input available to one facility while removing it from another reserve. Placing the approval just before that change preserves the chance to respond to new evidence without stranding the plan between states.
The distinction between reserved and available material becomes important here. Once inputs are assigned to an approved job, counting them as general reserve promises them twice. Mark the reservation before installation, not after another pilot tries to use the same stock. If the job is cancelled, the record must state which usable materials remain rather than assuming the original plan has simply reversed.
Industry also carries information dependencies. A need for output may be known without the current specialised details required to produce it efficiently or correctly. This book does not fill that gap with old figures. Current activity-specific information is obtained by the job owner where it matters. Only the resulting decision needed by the shared operation is recorded.
Continuity includes the people around the timer. Installing a job and leaving does not assign receipt. Somebody must know when to check, what state can interrupt the expectation and where the output should go next. If the installer will not be available, the handover occurs while the job and its purpose are still legible.
The replacement item in the opening scene was already manufactured, but its access failure exposes the same lesson. Production is not complete capability. The chain ends only when the intended user can obtain the output and the reserve record recognises it.
Services Can Pause
Industry depends on maintained infrastructure.
An appropriate Structure Service being present today does not make it a permanent property of Home. Service Modules consume Fuel. A relevant Service can be taken offline, which can pause associated Industry jobs. Removing the Service or losing the Structure can cancel work. The exact consequences of a specific job should be checked before commitment; the general dependency is enough to shape the plan.
The distinction between pause and cancellation matters. A pause delays the expected output and may break a replacement deadline even if the job later continues. Cancellation can leave the group without the planned result and without every input consequence being reversible. Neither should be reduced to “the Structure still exists.”
Before installation, connect the job to Chapter 8’s infrastructure record. Which Service does it require? Who maintains the Fuel path? What was last observed about Service state, and when must that Observation be renewed? Who can decide to postpone the job if the support period is doubtful? What alternative restores the capability if the Service cannot carry the work?
The support period should include more than the displayed job duration. Inputs must be prepared, the job must be installed, the output must be delivered and somebody must remain responsible through receipt. A Service expected to last only until an optimistic completion moment does not cover the whole replacement path.
Service confidence also has a Source. The fitted module, the current online state and the maintainer’s plan are different observations. Seeing the module does not establish that it is online. Seeing the Service online does not establish how long Fuel and ownership will support it. A maintainer’s intention does not replace the visible state. The job record keeps these claims separate so that one reassuring fact cannot stand in for the entire support period.
If support becomes uncertain before installation, postponement keeps the inputs available for another path. If the uncertainty appears during a job, the owner records the observed job state and the effect on the expected output. The same word—unavailable—must not conceal whether the work is waiting, cancelled or merely inaccessible to the viewer.
Promises to other work must be reconciled. One maintainer may intend to take a Service offline after a current task, while another pilot prepares a new job that assumes continued availability. Both plans can be reasonable in isolation. The shared record must make the overlap visible before installation turns it into a dispute with material committed.
When the Service state changes, the response follows evidence. Record the observed state, identify affected jobs and stop new commitments. Do not claim that every job has failed when the visible result is a pause. Do not promise that work will resume merely because the module remains fitted. Job owner and maintainer determine what can be supported from the actual Structure, Service and Fuel state.
Defence and repair doctrine remain outside this chapter. The text does not explain why a Service became unavailable beyond what the group can observe. The operational question is narrower: which promised capability no longer has a continuous path, and how can exposure be reduced before more work depends on it?
The visible replacement at the start avoided this Service dependency because its job had finished. Future replacements may not. Preparedness should count completed, accessible capability differently from material inside a running or unsupported job.
Replace Before Empty
The last usable item is not a reserve. It acts as a countdown without time attached.
If replacement begins only when the final copy is consumed, every dependency in the path becomes urgent at once. Materials, Blueprint, access, Service, route and people must all remain available without delay. A minor pause then becomes a capability gap.
Set the trigger before absence. The trigger should be based on the time and uncertainty of the replacement path rather than a universal stock number. A locally manufactured item may still depend on imported inputs. A large visible stock may be inaccessible to the users who need it. A small reserve may be adequate when substitutes and a short tested path exist. Quantity alone cannot set the boundary.
Begin with consumption or loss that the group can observe. Which events reduce the usable reserve? Who updates the count? Does an item become unavailable when installed elsewhere, reserved for a job or moved beyond the current Chain? A count that changes only after physical destruction overlooks several ways capability leaves Home.
Next describe replacement lead time as a chain of conditions, not a confident duration. Detection starts the process. An owner approves the need. Inputs are released or moved. The job is installed, or an existing replacement is transported. The output reaches usable storage. Each stage can wait on people, access, Service or Connections. The trigger must leave room for the uncertain stages the group actually has.
Two horizons help make that uncertainty visible. The usable horizon asks how long current reserve can support the accepted purpose. The replacement horizon asks how long the slowest credible path to another usable item may require. Replacement begins before those horizons meet. Neither horizon needs false precision. A range, a limiting dependency and the next check are more honest than a confident date built from best-case steps.
Work already in progress belongs to neither reserve nor completed replacement. Count it as an open dependency with its Service, owner and expected receipt. Doing so prevents a running job from reassuring users who need an item now, while still allowing the group to see that replacement has begun.
Replacement priorities follow consequence. Restore the capability whose absence blocks observation, return, access or another replacement path before optional depth. No universal item ranking follows. Ask which missing function would make the group’s other promises false.
The reserve must be tested as a user would encounter it. Can an authorised Character find and take the item? Does the output sit in the expected ownership context? Does the inventory distinguish accessible stock from reserved input and personal property? Can the next shift identify the owner and trigger without contacting the person who designed the system?
By the time the delayed item reaches Home, the group does not return it to an unchanged shelf. One usable replacement is placed in a tested access path. The remaining stock is separated by purpose. The inventory names ownership and the next trigger. A second authorised person confirms the action while the first is still available.
The result is not infinite readiness. It creates an honest interval during which a capability remains supported, plus a visible condition that begins replacement before that interval ends.
Field Principle
Storage is a dependency, not a pause in the story of value.
For every critical item, name purpose, ownership and location. Add the access path, concentration, user and replacement trigger. Keep personal assets distinct from Corporation assets. Treat visibility, deposit, removal, installation and distribution as separate actions until the complete user path has been tested.
For manufactured replacement, follow the chain from need through Blueprint, inputs, facility, Service and output to an authorised receiver. A job can pause or fail to deliver capability while the Structure remains visible. Begin replacement while time and alternatives still belong to the group.
The item in the opening scene had not vanished. The surrounding assumptions had. By tracing those assumptions, the group restored more than access to one object. It made the next failure visible before the next need.
Part III began with a ship committing to work. It now ends with the result stored, usable and connected to replacement. That continuity will not preserve itself across days and people. Part IV begins when the person who understood today’s arrangement is no longer the person who must act tomorrow.