The permission paths from Chapter 7 are corrected before the work resumes.
The intended Character can dock. The Structure presents the required Service, the material path is visible, and the Corporation member holds the abilities needed to manage the job. Every access question now returns the expected answer.
The job still cannot begin. The Service is offline.
The Structure occupies the same Grid as before. Pilots can dock, open their hangars and see the familiar interior. The hull has preserved the appearance of continuity while one of the functions around which the group organised its work has stopped.
The failure feels sudden only because the dependency was hidden. The Service required a Service Module to remain online. The module required Fuel. Fuel required a route, a reserve, access to the Fuel Bay and a person responsible for noticing when the reserve no longer carried the intended work. The job at the end of that chain was the first place where the missing care became unavoidable.
Infrastructure is not the object standing in space. It consists of the maintained relationship between that object, its functions and the people who depend on them.
Services Need Inputs
Service Modules give Upwell Structures their functionality.
The Structure itself does not consume Fuel merely by existing. Installed Service Modules do consume Fuel when they are online. Different Services can have different requirements, and those requirements are visible with the individual module. This Chapter needs no universal quantity because the useful question comes before calculation: which function is online, what keeps it online, and which work fails when it stops?
That distinction changes the opening scene. The Structure has not vanished. Its docking and storage functions still give the group somewhere to arrive. The particular Service needed for the job is unavailable because its own operational chain has broken.
Begin with the function rather than the hull. Name the Service the group actually uses. Identify the Service Module that supplies it and whether that module is online. Record the Fuel condition through a Character able to see and maintain it. Then follow the dependency outward to the work.
The chain can fail at several points without producing the same observation. The module may be installed but offline. Fuel may exist in the Structure while the responsible Character cannot place it where the online module can use it. A Character may be authorised to manage the Structure but absent when the route carrying replacement Fuel closes. The user may have Service access while the owner has not assigned anyone to maintain the module.
The statement we own a Structure solves none of these conditions. Ownership says where ultimate control resides without moving Fuel, keeping a Service online or making the responsible Character available.
The reverse is equally important. A Service can support work used mainly by guests, but its care remains an obligation of the owner. Guest demand does not automatically create Fuel, a maintainer or a recovery decision. If a group publishes a capability, someone must know whether the promise is intentional and how long the present inputs can carry it.
Follow Fuel as capability rather than inventory. A reserve outside Home must still cross a usable Chain. A reserve inside the Structure must be available to a Character who can place it in the Fuel Bay and manage the relevant Service. Fuel in the correct bay must still be sufficient for the online modules expected to run. Each step can be true while the next remains Unknown.
The group therefore gains little from a reassuring total with no path attached to it. Fuel exists may describe material in transit, inaccessible storage or a reserve intended for another purpose. The authorised maintainer observed the Fuel available to these online Services before this work gives the next decision a usable boundary.
Consumption also changes with the selected Services. An owner who adds a new online module changes the conditions supporting every existing estimate. A maintainer who takes one offline may extend the remaining input while removing a function on which someone still depends. A useful record needs both the input observation and the Service set it was expected to carry.
This makes a deliberate offline decision part of care rather than the opposite of it. At times, the group may be unable to sustain a Service or may no longer intend to support its work. Taking it out of the operational Baseline is then more honest than allowing users to plan around a capability that will disappear without an owner. The decision must reach those users before their next commitment.
Care does not require every installed Service to remain online. An unused function can consume attention and resources without serving the current purpose. It includes deciding which Services Home intends to support and removing abandoned expectations from the Baseline before users build work on them.
The offline Service in the opening scene therefore reveals two questions. What input is missing now? Why did nobody see the dependency approaching its limit? Restoring the module can answer the first. Only an assigned care practice can answer the second.
Power Has Meaning
An Upwell Structure is in Full Power when at least one Service Module is online. If no Service Module is installed or online, the Structure is in Low Power.
Those terms describe a real state, but they do not answer whether a particular Service is available. A Structure with one online module can be Full Power while the module required for the group’s work remains offline. Reading Full Power as all functions ready would repeat the mistake made when docking was treated as proof of Service access.
Low Power gives a different observation. No Service Module is presently online. That fact is broader than one missing job function, but it still does not explain the cause. Fuel may be absent. Modules may have been deliberately taken offline. Another Structure condition may be involved. The visible state sets a boundary for investigation without supplying a complete history.
Power State also has effects beyond ordinary work. The official system distinguishes the states in Structure vulnerability and operation. Defence, reinforcement and combat response remain outside this Chapter. The operational lesson is only that Full Power and Low Power are not decorative labels, and a change between them belongs in the shared Baseline.
Prolonged absence of Fuel consumption by Service Modules can move a Structure from Low Power into Abandoned. In that state, specific Structure abilities are no longer available. The exact transition time is not needed for a care practice. Waiting for an Abandoned observation would mean allowing the earlier maintenance failure to mature into a much broader condition.
The three names should remain separate. Full Power proves at least one online Service Module, not every intended function. Low Power proves the absence of online Service Modules, not the reason. Abandoned is a distinct state reached after sustained lack of Service Module Fuel consumption, with additional lost abilities.
This vocabulary lets the group report the opening failure precisely. A Structure remaining at Full Power allows the required Service to be investigated as a particular module or dependency. A Low Power observation widens the investigation to every intended Service. An Abandoned observation shows that ordinary work planning has already lost assumptions beyond the original job.
Power has meaning when it changes the scope of the next question. It becomes misleading when one label is used as a general verdict on the health of Home.
State Is Visible
Care requires a Source that can see the state being maintained.
The Structure Browser shows accessible Structures and the Services they offer. That view helps a user establish whether the required capability is presented to their Character. Owner conditions behind the offer remain outside that view.
Members of the owning Corporation with the appropriate authority can see the My Structures view. That information includes remaining Fuel and the current Vulnerability State of their Structures, alongside Profile and assignment information. The owner view can therefore carry observations unavailable to a guest.
The two perspectives should meet without being blended. Guests can report that the Service is unavailable to the intended Character at a stated time. An authorised owner can report that the module is offline, what Fuel condition is visible and which Structure state applies. Together, the observations explain more than either one alone.
Do not turn the owner’s broader view into permanent knowledge. Fuel is consumed while online Service Modules run. A value seen at the beginning of a work period ages as those Services operate and as people change the Structure. The Timestamp belongs to the observation even when the interface offers a precise number.
The Service state also deserves its own line. An online module, the Structure’s Power State and the user’s ability to access the Service are related but distinct. One can change without all the others producing the same result. Recording only Structure green erases the layer that the next person needs to test.
Visibility must lead to a decision boundary. A Fuel observation matters when it shows whether the intended Service can remain online through the work and until the next responsible person can act. The group need not publish every changing value to every user. It must make the condition visible to the person who owns the response.
When the view is unavailable, the state becomes Unknown rather than assumed. The absent owner may not indicate a problem with Fuel, but their absence can remove the group’s ability to confirm or correct the condition. That is a capability failure in its own right.
The pilots can now separate what each knows. The working Character observes the offline Service. The authorised owner confirms the module and Fuel condition. Their shared account connects those observations to the paused job without claiming that every Structure function has failed.
Failure Spreads Outward
A Service failure rarely ends at the Service.
Manufacturing and research work can be made available in Upwell Structures through their corresponding Service Modules. If the relevant Service Module goes offline, running jobs of that kind can pause until the Service returns. If the module is removed or the Structure is destroyed, the corresponding jobs can be cancelled.
Those mechanical outcomes shape operations through the dependent work. A paused job keeps its expected output from appearing. A later task may be waiting for that output. A pilot and ship may already be assigned to move it. The Chain may have been confirmed for a delivery whose material will not be ready.
Follow the opening failure outward. The Service is offline, so the job cannot begin. Material remains in storage instead of entering the job. The planned completion time loses its basis. A replacement item expected by another pilot will not be available. The route prepared to carry it no longer has a current purpose.
No single step is a crisis. The exposure comes from allowing each dependent plan to continue using the old assumption. A transport pilot who waits on a route for material that cannot be produced spends attention on a dead branch. A group that commits another ship because it expects the output can deepen the same shortage.
The response should move through the chain in the opposite direction. Pause the job decision. Notify the owner of the dependent work. Release movement that no longer has cargo or purpose. Decide whether restoring this Service is the correct use of Fuel and authority, or whether the work should move to an existing alternative.
Access can make the failure harder to read. The Service might appear unavailable to one Character because of the Profile while remaining online for another. Conversely, perfect user access cannot make an offline module work. Both paths need confirmation before the cause is assigned.
Cancellation carries a stronger boundary than pause. A paused job may resume when its Service returns. Removal of the relevant module or destruction of the Structure can cancel the work instead. The care record must distinguish a recoverable interruption from a decision that ends or replaces the job.
Other Services create different outward consequences. A catalogue lies outside this Chapter. The method remains the same: name the function, identify the work that assumes it, describe the first visible failure and decide what must stop before the missing output spreads into another plan.
Time changes the size of the consequence. A Service discovered offline before a new job begins may cost only a postponed decision. The same failure found after several jobs and movements have been organised around their expected outputs can hold pilots, materials and routes in place. Early visibility does not make the mechanical condition smaller; it keeps fewer commitments attached to it.
For that reason, the work owner belongs in the response. The Structure maintainer can report whether the module can return. They cannot decide alone whether the old schedule, material and movement still make sense. Restoring a Service after a long interruption does not restore the assumptions made before the pause.
Rebuild those assumptions in order. Confirm the Service. Re-evaluate the job and its inputs. Give any new completion expectation to the dependent work. Only then recommit the movement. The Chain may have changed while the Service was unavailable, and the pilot once assigned to transport may now be carrying another purpose.
If restoration is uncertain, the fallback must be compared with the same discipline. Another Structure may offer the Service to the intended Character but lack a confirmed route. Moving the material may create more exposure than waiting. The right decision comes from the combined dependency, not from a desire to make the original schedule look intact.
Infrastructure becomes understandable when its consequences are traced before failure, not discovered after every dependent pilot has already acted.
Assign Every Dependency
Critical infrastructure needs an owner before it needs repair.
Start with the Service that carries current work. Record its intended purpose, the Service Module that supplies it and the owner who can see its operational and Fuel state. Name the person responsible for acting when the observed condition no longer carries that purpose.
The observer and maintainer may be different Characters. A user can notice that a Service has disappeared. An authorised owner can inspect Fuel and module state. Another pilot may carry the replacement input through the Chain. The care practice succeeds when those contributions meet at one named decision, not when every person receives every authority.
Give the dependency a trigger. A check may belong at the beginning of a work period, before a long job, before the only maintainer leaves or when route conditions change. The useful frequency comes from Fuel consumption, access to replacement and the consequence of interruption. No universal schedule can replace those conditions.
Add the dependent work. A Service with no named user may not be critical even if it is expensive to run. A modest function can be load-bearing when several open commitments assume it. Purpose determines what the group maintains.
Add the failure consequence and first response. If the module goes offline, which work pauses? Who needs to be told? Which movement can be released? What state requires escalation from a Service question to a Structure-wide review? These decisions should exist before the interface supplies the failure.
Finally, name the replacement path. The alternative might be another available Service, a postponed job, a smaller commitment or a route for restoring inputs. A fallback is credible only if its access, Chain and material conditions have been read with the same care as the primary path.
This small dependency record is not a permanent inventory of every module. It follows active purpose. When a job closes, its Service may leave the critical set. When new work begins, a previously incidental Service can enter it with a Steward, observation Source and response boundary.
Imagine the record at the start of the next work period. It names the Service required for the open job and the authorised Character who last observed its module online. The same entry identifies the maintainer responsible for Fuel, the time of the Fuel observation and the point before which another check is required. It names the job owner, the movement waiting for its output and the fallback if the Service cannot carry the work.
The next pilot can read that record without needing every management right. When the Service remains visible and the next check is not yet due, the pilot knows which dated evidence supports the plan. Its absence identifies the work to pause and the person to contact. An unavailable maintainer leaves a prepared fallback rather than an improvised search for authority.
Handover must preserve limits. A maintainer who observed Fuel before leaving does not certify what will remain after an unspecified period of consumption. They state which Services were online, which work the observation was intended to carry and when responsibility passes to the next person. The receiving maintainer confirms acceptance just as a Chain Steward accepts an unresolved branch.
If nobody accepts, the infrastructure should degrade visibly in the plan. Postpone the new job, shorten the supported period or remove the Service from the set of promised capabilities. Continuing unchanged would assign the dependency to chance while leaving users to believe it still has an owner.
Responsibility also includes authority without hoarding it. The maintainer needs the access required to observe and act, but they need not receive every Structure or Corporation ability. A separate administrator can retain broader control as long as the response path is explicit and available within the time the Service can tolerate.
This arrangement survives absence better than a familiar name in a note. It states who observes, who acts, who decides about the work and who accepts the next handover. One Character may fill several positions, but the functions remain distinct enough to transfer when that Character leaves.
The offline module can be restored without hiding the failure that exposed its dependencies. The owner confirms the Fuel and module state. The work owner decides whether the job still matters. A maintainer accepts the next check, and the group records what should happen if the Service cannot be kept online through the work.
Repair returns functionality. Assignment makes the return sustainable.
Field Principle
Infrastructure is an ongoing obligation, not a hull placed once.
Separate Structure, Service Module, Fuel, user access and dependent work. Read Full Power, Low Power and Abandoned as bounded states rather than general judgements. Give every critical Service a visible condition, a responsible person, a trigger for review and an alternative when the condition fails.
The Structure in the opening scene never moved. What changed was the maintained relationship between its Service and the work built around it. By following that relationship backwards, the group can restore capability without mistaking permission, Power State or ownership for the whole answer.
Part II began by making ordinary Home observable. It kept the Chain honest, separated authority from capability and exposed the care beneath a familiar Structure. Home can now support work without pretending that its support is automatic.
Function alone is not purpose. The next question is what the group chooses to do with that capability, and which new exposure begins when attention, ships, routes and material are committed to the task.
Part III begins with work.