Two candidate systems have survived the first discussion.
On the shared page, they look almost equal. Both can be reached. Both have space in which the group could work. Each has an Upwell Structure visible in the system, although only one currently offers guest access. Short notes list a Class, an Effect and several Connections observed during scouting.
The question at the top of the page asks which system is better.
It is the wrong question.
One candidate supports the planned work but places replacement farther away. The other is convenient today because another corporation provides access. That convenience rests on a decision the group does not control. Neither system is simply good or bad. Each asks the group to accept a different kind of dependency.
Choosing Home begins by naming what the system is meant to carry.
Purpose Before Class
A Class is easy to place in a heading. Purpose is harder because it forces the group to describe itself.
What will people actually do here? How often will they do it? Which capability must be available when they arrive? What must travel into or out of the system? How long is the arrangement meant to last? These questions are less elegant than a ranking, but they reveal what a ranking would conceal.
Suppose the group says that Home should support exploration, limited resource work and basic replacement for a few pilots. That sentence is a start, not a complete purpose. It leaves open whether the group can pause when access changes, whether materials must leave every day and whether one absent person would stop the work.
A useful purpose has five parts.
First, it names the work. Live in Wormhole Space is an identity. Maintain a small base for exploration and a defined period of resource work describes a use.
Second, it names the people. A system chosen for one independent pilot carries different coordination costs from a system expected to support several shifts. The difference is not only scale. More people create more handovers, more owners and more opportunities for an assumption to pass unnoticed.
Third, it names the required capabilities. Scanning, storage, replacement and whatever services the work genuinely needs should be visible before a Structure is admired for offering them. A capability that is merely pleasant to have must not quietly become a requirement during the comparison.
Fourth, it names the time. A trial can accept dependencies that would be weak foundations for an open-ended presence. An arrangement intended to last must survive absence, delayed replacement and changing access without pretending that these conditions will never occur.
Finally, it names the end. The group should know what result would make the trial successful, what finding would make the system unsuitable and how much can be left behind while that decision remains open.
A workable purpose might read like this: For one trial period, Home will support exploration by several pilots. It will hold replaceable working assets and provide only the services needed to return those assets to use. Work pauses when the relevant Chain cannot support replacement. The trial ends before any single asset or access arrangement becomes necessary to recover everything else.
The wording deliberately avoids predicting how often useful Connections will appear or how much work the pilots will complete. It says which capability the system is being asked to support and what the group will not yet ask of it. New opportunities can be observed without being promoted into new commitments during the same trial.
Purpose should also be readable by someone who did not help choose the system. If the explanation depends on enthusiasm, reputation or an unwritten history, the next shift cannot test it. A short, explicit purpose gives later evidence something to confirm or challenge.
Purpose does not choose the system by itself. It turns system properties into questions that can be answered. Class becomes relevant to a defined activity. An Effect becomes a condition applied to actual ships and work. Connections become routes asked to carry particular movement. Infrastructure becomes a set of capabilities with owners and limits.
Without purpose, every useful feature invites another activity. The group chooses a system because it could do many things and later discovers that it cannot explain which of those things justified the commitment. With purpose, possibility can remain possibility. Only the required conditions enter the decision.
Read the System
Regular Wormhole Systems are commonly organised into Classes C1 through C6. The official Static Data also represents Wormhole Class and system Effects. These are stable system properties that can be recorded and checked. They are not a complete description of Home.
Class is a category before it is an interpretation. It can help identify which system is being considered and which further questions belong to the plan. It does not, by itself, reveal the route that will be available tomorrow, the people who will share the system or the access a guest will retain.
The distinction matters because players often inherit conclusions with the Class label. A candidate may be called easy, difficult, rich, poor, suitable or undesirable before the group’s purpose has entered the sentence. Some of those judgments may have been useful to the person who formed them. They are still interpretations, produced for another plan.
Record the property first.
The system has a stated Class. Record the Source used to establish it. The system has an Effect, or no relevant Effect has been established. Record that separately. Structures and other visible infrastructure belong to another layer. Current Connections belong to the Chain, not to the Class field.
This separation prevents a correct observation from carrying an unsupported conclusion. C3 can be a checked property. C3 is right for us is a decision that needs the group’s purpose, capabilities and accepted costs. The first can remain true while the second changes.
Static Data is valuable here because it preserves the difference between what the game defines and what residents learn by operating in a system. It contains information about Wormhole Classes and Effects. Yet it provides no third-party developers with the system-specific static Wormholes that players may expect from experience or other records. A field note about an expected Connection must therefore keep its own Source and uncertainty.
This Chapter does not need a catalogue of Classes. A catalogue would encourage selection by label and become stale wherever it smuggled in values, income or an assumed way of living. The Explorer needs a cleaner skill: read each system property, then ask what consequence it has for this purpose.
A group unable to answer that question should not fill the gap with reputation. It can test the consequence, seek a current Source or leave the property unresolved. Unknown is more useful than a borrowed ranking.
Read the Connections
The first candidate has produced a convenient route during several scouting visits. The second has repeatedly required more steps to reach the places the group uses. It is tempting to turn those observations into permanent features of the systems.
They are not permanent features.
Wormholes form short-lived Connections. Their information offers rough indications about lifetime and mass condition, not a timetable or a promise of the next destination. The Chain observed around a candidate describes access during that observation. Recording it repeatedly cannot turn it into infrastructure.
Repeated observations can still be useful. They show what the group has actually encountered, how often it has had to rebuild routes and which kinds of movement were difficult during the sample. Their value comes from preserved limits: dates, Sources, missing shifts and the purpose for which the routes were judged.
Call this an observed Connection profile. The word profile does not mean a guaranteed set of exits. It means a controlled history of what the group found and what that finding required from them.
The record should keep four things apart.
The current Chain shows the Connections available to the latest observer. An expected relationship identifies something residents believe is likely to be found, with its Source. Route demand describes what the purpose needs to move and how often. Route tolerance states what the group will do when that movement cannot occur as planned.
These layers answer different questions. A useful exit today may support a scouting flight without proving that the system will support regular transport. An expected Connection may guide the next scan without authorising cargo to be committed before the route is observed. A difficult route may be acceptable when the work can pause, but unsuitable when replacement depends on a deadline.
This is where Home selection becomes operational. The group is not choosing a permanent road. It is choosing how much recurring work it can accept to discover, evaluate and use temporary roads.
The comparison between candidates should therefore avoid statements such as this system has good access. Say what was observed and what the purpose requires. Perhaps one candidate has so far demanded longer transport paths, while the other has been easier to reach during the same observation period. One result may be preferred, but the comparison must preserve the possibility that the next Chain will reverse the experience.
A choice made under that uncertainty is not weak. It is honest. The weakness would be building an irreversible plan on a route description that never claimed to be permanent.
The observation period should match the decision being supported. A brief visit can establish that movement was possible during the visit. It cannot establish the recurring effort of residence. Longer observation can reveal variation, but it never becomes a guarantee. The record gains value by showing what it covered and loses value when quiet periods or missing observers are silently treated as ordinary conditions.
Do not wait for a perfect sample. Waiting also consumes time and may encourage the group to act as though the candidate has already been chosen. Gather enough evidence for the size of the first commitment, keep that commitment reversible and continue observing after the trial begins.
Read the Effect
An Effect changes the conditions under which ships operate in a Wormhole System. The official Static Data identifies Effect types and the system data to which they belong. This makes the presence and Effect type a checkable property. Its operational consequence still depends on the plan.
The same Effect can meet different ships, fittings, tasks and tolerances. Calling it beneficial or harmful before naming those relationships repeats the mistake made with Class. It converts a property into a ranking without showing the plan beneath the judgment.
Read the Effect in three passes.
First, establish what Effect applies. Keep the current official data or other controlled Source visible. Do not rely on a label copied from an old map when the property can be checked.
Second, identify which required capability it touches. The question is not whether the Effect is popular. The question is whether it changes the ships or actions on which the stated purpose depends. If the purpose does not require a capability, its interaction should not dominate the choice.
Third, decide how the consequence will be tested. A group may need to confirm that its intended ships, margins and working habits remain suitable. The test belongs to the group and its present plan. It should not be disguised as a timeless rule for every reader.
No numerical Effect table is needed for this decision model. Values would require a separate current data review, and a complete list would invite the reader to optimise before understanding the work. Explorer needs the Effect to remain visible as an operating condition, not to become the identity of the system.
The result can be recorded in plain language. Effect confirmed; interaction with the planned scanning capability accepted after testing. Or: Effect confirmed; consequence for the required work remains Unknown, so no commitment depends on it yet.
Such a record is less impressive than a colour-coded ranking. It is more useful to the next person because the line between property, interpretation and decision remains intact.
Existing Infrastructure
The second candidate appears easier because a Structure is already present. Current use by the group is a real advantage. It is not the same as control.
Upwell Structure Profiles define which services are made available to other players. Access Lists determine who can use those services. A visible Structure, an advertised service and a character’s actual access are therefore separate facts. Each can be true while another is false or later changes.
A guest arrangement should be read as a dependency on another owner. Which capabilities are available now? Who controls the Profile and Access Lists? How will a change be noticed? What work stops if access is removed? Which assets can be recovered without that access? The answers determine whether guest use supports a trial, routine work or only a temporary convenience.
The owner carries a different set of commitments. Deployment of an Upwell Structure is limited to members of a player-owned corporation with the appropriate role. The current official deployment rules also exclude Shattered Wormhole Systems and Thera. These boundaries matter during selection because not every candidate permits the group to replace guest access with its own Upwell Structure.
This is not a reason to prefer ownership automatically. Ownership creates control over some decisions and responsibility for many more. The Structure, its services, inputs, states, access design and eventual removal all become commitments. Chapter 8 will examine that care directly. For now, it is enough to refuse the idea that ownership converts uncertainty into permanence.
Guest use and ownership can both support a valid Home. They fail differently.
Guest capability may disappear because another owner changes access, services or the arrangement itself. The guest can reduce that dependency by limiting what is stored, preserving an alternative and defining how quickly work can stop. The owner may control access yet lose capability through neglected inputs, unclear responsibility or infrastructure state. Control moves the dependency; it cannot remove it.
Existing infrastructure must also be read service by service. The Structure’s presence says that the object exists. That presence cannot prove that every desired service is offered, that the current character can use it or that it will remain available for the duration of the plan. Confirm only the capabilities the purpose requires, and attach the observation to time.
The two candidates now look less alike. One asks the group to carry more of the infrastructure commitment itself. The other allows a lighter beginning but places a critical decision in someone else’s hands. The relevant difference is not independence versus dependence. It is which dependency the group can see, limit and end.
Ease of beginning should not be confused with a small commitment. Guest access can remove the immediate work of deployment while encouraging assets and routines to gather behind a permission the group cannot preserve. Ownership can demand more preparation while making the controlling decisions clearer. Either arrangement becomes heavy when the assets accumulated behind it can no longer be removed on the group’s own timetable.
For that reason, access belongs in the selection record even when it appears uncomplicated. Note the capability actually used, the party controlling it, the latest confirmation and the action available if it changes. The record does not make another owner predictable. It prevents convenience from being mistaken for control.
Accept the Tradeoff
After the properties are separated, neither candidate wins every column.
The first system fits the planned work and gives the group more control over required capability. Its observed routes have made replacement slower and more laborious. Choosing it means accepting transport effort and limiting what can become irreplaceable between useful Connections.
The second allows the group to begin with less infrastructure of its own. Current guest access supports the required services. Choosing it means accepting that another corporation controls a capability on which the work depends. The chosen arrangement must allow the group to pause, recover or leave if that access changes.
There is no calculation that makes those costs identical. The decision depends on which failure the purpose can tolerate and which burden the group can actually carry. A group with little time for infrastructure may reasonably prefer limited guest use. A group whose work cannot tolerate uncertain access may prefer the transport burden. Reverse the purpose, and the same systems may reverse their order.
Treat the choice as a bounded hypothesis.
State the purpose: what work, for whom and for how long. Record the checked properties: Class, Effect, observed Connections and required infrastructure. Name the accepted tradeoff in one sentence. Then define what evidence will cause review.
The decision record should also preserve rejected interpretations. Class was recorded but was not used as an income ranking. Current guest access was confirmed but was not treated as permanent. Observed Connections informed the trial but were not promoted into guaranteed routes. These limits protect the decision from becoming more certain when retold.
The review condition may be repeated failure to support necessary movement, an Effect interaction that makes the required work unsuitable, changed access, an unavailable service or a workload the group cannot maintain. It should be observable. We no longer like the system is difficult to act upon. The replacement route has repeatedly exceeded the delay our trial permits shows which assumption failed.
Finally, limit the first commitment. Move only the assets needed to test the purpose. Avoid building several activities around the candidate before the first one has proved sustainable. Set a date or event for review, and preserve a way to end the trial without requiring the system to become convenient at the moment of departure.
This approach does not guarantee that the better candidate has been chosen. It makes the reason for choosing visible. When conditions change, the group can revise a recorded hypothesis instead of defending an identity.
Home is not the system that asks for nothing. No such system exists. Home is a system whose required tradeoffs have been observed closely enough to accept, and whose remaining Unknowns have been kept small enough to survive being wrong.
Field Principle
Choose purpose before property.
Record Class, Effect, Connections and infrastructure as separate layers. Let each become favourable or unfavourable only in relation to the work, people, time and exit the group has named. Treat current access as current, repeated routes as observed history and ownership as responsibility rather than safety.
The decision to remain should be a bounded hypothesis with review conditions, not a declaration that the ideal system has been found.
Once Home has been chosen, the next question is how much can be tied to that hypothesis. Chapter 3 turns from selection to the weight of assets, replacement and concentrated loss.