The route from Chapter 6 is confirmed before the movement begins.
At the destination, the first Character docks in the expected Structure. They can see their ships and personal inventory, but the Service required for the next step does not appear available to them. A second Character belongs to the owning Corporation and carries the Factory Manager role. They can inspect the relevant corporation job, yet the material needed to continue cannot be removed from its hangar division.
Nothing in either scene is necessarily broken.
Docking did not promise access to every Service. A Corporation role did not promise access to every item. Ownership of the Structure did not make every member its administrator, and visibility of a job did not make the inputs usable.
The route answered where the pilots could travel. It could not answer what their Characters could do after arrival.
That capability must be read as a path. Ownership, visibility, use and administration meet different systems before an action becomes real. The group can understand the failure only by keeping those questions separate long enough to find the missing condition.
Four Separate Questions
Begin with ownership: who owns the Structure, asset or information?
Ownership identifies the person or Corporation whose systems contain the thing. It may indicate who can ultimately assign authority. Ownership alone cannot prove that the Character standing on Grid holds that authority now.
The Structure in the opening scene belongs to a Corporation. That fact says nothing by itself about which member can edit its Profile, who can use a particular Service or who can remove material from a corporation hangar. A guest can sometimes perform useful work in a Structure they do not own. An owner’s member can be unable to complete the same work.
The second question is visibility: what can this Character see?
A visible Structure, Service, job or inventory division gives the Character information. The information may be enough to report a condition. Such a view does not always provide the right to use or change what is visible. Conversely, a Character may hold a narrow ability that does not include a convenient view of all surrounding information.
The third question is use: can the Character receive the Service or handle the material required for the action?
Use can depend on a Structure Profile, one or more Access Lists, Corporation hangar permissions and the state of the Service itself. These conditions do not merge because they happen in one Structure. Passing one condition can still leave the Character stopped at the next.
The fourth question is administration: who can alter the governing state?
An administrator may edit a Profile or manage a corporation job without being the pilot expected to perform the work. The working pilot may use the Service without holding the authority to change its audience. Administration carries the ability to affect other users and should not be inferred merely because a Character completed one task.
Material deserves its own place inside this model. A Service can be visible and usable while its input remains in a division the Character cannot query or take from. Likewise, access to material does not establish access to the Service that will transform it.
Only after those layers are known should the group ask about capability. The real question is not whether one permission exists. Capability depends on whether the intended Character, at the intended place and time, can follow the whole path from recognising the task to completing it with the required ship, material and Service.
The first Character in the opening scene therefore has confirmed docking and some personal visibility. The second has confirmed job-management authority. Neither result answers the next action. The missing conditions are different, even though both Characters describe the same outcome: I cannot continue.
Profiles Expose Services
A Structure Profile defines which Services are available to other players. Access Lists assigned within that Profile define who can access each Service.
That separation is the first key to the docked guest’s problem. Docking is one Service governed through the Profile. The Service needed after docking can have a different assignment. Passing through the first audience does not place the Character inside every other audience.
One or more Access Lists can be assigned independently to each Service within a Profile. The same Profile can be used by multiple Structures, and a change to it affects all Structures using it. A Profile is therefore not merely a label attached to one hull. The Profile acts as a shared publication of service access whose scope must be understood before it is changed.
The Profile does not make a Service physically functional. It defines availability to users. Chapter 8 will separate that offer from the Service Module, Fuel and state needed to deliver the capability. For now, the important boundary is that an access configuration can explain why two Characters receive different results from the same Structure.
The current Profile can be changed by the owning Corporation’s CEO, Directors and members with the Station Manager role. That authority belongs to administration. Its scope is broader than the guest’s ability to dock or use one Service. The working pilot should not receive it merely to solve an unclear access path.
The administrator also needs to identify the correct scope. Editing a Profile used by several Structures can alter access beyond the Structure in the opening scene. A local problem should not trigger a shared change until the owner knows which Profile, Service and Access Lists produce the result.
This makes a precise report valuable. The Service is missing confuses several possibilities. This Character can dock but cannot access the required Service in this Structure at this time identifies the tested path. An owner can compare the Profile assignment, the Service’s Access Lists and the Service’s operational state without treating one observation as a universal failure.
Profiles therefore expose a relationship, not a guarantee. They link a Structure’s offered Services to audiences. The user still needs to be selected by those audiences, hold any separate material rights and arrive while the infrastructure can actually perform the work.
Lists Select People
Access Lists are lists of people used with Profiles to control access to Services in an Upwell Structure.
An Access List can include individual Characters, Corporations, Alliances or Everyone. The relevant entry can allow or block an individual Character. The result does not follow the broadest entity type shown on the page. Within one list, the most granular applicable setting governs: Alliance is more specific than Everyone, Corporation more specific than Alliance, and Character more specific than Corporation.
Suppose the guest’s Corporation is allowed to use the required Service, but the guest has a specific blocked Character entry in the same Access List. The specific Character setting governs that list. The Character can still belong to the Corporation and can still have docking through another assignment. The Service result is not a contradiction.
Multiple Access Lists add another boundary. When several lists are assigned to the same Service, the applicable result from each list is combined. A grant through one assigned list can therefore allow access even if another assigned list blocks the Character. Reading only the list containing the block would not explain the Service’s final audience.
This combination should be understood before anyone attempts to repair access. Adding a Character to another list may produce a grant while leaving the original disagreement in place. Removing a Corporation from one list may have no effect because a second list still allows it. The tested Service and all lists assigned to it form the relevant path.
Access List administration is also separate from Structure ownership. Only Admins or Managers of an Access List can see and modify the lists they manage. A Station Manager who can change a Structure Profile does not thereby prove administrative control over every Access List available for assignment. The group must identify who can change each layer instead of searching for one role that sounds senior enough.
The model does not justify broad access. Nor is it a security doctrine for finding disloyal members. The rule is interpretive. Begin with the intended Character and Service. Follow the Profile to every assigned Access List. Apply the specific entries and their combination. Stop when the observable result is explained or return the unexplained condition to Unknown.
The failed Service path can be investigated without changing the guest’s ownership. The owner checks the Service’s Profile path. The guest tests the result through the same Character. Access is confirmed only when the intended path works, not when an administrator sees a plausible name on a list.
Roles Enable Action
Corporation Roles provide particular abilities. They are not a general level of trust, and their names cannot stand in for the action path.
The second Character carries Factory Manager. That role allows management of Corporation jobs, including jobs installed by other members. It also allows the listing and use of Corporation-owned blueprints in the relevant Industry view independently of corporation hangar access.
The same official description preserves the missing boundary: proper Take access to the relevant hangar or container is still required for a job that needs input material. Job authority and material authority are not the same thing.
Corporation hangar divisions distinguish several access abilities. Query allows the Character to view the contents of the relevant hangar but does not allow removal. Take allows removal of items and opening containers in that hangar, but it does not allow the container itself to be removed. Container Take governs removal of containers. The relevant location context of the role must also match where the material is held.
These distinctions explain several outcomes that otherwise appear arbitrary. One Character may see the input and be unable to take it. Another can hold Take without Query and lack a normal inventory listing, while an Industry job can still verify and take necessary material from the permitted hangar. A third can remove items from a container but not remove the container itself.
The Chapter does not need every Corporation role to make the point. It needs only the abilities touched by the scene. Factory Manager answers who may manage the job. Query, Take and, if the task moves the container itself, Container Take answer how the material can be seen and handled. The Profile and Access Lists answer whether the Structure Service is available to the Character.
Station Manager belongs to another path. It provides management options for Upwell Structures owned by the Corporation, including Profiles. The role cannot replace the material permissions required for the job. Granting it to the worker would add administrative authority without necessarily fixing the missing input.
Reverse the opening task from its result. The Character must be able to manage the Corporation job, access the correct Service, identify the required material and allow the job to use that material. The existing role confirms only the first part. The failure no longer looks like an unreliable UI or a broken Structure. The visible break lies between two legitimate permission layers.
Guests Depend Differently
Guests can have real capability without owning its foundation.
The first Character docks, stores personal ships and may be able to use some Services. Those actions are not imaginary or second-class. They support real work. Their dependency is different because another owner controls the Profile, Access Lists, Service Modules and Structure state on which the work rests.
Docking permission is also a prerequisite for ship tethering at an Upwell Structure. That relationship does not turn permission into a safety promise. An active tether has specific effects, while several actions and states can prevent or break tethering. The pilot must observe the active condition rather than infer it from the fact that docking was available earlier.
The same principle applies inside the Structure. A guest who used a Service yesterday has evidence of yesterday’s access and operational state. The owner can change the Profile or an assigned Access List. The Service can enter a different state. A guest plan should depend on a current test when the consequence justifies it.
Owners carry dependencies too. A Corporation may own the hull while the only person able to modify a necessary Access List is unavailable. Material may be owned by the Corporation while the intended operator lacks the matching hangar rights. Ownership centralises ultimate control without guaranteeing that the required people and permissions meet at the required time.
This makes fallback different for owners and guests. An owner can assign a Steward to maintain the access and infrastructure path, subject to the Corporation’s chosen authority. A guest cannot assume that change. They can confirm the offered capability, preserve alternatives and limit the work that depends on someone else’s configuration.
None of this makes guest access inherently unsuitable. It makes its revocable and externally managed nature part of the Baseline. If the work can pause or move when access changes, the dependency may be acceptable. If one unavailable Service would strand irreplaceable capability or open commitments, the plan needs a different boundary before work begins.
The docked guest in the opening scene should not ask to own the Structure. The necessary answer is whether the required Service is intentionally available to their Character, who can correct an unintended result and what happens to the planned work if access remains absent.
Test the Path
Permission names are evidence about configuration. A completed action is evidence about capability.
For a critical task, test the path with the actual Character expected to perform it. Begin at the result and move backwards. Confirm that the Character can recognise the task, reach the Service and use the required material under the relevant Corporation rights. Then establish whether the correct ship or other capability is present. A separate owner must hold the authority to resolve a failed layer without changing unrelated access.
Place and time belong to the test. A permission associated with the wrong hangar context cannot carry material held here. A Service result from another Structure cannot confirm the assigned Profile at this one. Yesterday’s successful action remains useful history, but it cannot silently replace a current check when the work now carries a larger consequence. These boundaries keep a familiar Character name from making several different paths look like one permission.
The test should be proportionate. It need not consume valuable material or start an irreversible job merely to prove a concept. The Character can inspect the relevant views, confirm the Service appears, verify the intended material path and stop before commitment. If the action cannot be tested safely, record which parts were directly observed and which remain inferred.
Use the Character, not an administrator’s preview, as the Source for user capability. An owner may see that a Profile contains an Access List. Only the intended Character’s result confirms how the combined path presently resolves for that Character.
Follow the guest’s path in the opening scene. The intended result is not merely to enter the Structure. The Character must dock, find the required Service and reach the point at which the planned work can begin. Docking succeeds, so that part of the path receives a current Observation. The absent Service result stops the test before any material is committed.
An owner then reads the configuration from the same result backwards. Which Profile is assigned to this Structure? Which Access Lists are assigned to this Service? Where does the guest resolve within each list, and how do the list results combine? The investigation also preserves a separate question for Chapter 8: is the Service itself able to operate?
Suppose the owner finds the guest’s Corporation in an allowed list. That is not yet a reason to close the issue. A more specific Character entry may govern within the same list. Another list may contribute a separate result. The owner has identified relevant configuration, while the guest still provides the final evidence about access.
After a deliberate correction, the guest repeats only the failed portion. A new attempt can show that the Service is now available to the intended Character. That result proves neither that every member of the guest’s Corporation has the same access nor that all Services are available. It also cannot promise that the access will remain unchanged. The confirmation stays attached to this Character and purpose.
The Corporation member’s path begins elsewhere. They can see and manage the job, so Factory Manager is already evidenced for that part of the task. The failure occurs when the work meets its input. The member confirms the relevant hangar division and what the interface allows them to view or remove.
If the input is invisible, the group examines Query in the correct location context. If the input is visible but cannot be used as required, Take becomes relevant. Moving the container itself raises the narrower question of Container Take. Each test follows the object the task actually needs; none begins by granting a bundle of roles in the hope that one will work.
This method protects future handovers. The record can say that one guest’s Service path was confirmed and one Corporation member’s material path was corrected. The next shift inherits two bounded observations rather than the misleading conclusion that access is fixed.
The reverse is also true. A successful user test does not confirm the owner’s ability to alter the path later. Administration should be tested through the person assigned to maintain it. The two Sources answer different questions.
Record the test with its time and purpose. Access checked ages badly because it omits the Character, Service, material and action. The named Character could see the required Service and material path before this job can support the stated work without claiming permanent access.
Two bounded results now remain. Testing follows the guest’s Service path through the Profile and assigned Access Lists until the intended Character can use it or the work is postponed. The Corporation member’s job path is tested through Factory Manager and the relevant hangar access until the input can be used, or another authorised operator accepts the task.
No one needed to grant broad authority on intuition. No role name was treated as proof of readiness. Each missing capability was found at the layer that could actually supply it.
Field Principle
Access is not ownership. Seeing something does not grant permission to use it. A role is not the completed action, and administration is not readiness.
Read capability as a path through the intended Character, place, Service, material and authority. Let Profiles describe offered Services, Access Lists select their audiences and Corporation Roles supply only the abilities they actually name. Confirm the result through the Character who must act.
The route from Chapter 6 brought both pilots to the correct Structure. Chapter 7 explains why arrival still left them unable to work. Once the permission paths are corrected, another dependency remains outside every Access List and role.
Full authorisation can still lead to a Service that has no Fuel, is offline or no longer supports the surrounding work. Rights enable the attempt; they do not keep the infrastructure functional.
Chapter 8 follows the Service itself.